📚 课程目录第2章故障域概念

2. 故障域概念：什么是故障域、故障域在Kubernetes中的表现、故障域与Helm的关系

2.1 故障域的定义与核心特征

故障域（Failure Domain） 是指系统中一个独立故障单元的范围——当该单元内的任意组件发生故障时，整个单元内的服务或资源都会受到影响。故障域是分布式系统韧性设计的基石，决定了系统能够容忍多大范围的失效而不导致全局不可用。

特征	说明	典型粒度
隔离性	故障域之间的故障不会相互传播	物理机、机架、可用区
共享风险	同一故障域内的资源共享同一失效源	电源、网络交换机、数据中心
边界明确	故障域的边界可被明确定义和检测	节点标签、区域拓扑键
层次性	故障域可以嵌套，形成多层容错结构	Pod → 节点 → 机架 → 可用区 → 区域

关键认知： 故障域不是"故障发生的地方"，而是"故障影响的范围"。设计高可用系统时，核心目标是将副本或实例分布到不同的故障域中，确保单个故障域失效时仍有足够的副本存活。

2.2 故障域在Kubernetes中的表现

Kubernetes 通过拓扑分布约束（Topology Spread Constraints）和 Pod 反亲和性（Pod Anti-Affinity）将故障域概念内建到调度引擎中。Kubernetes 识别的故障域层次如下：

节点级故障域： 单个节点宕机（硬件故障、内核崩溃、kubelet 失联）。
机架级故障域： 同一机架的电源或 ToR 交换机故障，导致整机架节点不可用。
可用区级故障域： 云厂商的可用区（AZ）整体故障，如电力中断、网络分区。
区域级故障域： 跨地域的完整区域（Region）失效，通常用于多活或容灾架构。

Kubernetes 使用 topology.kubernetes.io/zone 和 topology.kubernetes.io/region 标签标记节点所属的故障域。调度器通过 topologySpreadConstraints 确保 Pod 在故障域间均匀分布：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 6
  template:
    spec:
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: topology.kubernetes.io/zone
          whenUnsatisfiable: DoNotSchedule
        - maxSkew: 1
          topologyKey: kubernetes.io/hostname
          whenUnsatisfiable: ScheduleAnyway

  实战要点： 上述配置强制 Pod 在可用区之间最多偏差 1 个副本（maxSkew=1），同时在节点级别尽量分散。当某个可用区故障时，其他可用区仍有 2 个副本提供服务，实现 AZ 级容错。

2.3 故障域与Helm的关系

Helm 作为 Kubernetes 的包管理器，在故障域管理中扮演着配置编排者和拓扑感知部署者的双重角色。具体关系体现在以下三个层面：

关系维度	Helm 的作用	故障域影响
模板化拓扑约束	在 Chart 的 values.yaml 中定义 topologySpreadConstraints 参数，用户可灵活调整故障域分布策略	避免硬编码拓扑键，支持多环境差异化配置
多副本亲和性编排	通过 Helm 模板生成 PodAntiAffinity 规则，确保同一应用的多个副本分布在不同故障域	降低单点故障导致的服务完全中断风险
故障域感知的升级策略	Helm 升级时结合 PodDisruptionBudget，控制每次升级影响的故障域数量	保证滚动更新期间不出现跨故障域的大规模中断

常见陷阱： 许多 Helm Chart 默认不配置 topologySpreadConstraints，导致所有 Pod 被调度到同一个可用区。当该可用区故障时，即使有 10 个副本也会全部失效。务必在 Chart 中显式声明故障域分布策略。

2.4 故障域层次与Helm部署策略

下图展示了 Kubernetes 集群中从 Pod 到 Region 的故障域层次，以及 Helm 在每个层次上的部署控制点：

2.5 Helm故障域配置最佳实践

在 Helm Chart 中配置故障域感知时，应遵循以下原则：

参数化拓扑键： 将 topologyKey 暴露为 values 参数，支持不同集群使用不同的故障域标签（如 topology.kubernetes.io/zone 或自定义标签）。
设置合理的 maxSkew： 生产环境建议 maxSkew=1，确保故障域间副本数均衡；非关键业务可放宽至 2。
结合 PodDisruptionBudget： 在 Helm 模板中生成 PDB 资源，设置 minAvailable: 50% 或 maxUnavailable: 1，防止主动运维操作（如节点池升级）导致跨故障域中断。
多副本强制反亲和： 对于有状态服务（如数据库），使用 requiredDuringSchedulingIgnoredDuringExecution 级别的 PodAntiAffinity，强制副本分布在不同节点或可用区。

  Helm 模板示例片段： 在 Chart 的 templates/deployment.yaml 中动态生成故障域约束

{{- if .Values.topologySpreadConstraints.enabled }}
topologySpreadConstraints:
  - maxSkew: {{ .Values.topologySpreadConstraints.maxSkew | default 1 }}
    topologyKey: {{ .Values.topologySpreadConstraints.topologyKey | default "topology.kubernetes.io/zone" }}
    whenUnsatisfiable: {{ .Values.topologySpreadConstraints.whenUnsatisfiable | default "DoNotSchedule" }}
    labelSelector:
      matchLabels:
        app: {{ include "myapp.name" . }}
{{- end }}

通过上述模板化设计，Helm 使得故障域策略不再是运维人员的"事后补救"，而是作为 Chart 的固有属性在部署时自动生效，从根本上提升了集群的容错能力。