在现代云原生架构中，高可用性是系统设计的核心目标之一。当我们将Kubernetes集群部署在云厂商的多个可用区时，如何确保应用实例能够均匀分布在不同的可用区，而不是集中在同一个可用区，是防止区域性故障导致服务全面瘫痪的关键。Kubernetes提供了多种调度机制来实现这一目标，其中反亲和性和拓扑分布约束是最常用的两种手段。通过合理配置这些策略，可以显著提升集群的容灾能力。
理解多可用区架构与Kubernetes拓扑域
可用区是云厂商在特定地理区域内提供的独立数据中心。每个可用区拥有独立的电力、网络和冷却系统，因此一个可用区发生物理故障时，通常不会影响其他可用区。在Kubernetes集群中，如果节点分布在多个可用区，我们就需要利用这些可用区信息来指导调度器进行合理的分布。
Kubernetes通过节点标签来识别拓扑域。默认情况下，云控制器会自动为节点打上topology.kubernetes.io/zone标签，其值即为节点所在的可用区名称，例如us-east-1a或cn-north-1a。要实现跨可用区调度，首先必须确认集群节点是否已经正确打上了这些拓扑标签。可以通过kubectl get nodes --show-labels命令查看节点的标签信息。如果节点缺少这些标签，调度器将无法识别拓扑域，所有的反亲和性或拓扑分布策略都会失效。
对于自建数据中心或裸金属服务器集群，管理员需要手动定义拓扑域。可以通过自定义标签（例如zone、rack或host）来标识节点的物理位置。只要在调度策略的topologyKey字段中指定对应的标签键，调度器就能按照预期的拓扑结构进行工作。理解拓扑域的概念是配置高可用调度策略的基础，它决定了调度器在计算分布时的边界。
使用Pod反亲和性实现跨可用区分布
Pod反亲和性是早期Kubernetes版本中实现跨拓扑域分布的主要方式。它允许用户指定一个Pod不希望与哪些其他Pod调度在同一个拓扑域中。反亲和性分为硬策略和软策略两种。硬策略使用requiredDuringSchedulingIgnoredDuringExecution字段，它是一个强制性的要求，如果调度器无法找到满足条件的节点，Pod将永远保持Pending状态。软策略使用preferredDuringSchedulingIgnoredDuringExecution字段，它是一个尽力而为的策略，调度器会尝试满足条件，但如果实在无法满足，Pod仍然会被调度到某个节点上。
在多可用区场景下，通常会结合使用软硬策略。例如，可以设置硬策略要求Pod不能与具有相同标签的其他Pod调度在同一个可用区，从而强制它们分散开来。然而，纯反亲和性策略在处理多副本应用时存在一定的局限性。当副本数量超过可用区数量时，硬策略会导致后续Pod无法调度。此外，反亲和性只能表达排斥关系，无法精确控制每个可用区内Pod数量的差异，这可能导致可用区之间的负载不完全均衡。
反亲和性的配置相对复杂，且在集群规模较大时，调度器的计算开销会显著增加。因为调度器需要遍历所有节点上的Pod及其标签，来判断当前Pod是否满足反亲和性条件。尽管如此，在只需要简单排斥的场景下，Pod反亲和性仍然是一个有效的工具。下面是一个使用软策略进行跨可用区分布的反亲和性配置示例，它要求Pod尽量不与带有app: my-app标签的Pod运行在同一个可用区。
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 3
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
affinity:
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 100
podAffinityTerm:
labelSelector:
matchExpressions:
- key: app
operator: In
values:
- my-app
topologyKey: topology.kubernetes.io/zone
containers:
- name: my-app-container
image: nginx:latest采用拓扑分布约束优化调度策略
为了解决反亲和性的局限性，Kubernetes引入了topologySpreadConstraints特性。这个特性提供了更精细的控制能力，允许用户定义Pod在不同拓扑域之间的最大不均匀度。通过maxSkew参数，可以指定不同拓扑域之间Pod数量的最大差值。例如，设置maxSkew为1，意味着调度器会尽量保证各个可用区之间的Pod数量差不超过1。如果某个可用区有2个Pod，另一个可用区只有1个，调度器就会优先将新的Pod调度到只有1个Pod的可用区。
拓扑分布约束同样支持whenUnsatisfiable字段来定义调度行为，可以设置为DoNotSchedule（相当于硬策略，不满足条件则不调度）或ScheduleAnyway（相当于软策略，尽量满足但不强制）。相比于反亲和性，拓扑分布约束的语义更加清晰，配置更加简洁，且能够更好地处理副本数量大于拓扑域数量的情况。当副本数超过可用区数时，拓扑分布约束会自动在各个可用区之间进行轮询调度，而不会像硬反亲和性那样卡死。
在实际生产环境中，推荐使用拓扑分布约束结合软策略，既能保证尽量均匀分布，又能在资源不足时避免Pod卡死。同时，还可以结合节点亲和性，限制Pod只能在特定可用区的节点上调度，从而实现更复杂的调度需求。拓扑分布约束不仅适用于可用区级别，还可以用于机架或节点级别，实现多层次的容灾分布。下面是一个使用拓扑分布约束的配置示例，它要求Pod在各个可用区之间尽量均匀分布，最大差值不超过1，且在无法满足时仍然允许调度。
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app-optimized
spec:
replicas: 4
selector:
matchLabels:
app: my-app-optimized
template:
metadata:
labels:
app: my-app-optimized
spec:
topologySpreadConstraints:
- maxSkew: 1
topologyKey: topology.kubernetes.io/zone
whenUnsatisfiable: ScheduleAnyway
labelSelector:
matchLabels:
app: my-app-optimized
containers:
- name: my-app-container
image: nginx:latest通过上述配置，Kubernetes调度器会持续监控各个可用区的Pod数量，并在调度新Pod时选择能够使分布最均匀的节点。这种方式不仅提升了集群的高可用性，还简化了运维人员的配置心智负担，是现代Kubernetes集群中实现跨可用区容灾的最佳实践方案。
Kubernetes多可用区反亲和性修改时间：2026-08-21 05:11:14