4. Pod 拓扑分布约束：PodTopologySpread 原理、maxSkew 与 topologyKey 配置对调度分布的影响

在 Kubernetes 集群中，默认的调度策略（如 NodeSelector、NodeAffinity）主要解决 Pod “能否调度” 的问题，但无法精细控制 Pod 在集群拓扑中的“均匀分布”。当多个相同副本的 Deployment 或 StatefulSet 被调度时，可能出现 Pod 集中堆积在少数节点或可用区，导致单点故障风险升高、资源利用率失衡。

PodTopologySpread（Pod 拓扑分布约束）正是为解决此问题而设计。它允许用户定义 Pod 在跨节点、跨可用区等拓扑域上的分布规则，通过 maxSkew 和 topologyKey 两个核心参数控制调度器对分布偏差的容忍度。

4.1 核心概念与工作原理

PodTopologySpread 的核心思想是：在指定的拓扑域（topologyKey）内，确保匹配标签的 Pod 数量尽可能均匀。调度器在预选阶段会计算每个拓扑域中已存在的匹配 Pod 数量，然后根据 maxSkew 限制新 Pod 被调度到某个拓扑域后的最大偏差。

4.2 maxSkew 与 topologyKey 的配置影响

不同的 maxSkew 和 topologyKey 组合会显著改变 Pod 的调度分布行为。以下通过一个 3 节点集群的示例说明：

• 节点拓扑： node-1（zone-a）、node-2（zone-a）、node-3（zone-b）
• 目标： 调度 4 个副本的 Deployment，标签 app: web

场景一：topologyKey = kubernetes.io/hostname（节点级分布）

场景二：topologyKey = topology.kubernetes.io/zone（可用区级分布）

4.3 调度决策流程与分布计算

调度器在处理 PodTopologySpread 约束时，遵循以下步骤：

1. 解析约束： 读取 Pod 中定义的 topologySpreadConstraints 列表，提取 topologyKey、maxSkew、whenUnsatisfiable 和 labelSelector。
2. 构建拓扑域： 根据 topologyKey 遍历所有节点，按标签值分组，形成拓扑域集合。
3. 统计现有 Pod： 在集群中查找所有匹配 labelSelector 的 Pod，按拓扑域统计数量。
4. 计算候选节点： 对每个节点，模拟将新 Pod 加入该节点所在拓扑域后的 Pod 数量分布，计算新的 skew 值。
5. 筛选与打分：
   • 若 whenUnsatisfiable=DoNotSchedule：排除加入后 skew > maxSkew 的节点。
   • 若 whenUnsatisfiable=ScheduleAnyway：所有节点均可选，但 skew 更小的节点获得更高分数。

4.4 配置示例与实战要点

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-spread
spec:
  replicas: 6
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: topology.kubernetes.io/zone
          whenUnsatisfiable: DoNotSchedule
          labelSelector:
            matchLabels:
              app: web
        - maxSkew: 2
          topologyKey: kubernetes.io/hostname
          whenUnsatisfiable: ScheduleAnyway
          labelSelector:
            matchLabels:
              app: web
      containers:
        - name: nginx
          image: nginx:1.25

4.5 常见问题与排错