如何确定以编程方式创建的pod的亲和力/反亲和力是什么？

Question

我们有问题，很少会有一个吊舱未能被调度的错误，所有16个节点都失败了，因为亲和/反亲和。我们不会期望亲缘关系阻止任何节点被调度。

我想确定调度中的亲和力失败的实际原因是什么，为此，我想我需要知道一个荚是用什么亲缘关系初始化的。但是，我无法查看图表配置文件，因为这些特定的pod是在运行时以编程方式调度的。我是否可以使用kubectl命令查看荚的亲和力设置为什么，或者确定为什么每个节点都无法检查其亲和力？

Answer 1

这是我自己想出来的。我使用的命令是：

kubectl get pods <pod_name> -o json | jq '.spec.affinity'

我不得不安装jq才能让它正常工作。如果您想查看所有豆荚的亲缘关系，我认为您需要删除荚名，并在jq命令的items[]前面添加一个. .spec。

对于那些好奇的人来说，我的亲和力是这样的

{ 
  "key": "host",
  "operator": "In",
  "values": [
     "yes"
  ]
}

对我来说，“是的”似乎不太对。所以是的，在我们的吊舱里发生了一些奇怪的事情。