1.简介
我们知道默认的调度器在使用的时候,经过了 predicates 和 priorities 两个阶段,但是在实际的生产环境中,往往我们需要根据自己的一些实际需求来控制 Pod 的调度,这就需要用到 nodeAffinity(节点亲和性)、podAffinity(pod 亲和性) 以及 podAntiAffinity(pod 反亲和性)。
亲和性调度可以分成软策略和硬策略两种方式:
软策略就是如果现在没有满足调度要求的节点的话,Pod 就会忽略这条规则,继续完成调度过程,说白了就是满足条件最好了,没有的话也无所谓
硬策略就比较强硬了,如果没有满足条件的节点的话,就不断重试直到满足条件为止,简单说就是你必须满足我的要求,不然就不干了
对于亲和性和反亲和性都有这两种规则可以设置: preferredDuringSchedulingIgnoredDuringExecution 和requiredDuringSchedulingIgnoredDuringExecution,前面的就是软策略,后面的就是硬策略。
2.节点亲和性
节点亲和性(nodeAffinity)主要是用来控制 Pod 要部署在哪些节点上,以及不能部署在哪些节点上的,它可以进行一些简单的逻辑组合了,不只是简单的相等匹配。
比如现在我们用一个 Deployment 来管理3个 Pod 副本,现在我们来控制下这些 Pod 的调度,如下例子:(node-affinity-demo.yaml)
apiVersion: apps/v1
kind: Deployment
metadata:
name: node-affinity
labels:
app: node-affinity
spec:
replicas: 3
selector:
matchLabels:
app: node-affinity
template:
metadata:
labels:
app: node-affinity
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
name: nginxweb
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution: # 硬策略
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/hostname
operator: NotIn
values:
- k8s-node3
preferredDuringSchedulingIgnoredDuringExecution: # 软策略
- weight: 1
preference:
matchExpressions:
- key: cm
operator: In
values:
- test
上面这个 Pod 首先是要求不能运行在 k8s-node3 这个节点上,如果有个节点满足 cm=test 的话就优先调度到这个节点上。
由于上面 k8s-node02 节点我们打上了 cm=test 这样的 label 标签,所以按要求会优先调度到这个节点来的,现在我们来创建这个 Pod,然后查看具体的调度情况是否满足我们的要求。
[root@k8s-master01 ~]# kubectl create -f node-affinity-demo.yaml
deployment.apps/node-affinity created
[root@k8s-master01 ~]# kubectl get pod -owide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
busybox 1/1 Running 261 11d 172.17.125.9 k8s-node01 <none> <none>
nginx-68db656dd8-qjhs9 1/1 Running 1 11d 172.25.244.200 k8s-master01 <none> <none>
nginx-68db656dd8-znwgp 1/1 Running 1 11d 172.18.195.11 k8s-master03 <none> <none>
node-affinity-7fc9bdc65c-8nzmk 1/1 Running 0 6s 172.27.14.229 k8s-node02 <none> <none>
node-affinity-7fc9bdc65c-gchtc 1/1 Running 0 6s 172.27.14.231 k8s-node02 <none> <none>
node-affinity-7fc9bdc65c-gzqsx 1/1 Running 0 7s 172.27.14.230 k8s-node02 <none> <none>
test-busybox 1/1 Running 0 15m 172.27.14.216 k8s-node02 <none> <none>
web 2/2 Running 0 3d17h 172.18.195.14 k8s-master03 <none> <none>
[root@k8s-master01 ~]# kubectl get deployment
NAME READY UP-TO-DATE AVAILABLE AGE
nginx 2/2 2 2 11d
node-affinity 3/3 3 3 56s
从结果可以看出有4个 Pod 被部署到了 ydzs-node2 节点上,但是可以看到并没有一个 Pod 被部署到 node3 这个节点上,因为我们的硬策略就是不允许部署到该节点上,而 node2 是软策略,所以会尽量满足。这里的匹配逻辑是 label 标签的值在某个列表中,现在 Kubernetes 提供的操作符有下面的几种:
In:label 的值在某个列表中
NotIn:label 的值不在某个列表中
Gt:label 的值大于某个值
Lt:label 的值小于某个值
Exists:某个 label 存在
DoesNotExist:某个 label 不存在
但是需要注意的是如果 nodeSelectorTerms 下面有多个选项的话,满足任何一个条件就可以了;如果 matchExpressions有多个选项的话,则必须同时满足这些条件才能正常调度 Pod。