跨多个区域运行

此页面介绍如何在多个区域运行 Kubernetes。

背景

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

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

控制平面行为

所有控制平面组件支持作为可互换资源池运行，每个组件进行复制。

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

节点行为

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

节点启动时，每个节点上的 kubelet 会自动将标签添加到代表 Kubernetes API 中特定 kubelet 的节点对象中。这些标签可能包括区域信息。

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

例如，可以设置一个约束，确保 StatefulSet 的 3 个副本尽可能地在彼此不同的区域中运行。可以声明性地定义这一点，而无需显式定义每个工作负载使用的可用区。

在区域中分配节点

Kubernetes 的核心不会为你创建节点；你需要自己完成，或者使用集群 API之类的工具来代表你管理节点。

使用集群 API 之类的工具，可以定义一组机器，作为集群中的工作节点跨多个故障域运行，以及在整个区域服务中断的情况下自动修复集群的规则。

Pod 的手动区域分配

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

区域的存储访问

创建持久卷时，Kubernetes 会自动将区域标签添加到与特定区域关联的任何持久卷。然后，调度器通过其NoVolumeZoneConflict谓词确保声明特定持久卷的 Pod 只能放置到与该卷相同的区域中。

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

可以为指定故障域（区域）的持久卷声明指定StorageClass，该存储类中可以使用该存储。要了解如何配置了解故障域或区域的 StorageClass，请参见允许的拓扑结构。

网络

Kubernetes 本身不包括区域感知网络。可以使用网络插件来配置集群网络，并且该网络解决方案可能具有区域特定的元素。例如，如果云提供商支持使用type=LoadBalancer的 Service，负载均衡器可能只将流量发送到与处理给定连接的负载均衡器元素相同区域中运行的 Pod。请查看云提供商的文档以了解详细信息。

对于自定义部署或内部部署，也适用类似的考虑因素。服务和入口的行为，包括处理不同的故障区域，确实会根据集群的具体设置而有所不同。

故障恢复

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

Kubernetes 不会提供针对此挑战的答案；但是，这是一个需要考虑的问题。

下一步

要了解调度器如何根据配置的约束将 Pod 放置到集群中，请访问调度和驱逐。