Kubernetes资源调度之节点亲和

Pod节点选择器

nodeSelector指定的标签选择器过滤符合条件的节点作为可用目标节点，最终选择则基于打分机制完成。因此，后者也称为节点选择器。用户事先为特定部分的Node资源对象设定好标签，而后即可配置Pod通过节点选择器实现类似于节点的强制亲和调度。

可以通过下面的命令查看每个node上的标签

[root@k8s-01 ~]# kubectl get nodes --show-labels
NAME     STATUS   ROLES                  AGE   VERSION   LABELS
k8s-01   Ready    control-plane,master   26d   v1.22.3   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/fluentd-ds-ready=true,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=k8s-01,kubernetes.io/os=linux,node-role.kubernetes.io/control-plane=,node-role.kubernetes.io/master=,node.kubernetes.io/exclude-from-external-load-balancers=
k8s-02   Ready                     26d   v1.22.3   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/fluentd-ds-ready=true,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=k8s-02,kubernetes.io/os=linux,type=kong,ype=kong
k8s-03   Ready                     26d   v1.22.3   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/fluentd-ds-ready=true,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=k8s-03,kubernetes.io/os=linux,type=kong
k8s-04   Ready                     8d    v1.22.3   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=k8s-04,kubernetes.io/os=linux
[root@k8s-01 ~]#

给node4节点打上标签

[root@k8s-01 ~]# kubectl label nodes k8s-04 type=test
node/k8s-04 labeled

测试的yaml

echo "
apiVersion: v1
kind: Pod
metadata:labels:app: nginx-testname: nginx-test
spec:containers:- image: nginxname: nginx-testnodeSelector:type: test
" | kubectl apply -f -

查看pod的分配情况

[root@k8s-01 ~]# kubectl get pods  -o wide |grep nginx-test
nginx-test                                1/1     Running   0               58s     10.244.7.81      k8s-04              
[root@k8s-01 ~]#

然后我们可以通过 describe 命令查看调度结果：

事实上，多数情况下用户都无须关心Pod对象的具体运行位置，除非Pod依赖的特殊条件仅能由部分节点满足时，例如GPU和SSD等。即便如此，也应该尽量避免使用.spec.nodeName静态指定Pod对象的运行位置，而是应该让调度器基于标签和标签选择器为Pod挑选匹配的工作节点。另外，Pod规范中的.spec.nodeSelector仅支持简单等值关系的节点选择器，而.spec.affinity.nodeAffinity支持更灵活的节点选择器表达式，而且可以实现硬亲和与软亲和逻辑。

节点亲和调度

节点亲和性(nodeAffinity)主要是用来控制 Pod 要部署在哪些节点上，以及不能部署在哪些节点上的，它可以进行一些简单的逻辑组合了，不只是简单的相等匹配。在Pod上定义节点亲和规则时有两种类型的节点亲和关系：强制(required)亲和和首选(preferred)亲和，或分别称为硬亲和与软亲和。

• 强制亲和限定了调度Pod资源时必须要满足的规则，无可用节点时Pod对象会被置为Pending状态，直到满足规则的节点出现。
• 柔性亲和规则实现的是一种柔性调度限制，它同样倾向于将Pod运行在某类特定的节点之上，但无法满足调度需求时，调度器将选择一个无法匹配规则的节点，而非将Pod置于Pending状态。

在Pod规范上定义节点亲和规则的关键点有两个：

• 一是给节点规划并配置合乎期望的标签；
• 二是为Pod对象定义合理的标签选择器。

正如preferredDuringSchedulingIgnoredDuringExecution和requiredDuringSchedulingIgnoredDuringExecution字段名字中的后半段符串IgnoredDuringExecution隐含的意义所指，在Pod资源基于节点亲和规则调度至某节点之后，因节点标签发生了改变而变得不再符合Pod定义的亲和规则时，调度器也不会将Pod从此节点上移出，因而亲和调度仅在调度执行的过程中进行一次即时的判断，而非持续地监视亲和规则是否能够得以满足。

查看官方说明：

[root@k8s-01 ~]# kubectl explain pod.spec.affinity.nodeAffinity
KIND:     Pod
VERSION:  v1RESOURCE: nodeAffinity