在多个可用区中运行

本页面介绍如何在多个可用区中运行 Kubernetes。

背景

Kubernetes 的设计使得单个 Kubernetes 集群可以跨多个故障域（通常称为区域的逻辑分组）运行。主要的云提供商将区域定义为一组故障域（也称为可用区），这些故障域提供一组一致的功能：在区域内，每个可用区都提供相同的 API 和服务。

典型的云架构旨在最大限度地减少一个可用区中的故障也损害另一个可用区中的服务的可能性。

控制平面行为

所有 控制平面组件 都支持作为一组可互换的资源运行，并按组件进行复制。

部署集群控制平面时，请将控制平面组件的副本放置在多个故障域中。如果可用性是一个重要问题，请选择至少三个故障域，并在至少三个故障域中复制每个单独的控制平面组件（API 服务器、调度器、etcd、集群控制器管理器）。如果您正在运行云控制器管理器，那么您还应该在您选择的所有故障域中复制它。

节点行为

Kubernetes 会自动将工作负载资源（例如 Deployment 或 StatefulSet）的 Pod 分布到集群中的不同节点。这种分布有助于减少故障的影响。

当节点启动时，每个节点上的 kubelet 都会自动将 标签 添加到 Kubernetes API 中表示该特定 kubelet 的节点对象。这些标签可以包含 可用区信息。

如果您的集群跨越多个可用区或区域，您可以将节点标签与 Pod 拓扑分布约束 结合使用，以控制 Pod 在故障域（区域、可用区，甚至特定节点）之间如何在集群中分布。这些提示使 调度器 能够放置 Pod 以获得更好的预期可用性，从而降低相关故障影响整个工作负载的风险。

例如，您可以设置一个约束，以确保 StatefulSet 的 3 个副本在可行的情况下始终在不同的可用区中运行。您可以以声明方式定义这一点，而无需明确定义每个工作负载使用哪些可用区。

跨可用区分发节点

Kubernetes 的核心不会为您创建节点；您需要自己创建，或者使用 Cluster API 等工具来代表您管理节点。

使用 Cluster API 等工具，您可以定义多组机器作为集群的工作节点，分布在多个故障域中，并定义在整个可用区服务中断的情况下自动修复集群的规则。

手动为 Pod 分配可用区

您可以将 节点选择器约束 应用于您创建的 Pod，以及工作负载资源（例如 Deployment、StatefulSet 或 Job）中的 Pod 模板。

可用区的存储访问

创建持久卷时，Kubernetes 会自动将可用区标签添加到链接到特定可用区的任何 PersistentVolume。然后，调度器 通过其 NoVolumeZoneConflict 谓词确保声明给定 PersistentVolume 的 Pod 仅放置在与该卷相同的可用区中。

请注意，添加可用区标签的方法可能取决于您的云提供商和您正在使用的存储供应器。请始终参考您的环境的特定文档以确保正确配置。

您可以为 PersistentVolumeClaim 指定一个 StorageClass，该类指定该类中的存储可以使用哪些故障域（可用区）。要了解如何配置可识别故障域或可用区的 StorageClass，请参阅 允许的拓扑。

网络

Kubernetes 本身不包含可识别可用区的网络。您可以使用 网络插件 来配置集群网络，并且该网络解决方案可能具有特定于可用区的元素。例如，如果您的云提供商支持 type=LoadBalancer 的服务，则负载均衡器可能只将流量发送到与处理给定连接的负载均衡器元素位于同一可用区中的 Pod。有关详细信息，请参阅您的云提供商的文档。

对于自定义或本地部署，也适用类似的注意事项。Service 和 Ingress 的行为（包括对不同故障域的处理）确实因集群的具体设置方式而异。

故障恢复

设置集群时，您可能还需要考虑如果区域中的所有故障域同时脱机，您的设置是否以及如何恢复服务。例如，您是否依赖于至少有一个节点能够在某个可用区中运行 Pod？
确保任何关键的集群修复工作都不依赖于集群中至少有一个健康节点。例如：如果所有节点都不健康，您可能需要运行一个具有特殊 容忍 的修复作业，以便修复可以完成到足以使至少一个节点投入使用的程度。

Kubernetes 没有针对此挑战的现成答案；但这需要考虑。

下一步

要了解调度器如何在集群中放置 Pod 并遵守配置的约束，请访问 调度和驱逐。