📚 课程目录第4章 Kubernetes故障域设计

4. Kubernetes 故障域设计：Node 拓扑标签、Pod 反亲和性、Pod 拓扑分布约束、节点故障域隔离策略

在 IDP 平台中，Kubernetes 集群是承载所有工作负载的核心底座。当底层节点、机架或可用区发生故障时，若 Pod 调度未考虑故障域分布，可能导致整个服务同时失效。本章深入解析 Kubernetes 原生故障域隔离机制，涵盖 Node 拓扑标签、Pod 反亲和性、Pod 拓扑分布约束以及节点故障域隔离策略，帮助你在 IDP 中构建高可用的工作负载调度体系。

4.1 故障域与拓扑标签基础

故障域（Failure Domain）是指共享单一故障点的物理或逻辑区域。Kubernetes 通过 Node 上的拓扑标签（Topology Labels）来标识故障域层级。常见的拓扑标签包括：

标签键	描述	典型值
`topology.kubernetes.io/region`	地理区域（Region）	`us-east-1`
`topology.kubernetes.io/zone`	可用区（Zone）	`us-east-1a`
`kubernetes.io/hostname`	节点主机名	`node-01`
`topology.kubernetes.io/rack`	机架（自定义标签）	`rack-01`

最佳实践：在 IDP 集群初始化时，建议通过 kubelet --node-labels 或云厂商自动注入机制，为每个节点打全三层拓扑标签（region/zone/hostname），这是后续所有故障域策略生效的前提。

4.2 Pod 反亲和性：硬约束与软约束

Pod 反亲和性（Pod Anti-Affinity）允许你指定 Pod 不应与哪些 Pod 调度到同一拓扑域。它分为两种模式：

requiredDuringSchedulingIgnoredDuringExecution（硬约束）：调度器必须满足规则，否则 Pod 无法调度。
preferredDuringSchedulingIgnoredDuringExecution（软约束）：调度器尽量满足规则，但不强制。

以下示例确保同一 Deployment 的副本不会调度到同一可用区：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: idp-gateway
spec:
  replicas: 3
  selector:
    matchLabels:
      app: idp-gateway
  template:
    metadata:
      labels:
        app: idp-gateway
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - idp-gateway
            topologyKey: topology.kubernetes.io/zone
      containers:
      - name: gateway
        image: idp/gateway:latest

  关键参数说明：

  topologyKey 指定故障域层级，例如 topology.kubernetes.io/zone 表示按可用区隔离；labelSelector 匹配需要互斥的 Pod 集合。硬约束适用于关键服务（如 API 网关、数据库），软约束适用于可容忍少量副本共存的非关键服务。

4.3 Pod 拓扑分布约束：精细化副本分布

Pod 拓扑分布约束（Pod Topology Spread Constraints）提供了比反亲和性更灵活的副本分布控制。你可以定义每个拓扑域的最大 Pod 数量差（maxSkew），以及是否按节点、可用区或自定义标签进行分布。

以下示例将 IDP 核心组件的副本均匀分布到三个可用区，允许最大偏差为 1：

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

参数	说明	推荐值
`maxSkew`	任意两个拓扑域之间 Pod 数量的最大差值	1（严格均衡）或 2（允许轻微倾斜）
`topologyKey`	用于分组的节点标签键	`topology.kubernetes.io/zone`
`whenUnsatisfiable`	不满足约束时的行为：`DoNotSchedule` 或 `ScheduleAnyway`	关键服务用 `DoNotSchedule`

注意：拓扑分布约束与反亲和性可以同时使用，但需避免规则冲突。例如，反亲和性要求每个可用区最多 1 个 Pod，而分布约束要求 maxSkew=1，两者叠加可能导致小规模副本无法调度。建议在 IDP 中优先使用拓扑分布约束，仅在需要精确互斥时补充反亲和性。

4.4 节点故障域隔离策略

节点故障域隔离策略是 IDP 平台层面的调度策略组合，用于确保工作负载在节点、机架、可用区三个层级均实现故障隔离。以下 SVG 图展示了三层隔离架构：

4.5 策略组合与 IDP 平台集成

在 IDP 平台中，建议按以下优先级组合故障域策略：

全局默认策略：为所有工作负载启用节点级反亲和性（hostname 级别），确保同一 Deployment 的 Pod 不会调度到同一节点。
关键服务策略：对 API 网关、认证服务、数据库等核心组件，叠加可用区级拓扑分布约束（maxSkew=1）和机架级反亲和性。
弹性服务策略：对无状态微服务，使用软约束（preferred）的可用区分布，允许在资源紧张时少量副本共处同一故障域。
有状态服务策略：对 StatefulSet，结合 Pod 拓扑分布约束与 PVC 拓扑感知调度，确保数据和计算在同一可用区。

  IDP 平台集成建议：

  - 在 Backstage 插件模板中预置故障域策略模板，开发者创建服务时自动注入。

  - 通过 OPA/Gatekeeper 策略引擎，强制要求所有生产环境工作负载至少包含节点级反亲和性。

  - 在 IDP 的 Service Catalog 中展示每个服务的故障域分布状态，帮助平台工程师快速识别单点故障风险。

4.6 故障域隔离效果验证

部署完成后，使用以下命令验证 Pod 分布是否符合预期：

# 查看 Pod 在可用区的分布
kubectl get pods -l app=idp-core -o custom-columns=NAME:.metadata.name,NODE:.spec.nodeName,ZONE:.spec.nodeSelector.'topology\.kubernetes\.io/zone'

# 使用拓扑分布约束检查工具
kubectl describe pod idp-core-xxx | grep -A5 "Topology Spread Constraints"

# 模拟节点故障（封锁节点）
kubectl cordon node-01
kubectl drain node-01 --ignore-daemonsets

# 验证剩余 Pod 是否仍满足故障域分布
kubectl get pods -l app=idp-core -o wide

常见陷阱：
1. 忘记为节点打拓扑标签，导致拓扑分布约束无法生效。
2. 反亲和性规则过于严格（如 required 级别 + 小副本数），导致 Pod 无法调度。
3. 拓扑分布约束的 maxSkew 设置过小，在节点滚动更新时造成调度阻塞。
4. 未考虑 DaemonSet 对节点资源的占用，导致故障域分布计算偏差。

通过合理组合 Node 拓扑标签、Pod 反亲和性、Pod 拓扑分布约束以及节点故障域隔离策略，IDP 平台可以在 Kubernetes 集群中实现从节点到可用区的多层次故障隔离，确保核心工作负载在基础设施故障时仍能保持可用性。