拓扑分布约束

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、反亲和

机制	作用
Topology Spread	跨域 数量 均衡
Pod Anti-Affinity	避免同 app 同 hostname（更粗）
PDB	minAvailable / maxUnavailable 限制 自愿驱逐 下限

滚动更新 + maxUnavailable: 1 + spread + PDB 是 prod 标配组合；GitOps 仓库里 prod values 应显式写出，见 helm-patterns。

CodeRoadMap 示例

backend Deployment replicas: 3
  spread: maxSkew 1 across zone（DoNotSchedule）
  PDB: minAvailable 2
  HPA: maxReplicas 6（扩时仍受 spread 约束）

tracks API 读多写少 → 跨 AZ 延迟可接受
MySQL 若集群内 → 另用 StatefulSet + 独立 spread（选做）

多集群地域部署见 k8a-multi；流量层 health check 需等 各 AZ 至少一条就绪，Ingress 配置见 k8s-ingress。

练习

• 写 backend 的 topologySpreadConstraints 完整 YAML 片段
• 计算：2 AZ、3 副本、maxSkew 1 时，一 AZ 最多几个 Pod？
• 说明 ScheduleAnyway 在节点资源不足时的行为

小结

Spread 把副本摊开，PDB 把更新刹住——高可用的调度层组合。 下一课用 CRD 扩展 Kubernetes API。