配置节点亲和性仍遇Kubernetes InvalidVolume.ZoneMismatch错误

以下是可能的原因及对应的排查、解决方法：

1. 节点亲和性配置错误 #

最常见的问题是亲和性规则的标签键错误或配置层级不对：

• 新版Kubernetes（1.17+）使用topology.kubernetes.io/zone作为可用区标签键，旧版的failure-domain.beta.kubernetes.io/zone已被废弃，若配置时用了旧标签，调度器无法匹配目标节点。
• 需确保亲和性配置在runners.config.kubernetes.node_affinity层级下，而非chart的全局配置块。正确的配置示例：

runners:
  config: |
    [[runners.kubernetes]]
      namespace = "gitlab-runner"
      [runners.kubernetes.node_affinity]
        [runners.kubernetes.node_affinity.required_during_scheduling_ignored_during_execution]
          [[runners.kubernetes.node_affinity.required_during_scheduling_ignored_during_execution.node_selector_terms]]
            [[runners.kubernetes.node_affinity.required_during_scheduling_ignored_during_execution.node_selector_terms.match_expressions]]
              key = "topology.kubernetes.io/zone"
              operator = "In"
              values = ["us-east-1c"]

2. 目标节点的可用区标签缺失/不匹配 #

即使确认us-east-1c只有一个节点，仍需验证该节点是否带有正确的可用区标签：
执行命令检查节点标签：

kubectl get nodes --show-labels | grep us-east-1c

若输出中没有topology.kubernetes.io/zone=us-east-1c（或对应旧标签），调度器会忽略亲和性规则，随机选择其他节点。

3. Runner配置未正确传递到Job Pod #

GitLab Runner生成CI Job Pod时，可能未正确继承亲和性配置。需检查实际运行的Pod的调度规则：
执行命令查看Pod详情：

kubectl describe pod <pod-name> -n <runner-namespace>

在Spec部分查看Node Affinity字段，若该字段为空或规则与配置不符，说明Runner的配置未生效，需重新检查chart values的缩进和层级是否正确。

4. 集群存在干扰调度的其他规则 #

若集群中存在Pod优先级类、调度器插件（如descheduler）或节点污点/容忍度配置，可能覆盖了节点亲和性规则的优先级。需确认：

• 目标节点没有无法被Pod容忍的污点
• 集群中没有强制调度Pod到其他可用区的优先级策略

内容的提问来源于stack exchange，提问作者void_panda