每天一点基础K8S–K8S中的调度策略—pod亲和性和反亲和性()-其他
每天一点基础K8S–K8S中的调度策略—pod亲和性和反亲和性()
pod亲和性和反亲和性
上面实验了pod的资源调度可以通过nodeName、nodeSelector完成，以及node节点亲和性，都是根据依赖关系完成node与pod之间的调度。在实际的需求中，还需要对pod和pod的调度进行控制。
本节就测试一下pod的亲和性和反亲和性
准备一个基础pod作为亲和性的基础pod
[root@master-worker-node-1 pod]# cat pod-affinity-base-pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod-affinity-base-pod
labels:
func: pod-affinity
spec:
containers:
- name: pod-affinity-base-pod
image: busybox:latest
imagePullPolicy: IfNotPresent
command: ['/bin/sh','-c','sleep 1234']
[root@master-worker-node-1 pod]# kubectl apply -f pod-affinity-base-pod.yaml
pod/pod-affinity-base-pod created
[root@master-worker-node-1 pod]# kubectl get pods -o wide | grep pod-affinity
pod-affinity-base-pod 1/1 Running 0 69s 10.244.31.11 only-worker-node-3 <none> <none>
requiredDuringSchedulingIgnoredDuringExecution： 调度器只有在规则被满足的时候才能执行调度。此功能类似于 nodeSelector， 但其语法表达能力更强。
preferredDuringSchedulingIgnoredDuringExecution： 调度器会尝试寻找满足对应规则的节点。如果找不到匹配的节点，调度器仍然会调度该 Pod。
pod亲和性–强亲和性（required）
pod强亲和性下主要字段包括：
kubectl explain pod.spec.affinity.podAffinity.requiredDuringSchedulingIgnoredDuringExecution
FIELDS:
labelSelector <Object>
namespaceSelector <Object>
namespaces <[]string>
topologyKey <string> -required-
通过labelSelector实现强亲和性
[root@master-worker-node-1 pod]# cat test-pod-affinity-labelSeletor.yaml
apiVersion: v1
kind: Pod
metadata:
name: test-pod-affinity-by-labelselector
labels:
func: by-label-selector
spec:
containers:
- name: by-label-selector
image: busybox:latest
imagePullPolicy: IfNotPresent
command: ['/bin/sh','-c','sleep 1234']
affinity:
podAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: func
operator: In
values:
- pod-affinity
topologyKey: node-role.kubernetes.io/worker # 确定一个逻辑节点（自创的概念）
[root@master-worker-node-1 pod]# kubectl apply -f test-pod-affinity-labelSeletor.yaml
pod/test-pod-affinity-by-labelselector created
[root@master-worker-node-1 pod]# kubectl get pods -o wide | grep pod-affinity
pod-affinity-base-pod 1/1 Running 2 (7m31s ago) 48m 10.244.31.11 only-worker-node-3 <none> <none>
test-pod-affinity-by-labelselector 1/1 Running 0 15s 10.244.54.10 only-worker-node-4 <none> <none>
上面的例子看到，计划依赖的pod是运行在only-worker-node-3上，但是新建的pod却运行在only-worker-node-4上。这里就要说明一下topologyKey的意思了，topologyKey表示，只要满足topologyKey规则的节点被认为是逻辑节点。只要在该逻辑节点上能够找到满足label Selector表达式的pod，那么新建的pod就能在这个逻辑节点上创建。本例中，only-worker-node-3和only-worker-node-4都具有node-role.kubernetes.io/worker，那么就讲她两作为一个逻辑节点。同时，在该节点上也有一个pod满足labelSelector要求，那么新建的pod就能被调度，并随机调度到only-worker-node-4pod亲和性–弱亲和性（preferred）
[root@master-worker-node-1 pod]# cat test-pod-affinity-prefered.yaml
apiVersion: v1
kind: Pod
metadata:
name: test-prefered-1
labels:
func: test-preferred
spec:
containers:
- name: test-preferred-1
image: busybox:latest
imagePullPolicy: IfNotPresent
command: ['/bin/sh','-c','sleep 3600']
affinity:
podAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- podAffinityTerm:
labelSelector:
matchExpressions:
- key: func
operator: In
values:
- pod-affinity
topologyKey: node-role.kubernetes.io/worker
weight: 50 # weight同之前nodeaffinity perfered方法类似，同样需要两条才有意义
[root@master-worker-node-1 pod]# kubectl apply -f test-pod-affinity-prefered.yaml
pod/test-prefered-1 created
# 这里的结果和上面一样，因为topologyKey标识了一个逻辑节点，只要在节点内满足pod亲和性的调度的都是允许的。基础pod在only-worker-node-3，新建的pod在only-worker-node-4上。
[root@master-worker-node-1 pod]# kubectl get pods -o wide | grep prefer
test-prefered-1 1/1 Running 0 2m3s 10.244.54.11 only-worker-node-4 <none> <none>
[root@master-worker-node-1 pod]# cat test-pod-affinity-prefered-2.yaml
apiVersion: v1
kind: Pod
metadata:
name: test-prefered-2
labels:
func: test-preferred
spec:
containers:
- name: test-preferred-2
image: busybox:latest
imagePullPolicy: IfNotPresent
command: ['/bin/sh','-c','sleep 3600']
affinity:
podAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- podAffinityTerm:
labelSelector:
matchExpressions:
- key: func
operator: In
values:
- pod-affinity
topologyKey: node-role.kubernetes.io/worker3456789 #肯定不存在这样一个逻辑节点
weight: 50
但是pod依然可以正常创建
[root@master-worker-node-1 pod]# kubectl get pods -o wide | grep prefer
test-prefered-1 1/1 Running 0 10m 10.244.54.11 only-worker-node-4 <none> <none>
test-prefered-2 1/1 Running 0 26s 10.244.31.13 only-worker-node-3 <none> <none>
pod的反亲和性–AntiAffinity
pod反亲和性除了可以通过修改pod的亲和性中operator字段为NotIn或者DoesNotExist实现反亲和性，还可以通过专门的AntiAffinity实现pod的反亲和性。
这部分的语法和其他情急下的语法类似。
kubectl explain pod.spec.affinity.podAntiAffinity
小结
pod的亲和性同样分为强亲和性（required）和弱亲和性(perferred)，两种情况和node affinity并无区别pod亲和性中新增了topologyKey的概率，可以理解为一个逻辑节点，一个逻辑节点中可以不包含node，也可以包含一个或者多个node————————
pod亲和性和反亲和性
上面实验了pod的资源调度可以通过nodeName、nodeSelector完成，以及node节点亲和性，都是根据依赖关系完成node与pod之间的调度。在实际的需求中，还需要对pod和pod的调度进行控制。
本节就测试一下pod的亲和性和反亲和性
准备一个基础pod作为亲和性的基础pod
[root@master-worker-node-1 pod]# cat pod-affinity-base-pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod-affinity-base-pod
labels:
func: pod-affinity
spec:
containers:
- name: pod-affinity-base-pod
image: busybox:latest
imagePullPolicy: IfNotPresent
command: ['/bin/sh','-c','sleep 1234']
[root@master-worker-node-1 pod]# kubectl apply -f pod-affinity-base-pod.yaml
pod/pod-affinity-base-pod created
[root@master-worker-node-1 pod]# kubectl get pods -o wide | grep pod-affinity
pod-affinity-base-pod 1/1 Running 0 69s 10.244.31.11 only-worker-node-3 <none> <none>
requiredDuringSchedulingIgnoredDuringExecution： 调度器只有在规则被满足的时候才能执行调度。此功能类似于 nodeSelector， 但其语法表达能力更强。
preferredDuringSchedulingIgnoredDuringExecution： 调度器会尝试寻找满足对应规则的节点。如果找不到匹配的节点，调度器仍然会调度该 Pod。
pod亲和性–强亲和性（required）
pod强亲和性下主要字段包括：
kubectl explain pod.spec.affinity.podAffinity.requiredDuringSchedulingIgnoredDuringExecution
FIELDS:
labelSelector <Object>
namespaceSelector <Object>
namespaces <[]string>
topologyKey <string> -required-
通过labelSelector实现强亲和性
[root@master-worker-node-1 pod]# cat test-pod-affinity-labelSeletor.yaml
apiVersion: v1
kind: Pod
metadata:
name: test-pod-affinity-by-labelselector
labels:
func: by-label-selector
spec:
containers:
- name: by-label-selector
image: busybox:latest
imagePullPolicy: IfNotPresent
command: ['/bin/sh','-c','sleep 1234']
affinity:
podAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: func
operator: In
values:
- pod-affinity
topologyKey: node-role.kubernetes.io/worker # 确定一个逻辑节点（自创的概念）
[root@master-worker-node-1 pod]# kubectl apply -f test-pod-affinity-labelSeletor.yaml
pod/test-pod-affinity-by-labelselector created
[root@master-worker-node-1 pod]# kubectl get pods -o wide | grep pod-affinity
pod-affinity-base-pod 1/1 Running 2 (7m31s ago) 48m 10.244.31.11 only-worker-node-3 <none> <none>
test-pod-affinity-by-labelselector 1/1 Running 0 15s 10.244.54.10 only-worker-node-4 <none> <none>
上面的例子看到，计划依赖的pod是运行在only-worker-node-3上，但是新建的pod却运行在only-worker-node-4上。这里就要说明一下topologyKey的意思了，topologyKey表示，只要满足topologyKey规则的节点被认为是逻辑节点。只要在该逻辑节点上能够找到满足label Selector表达式的pod，那么新建的pod就能在这个逻辑节点上创建。本例中，only-worker-node-3和only-worker-node-4都具有node-role.kubernetes.io/worker，那么就讲她两作为一个逻辑节点。同时，在该节点上也有一个pod满足labelSelector要求，那么新建的pod就能被调度，并随机调度到only-worker-node-4pod亲和性–弱亲和性（preferred）
[root@master-worker-node-1 pod]# cat test-pod-affinity-prefered.yaml
apiVersion: v1
kind: Pod
metadata:
name: test-prefered-1
labels:
func: test-preferred
spec:
containers:
- name: test-preferred-1
image: busybox:latest
imagePullPolicy: IfNotPresent
command: ['/bin/sh','-c','sleep 3600']
affinity:
podAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- podAffinityTerm:
labelSelector:
matchExpressions:
- key: func
operator: In
values:
- pod-affinity
topologyKey: node-role.kubernetes.io/worker
weight: 50 # weight同之前nodeaffinity perfered方法类似，同样需要两条才有意义
[root@master-worker-node-1 pod]# kubectl apply -f test-pod-affinity-prefered.yaml
pod/test-prefered-1 created
# 这里的结果和上面一样，因为topologyKey标识了一个逻辑节点，只要在节点内满足pod亲和性的调度的都是允许的。基础pod在only-worker-node-3，新建的pod在only-worker-node-4上。
[root@master-worker-node-1 pod]# kubectl get pods -o wide | grep prefer
test-prefered-1 1/1 Running 0 2m3s 10.244.54.11 only-worker-node-4 <none> <none>
[root@master-worker-node-1 pod]# cat test-pod-affinity-prefered-2.yaml
apiVersion: v1
kind: Pod
metadata:
name: test-prefered-2
labels:
func: test-preferred
spec:
containers:
- name: test-preferred-2
image: busybox:latest
imagePullPolicy: IfNotPresent
command: ['/bin/sh','-c','sleep 3600']
affinity:
podAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- podAffinityTerm:
labelSelector:
matchExpressions:
- key: func
operator: In
values:
- pod-affinity
topologyKey: node-role.kubernetes.io/worker3456789 #肯定不存在这样一个逻辑节点
weight: 50
但是pod依然可以正常创建
[root@master-worker-node-1 pod]# kubectl get pods -o wide | grep prefer
test-prefered-1 1/1 Running 0 10m 10.244.54.11 only-worker-node-4 <none> <none>
test-prefered-2 1/1 Running 0 26s 10.244.31.13 only-worker-node-3 <none> <none>
pod的反亲和性–AntiAffinity
pod反亲和性除了可以通过修改pod的亲和性中operator字段为NotIn或者DoesNotExist实现反亲和性，还可以通过专门的AntiAffinity实现pod的反亲和性。
这部分的语法和其他情急下的语法类似。
kubectl explain pod.spec.affinity.podAntiAffinity
小结
pod的亲和性同样分为强亲和性（required）和弱亲和性(perferred)，两种情况和node affinity并无区别pod亲和性中新增了topologyKey的概率，可以理解为一个逻辑节点，一个逻辑节点中可以不包含node，也可以包含一个或者多个node