在多个区域中运行

本页介绍如何在多个区域中运行 Kubernetes。

背景

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

典型的云架构旨在最大程度地降低一个区域中的故障影响到另一区域服务的可能性。

控制平面行为

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

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

节点行为

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

节点启动时，每个节点上的 kubelet 会自动为在 Kubernetes API 中代表该特定 kubelet 的 Node 对象添加标签。这些标签可以包含区域信息。

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

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

跨区域分布节点

Kubernetes 核心本身不会为你创建节点；你需要自己完成此操作，或者使用诸如 Cluster API 的工具来代表你管理节点。

使用 Cluster API 等工具，你可以定义一组机器作为集群的工作节点跨多个故障域运行，并定义规则以在整个区域服务中断时自动修复集群。

Pod 的手动区域分配

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

区域的存储访问

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

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

你可以为 PersistentVolumeClaims 指定一个StorageClass，该 StorageClass 指定了该类存储可能使用的故障域（区域）。要了解如何配置感知故障域或区域的 StorageClass，请参阅允许的拓扑结构。

网络

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

对于定制或本地部署，也适用类似的考量。Service 和 Ingress 的行为，包括处理不同故障域的方式，确实取决于你的集群是如何具体设置的。

故障恢复

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

Kubernetes 没有自带应对这个挑战的答案；然而，这是一个需要考虑的问题。

下一步

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