在上一节中我们看到，Istio中的每个Pod，都自带了反向代理sidecar。我们遇到的问题是，所有的sidecar都没有就绪。我们也看到readiness probe定义的，判断sidecar容器就绪的方式就是访问下面这个接口。
接下来，我们深入理解一下Pod，以及其sidecar的组成和原理。在服务网格里，一个Pod内部除了本身处理业务的容器之外，还有istio-proxy这个sidecar容器。正常情况下，istio-proxy会启动两个进程，pilot-agent和Envoy。
如图17-4所示，Envoy是实际上负责流量管理等功能的代理，从业务容器出、入的数据流，都必须经过Envoy；而pilot-agent负责维护Envoy的静态配置，并且管理Envoy的生命周期。这里的动态配置部分，我们在下一节中会展开来讲。
图17-4 代理与代理生命周期管理
我们可以使用下面的命令进入Pod的istio-proxy容器做进一步排查。这里的一个小技巧是，我们可以以用户1337身份，使用特权模式进入istio-proxy容器，如此就可以使用iptables等只能在特权模式下运行的命令。
这里的用户1337，其实是sidecar镜像里定义的一个同名用户istio-proxy，默认sidecar容器使用这个用户。如果我们在以上命令中不使用用户选项u，则特权模式实际上是赋予root用户的，所以我们在进入容器之后，需切换为root用户执行特权命令。
进入容器之后，我们使用netstat命令查看监听，我们会发现，监听readiness probe端口15020的，其实是pilot-agent进程。
我们在istio-proxy内部访问readiness probe接口，一样会得到“503”的错误。