Google Kubernetes设计文档之Pod篇

摘要:Kubernetes是Google开源的容器集群管理系统,构建于Docker之上,为容器化的应用提供资源调度、部署运行、服务发现、扩容缩容等功能。CSDN联合浙江大学SEL实验室共同翻译其设计文档,本文为系列的第二篇:Pod。

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

1.什么是Pod

一个Pod对应于由若干容器组成的一个容器组,同个组内的容器共享一个存储卷(volume)。Pod主要是在容器化环境中建立了一个面向应用的“逻辑主机”模型,它可以包含一个或多个相互间紧密联系的容器。在没有容器化技术的场景里,同个Pod内的“容器”都在同一台物理或虚拟主机上运行。 Pod与容器一样都不是持续存在的,在容器的生命周期里,每个Pod被分配到节点上运行直至运行结束或被删除。当一个节点消失时,该节点上的Pod也随之被删除。每个Pod实体只会被调度一次,不会重复分配给别的节点,由replication controller负责创建新的Pod来替代旧的(在未来也可能有新的API用于Pod迁移)。

2.开发Pod的原因

2.1 资源共享和通信

Pod的存在使同个Pod下的容器之间能更方便的共享数据和通信。 同个Pod下的容器使用相同的网络命名空间、IP地址和端口区间,相互之间能通过localhost来发现和通信。在一个无层次的共享网络中,每个Pod都有一个IP地址用于跟别的物理主机和容器通信,Pod的名字就用作容器通信时的主机名。(有关网络的内容,我们稍后会翻译) 在同个Pod内运行的容器还共享一块存储卷空间,存储卷内的数据不会在容器重启后丢失,同时能被同Pod下别的容器读取。 未来的开发计划是使Pod共享IPC命名空间,CPU和内存。(参加Google的lmctfy文档,lmctfy的意思是Let me Contain That For You)

2.2 管理

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

3.Pod用例

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

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

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

4.其他考虑因素

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

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

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

原文链接:Pods(编译/叶瑞浩 审校/孙宏亮、张磊)

作者介绍 叶瑞浩 浙江大学SEL/VLIS实验室研究生

浙江大学SEL实验室是本网站上所有页面设计、页面内容的著作权人,对该网站所载的作品,包括但不限于网站所载的文字、数据、图形、照片、有声文件、动画文件、音视频资料等拥有完整的版权,受著作权法保护。严禁任何媒体、网站、个人或组织以任何形式或出于任何目的在未经本实验室书面授权的情況下抄袭、转载、摘编、修改本网站內容,或链接、转帖或以其他方式复制用于商业目的或发行,或稍作修改后在其它网站上使用,前述行为均将构成对本网站版权之侵犯,本网站將依法追究其法律责任。
本网站与他人另有协议授权下载的或法律另有规定的,在下载使用时必须注明“稿件来源:浙江大学SEL实验室”。

Leave a Reply

Your email address will not be published. Required fields are marked *