3. 故障域模型：物理故障域与逻辑故障域
在 Kubernetes 集群升级与节点迁移场景中，故障域（Failure Domain）是定义系统容错边界的基础单元。理解物理与逻辑两个维度的故障域模型，是设计隔离策略、避免单点失效的前提。本节从物理故障域（机架、可用区、区域）和逻辑故障域（节点池、标签、污点）两个层面展开，并给出对应的隔离策略。
3.1 物理故障域
物理故障域由基础设施的物理拓扑决定，通常按共享风险组（Shared Risk Group, SRG）划分。Kubernetes 通过内置标签（如 topology.kubernetes.io/zone）将节点与物理故障域关联。
| 故障域层级 | Kubernetes 标签示例 | 故障范围 | 典型故障场景 |
|---|---|---|---|
| 机架（Rack） | topology.kubernetes.io/rack |
单机架电源/网络交换机故障 | 机架断电、TOR 交换机宕机 |
| 可用区（AZ） | topology.kubernetes.io/zone |
独立数据中心或电力区域 | AZ 级网络中断、制冷失效 |
| 区域（Region） | topology.kubernetes.io/region |
跨 AZ 的地理区域 | 地震、大规模电力故障 |
实践要点：在集群升级时，应确保同一工作负载的 Pod 副本分布在至少两个不同的物理故障域中。例如，将 3 个副本分别调度到 3 个不同的可用区，避免单个 AZ 故障导致全部副本丢失。
3.2 逻辑故障域
逻辑故障域通过 Kubernetes 的调度与隔离机制人为定义，不依赖物理拓扑。常见的逻辑故障域包括节点池、标签和污点。
- 节点池（Node Pool）：一组具有相同配置（如实例类型、操作系统、内核版本）的节点集合。节点池是集群升级的最小操作单元。
- 标签（Label）：键值对形式的元数据，用于标识节点属性（如
node-role.kubernetes.io/control-plane）。标签是 Pod 调度亲和性/反亲和性的基础。 - 污点（Taint）：节点上的排斥标记，阻止不匹配容忍度的 Pod 被调度。污点常用于隔离特殊硬件节点或维护中的节点。
| 逻辑故障域类型 | 定义方式 | 隔离粒度 | 升级场景作用 |
|---|---|---|---|
| 节点池 | 云厂商 API 或集群自动缩放组 | 粗粒度（整组节点） | 按节点池分批升级，控制爆炸半径 |
| 标签 | kubectl label node |
细粒度（单个节点） | 通过 nodeSelector 或 nodeAffinity 精确调度 |
| 污点 | kubectl taint node |
细粒度（单个节点） | 在升级前标记节点为不可调度，驱逐已有 Pod |
3.3 故障域隔离策略
故障域隔离策略的核心目标是：确保任何单一故障域失效时，工作负载仍能维持可用副本数。以下策略按物理与逻辑维度分别给出。
3.3.1 物理故障域隔离策略
- 跨 AZ 部署：使用
topologySpreadConstraints将 Pod 均匀分布到多个可用区。 - 机架感知调度：在自建机房中，通过自定义调度器或
podAntiAffinity避免 Pod 集中在同一机架。 - Region 级容灾：对于关键业务，部署多集群联邦（Federation），实现跨 Region 故障切换。
3.3.2 逻辑故障域隔离策略
- 节点池隔离：将控制面节点与工作节点分属不同节点池，升级时先升级工作节点池，再升级控制面节点池。
- 标签与污点配合：在升级前对目标节点添加
node.kubernetes.io/unschedulable: NoSchedule污点，确保新 Pod 不会被调度到待升级节点。 - Pod 反亲和性：设置
podAntiAffinity规则，使同一 Deployment 的 Pod 不调度到同一逻辑故障域（如同一个节点池或同一组标签的节点）。
常见误区：仅依赖物理故障域而忽略逻辑故障域。例如，虽然 Pod 分布在三个不同 AZ，但所有 Pod 都运行在同一节点池中，当该节点池因升级被整体封锁时，所有副本同时不可用。正确的做法是：物理与逻辑故障域交叉隔离。
3.4 故障域模型关系图
下图展示了物理故障域与逻辑故障域的层级关系，以及隔离策略的作用位置。
3.5 故障域隔离策略对比
下表从隔离粒度、配置复杂度、升级影响范围三个维度对比常见策略，帮助你在实际集群升级中选择合适方案。
| 策略 | 隔离粒度 | 配置复杂度 | 升级影响范围 | 推荐场景 |
|---|---|---|---|---|
| 跨 AZ 部署 | 物理（AZ） | 低（内置调度器支持） | 单个 AZ 故障不影响全局 | 公有云多 AZ 集群 |
| 节点池分批 | 逻辑（节点池） | 中（需定义节点池策略） | 单节点池升级期间该池 Pod 迁移 | 大规模集群滚动升级 |
| 污点+容忍度 | 逻辑（节点） | 低（kubectl taint） | 仅影响被封锁节点上的 Pod | 节点级维护或故障隔离 |
| Pod 反亲和性 | 逻辑（Pod） | 中（需定义 topologyKey） | 确保副本不共置，间接限制升级范围 | 有状态服务或关键无状态服务 |
最佳实践组合：在 Helm 升级流程中，建议同时启用“跨 AZ 部署 + 节点池分批 + 污点封锁”三层隔离。例如：先对节点池 A 的所有节点添加
NoSchedule 污点，等待 Pod 被驱逐到其他 AZ 的节点池 B 后，再执行节点池 A 的升级操作。这样即使升级过程中出现异常，工作负载仍可在其他故障域中正常运行。