拓扑分布约束

Deployment 设 replicas: 3 不保证三个 Pod 落在 不同可用区（AZ）——Scheduler 可能全堆在同一故障域。Topology Spread Constraints 在调度阶段约束 Pod 在 topologyKey（常见 topology.kubernetes.io/zone）上的 分布 skew，对应路线图 topology-spread-constraints 与高可用部署。

学习目标

• 读懂 maxSkew、topologyKey、whenUnsatisfiable 字段含义
• 为无状态 Web 与有状态服务各写一条 spread 策略
• 结合 PodDisruptionBudget 理解「 voluntary 中断」时的可用性

问题从哪来

3 副本 backend Deployment
  → 若 3 Pod 全在 zone-a
  → zone-a 电力故障 → 服务全挂

k8s-deployments 管副本数；本课管 副本落在哪。与 k8a-taints 正交：一个管 哪些节点能进，一个管 进之后怎么散。

核心字段

topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: topology.kubernetes.io/zone
    whenUnsatisfiable: DoNotSchedule
    labelSelector:
      matchLabels:
        app: backend

字段	含义
maxSkew	任意两 topology 域 Pod 数之差上限
topologyKey	节点标签定义的「域」：zone、hostname、自定义 rack
whenUnsatisfiable	DoNotSchedule 硬约束；ScheduleAnyway 软约束
labelSelector	统计哪些 Pod 参与 spread（同 Deployment 通常 match app 标签）

硬约束 vs 软约束

策略	适用
DoNotSchedule	prod 核心 API，宁可 Pending 也不违反 AZ 均衡
ScheduleAnyway	资源紧张时仍调度，尽量接近 skew

节点数少于 AZ 数时，硬约束可能导致 Pod 长期 Pending——需扩节点或降副本，与 k8a-monitor 资源规划衔接。

与 PDB、反亲和

机制	作用