6. Pod资源对象

# 一、Pod概念的产生

1. 在一个真正的操作系统里，进程并不是“孤苦伶仃”地独自运行的，而是以进程组的方式，“有原则地”组织在一起。
2. 而Kubernetes项目所做的，其实就是将“进程组”的概念映射到了容器技术中，并使其成为了这个云计算“操作系统”里的“一等公民”。
3. 分别运行于各自容器的进程之间无法实现基于IPC的通信机制，此时，容器间的隔离机制对于依赖于此类通信方式的进程来说却又成了阻碍。Pod资源抽象正是用来解决此类问题

# 二、Pod特点

1. 在 Kubernetes项目里， Pod的实现需要使用一个中间容器，这个容器叫作Infra容器。在这个 Pod中，Infra容器永远都是第一个被创建的容器，而其他用户定义的容器，则通过 Join Network Namespace的方式，与 Infra容器关联在一起。

![未命名图片.png](/media/202406/4.6.15262253_image1.png)

2. 对于 Pod 里的容器 A 和容器 B 来说：
- 它们可以直接使用 localhost 进行通信；
- 它们看到的网络设备跟 Infra 容器看到的完全一样；
- 一个 Pod 只有一个 IP 地址，也就是这个 Pod 的 Network Namespace 对应的 IP地址；
- 其他的所有网络资源，都是一个 Pod 一份，并且被该 Pod 中的所有容器共享；
- Pod 的生命周期只跟 Infra 容器一致，而与容器 A 和 B 无关。
3. 把整个虚拟机想象成为一个 Pod，把这些进程分别做成容器镜像，把有顺序关系的容器，定义为 Init Container。这才是更加合理的、松耦合的容器编排诀窍，也是从传统应用架构，到“微服务架构”最自然的过渡方式。

# 三、Pod模型

1. Sidecar pattern（边车模型或跨斗模型）：即为Pod的主应用容器提供协同的辅助应用容器，每个应用独立运行

- 最为典型的代表是将主应用容器中的日志使用agent收集至日志服务器中时，可以将agent运行为辅助应用容器，即sidecar。另一个典型的应用是为主应用容器中的database server启用本地缓存。

![未命名图片.png](/media/202406/4.6.15262253_image2.png)

2. Ambassador pattern（大使模型）：即为远程服务创建一个本地代理，代理应用运行于容器中，主容器中的应用通过代理容器访问远程服务

- 一个典型的使用示例是主应用容器中的进程访问“一主多从”模型的远程Redis应用时，可在当前Pod容器中为Redis服务创建一个Ambassador container，主应用容器中的进程直接通过localhost接口访问Ambassador container即可。即便是Redis主从集群架构发生变动时，也仅需要将Ambassador container加以修改即可，主应用容器无须对此做出任何反应。

![未命名图片.png](/media/202406/4.6.15262253_image3.png)

3. Adapter pattern（适配器模型）：此种模型一般用于将主应用容器中的内容进行标准化输出，

- 例如，日志数据或指标数据的输出，这有助于调用者统一接收数据的接口，另外，某应用滚动升级后的版本不兼容旧的版本时，其报告信息的格式也存在不兼容的可能性，使用Adapter container有助于避免那些调用此报告数据的应用发生错误。

![未命名图片.png](/media/202406/4.6.15262253_image4.png)

4. Kubernetes系统的Pod资源对象用于运行单个容器化应用，此应用称为Pod对象的主容器（main container），同时Pod也能容纳多个容器，不过额外的容器一般工作为Sidecar模型，用于辅助主容器完成工作职能。

# 四、yaml文件Pod与Container对象

1. 基本原则
- 凡是调度、网络、存储，以及安全相关的属性，基本上是 Pod 级别的，凡是跟容器的Linux Namespace 相关的属性，也一定是 Pod 级别的，凡是 Pod中的容器要共享宿主机的 Namespace，也一定是 Pod 级别的定义
2. 应用举例
- NodeSelector：供用户将 Pod 与 Node 进行绑定
- HostAliases：定义了 Pod 的 hosts 文件（比如 /etc/hosts）里的内容
- shareProcessNamespace=true：这个 Pod 里的容器要共享 PID Namespace