为什么需要 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 直接通信的。
- 适配器容器:将业务容器暴露出来的接口转换为另一种格式。