📚 课程目录第3章故障域隔离基础

3. 故障域隔离基础：节点故障域、可用区(AZ)、区域(Region)、Pod拓扑约束

故障域（Fault Domain）是云原生架构中实现高可用与弹性的核心抽象。Kubernetes 通过将物理基础设施的故障边界抽象为节点、可用区（Availability Zone, AZ）和区域（Region）三个层级，配合 Pod 拓扑约束策略，使工作负载能够感知并避开单点故障。理解这些概念是正确编写 Helm Values 配置模板、实现故障域隔离参数校验的前提。

3.1 故障域层级模型

Kubernetes 集群的故障域从下到上分为三个层级，每一层对应不同的故障范围和隔离能力：

层级	故障范围	Kubernetes 标签/字段	典型故障场景
节点 (Node)	单台物理机或虚拟机	`kubernetes.io/hostname`	硬件故障、内核崩溃、磁盘损坏
可用区 (AZ)	同一 Region 内独立的物理数据中心	`topology.kubernetes.io/zone`	电力中断、网络分区、制冷故障
区域 (Region)	地理上隔离的完整云服务区域	`topology.kubernetes.io/region`	自然灾害、大规模光缆中断、区域级服务瘫痪

关键认知： 故障域是嵌套关系。一个 Region 包含多个 AZ，一个 AZ 包含多个 Node。Pod 的拓扑约束策略正是利用这种嵌套关系，将副本分散到不同故障域中，避免单点故障导致整个服务不可用。

3.2 节点故障域：最底层的隔离单元

节点是 Kubernetes 中最小的故障域单元。每个节点对应一台物理服务器或云虚拟机，拥有独立的 CPU、内存、存储和网络栈。节点故障域通过 kubernetes.io/hostname 标签唯一标识。

在 Helm Values 中，节点故障域通常通过 nodeSelector 或 nodeAffinity 来约束 Pod 调度。例如，将特定工作负载固定到 GPU 节点或高内存节点：

# values.yaml 片段
nodeSelector:
  node-type: gpu
  kubernetes.io/hostname: "node-01"

注意： 直接使用 kubernetes.io/hostname 做硬绑定会破坏故障域隔离，因为所有 Pod 都调度到同一节点。生产环境应优先使用 nodeAffinity 的 preferredDuringSchedulingIgnoredDuringExecution 软约束，或结合 Pod 拓扑约束实现跨节点分布。

3.3 可用区 (AZ)：跨数据中心的高可用基石

可用区是同一 Region 内物理隔离的数据中心，拥有独立的电力、冷却和网络。AZ 之间通过低延迟光纤互联，但故障域完全独立。Kubernetes 通过 topology.kubernetes.io/zone 标签标记每个节点所属的可用区。

在 Helm 模板中，AZ 级别的故障域隔离通常通过 topologySpreadConstraints 实现。以下是一个典型的跨 AZ 分布配置：

# values.yaml 片段
topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: topology.kubernetes.io/zone
    whenUnsatisfiable: DoNotSchedule
    labelSelector:
      matchLabels:
        app: my-app

参数说明：

maxSkew：允许的最大 Pod 分布不均衡度。值为 1 表示每个 AZ 上的 Pod 数量差不超过 1。
topologyKey：指定故障域维度，此处为可用区。
whenUnsatisfiable：当无法满足约束时的行为。 DoNotSchedule 表示不调度，ScheduleAnyway 表示尽量满足。

3.4 区域 (Region)：地理级灾难恢复

区域是最大的故障域，通常跨越数百公里。跨 Region 部署可以实现地理级灾难恢复，但会引入更高的网络延迟和数据同步成本。Kubernetes 通过 topology.kubernetes.io/region 标签标识节点所属区域。

跨 Region 的 Pod 拓扑约束与 AZ 类似，但 topologyKey 改为 region：

# values.yaml 片段
topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: topology.kubernetes.io/region
    whenUnsatisfiable: DoNotSchedule
    labelSelector:
      matchLabels:
        app: my-app

  实践建议： 在 Helm Values 中，建议将 Region 和 AZ 的拓扑约束同时配置，形成双层故障域隔离。先按 Region 分布，再在每个 Region 内按 AZ 分布，确保即使整个 Region 故障，其他 Region 仍能提供服务。

3.5 Pod 拓扑约束：故障域隔离的调度引擎

Pod 拓扑约束（Pod Topology Spread Constraints）是 Kubernetes 内置的调度策略，用于将 Pod 副本均匀分布到指定的故障域中。它通过 topologyKey 指定故障域维度，通过 maxSkew 控制分布均匀度。

以下 SVG 图展示了 Pod 拓扑约束在节点、AZ、Region 三个层级上的分布效果：

3.6 故障域隔离的 Helm Values 参数校验要点

在 Helm 模板中，故障域隔离相关的 Values 参数需要经过严格的校验，确保配置正确且符合预期。以下是常见的校验规则：

参数路径	校验规则	错误示例	正确示例
`topologySpreadConstraints[].topologyKey`	必须是合法的 Kubernetes 拓扑键，如 `topology.kubernetes.io/zone`	`zone`（缺少前缀）	`topology.kubernetes.io/zone`
`topologySpreadConstraints[].maxSkew`	必须为正整数，通常为 1 或 2	`0` 或 `-1`	`1`
`topologySpreadConstraints[].whenUnsatisfiable`	必须是 `DoNotSchedule` 或 `ScheduleAnyway`	`Fail`	`DoNotSchedule`
`nodeSelector` 与 `topologySpreadConstraints` 共存	不能同时使用硬性 `nodeSelector` 绑定单一节点和拓扑约束	`nodeSelector: {kubernetes.io/hostname: node-01}` + 拓扑约束	使用 `nodeAffinity` 软约束替代

3.7 故障域隔离配置的常见陷阱

陷阱一：拓扑键拼写错误。例如将 topology.kubernetes.io/zone 误写为 topology.kubernetes.io/Zone（大小写敏感），导致约束不生效。
陷阱二：maxSkew 设置过大。当副本数较少时，maxSkew 设为 2 可能导致所有 Pod 集中到同一个 AZ，失去隔离意义。
陷阱三：忽略 labelSelector 匹配。拓扑约束必须通过 labelSelector 指定目标 Pod，否则约束会作用于命名空间下所有 Pod，导致调度冲突。
陷阱四：跨 Region 约束未考虑网络延迟。跨 Region 的 Pod 间通信延迟可能高达数十毫秒，需要结合 podAntiAffinity 和 topologySpreadConstraints 综合设计。

  Helm Values 校验实践： 在 Chart 的 templates/_helpers.tpl 中定义校验函数，使用 fail 函数在模板渲染阶段拦截非法参数。例如：

  {{- if not (has .Values.topologySpreadConstraints.topologyKey (list "topology.kubernetes.io/zone" "topology.kubernetes.io/region")) -}}

  {{- fail "topologyKey must be zone or region" -}}

  {{- end -}}

3.8 故障域隔离与 Helm Values 的映射关系

以下 SVG 图展示了 Helm Values 参数如何映射到 Kubernetes 的故障域隔离配置：

3.9 故障域隔离的验证方法

在 Helm 部署后，可以通过以下命令验证故障域隔离是否生效：

# 查看 Pod 分布到各节点
kubectl get pods -o wide --selector app=my-app

# 查看 Pod 分布到各可用区
kubectl get pods -o custom-columns=NAME:.metadata.name,NODE:.spec.nodeName,ZONE:.metadata.labels.topology\.kubernetes\.io/zone

# 查看 Pod 拓扑约束是否满足
kubectl describe pod my-app-0 | grep -A5 "Topology Spread Constraints"

通过以上输出，可以直观地确认 Pod 是否按照预期的故障域策略分布，从而验证 Helm Values 配置的正确性。