了解 Pod 亲和性、它们不匹配的原因以及 yes 中的主机的含义

Question

由于我测试的系统目前无法连接到互联网，所以我不得不手动重新键入大部分内容，请原谅任何明显的拼写错误。

我们以编程方式将部署调度到一个有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或节点上找不到任何"host"标签。我也不明白为什么pod关联会阻止pod在节点上被调度。

更重要的是，我不明白一大堆&;是的&;的意思。它并不是在寻找一个值为"是"的标签;是吗?

由于我不理解在分配功能pod时affinity是如何工作的，我真的不理解为什么相同的affinity偶尔会失败。如果你能帮助我理解亲和关系到底在做什么，或者为什么它偶尔会失败，我将不胜感激。

Answer 1

这是关于pod亲和性，而不是节点亲和性。因此，标签预计将在运行的pod上。

要调度pod，您的代码要求(requiredDuringSchedulingIgnoreDuringExecution)已经有一个pod在节点("topologyKey": "kubernetes.io/hostname")上运行，并且具有匹配的标签

apiVersion: v1
kind: Pod
metadata:
name: foo
labels:
"app.kubernetes.io/instance": <instance-name>
host: yes

如果这样的pod没有在您的一个工作节点上运行，那么您的pod无法被调度。

Answer 2

您应该使用nodeAffinity ("将我安排在我喜欢的节点上")而不是podAffinity ("将我安排在我喜欢的特定pod上")。

用例的节点亲和性配置在pod.spec.affinity:

下看起来像这样

affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/hostname
operator: In
values:
- "<INSTANCE HOSTNAME>"

不过，我还是要提醒您不要使用这种方法。将您的pod强制到特定节点可能会有问题(例如，调度器可能无法解决其他亲和约束或处理污染)。

它也可能是不必要的。默认情况下，kubernetes调度器默认在分配最少的节点上调度工作负载。

NodeResourcesFit是一个调度插件，它根据可用资源和pod需求对节点进行排名。默认为LeastAllocated。