📚 课程目录第3章故障域模型设计

3. 故障域模型设计：物理故障域与逻辑故障域的抽象

在 Kubernetes 集群中，故障域（Failure Domain）是描述资源隔离边界和故障影响范围的核心概念。设计合理的故障域模型，是 OPA Gatekeeper 实现准入控制策略的基础。本章将物理故障域与逻辑故障域进行系统化抽象，为后续策略编写提供清晰的模型支撑。

3.1 物理故障域：机房与机架

物理故障域对应基础设施的硬件隔离边界，通常包含两个层级：机房（Datacenter） 和 机架（Rack）。每个层级代表一个独立的故障爆炸半径。

层级	故障范围	典型故障场景	Kubernetes 标签示例
机房	整个数据中心	电力中断、网络骨干故障、火灾	`topology.kubernetes.io/zone=dc-shanghai-1`
机架	单个机架内所有节点	交换机故障、机架 PDU 断电、上联链路中断	`topology.kubernetes.io/rack=rack-a12`

  设计要点： 物理故障域标签应直接绑定到 Node 对象上，作为节点拓扑信息的一部分。OPA Gatekeeper 通过检查 Pod 的 nodeSelector 或 topologySpreadConstraints 来验证 Pod 是否跨物理故障域分布。

3.2 逻辑故障域：可用区与地域

逻辑故障域是对物理故障域的更高层次抽象，通常由云平台或基础设施团队定义。它不直接对应某个物理设备，而是代表一组资源的逻辑分组。

地域（Region）：地理上隔离的区域，通常包含多个可用区。地域间延迟较高，用于实现跨区域容灾。
可用区（Availability Zone, AZ）：地域内独立的故障隔离区域，每个可用区由一组独立的物理设施（机房、电力、网络）构成。可用区之间低延迟互联，但故障隔离。

属性	地域（Region）	可用区（AZ）
隔离级别	完全独立，跨地域故障不扩散	部分独立，同地域内故障隔离
网络延迟	高（通常 > 10ms）	低（通常 < 2ms）
典型用途	异地多活、灾备	高可用部署、负载均衡
Kubernetes 标签	`topology.kubernetes.io/region`	`topology.kubernetes.io/zone`

3.3 故障域抽象模型

将物理故障域与逻辑故障域统一抽象为层级模型，便于在 OPA 策略中统一处理。模型采用 树形结构，根节点为全局集群，叶子节点为单个节点。

抽象原则： 每个故障域层级都对应一个独立的 topology.kubernetes.io/* 标签。OPA 策略通过匹配这些标签的取值组合，判断 Pod 是否满足故障域分布要求。

3.4 故障域标签体系与 OPA 策略映射

在 Kubernetes 中，故障域信息通过节点标签（Node Labels）暴露。OPA Gatekeeper 通过检查 Pod 的调度约束，确保 Pod 分布满足故障域隔离要求。以下是推荐的标签体系与策略映射关系：

# 节点标签示例（Node 对象）
apiVersion: v1
kind: Node
metadata:
  labels:
    topology.kubernetes.io/region: "cn-east"
    topology.kubernetes.io/zone: "cn-east-1a"
    topology.kubernetes.io/datacenter: "dc-shanghai-1"
    topology.kubernetes.io/rack: "rack-a12"
spec:
  ...

# OPA 策略片段：检查 Pod 是否跨可用区部署
package k8s.failuredomain

violation[{"msg": msg}] {
    input.request.kind.kind == "Pod"
    spec := input.request.object.spec
    # 获取 Pod 的 topologySpreadConstraints
    constraints := spec.topologySpreadConstraints[_]
    constraints.topologyKey == "topology.kubernetes.io/zone"
    constraints.whenUnsatisfiable == "DoNotSchedule"
    # 如果 maxSkew 大于 1，说明分布不均衡
    constraints.maxSkew > 1
    msg := sprintf("Pod 分布违反可用区故障域约束：maxSkew 为 %v，要求不超过 1", [constraints.maxSkew])
}

注意： 物理故障域（机房/机架）标签并非 Kubernetes 内置标签，需要管理员手动添加或通过外部控制器自动注入。逻辑故障域（地域/可用区）标签通常由云平台自动管理。OPA 策略应同时支持两种标签体系，并允许用户通过参数配置故障域层级。

3.5 故障域模型设计原则

在设计故障域模型时，应遵循以下原则，确保模型的可扩展性和策略的可维护性：

层级清晰：每个故障域层级有明确的故障边界和标签键，避免层级混淆。
标签标准化：统一使用 topology.kubernetes.io/* 命名空间，与 Kubernetes 社区标准保持一致。
最小爆炸半径：每个故障域层级的故障影响范围应尽可能小，避免单点故障扩散。
策略可配置：OPA 策略应支持通过参数指定故障域层级和约束阈值，适应不同场景。
兼容多云：模型应同时支持自建机房和公有云环境，通过标签映射实现统一管理。

通过上述抽象，OPA Gatekeeper 可以基于统一的故障域模型，对 Pod 的调度分布进行准入控制，确保关键工作负载在物理和逻辑层面都具备故障隔离能力。