K8S 亲和性与反亲和性深度好文

今天我们来实验 pod 亲和性。官网描述如下：

假设有如下三个节点的 K8S 集群：

k8s31master 是控制节点

k8s31node1、k8s31node2 是工作节点

容器运行时是 containerd

一、镜像准备

1.1、镜像拉取

docker pull tomcat:8.5-jre8-alpine
docker pull nginx:1.14.2

1.2、镜像导出

docker save -o tomcat-8.5-jre8-alpine.tar.gz docker.io/library/tomcat:8.5-jre8-alpine
docker save -o nginx-1.14.2.tar.gz docker.io/library/nginx:1.14.2

1.3、镜像导入工作节点 containerd

# k8s31node1 执行
[root@k8s31node1 ~]# ctr -n=k8s.io images import tomcat-8.5-jre8-alpine.tar.gz
[root@k8s31node1 ~]# ctr -n=k8s.io images import nginx-1.14.2.tar.gz
[root@k8s31node1 ~]# ctr -n=k8s.io images ls|grep tomcat
[root@k8s31node1 ~]# ctr -n=k8s.io images ls|grep nginx# k8s31node2 执行
[root@k8s31node2 ~]# ctr -n=k8s.io images import tomcat-8.5-jre8-alpine.tar.gz
[root@k8s31node2 ~]# ctr -n=k8s.io images import nginx-1.14.2.tar.gz
[root@k8s31node2 ~]# ctr -n=k8s.io images ls|grep tomcat
[root@k8s31node2 ~]# ctr -n=k8s.io images ls|grep nginx

说明:

ctr 是 containerd 命令
ctr images import：导入镜像
-n=k8s.io：K8S 镜像存储命名空间

1.4、亲和性介绍

亲和性（affinity）属性，位于 pod.spec.affinity，它有三种亲和性：

kubectl explain pod.spec.affinity

分别是 nodeAffinity（节点亲和性）、podAffinity（pod间亲和性）、podAntiAffinity（pod间反亲和性），它们可以分为两类：

节点亲和性功能类似于 nodeSelector 字段，但它的表达能力更强，并且允许你指定软规则。
Pod 间亲和性/反亲和性允许你根据其他 Pod 的标签来约束 Pod。

简单来说：

nodeAffinity 定义了 pod 倾向于（亲和）被调度到哪些节点上。

podAffinity 定义了 pod 倾向于（亲和）跟哪些 pod 调度在一起。

podAntiAffinity 定义 pod 倾向于不（反亲和）跟哪些 pod 调度在一起。

二、nodeAffinity（节点亲和性）

查看帮助文档

kubectl explain pod.spec.affinity.nodeAffinity

节点亲和性概念上类似于 nodeSelector，它使你可以根据节点上的标签来约束 Pod 可以调度到哪些节点上。节点亲和性有两种：

requiredDuringSchedulingIgnoredDuringExecution：调度器只有在规则被满足的时候才能执行调度。此功能类似于 nodeSelector，但其语法表达能力更强。
preferredDuringSchedulingIgnoredDuringExecution：调度器会尝试寻找满足对应规则的节点。如果找不到匹配的节点，调度器仍然会调度该 Pod。

在上述类型中，IgnoredDuringExecution 意味着如果节点标签在 Kubernetes 调度 Pod 后发生了变更，Pod 仍将继续运行。

简单来说：

required 表示必须有节点满足这个位置定义的亲和性，这是个硬性条件，硬亲和性。

preferred 表示有节点尽量满足这个位置定义的亲和性，这不是一个必须的条件，软亲和性。

2.1、required 硬亲和性

查看 requiredDuringSchedulingIgnoredDuringExecution

kubectl explain pod.spec.affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution

它有一个必填字段 nodeSelectorTerms。

查看 nodeSelectorTerms

kubectl explain pod.spec.affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution.nodeSelectorTerms

它是 NodeSelectorTerm 数组

NodeSelectorTerm 定义了两种匹配模式：

matchExpressions 数组
matchFields 数组

2.1.1、matchExpressions

matchExpressions：它允许你使用表达式来匹配节点的标签。例如，你可以使用 In、NotIn、Exists、DoesNotExist、Gt、Lt 等操作符来创建复杂的标签匹配规则。

kubectl explain pod.spec.affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution.nodeSelectorTerms.matchExpressions

key：标签名称。

operator：匹配操作。

values：值列表。[] 或 - 形式都可以。

编写资源文件

pod-node-affinity-required-match-expressions-demo.yaml

apiVersion: v1
kind: Pod
metadata:name: pod-node-affinity-required-match-expressions
spec:affinity:nodeAffinity:requiredDuringSchedulingIgnoredDuringExecution:nodeSelectorTerms:- matchExpressions:- key: zoneoperator: Invalues:- east- southcontainers:- name: tomcatimage: tomcat:8.5-jre8-alpineimagePullPolicy: IfNotPresentports:- containerPort: 8080

matchExpressions 表达式的意思是，寻找具有 label key 为 zone，值为 east 或 south 的节点，把 pod 绑定上去。

运行并查看

kubectl apply -f pod-node-affinity-required-match-expressions-demo.yaml
kubectl get pod -owide

会发现 pod 并没有被正确调度。

因为我现在工作节点上，并没有一个节点有 zone 标签，值为 east 或 south。

required 是硬亲和性，必须满足表达式，pod 才能被正确调度。

查看 pod 日志

kubectl describe pod pod-node-affinity-required-match-expressions

也能发现报 node affinity 错误。

给 k8s31node1 打上标签 zone=east

kubectl label node k8s31node1 zone=east
kubectl get node --show-labels

观察 pod 现在可以正常调度了

如果这个时候，我们变更 k8s31node1 的标签

kubectl label node k8s31node1 zone-
# zone- 表示删除标签 zone
kubectl get pod -owide

会发现 pod 并没有被驱逐。

2.1.2、matchFields

matchFields：它允许你根据资源的非标签字段进行匹配，例如资源的名称、状态等。

kubectl explain pod.spec.affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution.nodeSelectorTerms.matchFields

matchFields 跟 matchExpressions 匹配模式一样。

key：标签名称。

operator：匹配操作。

values：值列表。[] 或 - 形式都可以。

编写资源文件

pod-node-affinity-required-match-fields-demo.yaml

apiVersion: v1
kind: Pod
metadata:name: pod-node-affinity-required-match-fields
spec:affinity:nodeAffinity:requiredDuringSchedulingIgnoredDuringExecution:nodeSelectorTerms:- matchFields:- key: metadata.nameoperator: Invalues: ['k8s31node2']containers:- name: tomcatimage: tomcat:8.5-jre8-alpineimagePullPolicy: IfNotPresentports:- containerPort: 8080

matchFields 表达式的意思是，寻找节点具有 metadata.name 属性，且值是 k8s31node2 的节点，把 pod 绑定上去。

怎么看 node 节点具有哪些属性？
# 以 json 格式或 yaml 格式输出 节点信息
kubectl get node k8s31node2 -o json
kubectl get node k8s31node2 -o yaml

运行并查看

kubectl apply -f pod-node-affinity-required-match-fields-demo.yaml
kubectl get pod -owide

可以发现，它被正确调度到 k8s31node2 上。

2.2、preferred 软亲和性

查看 preferredDuringSchedulingIgnoredDuringExecution

kubectl explain pod.spec.affinity.nodeAffinity.preferredDuringSchedulingIgnoredDuringExecution

有两个必填字段：

preference：偏好。偏好也是一个 NodeSelectorTerm，所以也会有 matchExpressions 和 matchFields。

weight：权重。1-100 的数，weight 是相对权重，权重越高，pod 调度的几率越大。

2.2.1、matchExpressions

编写资源文件

pod-node-affinity-preferred-match-expressions-demo.yaml

apiVersion: v1
kind: Pod
metadata: name: pod-node-affinity-preferred-match-expressions
spec:affinity:nodeAffinity:preferredDuringSchedulingIgnoredDuringExecution:- preference:matchExpressions:- key: diskoperator: Invalues: ['SSD']weight: 20- preference:matchExpressions:- key: diskoperator: Invalues: ['HDD']weight: 10containers:- name: tomcatimage: tomcat:8.5-jre8-alpineimagePullPolicy: IfNotPresentports:- containerPort: 8080

preferred 匹配的意思是：

将 pod 节点优先调度到有标签 disk=SSD 的节点上。因为 disk=SSD 的 weight 数值更大，优先级更高。

业务含义是，将 pod 节点优先调度到拥有固态硬盘的节点上，没有固态硬盘的话，调度到拥有机械硬盘的节点上。

运行并查看

kubectl apply -f pod-node-affinity-preferred-match-expressions-demo.yaml
kubectl get pod -owide

虽然我们现在系统上并没有 disk=SSD 与 disk=HDD 的节点，但是 pod 依然可以正常调度。这是因为 preferred 是一种软亲和性，即使找不到符合条件的节点，调度器 scheduler 依然会调度该 pod。

给节点打标签

# 给 k8s31node1 节点打上 disk=HDD
kubectl label node k8s31node1 disk=HDD
# 给 k8s31node2 节点打上 disk=SSD
kubectl label node k8s31node2 disk=SSD
# 查看节点信息
kubectl get node --show-labels

删除原来的 pod 并运行

kubectl delete -f pod-node-affinity-preferred-match-expressions-demo.yaml
kubectl apply -f pod-node-affinity-preferred-match-expressions-demo.yaml
kubectl get pod -owide

可以看到 pod 被优先调度到 k8s31node2，因为它标签是 disk=SSD，权重最高。

如果这个时候，我们变更 k8s31node2 的标签

kubectl label node k8s31node2 disk-
kubectl get pod -owide

会发现 pod 并没有被驱逐。

matchFields 的情况与 required 类似，就不举例了。

2.3、节点亲和性总结

节点亲和性 nodeAffinity 包括 required 和 preferred
required 是硬亲和性，只有条件满足，pod 才会被调度。
preferred 是软亲和性，条件匹配，优先按条件调度，条件不匹配，按默认算法调度。
matchExpressions 是按节点标签表达式来进行匹配。
matchFields 是按节点属性来进行匹配。
无论 required 还是 preferred，在 pod 运行期，标签变更，pod 不会被驱逐。

2.4、还原实验环境

删除 default 命名空间下所有 pod，

删除节点所有标签，为下一个实验做准备。

三、podAffinity（pod间亲和性）

podAffinity 定义了 pod 倾向于（亲和）跟哪些 pod 调度在同一个位置。

查看帮助文档

kubectl explain pod.spec.affinity.podAffinity

与节点亲和性类似，Pod 的亲和性与反亲和性也有两种类型：

requiredDuringSchedulingIgnoredDuringExecution
preferredDuringSchedulingIgnoredDuringExecution

例如，你可以使用 requiredDuringSchedulingIgnoredDuringExecution 亲和性来告诉调度器，将两个服务的 Pod 放到同一个云提供商可用区内，因为它们彼此之间通信非常频繁。

类似地，你可以使用 preferredDuringSchedulingIgnoredDuringExecution 反亲和性来将同一服务的多个 Pod 分布到多个云提供商可用区中。

3.1、required 硬亲和性

查看 requiredDuringSchedulingIgnoredDuringExecution

kubectl explain pod.spec.affinity.podAffinity.requiredDuringSchedulingIgnoredDuringExecution

它是 PodAffinityTerm 数组。

PodAffinityTerm 它有三个比较重要的字段：

toplogyKey：拓扑键，必填。我们在定义 pod 间亲和性时有一个前提，就是 B pod 想调度到跟 A pod 同一个位置，那么怎么定义这个位置？就是以这个字段来定义的。其取值是系统用来标示域的节点标签键。也就是说，不同节点具有相同标签 key，且 key 所对应的 value 也相同，则它们被定义为同一个位置。

假设有如下服务器集群，在可用区A中有节点 node1、node2，它们拥有相同的节点标签（zone=A）则 node1 与 node2 被定义为同一个位置。node3 因为拥有不同的节点标签（zone=B）所以 node3 被视为不同位置。

toplogyKey 它是一个拓扑的概念，同一个机架、可用区、地域里面所有节点，都可以被 K8S 视为同一个位置而被统一调度。

labelSelector：标签选择器。通过 labelSelector 选取一组能作为亲和对象的已存在的 pod 资源。它定义了两种匹配模式：

matchExpressions <[]LabelSelectorRequirement>
matchLabels <map[string]string>

namespaces：名称空间。pod 在 Kubernetes 中是名称空间作用域的对象，因此 pod 的标签也隐式地具有名称空间属性。针对 pod 标签的所有标签选择器都要指定名称空间，Kubernetes 会在指定的名称空间内寻找标签。

如果不指定 namespaces，那么标签选择器就是在当前要创建的 pod 的名称空间里查找符合条件的一组 pod。

3.1.1、matchExpressions

matchExpressions：它允许你使用表达式来匹配 Pod 的标签。例如，你可以使用 In、NotIn、Exists、DoesNotExist 等操作符来创建复杂的标签匹配规则。

kubectl explain pod.spec.affinity.podAffinity.requiredDuringSchedulingIgnoredDuringExecution.labelSelector.matchExpressions

key：标签名称。

operator：匹配操作。

values：值列表。[] 或 - 形式都可以。

实验准备

使用 kubeadm join 往集群中加入一个新的工作节点 k8s31node3:

镜像准备

# 将 tomcat、nginx 镜像也导入到 k8s31node3
# k8s31node3 执行
[root@k8s31node3 ~]# ctr -n=k8s.io images import tomcat-8.5-jre8-alpine.tar.gz
[root@k8s31node3 ~]# ctr -n=k8s.io images import nginx-1.14.2.tar.gz
[root@k8s31node3 ~]# ctr -n=k8s.io images ls|grep tomcat
[root@k8s31node3 ~]# ctr -n=k8s.io images ls|grep nginx

资源文件编写

假设我们现在有两个 pod，nginx 跟 tomcat，nginx 反向代理 tomcat，它们之间要频繁通信，所以我们希望 pod-nginx 跟 pod-tomcat 能调度到同一个可用区内。

pod-pod-affinity-required-match-expressions-tomcat.yaml

apiVersion: v1
kind: Pod
metadata:name: tomcatlabels:app: tomcat
spec:containers:- name: tomcatimage: tomcat:8.5-jre8-alpineimagePullPolicy: IfNotPresentports:- containerPort: 8080

运行并查看

kubectl apply -f pod-pod-affinity-required-match-expressions-tomcat.yaml
kubectl get pod -owide

tomcat 被调度到 k8s31node3 节点上。

资源文件编写

pod-pod-affinity-required-match-expressions-nginx.yaml

apiVersion: v1
kind: Pod
metadata:name: nginx
spec:affinity:podAffinity:requiredDuringSchedulingIgnoredDuringExecution:- topologyKey: zonelabelSelector:matchExpressions:- {key: app, operator: In, values: ["tomcat"]}containers:- name: nginximage: nginx:1.14.2imagePullPolicy: IfNotPresentports:- containerPort: 80

运行并查看

kubectl apply -f pod-pod-affinity-required-match-expressions-nginx.yaml
kubectl get pod -owide

发现 nginx 无法被调度。

查看 pod 日志

kubectl describe pod nginx

报 pod 亲和性不符合。

原因是我们现在所有节点上，并没有定义 topologyKey=zone 这个键，而 required 是属于硬亲和性，在节点调度期，找不到符合调度规则的节点，系统不会对 pod 进行调度。

给节点打标签

kubectl label node k8s31node1 zone=A
kubectl label node k8s31node2 zone=B
kubectl label node k8s31node3 zone=B
kubectl get pod -owide

可以看到 nginx 被调度到 tomcat 所在的节点 k8s31node3 上了。

倘若这个时候，我们起一个 nginx：

pod-pod-affinity-required-match-expressions-nginx2.yaml

就只是把上一个 nginx.yaml 改了一下 metadata.name 为 nginx2 而已。

apiVersion: v1
kind: Pod
metadata:name: nginx2
spec:affinity:podAffinity:requiredDuringSchedulingIgnoredDuringExecution:- topologyKey: zonelabelSelector:matchExpressions:- {key: app, operator: In, values: ["tomcat"]}containers:- name: nginximage: nginx:1.14.2imagePullPolicy: IfNotPresentports:- containerPort: 80

kubectl apply -f pod-pod-affinity-required-match-expressions-nginx2.yaml
kubectl get pod -owide

会发现 nginx2 被调度到 k8s31node2 上了。

分析

整个的部署图如下：

tomcat 首先被调度到 node3，这个过程是随机的，scheduler 调度器根据自己内部的调度算法来决定的。
nginx 被调度时，因为 nginx 跟 tomcat podAffinity，所以它要被调度到跟 tomcat 具有相同 topologyKey 的节点上，这个时候 node3 跟 node2 都满足要求（node1 因为 topologyKey 的值是 A，所以不满足要求），scheduler 调度器觉得 node3 这个时候的负载不高，所以也把 nginx 调度到 node3 上。
nginx2 被调度时，走 nginx 一样的逻辑，所以 node3 跟 node2 都满足要求，但此时 node3 负载已经很高了（跑着两个 pod），所以 scheduler 调度器决定将 nginx2 调度到 node2。

还原实验环境

删除 nginx 跟 nginx2 以便进行下面的实验。

kubectl delete pod nginx
kubectl delete pod nginx2

3.1.2、matchLabels

matchLabels 的匹配方式，相对于 matchExpressions 更简单，它是以键值对的方式进行匹配的。

kubectl explain pod.spec.affinity.podAffinity.requiredDuringSchedulingIgnoredDuringExecution.labelSelector.matchLabels

编写资源文件

pod-pod-affinity-required-match-labels-nginx.yaml

apiVersion: v1
kind: Pod
metadata:name: nginx
spec:affinity:podAffinity:requiredDuringSchedulingIgnoredDuringExecution:- topologyKey: zonelabelSelector:matchLabels:app: tomcatcontainers:- name: nginximage: nginx:1.14.2imagePullPolicy: IfNotPresentports:- containerPort: 80

pod-pod-affinity-required-match-labels-nginx2.yaml

俩个文件之间的差异，只在 metadata.name

apiVersion: v1
kind: Pod
metadata:name: nginx2
spec:affinity:podAffinity:requiredDuringSchedulingIgnoredDuringExecution:- topologyKey: zonelabelSelector:matchLabels:app: tomcatcontainers:- name: nginximage: nginx:1.14.2imagePullPolicy: IfNotPresentports:- containerPort: 80

运行并查看

kubectl apply -f pod-pod-affinity-required-match-labels-nginx.yaml
kubectl apply -f pod-pod-affinity-required-match-labels-nginx2.yaml
kubectl get pod -owide

可以看到跟 matchExpressions 是一样的效果。

节点标签变更

倘如我们这个时候，将所有节点的 zone 标签删除，看看会有什么效果。

kubectl label node k8s31node1 zone-
kubectl label node k8s31node2 zone-
kubectl label node k8s31node3 zone-
kubectl get pod -owide

可以看到 pod 并不会被驱逐。

还原实验环境

删除 tomcat、nginx 跟 nginx2 以便进行下面的实验。

kubectl delete pod tomcat
kubectl delete pod nginx
kubectl delete pod nginx2

3.2、preferred 软亲和性

查看 preferredDuringSchedulingIgnoredDuringExecution

kubectl explain pod.spec.affinity.podAffinity.preferredDuringSchedulingIgnoredDuringExecution

它是 WeightedPodAffinityTerm 数组。

WeightedPodAffinityTerm 它有两个必填字段：

podAffinityTerm：PodAffinityTerm 对象。它跟上面 required 是一模一样的。所以也必然有 toplogyKey、labelSelector、namespaces。

weight：权重。1-100 的数，weight 是相对权重，权重越高，pod 调度的几率越大。

假设现在有如下部署图：

node1、node2、node3 分别有标签 zone=A、zone=B、zone=C，表示它们分别位于可用区 A B C。

node1、node2、node3 上分别运行着 pod tomcat1、tomcat2、tomcat3。

tomcat1、tomcat2、tomcat3 分别有标签 app=tomcat1、app=tomcat2、app=tomcat3，它们的权重，分别是 10、30、20。

现在有一个新的 pod-nginx，加入进来，我们看看 K8S 是如何调度的-->

编写 tomcat 配置文件

pod-pod-affinity-preferred-match-expressions-tomcat1.yaml

apiVersion: v1
kind: Pod
metadata:name: tomcat1labels:app: tomcat1
spec:nodeName: k8s31node1containers:- name: tomcatimage: tomcat:8.5-jre8-alpineimagePullPolicy: IfNotPresentports:- containerPort: 8080

nodeName 指定它运行在 node1 节点上。

pod-pod-affinity-preferred-match-expressions-tomcat2.yaml

apiVersion: v1
kind: Pod
metadata:name: tomcat2labels:app: tomcat2
spec:nodeName: k8s31node2containers:- name: tomcatimage: tomcat:8.5-jre8-alpineimagePullPolicy: IfNotPresentports:- containerPort: 8080

nodeName 指定它运行在 node2 节点上。

pod-pod-affinity-preferred-match-expressions-tomcat3.yaml

apiVersion: v1
kind: Pod
metadata:name: tomcat3labels:app: tomcat3
spec:nodeName: k8s31node3containers:- name: tomcatimage: tomcat:8.5-jre8-alpineimagePullPolicy: IfNotPresentports:- containerPort: 8080

nodeName 指定它运行在 node3 节点上。

启动 tomcat

kubectl apply -f pod-pod-affinity-preferred-match-expressions-tomcat1.yaml
kubectl apply -f pod-pod-affinity-preferred-match-expressions-tomcat2.yaml
kubectl apply -f pod-pod-affinity-preferred-match-expressions-tomcat3.yaml
kubectl get pod -owide --show-labels

给节点打标签

kubectl label node k8s31node1 zone=A
kubectl label node k8s31node2 zone=B
kubectl label node k8s31node3 zone=C
kubectl get node --show-labels

编写 nginx 配置文件

pod-pod-affinity-preferred-match-expressions-nginx.yaml

apiVersion: v1
kind: Pod
metadata:name: nginx
spec:affinity:podAffinity:preferredDuringSchedulingIgnoredDuringExecution:- weight: 10podAffinityTerm: topologyKey: zonelabelSelector:matchExpressions:- {key: app, operator: In, values: ["tomcat1"]}- weight: 30podAffinityTerm:topologyKey: zonelabelSelector:matchExpressions:- {key: app, operator: In, values: ["tomcat2"]}- weight: 20podAffinityTerm:topologyKey: zonelabelSelector:matchExpressions:- {key: app, operator: In, values: ["tomcat3"]}containers:- name: nginximage: nginx:1.14.2imagePullPolicy: IfNotPresentports:- containerPort: 80

app=tomcat2 的权重最高，所以 nginx 需要被调度到跟 tomcat2 相同 zone 下的服务器上，因为该 zone 只有一个 node2，所以 nginx 被调度到 node2 上。

删掉 nginx，并修改所有 pod label

kubectl delete pod nginx
kubectl label pod tomcat1 app=tomcat --overwrite=true
kubectl label pod tomcat2 app=tomcat --overwrite=true
kubectl label pod tomcat3 app=tomcat --overwrite=true
# --overwrite=true 表示覆盖原来 label 的值
kubectl get pod -owide --show-labels

重新运行 nginx，我们看看会发生什么

kubectl apply -f pod-pod-affinity-preferred-match-expressions-nginx.yaml
kubectl get pod -owide --show-labels

现在没有一个 pod 的标签符合标签选择器的规则，但是 nginx 还是能被正常的调度，因为 preferred 是一种软亲和性。标签选择器的规则不匹配，scheduler 调度器会根据内部的算法选择合适的节点来绑定pod。

3.3、pod 间亲和性总结

pod 间亲和性 podAffinity 包括 required 和 preferred
required 是硬亲和性，只有条件满足，pod 才会被调度。
preferred 是软亲和性，条件匹配，优先按条件调度，条件不匹配，按默认算法调度。
matchExpressions 是按 pod 标签表达式来进行匹配。
matchLabels 也是按 pod 标签来进行匹配，不过它是以键值对的方式来表示匹配规则。
无论 required 还是 preferred，在 pod 运行期，不管是节点标签变更，还是被亲和的 pod 标签变更，pod 都不会被驱逐。
podAffinity 中有一个很重要的概念是 toplogyKey，理解它对于理解 pod 调度非常重要。

3.4、还原实验环境

删除 nginx tomcat1 tomcat2 tomcat3

kubectl delete pod nginx tomcat1 tomcat2 tomcat3 --force --grace-period=0

保留 node1、node2、node3 的 zone label

四、podAntiAffinity（pod间反亲和性）

podAntiAffinity 定义了 pod 倾向于不跟哪些 pod 调度在同一个位置。

查看帮助文档

kubectl explain pod.spec.affinity.podAntiAffinity

可以看到，它跟 podAffinity 的定义，几乎是一摸一样的。

可以猜到，K8S 内部在进行调度的时候，应该是采用一种取反的操作。

筛选出不想亲和的 pod 所具有的 toplogyKey，然后在剩下的 toplogyKey 里选择节点进行绑定。

下面是 podAffinity 的定义。

4.1、required 硬亲和性

这一节，我们只演示 required，其他大同小异。

假设现在有如下部署图：

node1、node2、node3 分别有标签 zone=A、zone=B、zone=C，表示它们分别位于可用区 A B C。

node3 运行着 tomcat1，它有标签 app=tomcat。

现在再来一个 tomcat2，我们不希望它跟 tomcat1 在同一个可用区下。

在实际业务中，相同的可用区往往意味着同一个机房，而部署同一个应用，往往不希望它们在同一个节点、或者同一个可用区下，因为这样容易导致单点故障。从而让整个服务不可用。

我们看看这在 K8S 中要怎么实现-->

编写 tomcat1 资源文件

pod-pod-antiaffinity-required-match-expressions-tomcat1.yaml

apiVersion: v1
kind: Pod
metadata:name: tomcat1labels:app: tomcat
spec:nodeName: k8s31node3containers:- name: tomcatimage: tomcat:8.5-jre8-alpineimagePullPolicy: IfNotPresentports:- containerPort: 8080

nodeName 指定它运行在 node3 节点上。

编写 tomcat2 资源文件

pod-pod-antiaffinity-required-match-expressions-tomcat2.yaml

apiVersion: v1
kind: Pod
metadata:name: tomcat2labels:app: tomcat
spec:affinity:podAntiAffinity:requiredDuringSchedulingIgnoredDuringExecution:- topologyKey: zonelabelSelector:matchExpressions:- {key: app, operator: In, values: ["tomcat"]}containers:- name: tomcatimage: tomcat:8.5-jre8-alpineimagePullPolicy: IfNotPresentports:- containerPort: 8080

运行并查看

kubectl apply -f pod-pod-antiaffinity-required-match-expressions-tomcat1.yaml
kubectl apply -f pod-pod-antiaffinity-required-match-expressions-tomcat2.yaml
kubectl get pod -owide --show-labels