Pod和容器设计模式

为什么需要Pod

一些应用的实现是需要多个进程配合完成的，由于容器实际上是一个“单进程”模型，如果在容器里启动多个进程会存在进程管理的难题。在Kubernetes里面，实际上会被定义为一个拥有四个容器的Pod。

Pod相当于进程组

Kubernetes 是云时代的操作系统，Pod相当于进程组，容器就是一个个进程。Pod是Kubernetes分配资源的一个单位，因为里面的容器要共享某些资源，所以Pod也是Kubernetes的原子调度单位。

Pod是原子调度单位

为什么Pod必须是Kubernetes的原子调度单位，下面一个例子解释：

具有超亲密关系的容器的部署在ks8中会通过Pod去解决，对于超亲密关系的描述如下：

• 两个进程之间会发生文件交换，前面提到的例子就是这样，一个写日志，一个读日志；
• 两个进程之间需要通过localhost或者说是本地的Socket去进行通信，这种本地通信也是超亲密关系；
• 这两个容器或者是微服务之间，需要发生非常频繁的 RPC 调用，出于性能的考虑，也希望它们是超亲密关系；
• 两个容器或者是应用，它们需要共享某些 Linux Namespace。最简单常见的一个例子，就是我有一个容器需要加入另一个容器的Network Namespace。这样我就能看到另一个容器的网络设备，和它的网络信

息。

Pod的实现机制

Pod要解决的问题：容器之间原本是被Linux Namespace和cgroups隔开的，所以现在实际要解决的是怎么去打破这个隔离，然后共享某些事情和某些信息。主要是解决网络和存储。

共享网络

在每个 Pod 里，额外起一个Infra container小容器来共享整个 Pod 的 Network Namespace。由于有了这样一个 Infra container 之后，其他所有容器都会通过 Join Network Namespace 的方式加入到Infra container的Network Namespace中。

Infra container是一个非常小的镜像，大概100~200KB 左右，是一个汇编语言写的、永远处于暂停状态的容器。

整个Pod的生命周期和Infra容器一致，与其他容器无关。

共享存储

Pod中的容器声明挂载同一个volume，通过这种方式实现存储共享。

容器设计模式

容器设计模式Sidecar：在Pod定义一些专门的容器，来执行主业务容器所需要的一些辅助工作。优势是将辅助功能同主业务容器解耦，实现独立发布和能力重用。一些常用的场景如下：

• 使用Init Container在主业务容器启动前，将一些必要的文件或其他资源拷贝到共享的数据卷中，主业务容器启动后直接就可以从数据卷中读取和使用。
• 应用日志收集，在Pod中启动一个Sidecar容器从共享的Volume中读取日志，然后存到远程存储里面。

• 代理容器：单独写一个 Proxy容器，用来处理对接外部的服务集群，它对外暴露出来只有一个 IP 地址就可以了。所以接下来，业务容器主要访问Proxy，然后由 Proxy 去连接这些服务集群， 这里的关键在于 Pod 里面多个容器是通过 localhost 直接通信的。

• 适配器容器：将业务容器暴露出来的接口转换为另一种格式。