问题是这样的：用户在自己的测试集群里安装了Istio，并依照官方文档部署bookinfo应用。部署之后，用户执行kubectl get pods命令，发现所有的Pod都只有二分之一个容器是Ready的。
如果从来都没有注意过Ready这一列的话，我们大概会有两个疑惑：“2”在这里是什么意思？“1/2”到底意味着什么？
简单来讲，这里的Ready列，给出的是每个Pod内部容器的readiness，即就绪状态。每个集群节点上的Kubelet会根据容器本身readiness规则的定义，分别以tcp、http或exec的方式，来确认对应容器的readiness情况。
更具体一点，Kubelet作为运行在每个节点上的进程，以tcp/http的方式（从节点网络命名空间到Pod网络命名空间）访问容器定义的接口，或者在容器的命名空间里执行exec定义的命令，来确定容器是否就绪，如图17-1所示。
这里的“2”说明这些Pod里都有两个容器，“1/2”则表示每个Pod里只有一个容器是就绪的，即通过readiness测试的。关于“2”这一点，我们下一节会深入讲，这里我们先看一下，为什么所有的Pod里都有一个容器没有就绪。
使用kubectl工具拉取第一个details pod的编排模板，可以看到这个Pod里的两个容器只有一个定义了readiness probe。对于未定义readiness probe的容器，Kubelet认为，只要容器里的进程开始运行，容器就进入就绪状态了。所以1/2个就绪Pod意味着，有定义了readiness probe的容器没有通过Kubelet的测试。
图17-1 Kubelet健康检查机制
没有通过readiness probe测试的是istio-proxy这个容器。它的readiness probe规则定义如下。
我们登录这个Pod所在的节点，用curl工具来模拟Kubelet访问下面的URI，测试istio-proxy的就绪状态。
