我们知道容器是通过 pod 来承载的，我们在 k8s 中，服务都是跑在 pod 里面的，pod 里面可以跑 1 个容器，或者跑多个容器，那么咱们 pod 里面跑 1 个服务容器，咱真的就以为里面就只有这样个容器吗？
pod 到底是个啥？
假如咱们 pod 里面只运行我们的一个服务的时候，也就是里面只运行一个容器，那么实际上里面是有几个容器呢？
是有两个的，默认会有一个基础容器，提供 Linux 命名空间
- 一个我们自己的容器
- 一个附加容器
这个附加容器难道就只提供命名空间？
不不不，这个附加容器就干一件事，就是保存这个 pod 的所有容器的命名空间
画一个简图来形象的说明一下：
最开始我们认为的是图中的上半部分，那么实际上容器 A 共享的命名空间是保存在哪里的呢？就是保存在基础容器里面的
哪怕我们现在再加一个容器 B，这个容器 B 也是共享这个基础容器的 Linux 命名空间的
那么基础容器的生命周期是多少呢？
上述有说到一个 pod 里面的所有容器都会共享这个基础容器保存的命名空间
咱们自己加入的容器，做服务，可能会有挂的时候，也会有重启的时候，放咱们的服务容器重启启动时，还是需要之前的 Linux 命名空间，这个时候，就可以找基础容器获取了
只要 pod 还活着，基础容器就会一直陪着它， pod 不挂，基础容器不消失
如果手动关闭了这个重要的基础容器，那么节点里面的 关键角色之一 kubelet 就会监控到异常信息，就会马上重新建立一个基础容器
pod 和 pod 之间通信会进行网络地址转换吗？
首先说一下结论：
- pod 和 pod 之间通信，是没有进行网络地址转换 NAT 的
- pod 和 node 之间通信，也没有进行网络地址转换 NAT
就比如说在 节点 1 里面有一个 pod1，ip 是 1.1.1.1 ， 节点 2 里面有一个 pod 2， ip：1.1.1.2
当 pod 1 中的容器需要访问 pod 2 的时候， 节点 1 出去的包，源 ip 是 pod 1 的 ip，目的 ip 是 pod 2 的 ip，同样，到 pod 2 收到包的时候也是这样的，并没有经过 NAT
pod 和 node 通信也是这样的逻辑
我们知道 pod 容器实际上是运行在 worker 节点上的， 那么我们要访问咱们运行在 worker 节点上的 pod ，但是咱们的主控节点是 master
这个时候，如果我们外面的网络，需要访问上面这个 pod 节点的容器，那么这个时候，外面的网络需要访问 master 的 ip 还是 worker 的 ip 呢？
需要访问 worker 的 ip ，这是为什么呢？可以思考一下...
