上一节我们描述了问题的现象，但是留下一个问题，就是Pod里的容器个数为什么是2。虽然每个Pod本质上至少有两个容器，一个是占位符容器pause，另一个是真正的工作容器，但是我们在使用kubectl命令获取Pod列表的时候，Ready列是不包括pause容器的。
这里的另外一个容器，其实就是服务网格的核心概念sidecar。其实把这个容器叫作sidecar，某种意义上是不能反映这个容器的本质的。从本质上来说，sidecar容器是反向代理，如图17-2所示，它本来是一个Pod访问其他服务后端Pod的负载均衡。
图17-2 服务网格局部视角
然而，当我们让集群中的每一个Pod都“随身”携带一个反向代理的时候，Pod和反向代理就变成了服务网格，正如图17-3这张经典大图所示。
图17-3 服务网格全局视角
所以sidecar模式其实是“自带通信员”模式。有趣的是，在我们把sidecar和Pod绑定在一起的时候，sidecar在出流量转发时扮演着反向代理的角色，而在入流量接收的时候，可以做一些超过反向代理职责的一些事情。
Istio在Kubernetes基础上实现了服务网格，Isito使用的sidecar容器就是17.1节提到的没有就绪的容器。所以这个问题其实就是，服务网格内部所有的sidecar容器都没有就绪。