k8s管理pod资源对象

现代的容器技术被设计用来运行单个进程时，该进程在容器中pid名称空间中的进程号为1，可直接接收并处理信号，于是，在此进程终止时，容器即终止退出。若要在一个容器中运行多个进程，则需要为这些进程提供一个类似于linux操作系统init进程的管控类进程，以树状结构完成多进程的生命周期管理。绝大多数场景中都应该于一个容器中仅运行一个进程，它将日志信息直接输出至容器的标准输出。不过，分别运行于各自容器的进程之间无法实现基于ipc的通信机制，此时，容器间的隔离机制对于依赖于此类通信方式的进程来说却又成了阻碍。pod资源抽象正是用来解决此类问题的组件。pod对象是一组容器的集合，这些容器共享network、uts及ipc名称空间，因此具有相同的域名、主机名和网络接口，并可通过ipc直接通信。为一个pod对象中的各容器提供网络名称空间等共享机制的是底层基础容器pause。

尽管可以将pod类比为物理机或vm，但一个pod内通常仅应该运行一个应用，除非多个进程间有密切关系。不过，有些场景要求必须于同一pod中同时运行多个容器，此时，这些分布式应用必须遵循某些最佳实践机制或基本准则。事实上，k8s并非期望成为一个管理系统，而是一个支持这些最佳实践的向开发人员或管理人员提供更高级别服务的系统。分布式系统设计通常包含以下几种模型：

1、sidecar pattern（边车模型或挎斗模型）：即为pod的主应用容器提供协同的辅助应用容器，每个应用独立运行，最为典型的代表是将主应用容器中的日志使用agent收集至日志服务器中时，可以将agent运行为辅助容器。

2、ambassador pattern（大使模型）：即为远程服务创建一个本地代理，代理应用运行于容器中，著容器中的应用通过代理容器访问远程服务。一个典型的场景是主应用容器中的进程访问一主多从模型的redis应用时，可在当前pod容器中为redis服务创建一个ambassador container，主应用容器中的进程直接通过localhost接口访问ambassador container即可。即便是redis主从集群架构发生变动时，也仅需要将ambassador conftainer加以修改即可，主应用容器无须对此做出任何反应。

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

k8s系统的pod资源对象用于运行单个容器化应用，此应用称为pod对象的主容器，同时pod也能容纳多个容器，不过额外的容器一般工作为sidecar模型，用于辅助著容器完成工作职能。