Google Kubernetes设计文档之Pod篇

在Kubernetes中，创建、调度和管理的最小部署单位是Pod，而不是容器。

什么是Pod

一个Pod对应于由若干容器组成的一个容器组，同个组内的容器共享一个存储卷(volume)。Pod主要是在容器化环境中建立了一个面向应用的“逻辑主机”模型，它可以包含一个或多个相互间紧密联系的容器。在没有容器化技术的场景里，同个Pod内的“容器”都在同一台物理或虚拟主机上运行。

Pod与容器一样都不是持续存在的，在容器的生命周期里，每个Pod被分配到节点上运行直至运行结束或被删除。当一个节点消失时，该节点上的Pod也随之被删除。每个Pod实体只会被调度一次，不会重复分配给别的节点，由replication controller负责创建新的Pod来替代旧的（在未来也可能有新的API用于Pod迁移）。

开发pod的原因

资源共享和通信

Pod的存在使同个Pod下的容器之间能更方便的共享数据和通信。

同个Pod下的容器使用相同的网络命名空间、IP地址和端口区间，相互之间能通过localhost来发现和通信。在一个无层次的共享网络中，每个Pod都有一个IP地址用于跟别的物理主机和容器通信，Pod的名字就用作容器通信时的主机名。（有关网络的内容，我们稍后会翻译）

在同个Pod内运行的容器还共享一块存储卷空间，存储卷内的数据不会在容器重启后丢失，同时能被同Pod下别的容器读取。

未来的开发计划是使Pod共享IPC命名空间，CPU和内存。（参加Google的lmctfy文档，lmctfy的意思是Let me Contain That For You）

管理

相比原生的容器接口，Pods通过提供更高层次的抽象，简化了应用的部署和管理。Pods就像一个管理和横向部署/和管理的单元，主机托管、资源共享、协调复制和依赖管理都可以自动处理。

Pods用例

Pod能应用于构建垂直集成应用栈，但它的主要为了集中管理一些辅助程序，如：

• 内容管理系统，文件和数据载入器，本地缓存管理等；
• 日志和检查点备份，压缩，轮换，快照系统等；
• 数据变化监视，日志末端数据读取，日志和监控适配器，事件打印等；
• 代理，桥接和适配器；
• 控制器，管理器，配置编辑器和更新器。

Pod的设计并不是为了运行同一个应用的多个实例。

其他考虑因素

为什么不直接在单个Docker容器中运行多个程序？主要是出于以下几个原因：

1. 透明性：将Pod内的容器向基础设施可见，底层系统就能向容器提供如进程管理和资源监控等服务，这样能给用户带来极大便利；
2. 解绑软件的依赖：这样单个的容器可以独立地重建和重新部署。未来有可能在Kubernetes上实现独立容器的实时更新；
3. 易用性：用户不需要运行自己的进程管理器，也不需负责信号量和退出码的传递等；
4. 高效性：因为底层设备负责更多了管理，容器因而能更轻量化。

为什么不直接将相近的容器集中管理呢？那种方法虽然提供了集中管理的功能，但却没有Pod所拥有的大部分便利之处，如不提供资源共享和进程间通信，无法保证容器同时开始和结束，不能简化管理等。

原文链接：Pods（编译/叶瑞浩  审校/孙宏亮、张磊  责编/周小璐）

译者简介：叶瑞浩，浙江大学SEL实验室硕士研究生，利用业余时间翻译一些开源技术文章，希望对读者有所帮助。 

国内首次 CoreOS 交流活动（北京）：https://huiyi.csdn.net/activity/product/goods_list?project_id=1596

如需要了解更多Docker相关的资讯或是技术文档可访问Docker技术社区；如有更多的疑问请在Dcoker技术论坛提出，我们会邀请专家回答。ImapBox Docker技术交流QQ群：303806405。