如何查看程序化创建Pod的亲和性/反亲和性及排查调度失败问题

查看Pod的亲和性配置 #

不管Pod是程序化创建还是通过Chart部署，其最终的亲和性规则都会保存在Pod的资源定义里，直接用kubectl导出即可：

• 导出单个Pod的完整配置（包含所有亲和/反亲和规则）：

  kubectl get pod <你的Pod名称> -n <命名空间> -o yaml
  

  在输出内容里找affinity字段，下面会包含nodeAffinity（节点亲和）、podAffinity（Pod亲和）、podAntiAffinity（Pod反亲和）三个子项，这就是Pod初始化时生效的规则。
• 哪怕Pod处于Pending状态，这个命令也能正常获取到配置，因为Pending状态的Pod已经完成了资源定义的提交。

排查节点被排除的具体原因 #

1. 查看Pod的调度事件 #

这是最直接的方式，调度器会把每个节点被排除的原因记录在Pod的事件里：

kubectl describe pod <你的Pod名称> -n <命名空间>

在输出的Events区块里，会看到类似0/16 nodes are available: 16 node(s) didn't match pod affinity/anti-affinity rules.的提示，往下翻还能找到每个节点被排除的具体细节——比如某个节点缺少Pod要求的标签，或者存在触发反亲和规则的Pod。

2. 获取更详细的调度日志 #

如果事件里的信息不够明确，加上-v=6参数可以输出调度器的决策细节：

kubectl describe pod <你的Pod名称> -n <命名空间> -v=6

这个级别的日志会展示调度器对每个节点的亲和性校验过程，能精准定位到哪条规则不满足。

3. 核对节点标签与亲和规则 #

如果是节点亲和性（nodeAffinity）导致的问题，先列出所有节点的标签，对比Pod的规则：

kubectl get nodes --show-labels

重点看Pod规则里的requiredDuringSchedulingIgnoredDuringExecution（强制要求的规则），只要有一条不匹配，节点就会被排除。

4. 排查Pod间亲和/反亲和冲突 #

如果是Pod级别的亲和/反亲和问题，先查看当前集群中同命名空间（或规则指定的命名空间）的Pod标签：

kubectl get pods -n <命名空间> --show-labels

比如Pod的反亲和规则要求不能和带有app=xxx标签的Pod同节点，但所有16个节点上都有这个标签的Pod，就会导致调度失败。

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