Kubernetes Pod调度失败：新增节点不符合亲和性规则求助

集群环境与问题背景 #

Kubernetes集群包含1个master节点、1个原有worker节点，近期新增一台CentOS 8临时worker节点temp-worker，节点状态如下：

节点详情 #

NAME            STATUS   ROLES                  AGE     VERSION
master-node     Ready    control-plane,master   34d     v1.20.2
temp-worker     Ready    <none>                 5h48m   v1.20.2
worker-node-2   Ready    worker                 34d     v1.20.0

尝试部署2副本Pod，配置了Pod亲和性与反亲和性规则后，Pod始终处于Pending状态，相关配置与调度日志如下：

Pod配置 #

podAffinity:
  requiredDuringSchedulingIgnoredDuringExecution:
  - labelSelector:
      matchExpressions:
      - key: app                      #security
        operator: DoesNotExist
    topologyKey: kubernetes.io/hostname
podAntiAffinity:
  preferredDuringSchedulingIgnoredDuringExecution:
  - weight: 100
    podAffinityTerm:
      labelSelector:
        matchExpressions:
        - key: app                      #security
          operator: In
          values:
          - hello-app
      topologyKey: kubernetes.io/hostname

Pod调度事件日志 #

Events:
  Type     Reason            Age    From               Message
  ----     ------            ----   ----               -------
  Warning  FailedScheduling  3m50s  default-scheduler  0/3 nodes are available: 1 node(s) didn't match pod affinity rules, 1 node(s) didn't match pod affinity/anti-affinity, 2 node(s) had volume node affinity conflict.
  Warning  FailedScheduling  3m50s  default-scheduler  0/3 nodes are available: 1 node(s) didn't match pod affinity rules, 1 node(s) didn't match pod affinity/anti-affinity, 2 node(s) had volume node affinity conflict.

核心问题诊断 #

1. Pod亲和性规则逻辑错误 #

你使用requiredDuringSchedulingIgnoredDuringExecution类型的Pod亲和性，要求调度节点上不存在任何带有app标签的Pod，这个逻辑存在本质问题：

• 亲和性（podAffinity）的设计目的是让Pod调度到有指定Pod的节点，而你用DoesNotExist反向限制，不仅逻辑混淆，还会排除所有已有app标签Pod的节点（比如原有worker节点）；
• master节点默认带有污点，不会调度用户Pod，直接被排除。

2. 反亲和性规则冗余且矛盾 #

配置的偏好型反亲和性要求"尽量不调度到已有app=hello-app Pod的节点"，这和亲和性规则的强制要求完全重复，反而增加调度逻辑复杂度，没有实际作用。

3. 新增节点的存储卷冲突 #

调度日志提到"2 node(s) had volume node affinity conflict"，说明Pod关联的存储卷（PVC/PV）存在节点亲和性限制，新增的temp-worker节点不满足存储卷的挂载要求（比如PV绑定了原有worker节点，或者存储类仅支持特定节点），导致该节点也被排除。

修复方案 #

1. 修正亲和性/反亲和性规则 #

如果你的需求是避免Pod调度到已有app=hello-app Pod的节点，应该用强制型反亲和性替代原有错误的亲和性规则，删除冗余的偏好规则：

podAntiAffinity:
  requiredDuringSchedulingIgnoredDuringExecution:
  - labelSelector:
      matchExpressions:
      - key: app
        operator: In
        values:
        - hello-app
    topologyKey: kubernetes.io/hostname

2. 解决存储卷节点亲和性冲突 #

• 检查Pod关联的PV，确认是否配置了nodeAffinity，调整规则让temp-worker节点满足条件；
• 如果使用动态存储类，检查存储类的节点亲和性配置，确保temp-worker节点符合存储挂载要求；
• 若不需要存储卷绑定特定节点，改用支持跨节点挂载的存储（如NFS、分布式存储），或删除不必要的存储卷配置。

3. 可选：调整master节点调度（非生产环境） #

如果需要让master节点参与调度，可移除其污点：

kubectl taint nodes master-node node-role.kubernetes.io/master-

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