Pod亲和性匹配失败原因排查及host:yes含义解析

一、该Pod亲和性的作用 #

你提供的podAffinity属于硬亲和性（requiredDuringSchedulingIgnoreDuringExecution），作用规则明确：
只有当集群中存在某个节点，且该节点上已运行着同时满足以下两个标签条件的Pod时，当前待调度的Pod才能部署到这个节点：

1. Pod标签包含app.kubernetes.io/instance: <instance name>
2. Pod标签包含host: yes
topologyKey: kubernetes.io/hostname限定亲和性的匹配范围为单个节点（每个节点主机名唯一，只会匹配到存在符合条件Pod的特定节点）。

对应的配置代码块：

"podAffinity": {
  "requiredDuringSchedulingIgnoreDuringExecution": [
    {
      "labelSelector": {
        "matchExpressions": [
          {
            "key": "app.kubernetes.io/instance",
            "operator": "In",
            "values": [ "<instance name>" ]
          },
          {
            "key": "host",
            "operator": "In",
            "values": [ "yes" ]
          }
        ]
      },
      "topologyKey": "kubernetes.io/hostname"
    }
  ]
}

二、调度失败的核心原因 #

结合“找不到host:yes标签但部署通常正常”的现象，问题本质是集群中满足标签条件的Pod存在性不稳定：

• 硬亲和性是强要求，只要集群内没有任何节点上存在同时符合app.kubernetes.io/instance: <instance name>和host: yes的Pod，待调度Pod就会因亲和性不匹配而调度失败。
• 部署正常的场景说明，你的程序化部署流程中必然存在某个环节会给特定Pod自动打上host: yes标签（比如该实例的第一个Pod），只是你未捕捉到打标签的时机（比如标签被临时添加后移除，或打标签操作在后台异步执行）。

触发失败的具体场景 #

• 首次部署的竞态问题：如果第一个Pod还未被打上host: yes标签，部署流程就开始调度后续Pod，此时集群无符合条件的Pod，亲和性条件不满足导致失败。
• 符合条件的Pod被意外删除：原本集群中存在带host: yes标签的Pod，但若该Pod因重启、扩容缩容等被清理，新部署的Pod就找不到匹配节点，触发调度失败。
• 部署代码逻辑异常：负责打host: yes标签的模块偶尔执行失败，导致无Pod满足亲和性条件，进而调度失败。

另外，错误信息中提到的3 node(s) had taint是正常情况——控制平面节点带污点，你的Pod无容忍度，不会被调度到这些节点，这部分并非调度失败的核心原因，核心是16个worker节点均不满足亲和性规则。

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