4.1 容器与 Pod 资源对象

现代的容器技术被设计用来运行单个进程（包括子进程）时，该进程在容器中PID名称空间中的进程号为1，可直接接受并处理信号，于是，在此类进程终止时，容器即终止退出。若要在一个容器内运行多个进程，则需要为这些进程提供一个类似与Linux操作系统init进程的管控类进程，以树状结构完成多进程的生命周期管理，例如，崩溃后回收相应的系统资源等。单容器运行多进程时，通常还需要日志进程来管理这些进程的日志，例如，将它们分别保存于不同的目标日志文件等，否则用户就不得不手动来分拣日志信息。因此，绝大多数场景中都应该于一个容器中仅运行一个进程，它将日志信息直接输出至容器的标准输出，支持用户直接使用命令（kubectl logs）进程获取，这也是Docker 或 Kubernetes 使用容器的标准方式。

不过，分别运行与各自容器的进程之间无法实现基于IPC的通信机制，此时，容器间的隔离机制对于依赖于此类通信方式的进程来说却又成为了障碍。Pod 资源抽象正是用来解决此类问题的组件，前文已然多次提到，Pod对象是一组容器的集合，这些容器共享 Network、UTS 及 IPC 名称空间，因此具有相同的域名、主机名和网络接口，并可通过IPC直接通信。为一个POD对象中的各容器提供网络名称空间等共享机制的是底层基础容器pause，图4-1所示为一个有三个容器组成的Pod资源，各容器共享Network、IPC和UTS名称空间，但分别拥有各自的MNT、USR和PID名称空间。需要特别强调的是，一个Pod对象中的多个容器必须运行于同一工作节点之上。

尽管可以将Pod类比为物理机或VM，但一个Pod内通常仅应该运行一个应用，除非多个进程之间具有密切的关系。这也意味着，实践中应该将多个应用分别构建到多个而非单个Pod中，这样也更能符合容器的轻量化设计、运行之目的。

例如，一个有着前端（application server）和后端（database server）的应用，其前、后端应该分别组织与各自的Pod中，而非同一个Pod的不同容器中。这样做的好处在于，多个Pod可被调度至多个不同的主机运行，提高了资源的利用率。另外，Pod也是Kubernetes进行系统规模伸缩的基础单元，分别运行与不同Pod的多个应用可独立按需求进行规模的变动，这就增强了系统架构的灵活性。事实上，前、后端应用的规模需求通常不会相同，而且无状态应用（application server）的规模变动也比有状态应用（database server）容易的多，将它们组织于同一个Pod中时将无法享受这种便利。

不过，这些场景要求必须与同一Pod中同时运行多个容器。此时，这些分布式应用（尤其是微服务架构中的多个服务）必须遵守某些最佳实践机制或基本准则。事实上，Kubernetes 并非期望成为一个管理系统，而是一个支持这些最佳实践的向开发人员或管理人员提供更高级别服务的系统。分布式系统设计通常包含以下几种模型：

1）Sidecar pattern（边车模型或跨斗模型）：即为 Pod 的主应用容器提供协同的辅助应用容器，每个应用独立运行，最为典型的代表是将主应用容器中的日志使用agent收集至日志服务器中时，可以将 agent 运行为辅助应用容器，即 sidecar。另一个典型的应用是为主应用容器中的 database server 启用本地缓存，如图 4-2 所示：

2）Ambassador pattern（大使模型）：即为远程服务创建一个本地代理，代理应用运行与容器中，主容器中的应用通过代理容器访问远程服务，如图4-3所示。一个典型的使用示例是主应用程序中的进程访问“一主多从”模型的远程Redis应用时，可在当前Pod容器中为Redis服务创建一个 Ambassador conteriner，主应用容器中的进程直接通过 localhost 接口访问 Ambassador container即可。即便是Redis主从集群架构发生变动时，也仅需要将 Ambassador container 加以修改即可，主应用容器无须对此做出任何反映。

3）Adapter pattern：（适配器模型）：此种模型一般用于将主应容器中的内容进行标准化输出，例如，日志数据或指标数据的输出，这有助于调用者统一接收数据的接口，如果图 4-4 所示。另外，某应用滚动升级后的版本不兼容旧的版本时，其报告信息的格式也存在不兼容的可能性，使用 Adapter container 有助于避免那些调用此报告数据的应用发生错误。

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