Node Affinity是否会引发Pod驱逐？集群Job Pod异常终止问题咨询

核心结论 #

你配置的preferredDuringSchedulingIgnoredDuringExecution类型节点亲和性不会导致Pod被驱逐，具体原因如下：

1. 该亲和性规则仅作用于调度阶段 #

preferredDuringSchedulingIgnoredDuringExecution的命名直接定义了它的行为边界：

• 调度阶段生效：调度器会根据权重优先选择匹配标签的节点，但如果没有符合条件的节点，仍可将Pod调度到其他节点。
• 运行阶段完全忽略：Pod一旦在节点上启动运行，该亲和性规则不会对运行中的Pod产生任何约束，kubelet不会因为节点标签变化或亲和性规则触发Pod驱逐。

2. 你的PriorityClass配置也不会触发驱逐 #

你配置的high-priority-nonpreempting优先级类：

• preemptionPolicy: Never：既不会抢占低优先级Pod，自身作为高优先级Pod，也不会被其他更高优先级Pod抢占（抢占逻辑是高优先级抢占低优先级，你的Pod已处于高优先级层级且禁止抢占，因此不会被抢占驱逐）。
• 你已排除节点压力导致的驱逐，资源不足触发的驱逐也可排除。

Pod随机终止的其他排查方向 #

既然亲和性和优先级配置不是问题，Pod随机终止并被Job重建，建议从以下方向排查：

• Pod进程异常：容器内应用进程崩溃、未捕获异常退出，或单个Pod内存/CPU超出limits被OOMKilled（需查看Pod事件中的OOMKilled记录，节点级压力正常不代表单个Pod资源未超限）。
• Job配置逻辑：检查Job的spec.completions、spec.parallelism、spec.activeDeadlineSeconds等参数，是否存在自动重启或重建Pod的规则。
• 节点临时异常：节点重启、网络波动导致kubelet与API Server失联，Pod被标记为失败后触发Job重建。
• 第三方组件干扰：集群内运维工具、自定义控制器、监控告警工具等是否存在误删Pod的逻辑。

你提供的配置参考 #

PriorityClass配置 #

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority-nonpreempting
value: 1000000
preemptionPolicy: Never
globalDefault: false
description: "This priority class will not cause other pods to be preempted."

Pod示例配置 #

apiVersion: v1
kind: Pod
metadata:
  namespace: default
  name: testingpod
spec:
  dnsPolicy: None
  priorityClassName: high-priority-nonpreempting
  containers:
  - name: container
    image: imageuri
    resources:
      limits:
        cpu: 2
        memory: 4G
  restartPolicy: Never
  dnsConfig:
    nameservers:
    - 8.8.8.8
  affinity:
    nodeAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        preference:
          matchExpressions:
          - key: zone
            values:
            - zone-1
            operator: In
      - weight: 90
        preference:
          matchExpressions:
          - key: zone
            values:
            - zone-2
            operator: In

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