2. K8s拓扑分布约束：topologySpreadConstraints工作原理，如何利用Label标识故障域

2.1 为什么需要拓扑分布约束

在集群故障域划分场景下，Pod 的调度位置直接影响服务的高可用性和资源利用率。默认的调度器虽然会考虑节点资源，但不会主动将同一工作负载的 Pod 分散到不同的故障域（如可用区、机房、机架）。当某个故障域发生故障时，所有 Pod 可能同时不可用。

topologySpreadConstraints（拓扑分布约束）是 Kubernetes 1.19+ 引入的调度特性，允许用户显式定义 Pod 在拓扑域中的分布规则，从而实现跨故障域的均匀调度。

2.2 核心概念与工作原理

拓扑分布约束的工作原理基于以下三个核心要素：

• 拓扑键（topologyKey）： 用于标识故障域的节点标签键，如 topology.kubernetes.io/zone、kubernetes.io/hostname。
• 最大偏差（maxSkew）： 允许的 Pod 分布不均匀程度。数值越小，分布越均匀。
• 当满足时（whenUnsatisfiable）： 约束不满足时的处理策略，可选 DoNotSchedule（硬约束）或 ScheduleAnyway（软约束）。

2.3 利用Label标识故障域

Kubernetes 节点上的 Label 是标识故障域的基础。常见的故障域标签体系包括：

• 云厂商标准标签： topology.kubernetes.io/region（区域）、topology.kubernetes.io/zone（可用区）
• 物理数据中心标签： topology.kubernetes.io/datacenter、topology.kubernetes.io/rack、topology.kubernetes.io/hostname
• 自定义标签： 如 failure-domain.beta.kubernetes.io/zone（旧版兼容）、node.kubernetes.io/instance-type

2.4 拓扑分布约束工作流程

调度器在处理拓扑分布约束时，遵循以下步骤：

1. 解析约束定义： 读取 Pod 规约中的 topologySpreadConstraints 字段。
2. 获取节点标签： 遍历所有可调度节点，提取 topologyKey 对应的标签值。
3. 计算当前分布： 根据 labelSelector 统计每个拓扑域中已运行的 Pod 数量。
4. 评估约束： 对于每个候选节点，计算将其加入后各拓扑域的 Pod 数量，检查 maxSkew 是否满足。
5. 执行调度决策： 根据 whenUnsatisfiable 策略决定是否调度到该节点。

2.5 配置示例与解析

以下是一个典型的拓扑分布约束配置，要求将 app: nginx 的 Pod 均匀分布在可用区级别：

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

2.6 多约束组合与优先级

Kubernetes 允许在同一个 Pod 规约中定义多个拓扑分布约束，调度器会按顺序依次评估。多约束组合的典型场景：

• 第一层约束： 按可用区（zone）均匀分布，maxSkew: 1，硬约束
• 第二层约束： 按主机（hostname）均匀分布，maxSkew: 2，软约束

2.7 故障域标签管理策略

为了有效利用拓扑分布约束，SRE 团队需要建立统一的故障域标签管理策略：

• 标签标准化： 所有节点必须包含 topology.kubernetes.io/zone 和 kubernetes.io/hostname 标签。
• 自动化注入： 使用节点初始化脚本或 Kubernetes 控制器自动添加故障域标签。
• 定期审计： 通过 kubectl get nodes -L topology.kubernetes.io/zone 检查标签完整性。
• 变更管理： 故障域标签变更需经过审批，避免影响正在运行的调度约束。

2.8 与可观测性的关联

在指标采集与告警分层场景中，拓扑分布约束直接影响：

• 指标采集覆盖： 确保每个故障域都有 Pod 运行，避免采集盲区。
• 告警阈值设计： 当某个故障域 Pod 数量偏离预期时，触发告警。
• 故障域健康度： 通过 kube_pod_status_phase 和 kube_node_labels 指标，按故障域聚合 Pod 状态。