在多可用区中运行

此页面描述了在多个区域中运行 Kubernetes。

背景

Kubernetes 的设计允许单个 Kubernetes 集群跨多个故障区域运行,通常这些区域位于一个逻辑分组中,称为区域。主要的云提供商将一个区域定义为一组故障区域(也称为可用区),这些区域提供了一致的功能集:在一个区域内,每个可用区都提供相同的 API 和服务。

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

控制平面行为

所有控制平面组件都支持作为可互换资源池运行,每个组件都有副本。

部署集群控制平面时,请将控制平面组件的副本放置在多个故障区域中。如果可用性是一个重要的考虑因素,请至少选择三个故障区域,并将每个独立的控制平面组件(API 服务器、调度器、etcd、集群控制器管理器)复制到至少三个故障区域中。如果正在运行云控制器管理器,则也应将其复制到所有选定的故障区域中。

节点行为

Kubernetes 会自动将工作负载资源(例如DeploymentStatefulSet)的 Pod 分散到集群中的不同节点上。这种分散有助于降低故障的影响。

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

如果你的集群跨越多个区域或可用区,你可以结合使用节点标签和 Pod 拓扑分布约束 来控制 Pod 在集群中不同故障域(区域、可用区甚至特定节点)之间的分布方式。这些提示使调度器能够为了更好的预期可用性而放置 Pod,从而降低相关故障影响整个工作负载的风险。

例如,你可以设置一个约束,以确保 StatefulSet 的 3 个副本在可行的情况下都运行在不同的可用区中。你无需显式定义每个工作负载使用哪些可用区,即可声明性地定义此约束。

跨区域分布节点

Kubernetes 的核心不会为你创建节点;你需要自己完成,或者使用 Cluster API 等工具代表你管理节点。

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

Pod 的手动区域分配

你可以将节点选择器约束应用于你创建的 Pod,以及工作负载资源(如 Deployment、StatefulSet 或 Job)中的 Pod 模板。

区域的存储访问

创建持久卷时,Kubernetes 会自动为任何与特定区域关联的 PersistentVolume 添加区域标签。调度器随后通过其 NoVolumeZoneConflict 谓词确保声明给定 PersistentVolume 的 Pod 只放置在该卷所在的同一区域中。

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

你可以为 PersistentVolumeClaim 指定一个 StorageClass,该 StorageClass 指定该类中存储可能使用的故障域(区域)。要了解如何配置感知故障域或区域的 StorageClass,请参阅允许的拓扑

网络

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

对于自定义或本地部署,类似考虑也适用。ServiceIngress 的行为,包括处理不同故障区域的方式,确实因集群的具体设置而异。

故障恢复

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

Kubernetes 没有为此挑战提供解决方案;然而,这是需要考虑的事情。

下一步

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

上次修改于太平洋标准时间 2024 年 9 月 1 日凌晨 1:54:修复“overview/components/#...”到“architecture/#...”的断开链接 (#47724) (7e64c2db82)