我不得不重新输入大部分这是由手，因为我的系统测试上目前不能连接到互联网，请原谅任何明显的错别字。
我们通过编程的方式将部署安排到一个有19个节点的大型沙箱中，其中16个节点是工作节点。通常我们会扫描可用的节点，找到具有最多可用内存/CPU的节点，并选择它进行新的部署，尽管考虑到下面的关系，我想知道这个特定的部署是否是通过我们代码的其他部分进行部署的，因为它根本没有nodeAffinity。
无论采用哪种方式，部署通常都能正常工作，但有时Pod会无法安排

0/19 nodes are available:  16 node(s) didn't match pod affinity rules, 16 node(s) didn't match pod affinity/anti-affinity, 3 node(s) had taint (node-role.kubernetes.io/controlplane: true), that the pod didn't tolerate

我已经使用kubectl在创建pod之后查找了它们的相似性。我们有多个几乎相同的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"
         }
      ]
   }

我通过查看spec.affinity得到这个结果：

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

我以为我理解了关联性，但显然不是因为我在pod或节点上找不到任何“主机”标签。我也不明白为什么pod关联性会阻止pod在节点上被调度。
更重要的是，我不明白一大堆“是”是什么意思，它不是字面上寻找一个标签与“是”的价值，是吗？
由于我不明白在分配一个正常工作的pod时，亲和性是如何工作的，所以我真的不明白为什么同一个亲和性偶尔会失败。如果能帮助我理解亲和性实际上在做什么，或者为什么它偶尔会失败，我将不胜感激。