本章涵盖
- 与指定和托管应用程序部署相关的 Kubernetes 概念
- 在云平台上将容器化应用程序部署到 Kubernetes
- 更新部署应用程序容器的新版本
- 在本地运行 Kubernetes 的版本进行测试和开发
在上一章中，我们介绍了如何将您的应用程序容器化。如果您就此停止，您将拥有一个可移植、可重现的应用程序环境，更不用说方便的开发者设置。然而，当您进入生产环境时，您可能会在扩展该应用程序时遇到困难。
对于超简单的部署，如果您不介意每个虚拟机（VM）运行一个容器，您可能可以直接将容器部署到虚拟机上，然后根据需要扩展虚拟机。您将获得容器的一些优势，例如便捷的打包。然而，如果像大多数人一样，您有多个不同的服务需要部署，您可能需要更灵活的解决方案。
这就是像 Kubernetes 这样的容器编排工具的用武之地。容器编排只是一个花哨的说法，指的是处理在不同机器上调度和监控一堆不同容器的工具。它允许您主要关注应用程序的部署——容器及其部署属性，例如应该有多少个副本（实例）；以及高可用性（跨故障域分布）、服务网络等要求——而不必过于关注底层计算的配置。
能够方便地管理共享计算资源池上的多个服务，使您在运行多个应用程序或采用微服务等模式时提高效率，在这些模式中，应用程序的各个部分被单独部署和管理。您还可以混合不同类型的部署，从无状态应用程序到有状态数据库、批处理作业等——所有这些都无需过多担心每个容器最终实际运行在哪台机器上。
3.1 Kubernetes 架构
Kubernetes 是一个抽象层，位于工作负载级别之上，基于原始计算原语，如虚拟机（或裸金属机器）和负载均衡器。虚拟机被称为节点，并被组织成一个集群。容器（一个或多个）被分组为一个称为 Pod 的调度单元。网络通过服务进行配置。还有其他更高阶的构建块，如部署，旨在使 Pod 更易于管理。在部署我们的第一个工作负载之前，让我们先探索一下这个架构的一些基本构建块。
3.1.1 Kubernetes 集群
Kubernetes 集群是节点的集合，这些节点是运行容器的计算实例。最常见的是虚拟机，但它们也可以是裸金属（非虚拟化）机器。每个节点运行一个特殊的 Kubernetes 过程，称为 kubelet，负责与控制平面（Kubernetes 编排过程）进行通信，并管理在节点上通过容器运行时运行的容器的生命周期。除了操作系统、kubelet 和容器运行时环境外，其余进程，包括您自己的工作负载和一些负责日志记录和监控的系统组件，都是在容器中运行的，如图 3.1 所示。
在集群中，一个或多个（在高可用模式下运行时）节点具有特殊角色，如图 3.2 所示：运行 Kubernetes 调度程序本身。形成控制平面的特殊节点负责
- 运行 API，您可以使用 Kubernetes 命令行界面 (CLI) 工具与集群进行交互
- 存储集群状态
- 协调集群中所有节点以调度（启动、停止、重启）容器
在大多数云环境中，控制平面作为一种托管服务提供。在这种环境中，控制平面节点通常对用户不可见，控制平面可能运行在某个节点上的事实是一个实现细节。在这些环境中，您通常会将集群视为带有工作节点的托管控制平面，如图 3.3 所示。
工作节点（以下简称节点）负责管理运行容器的生命周期，包括启动和停止容器等任务。控制平面将指示节点运行某个容器，但容器的实际执行则由节点负责。节点还会自行采取一些行动，而无需与控制平面进行检查，例如重启崩溃的容器或在节点内存不足时回收内存。
控制平面和节点共同构成 Kubernetes 集群，并提供 Kubernetes 平台，您可以在其上调度工作负载。集群本身由您用于运行 Kubernetes 的平台提供商进行配置和管理，负责创建节点等集群资源。本书面向开发人员，主要关注使用 Kubernetes 集群运行工作负载，而不是提供此服务给开发人员的平台提供商任务（这些任务更多属于云提供商领域）。
3.1.2 Kubernetes 对象
一旦集群创建完成，您主要通过 Kubernetes API 创建、检查和修改 Kubernetes 对象与 Kubernetes 进行交互。这些对象中的每一个都代表系统中的特定部署构造。例如，有一个对象代表一组容器（Pod），一个代表一组 Pods（Deployment），一个用于网络服务，等等。甚至节点也被表示为一个对象，您可以查询该对象以查看当前状态的各个方面，例如正在使用多少资源。要将一个典型的无状态 Web 应用程序部署到集群中，您将使用三个对象：Pod、一个封装 Pod 的 Deployment 和一个 Service。
舱
Pod 只是一个容器的集合。通常，Pod 将只是一个单一的容器，但在需要紧密耦合的容器一起部署的情况下，它可以是多个容器（图 3.4）。
Pod 是 Kubernetes 中用于主要调度单元的。它包含您的应用程序及其容器，是 Kubernetes 根据您所需的资源调度到节点上的计算单元。例如，如果您的工作负载需要两个 CPU 核心来运行，您可以在 Pod 定义中指定这一点，Kubernetes 将找到一台具有两个可用 CPU 资源的机器。
一个 Pod 中有多少个容器？
除了多个容器之间存在紧密耦合依赖关系的简单情况外，大多数容器都是单独部署的，每个 Pod 只有一个容器。您可能会遇到多个容器的常见情况，包括所谓的侧车，其中第二个容器用于授权、日志记录或其他某些功能，以及其他多个容器紧密耦合的情况，以便它们能够一起部署而受益。
如果您检查节点上运行的过程，您将看不到 Pod 本身，只会看到来自容器的一堆进程（图 3.5）。Pod 只是容器的逻辑分组。是 Kubernetes 将这些容器绑定在一起，确保它们共享一个共同的生命周期：它们一起创建；如果其中一个失败，它们一起重启；并且它们一起终止。
部署
虽然您可以指示 Kubernetes 直接运行 Pods，但您很少这样做。应用程序崩溃和机器故障，因此需要重新启动或重新调度 Pods。与其直接调度 Pods，不如将它们封装成一个管理 Pod 生命周期的高阶对象。
对于需要持续运行的应用程序，如 Web 服务器，该对象是一个 Deployment。其他选项包括用于完成批处理的 Job，详见第 10 章。在 Deployment 中，您可以指定希望运行的 Pod 副本数量以及其他信息，例如如何进行更新。
在 Kubernetes 中，像所有对象一样，Deployment（图 3.6）是系统期望状态的规范，Kubernetes 旨在实现这一目标。您可以指定诸如 Pod 的副本数量等内容，以及我们将在后面的章节中讨论的关于 Pods 在集群中分布的详细要求。Kubernetes 持续地将观察到的状态与期望状态进行协调，同时努力提供您所请求的内容。例如，如果在部署后某个时间点 Pod 变得不可用，比如运行它的节点发生故障，Kubernetes 将观察到运行的 Pods 数量少于期望数量，并调度新的 Pod 实例以再次满足您的要求。这些用于扩展和修复的自动化操作是使用 Deployment 来管理服务生命周期的主要原因，而不是直接运行 Pods。
服务
服务是如何将运行在一组 Pods 上的应用程序暴露为网络服务的。服务提供了单一的寻址机制，并在 Pods 之间分配负载（图 3.7）。服务拥有自己的内部 IP 地址和 DNS 记录，可以被集群内运行的其他 Pods 引用，也可以分配一个外部 IP 地址。