为什么需要Pod

为什么需要Pod

pod 是K8s种最小的API对象，更专业的说Pod是K8s项目中最小的原子调度单元。容器的本质是进程，那么K8s的本质可以理解为操作系统。

在linux操作系统中执行

$ pstree -g

这条命令可以看到系统中正在运行的进程的树状结构：

systemd(1)-+-accounts-daemon(1984)-+-{gdbus}(1984)
           | `-{gmain}(1984)
           |-acpid(2044)
          ...      
           |-lxcfs(1936)-+-{lxcfs}(1936)
           | `-{lxcfs}(1936)
           |-mdadm(2135)
           |-ntpd(2358)
           |-polkitd(2128)-+-{gdbus}(2128)
           | `-{gmain}(2128)
           |-rsyslogd(1632)-+-{in:imklog}(1632)
           |  |-{in:imuxsock) S 1(1632)
           | `-{rs:main Q:Reg}(1632)
           |-snapd(1942)-+-{snapd}(1942)
           |  |-{snapd}(1942)
           |  |-{snapd}(1942)
           |  |-{snapd}(1942)
           |  |-{snapd}(1942)

可以看到系统中进程不是单独存在的，进程间存在依赖关系以进程组的方式组织在一起。K8s要做的就是将”进程组“的概念映射到容器中。

以rsyslogd为例子，已知rsyslogd由三个进程组成：一个imklog模块，imuxsock模块，main主进程。这三个进程一定运行在同一台机器上，否则他们之间无法通过socket通信。由于受限于容器的”单进程模型“，这三个模块被分别制作成三个不同的容器，假设他们设置的内存配额都是1GB，K8s集群上有两个节点：node-1上有3GB的可用内存，node-2上有2.5GB可用内存。有可能就会出现三个容器都被调度到node-2上，就会引发问题。

在K8s中，这样的问题可以很好的被解决：Pod 是 Kubernetes 里的原子调度单位。这就意味着，Kubernetes 项目的调度器，是统一按照 Pod 而非容器的资源需求进行计算的。以上的三个容器在K8s中是一个Pod的概念，所以不会出现调度的问题。

Pod 在 Kubernetes 项目里还有更重要的意义，那就是：”容器设计模式。

Pod的实现原理

关于 Pod 最重要的一个事实是：它只是一个逻辑概念。
Pod其实是一组共享某些资源的容器，具体说就是Pod里的所有容器，共享同一个Network Namespace，并且可以声明共享同一个Volume。

在 Kubernetes 项目里，Pod 的实现需要使用一个中间容器，这个容器叫作 Infra 容器。在这个 Pod 中，Infra 容器永远都是第一个被创建的容器，而其他用户定义的容器，则通过 Join Network Namespace 的方式，与 Infra 容器关联在一起。这样的组织关系，可以用下面这样一个示意图来表达：

对于 Pod 里的容器 A 和容器 B 来说：

• 它们可以直接使用 localhost 进行通信；
• 它们看到的网络设备跟 Infra 容器看到的完全一样；
• 一个 Pod 只有一个 IP 地址，也就是这个 Pod 的 Network Namespace 对应的 IP 地址；
• 当然，其他的所有网络资源，都是一个 Pod 一份，并且被该 Pod 中的所有容器共享；
• Pod 的生命周期只跟 Infra 容器一致，而与容器 A 和 B 无关。