本文首发于我的公众号 CloudDeveloper(ID: cloud_dev)，专注于干货分享，号内有大量书籍和视频资源，后台回复「1024」即可领取，欢迎大家关注，二维码文末可以扫。
Hi，大家好，我是 CloudDeveloper，欢迎大家和我一起学习 K8S，这是系列第 6 篇。
Pod 中文译为豌豆荚，很形象，豌豆荚里面包裹的多颗小豌豆就是容器，小豌豆和亲密无间的老伙计壳荚子自出生之日起就得面对各种各样的人生大事：
容器、Pod、Node 之间的关系
Pod 的生命周期管理
Pod 的调度管理
Pod 的监控
Pod 的升级与回滚
Pod 的扩容与缩容
Pod 的存储管理
Pod 的网络管理
......
为什么需要 Pod？我们假设没有 Pod，应用部署的最小单元就是容器，会有什么问题？首先，应用调度粒度太细，不便于管理。想象一下淘宝网站运行着海量应用，每个应用又拆分成多个服务，每个服务部署在一个容器里，一个集群管理系统要管理庞大的容器集群，既要顾忌不同应用之间的隔离性，又要考虑相同应用之间的关联性，这在管理上将会是灾难性的难题。
其次，资源利用率低。有很多应用之间存在某种强关联关系，它们需要彼此能共享对方的资源，双方的交互需要快捷有效，如果把它们部署到单独的容器中，资源利用和通信将成为最主要的系统瓶颈。
Pod 的提出改变了这种局面，它将强关联的应用整合在一起，作为一个整体对外提供服务，既简化了管理的难度，又提高了资源的利用率。
那哪些应用是强关联，适合放到一个 Pod 中呢？举个例子，比如下面这个 Pod 包含两个容器，一个 File Puller，一个是 Web Server。
File Puller 会定期从外部的 Content Manager 中拉取最新的文件，将其存放在 Volume 中。然后 Web Server 从 Volume 中读取文件，来响应 Consumer 的请求。
这两个容器通过 Volume 来共享实时的数据，协作处理一个 Consumer 的请求，把它们放到同一个 Pod 中就是合适的。
如果有应用和任何应用之间都不存在联系，那么它们就单独部署在一个 Pod 中，称为one-container-per-pod。即便只有一个容器，K8S 管理的也是 Pod 而不是直接管理容器。
综上，Pod 在设计的时候，主要动机有以下两点：
方便管理
Pod 提供了比容器更高一层的抽象，K8S以 Pod 为最小单元进行应用的部署、调度、扩展、共享资源和管理周期。
资源共享和通信
Pod 内的所有容器共享同一个网络空间，它们之间可以通过 localhost 相互通信。同样，所有容器共享 Volume，一个容器挂载一个 Volume，其余容器都可以访问这个 Volume。
容器、Pod、Node 之间的关系容器是 Pod 的一个属性，定义了应用的类型及共享的资源。每个容器会分配一个 Port，Pod 内的容器通过 localhost:Port 的形式来通信。
一个 Pod 包含一个或多个容器，每个 Pod 会分配一个唯一的 IP 地址，Pod 内的多个容器共享这个 IP 地址，每个容器的 Port 加上 Pod IP 共同组成一个 Endpoint，共同对外提供服务。
在部署应用的时候，Pod 会被 Master 作为一个整体调度到一个 Node 上。如果开启多副本管理，则多个 Pod 会根据调度策略调度到不同的 Node 上。如果 Node 宕机，则该 Node 上的所有 Pod 会被自动调度到其他 Node 上。
下面是容器、Pod、Node 三者之间的关系图：
Pod 中有一个特殊的容器，叫 Pod 的根容器——Pause 容器，这是一个很小的容器，镜像大小大概为 200KB。
Pause 容器存在的意义是: 维护 Pod 的状态信息。
由于 Pod 是作为一个整体进行调度，我们难以对这个整体的信息进行简单的判断和有效地进行行动。
想象一下，假如 Pod 内一个容器死亡了，是算整体死亡呢还是 N/M 死亡率，如果 Pod 内所有容器都死亡了，那是不是该 Pod 也就死亡了，如果加入新的容器或原有容器故障恢复呢，如何让新成员快速融入环境？
理论上，虽然 Pod 是由一组容器组成的，但 Pod 和容器是彼此独立的，也就是容器的故障不应该影响 Pod 的存在，Pod 有相应的手段来保证容器的健康状况。