k8s 自身原理 5

我们知道容器是通过 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 ，这是为什么呢？可以思考一下…

今天就到这里，学习所得，若有偏差，还请斧正

欢迎点赞，关注，收藏

朋友们，你的支持和鼓励，是我坚持分享，提高质量的动力

好了，本次就到这里

技术是开放的，我们的心态，更应是开放的。拥抱变化，向阳而生，努力向前行。

我是小魔童哪吒，欢迎点赞关注收藏，下次见~

本作品采用《CC 协议》，转载必须注明作者和本文链接