Kubernetes加权节点亲和性优先级高于高权重Pod亲和性问题咨询

核心结论 #

节点亲和性和Pod亲和性的权重是共同参与调度打分的，不存在节点亲和性“始终优先”的机制。你遇到的问题并非权重失效，而是规则匹配范围或调度打分逻辑的细节导致的。

具体排查方向 #

1. 节点亲和性的字符串比较陷阱 #

你的节点亲和性规则使用Gt操作符匹配example.com/capacity-remaining标签：

- preference:
    matchExpressions:
    - key: example.com/capacity-remaining
      operator: Gt
      values:
      - "2457600"
  weight: 1

注意：Kubernetes对标签值的Gt/Lt操作是字符串字典序比较，而非数值比较。如果你的节点标签值是数字格式字符串（比如"3000000"），字符串比较"3000000" > "2457600"是成立的，但如果标签值格式不一致（比如纯数字不带引号、或包含非数字字符），可能导致大量节点都满足该规则，稀释了Pod亲和性的权重优势。

2. 调度器打分逻辑验证 #

Kubernetes调度器在打分阶段会累加所有满足的偏好型规则权重：

• 满足节点亲和性：+1分
• 满足第一个Pod亲和性规则：+100分
• 满足第二个Pod亲和性规则：+80分

若某节点同时满足Pod亲和性的两个规则，总分会是181分，远高于仅满足节点亲和性的1分。出现你描述的情况，大概率是没有节点同时满足Pod亲和性规则，或者Pod亲和性规则匹配失败。

3. Pod亲和性规则有效性检查 #

逐一验证以下条件：

• 集群中是否存在带example.com/lead-pod: receiver-0或example.com/imagery-destination: live-stitcher标签的Pod？
• 这些Pod所在的节点是否满足节点亲和性规则（example.com/capacity-remaining字符串值大于"2457600"）？
• 这些节点是否未被Pod反亲和性排除（节点上无example.com/regime: ingest标签的Pod）？

用以下命令快速验证：

# 查找符合Pod亲和性标签的Pod
kubectl get pods --all-namespaces -l example.com/lead-pod=receiver-0
kubectl get pods --all-namespaces -l example.com/imagery-destination=live-stitcher

# 查看目标Pod所在节点
kubectl get pods -o wide <pod-name>

# 检查节点的标签和已运行Pod
kubectl describe node <node-name>

4. 调度事件定位 #

查看Pod的调度事件，直接获取调度器的决策细节：

kubectl describe pod <your-pod-name>

在Events字段中，会显示节点被排除的原因、各节点的得分情况，这是定位问题最直接的方式。

总结 #

你的配置语法无错误，权重机制是生效的。问题根源在于Pod亲和性规则的实际匹配节点不存在，或节点亲和性匹配范围过大，导致调度器最终选择了仅满足节点亲和性的节点。通过上述步骤可快速定位具体原因。

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