Pod 抽象层

如果您有使用容器的背景，关于 Kubernetes 的第一个问题可能是：“为什么我们需要在容器之上再加一层？”虽然容器提供了进程隔离和打包功能，但它们并没有解决如何管理共同部署且相互依赖的进程的问题。Kubernetes 通过引入一个不同的原子单元来解决这个问题：Pod。

Pod 是 Kubernetes 对象模型中您可以创建或部署的最小、最简单的单元。Kubernetes 管理的是 Pod，而不是单个容器。一个 Pod 代表集群中运行进程的单个实例，并为其包含的容器提供特定的执行环境。

容器的逻辑主机

可以将 Pod 看作是一台逻辑主机。就像物理机或虚拟机承载操作系统及其应用程序一样，一个 Pod 承载一个或多个紧密耦合的容器。这种“逻辑主机”抽象正是 Pod 如此高效的原因。单个 Pod 中的所有容器共享相同的环境和资源，其中包括：

• 共享网络命名空间： 集群中的每个 Pod 都会被分配一个唯一的 IP 地址。该 Pod 内的所有容器共享此 IP 地址和端口空间。这意味着它们可以使用 localhost 互相查找并通信。例如，在同一个 Pod 中，container-a 中的 Web 服务器可以通过连接到 localhost:5432 与 container-b 中的数据库进行通信。
• 共享存储卷： Pod 可以指定一组共享存储卷。Pod 中的所有容器都可以访问这些卷，从而实现数据共享。这对于一个容器写入数据而另一个容器需要处理该数据的场景非常有用。

这种共同部署模型简化了应用程序设计。您不需要在已知始终一起运行的进程之间配置复杂的发现机制。它们已经处于相同的网络和存储上下文中了。

Pod 为其容器提供了一个共享的执行环境。它们共享网络命名空间（IP 地址）并可以共享存储卷，从而实现紧密耦合的通信和数据交换。

单容器 Pod 与多容器 Pod

Kubernetes 中最常见的模式是“每个 Pod 一个容器”模型。在这种设置下，Pod 作为一个包装器，在单个应用容器周围提供一致的管理层。虽然这看起来像是不必要的开销，但它允许 Kubernetes 为每个工作负载附加一套统一的行为（如健康检查和资源限制），无论其内部如何复杂。

Pod 模型的真正优势在多容器模式中得以体现。这种模式专门用于那些紧密耦合且需要共享资源的容器。将它们放在同一个 Pod 中是一个经过深思熟虑的设计决策。常见的多容器模式包括：

• 边车 (Sidecars)： 这些是辅助容器，用于扩展或增强主应用容器的功能。例如，边车容器可以处理日志记录、指标收集或充当网络代理。主应用程序感知不到边车的存在；它只需完成自己的工作，而边车也各司其职。
• 适配器 (Adapters)： 这些容器对主应用程序的输出进行标准化或转换。例如，适配器可以将旧版应用程序的日志条目重新格式化为集群级日志系统所期望的标准格式。
• 大使 (Ambassadors)： 大使容器充当网络流量代理，简化了主应用程序连接外部服务的方式。它可以代表应用容器处理服务发现或身份验证等事务。

指导原则是：只有当容器之间紧密耦合、需要共享网络或文件系统等资源，并且应该作为单个单元调度到同一台机器上时，才将它们组合到单个 Pod 中。

Pod 是瞬态的

最后需要理解的一个特征是，Pod 被设计为会消亡的，或者是瞬态的。它们并非旨在成为长期运行、持久存在的实体。当节点发生故障时，运行在该节点上的 Pod 就会丢失。Pod 不会自我修复或自行重新调度到新节点。

这听起来可能很脆弱，但这正是设计使然。Kubernetes 不是让单个 Pod 具备鲁棒性，而是使用更高级别的控制器（如 Deployment 和 ReplicaSet，我们将在下一章介绍）来管理 Pod 的生命周期。这些控制器负责替换失败的 Pod、处理扩缩容以及管理更新。因此，您很少会在生产环境中直接创建单个 Pod。然而，理解 Pod 作为基本构建模块对于使用管理它们的控制器来说非常必要。

有了这些基础，我们现在可以开始学习使用 YAML 清单定义和创建 Pod 的实际操作了。