Kubernetes Pod及容器设计模式

Pod是Kubernetes中最小的调度单元，Pod与容器的比较：

　　容器 = 单个进程

　　Pod = 多个容器 = 进程组

Kubernetes中最小的原子调度单位是Pod，为什么Pod必须是原子调度单位？因为多个容器需要紧密协作。

紧密协作的场景：

　　两个进程之间发生文件交换，一个写日志，一个读取日志。

　　两个进程需要通过localhost通讯。

　　两个容器或者微服务之间需要发生非常频繁的RPC调用，处于性能考虑需要是紧密协作。

　　两个容器需要共享某些Linux NameSpace，例如 network namespace。

容器之间原本是通过Linux NameSpace和Cgroups隔离开的，Pod需要解决的就是如何打破容器之间的隔离。

Pod设计需要解决2个核心问题：

网络共享

　　Infra Container (pause容器) 将自己的 Network Namespace 共享出来

　　其他 Container Join To Infra Container Network Namespace

　　整个Pod生命周期跟Infra Container一致，与Pod中其他Container无关

存储共享

　　Volume是Pod Level，不跟具体某个Container关联。

容器设计模式

InitContainer

　　比正常的Container优先启动，执行完成任务后立即退出。

Sidecar

　　辅助Container

　　例如Monitor, Operation，Log，Proxy，Adapter等Container

Pod 内容器的启动顺序按照：初始化容器 -> Sidecar 容器 -> 业务容器 的顺序依次启动。

Pod与容器的设计模式本质是： 解耦 -> 每个Container单个进程 重用 ->网络 与 存储

参考文档 https://zhuanlan.zhihu.com/p/83220717