3. Kubernetes 节点拓扑：节点标签（region/zone）、内置拓扑键、节点亲和性

在 Kubernetes 集群中，节点拓扑是故障域划分的物理基础。OPA 策略需要验证节点标签的完整性、拓扑键的合规性以及亲和性规则的边界条件。本节将系统梳理这三层概念及其在策略测试中的关键作用。

3.1 节点标签：region 与 zone 的语义约定

Kubernetes 节点通过标签（Label）标识其所在的故障域。社区和云厂商普遍遵循以下约定：

3.2 内置拓扑键：Kubernetes 的故障域抽象

Kubernetes 预定义了一组内置拓扑键，用于在 Pod 调度、拓扑分布约束（TopologySpreadConstraints）和卷拓扑（CSI Topology）中引用故障域。常见的内置拓扑键包括：

• kubernetes.io/hostname — 节点主机名，代表最细粒度的故障域（单个物理机/虚拟机）。
• topology.kubernetes.io/zone — 可用区，代表中等粒度的故障域。
• topology.kubernetes.io/region — 地理区域，代表最粗粒度的故障域。

在 OPA 策略中，需要验证用户定义的拓扑分布约束是否使用了合法的内置拓扑键，避免使用拼写错误或自定义的无效键名。

3.3 节点亲和性：调度约束与故障域绑定

节点亲和性（Node Affinity）允许用户将 Pod 调度到特定拓扑域的节点上。亲和性规则分为两种：

OPA 策略需要检查以下边界条件：

• 硬约束中引用的 region 或 zone 值是否存在于集群节点标签中。
• 软约束的权重是否为正整数且不超过 100。
• 是否同时使用了 region 和 zone 的亲和性规则，导致调度约束过于严格。

3.4 拓扑关系与策略验证流程

下图展示了节点标签、内置拓扑键和节点亲和性之间的逻辑关系，以及 OPA 策略在其中的验证位置：

3.5 策略测试的边界条件清单

针对节点拓扑的 OPA 策略测试，需要覆盖以下边界条件：

3.6 节点拓扑与 Pod 拓扑分布约束的联动

除了节点亲和性，Pod 拓扑分布约束（TopologySpreadConstraints）也依赖节点拓扑键。OPA 策略需要同时验证：

• topologyKey 字段是否使用了内置拓扑键。
• maxSkew 值是否在合理范围（通常为 1-3）。
• whenUnsatisfiable 字段是否为 DoNotSchedule 或 ScheduleAnyway。

3.7 策略代码示例：验证节点标签完整性

以下 OPA 策略片段用于验证节点是否同时具备 region 和 zone 标签：

package kubernetes.admission

import future.keywords.in

# 验证节点标签完整性
deny[msg] {
    input.request.kind.kind == "Node"
    node := input.request.object
    required_labels := {"topology.kubernetes.io/region", "topology.kubernetes.io/zone"}
    missing := [label | label := required_labels[_]; not node.metadata.labels[label]]
    count(missing) > 0
    msg := sprintf("节点 %v 缺少必要拓扑标签: %v", [node.metadata.name, missing])
}

# 验证 Pod 拓扑分布约束中的拓扑键
deny[msg] {
    input.request.kind.kind == "Pod"
    pod := input.request.object
    constraints := pod.spec.topologySpreadConstraints
    some i
    key := constraints[i].topologyKey
    not key in ["kubernetes.io/hostname", "topology.kubernetes.io/zone", "topology.kubernetes.io/region"]
    msg := sprintf("Pod %v 使用了非法的拓扑键: %v", [pod.metadata.name, key])
}