k8s中pod亲和性和反亲和性的使用
1.亲和性调度作用和分类- pod亲和性和节点nodeAffinity亲和性通用
亲和度可以分成软策略和硬策略两种方式
软策略：尽量满足条件，满足条件最好,不满足也无所谓,若没有满足调度要求的节点的话,pod会忽略这条规则,继续完成调度过程
硬策略: 必须满足条件，比较强硬，如果没有满足条件的节点的话，就不断重试直到满足条件为止。
2.亲和性和反亲和性的两种策略的配置写法-pod亲和性和节点nodeAffinity亲和性通用
对于亲和性和反亲和性都有这两种规则可以设置：
软策略：preferredDuringSchedulingIgnoredDuringExecution
硬策略：requiredDuringSchedulingIgnoredDuringExecution
3.pod亲和性和反亲和性的概念
pod亲和性和反亲和性都是处理pod与pod之间的关系。
pod亲和性： 主要是想把pod和某个依赖的pod放在一起。
pod亲和性主要解决pod可以和哪些pod部署在同一个拓扑域中的问题（其中拓扑域用主机标签实现，可以是单个主机，也可以是多个主机组成的 cluster等等）
例如：一个pod在一个节点上了，那么我这个pod也得在这个节点上。
注意：是以pod的标签进行标记的，将pod标签一样的几个pod部署到同一个节点上，pod1的标签是app=love,部署在node1节点，pod2的标签也是app=love，可以通过配置pod亲和性，让pod2也部署在node1，和pod1放到一起。
pod反亲和性：主要想把 pod和某个pod分开。
pod反亲和性主要是解决pod不能和哪些pod部署在同一个拓扑域中的问题，它们都是处理的pod与pod 之间的关系。
例如：你这个pod在节点上了，那么我就不想和你待在同一个节点上
注意：是以pod的标签进行标记的，将pod标签一样的几个pod不要部署到同一个节点上，pod1的标签是app=love,部署在node1节点，pod2的标签也是app=love，可以通过配置pod反亲和性，不让pod2部署在node1，不要和pod1放到一起。
4.pod亲和性的案例实战
1).准备k8s集群
[root@k8s-m1 ~]# kubectl get node
NAME STATUS ROLES AGE VERSION
k8s-m1 Ready control-plane,master 23h v1.22.10
k8s-m2 Ready control-plane,master 23h v1.22.10
k8s-m3 Ready control-plane,master 23h v1.22.10
k8s-n1 Ready worker 23h v1.22.10
k8s-n2 Ready worker 23h v1.22.10
[root@k8s-m1 ~]# kubectl get cs
Warning: v1 ComponentStatus is deprecated in v1.19+
NAME STATUS MESSAGE ERROR
scheduler Healthy ok
controller-manager Healthy ok
etcd-0 Healthy {"health":"true"}
etcd-1 Healthy {"health":"true"}
etcd-2 Healthy {"health":"true"}
2).先部署一个标签为app=love的pod1的nginx（应用nginx版本nginx:1.19.5）
[root@k8s-m1 ~]# vim nginx.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: dev-nginx-deployment
spec:
replicas: 1
selector:
matchLabels:
app: love
template:
metadata:
labels:
app: love
spec:
containers:
- name: nginx
image: nginx:1.19.5
[root@k8s-m1 ~]# kubectl apply -f nginx.yaml
[root@k8s-m1 ~]# kubectl get pod -o wide --show-labels #查看部署的pod1部署在k8s-n1上
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES LABELS
dev-nginx-deployment-7cdc5f7758-wgnbb 1/1 Running 0 8s 10.233.71.25 k8s-n1 <none> <none> app=love,pod-template-hash=7cdc5f7758
3).再使用pod亲和性部署另一个pod2(标签也是app=love，nginx版本为nginx:1.20)，和pod1部署到一起
[root@k8s-m1 ~]# vim nginx2.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx2-affinity-deployment
spec:
replicas: 3
selector:
matchLabels:
app: love2 #pod2的标签,和pod1的标签没关系
template:
metadata:
labels:
app: love2 #pod2的标签,和pod1的标签没关系
spec:
containers:
- name: nginx
image: nginx:1.20
ports:
- containerPort: 80
name: nginxweb
affinity:
podAffinity:
requiredDuringSchedulingIgnoredDuringExecution: # 硬策略,以硬策略为例,软策略类似
- labelSelector:
matchExpressions:
- key: app #规则: 匹配和pod1的标签的规则时
operator: In
values:
- love
topologyKey: kubernetes.io/hostname
[root@k8s-m1 ~]# kubectl apply -f nginx2.yaml #用pod亲和性部署pod2，和pod1部署到一起
[root@k8s-m1 ~]# kubectl get pod -o wide --show-labels #查看部署后的结果,会和pod1部署到一起,部署到同一个节点上
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES LABELS
dev-nginx-deployment-7cdc5f7758-wgnbb 1/1 Running 0 27m 10.233.71.25 k8s-n1 <none> <none> app=love,pod-template-hash=7cdc5f7758
nginx2-affinity-deployment-57b4b64d74-gbw8n 1/1 Running 0 18s 10.233.71.30 k8s-n1 <none> <none> app=love2,pod-template-hash=57b4b64d74
nginx2-affinity-deployment-57b4b64d74-rdjb7 1/1 Running 0 18s 10.233.71.31 k8s-n1 <none> <none> app=love2,pod-template-hash=57b4b64d74
nginx2-affinity-deployment-57b4b64d74-rmprr 1/1 Running 0 18s 10.233.71.32 k8s-n1 <none> <none> app=love2,pod-template-hash=57b4b64d74
加了pod亲和性配置后，会发现后面部署的pod2的3个副本都会部署到和pod1标签一致的node节点，即: k8s-n1上
如果不加pod亲和性配置，就会按原来的调度策略，k8s-n1和k8s-n2节点上都会部署。
4). 再使用pod反亲和性部署另一个pod2(标签也是app=love，nginx版本为nginx:1.20) ，不和pod1部署到一起
[root@k8s-m1 ~]# vim nginx2.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx2-affinity-deployment
spec:
replicas: 3
selector:
matchLabels:
app: love2 #pod2的标签,和pod1的标签没关系
template:
metadata:
labels:
app: love2 #pod2的标签,和pod1的标签没关系
spec:
containers:
- name: nginx
image: nginx:1.20
ports:
- containerPort: 80
name: nginxweb
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution: # 硬策略,以硬策略为例,软策略类似
- labelSelector:
matchExpressions:
- key: app #规则: 匹配和pod1的标签的规则时
operator: In
values:
- love
topologyKey: kubernetes.io/hostname
[root@k8s-m1 ~]# kubectl apply -f nginx2.yaml #用pod反亲和性部署pod2，不和pod1部署到一起
[root@k8s-m1 ~]# kubectl get pod -o wide --show-labels #查看部署后的结果,不会和pod1部署到一起,不会在同一节点上
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES LABELS
dev-nginx-deployment-7cdc5f7758-wgnbb 1/1 Running 0 23m 10.233.71.25 k8s-n1 <none> <none> app=love,pod-template-hash=7cdc5f7758
nginx2-affinity-deployment-684568686-hf4tm 1/1 Running 0 14s 10.233.81.22 k8s-n2 <none> <none> app=love2,pod-template-hash=684568686
nginx2-affinity-deployment-684568686-tqvp7 1/1 Running 0 14s 10.233.81.24 k8s-n2 <none> <none> app=love2,pod-template-hash=684568686
nginx2-affinity-deployment-684568686-zhhq2 1/1 Running 0 14s 10.233.81.23 k8s-n2 <none> <none> app=love2,pod-template-hash=684568686
加了pod反亲和性配置后，会发现后面部署的pod2的3个副本都不会部署到和pod1标签一致的node节点，即不会部署在 k8s-n1上，而是会部署在k8s-n2上
参考连接： https://www.cnblogs.com/lnlvinso/p/13599102.html
