玩转k8s pod调度之亲和性与反亲和性
简介
Scheduler 是 kubernetes 的调度器，主要的任务是把定义的 pod 分配到集群的节点上。听起来非常简单，但有很多要考虑的问题：
- 公平：如何保证每个节点都能被分配资源
- 资源高效利用：集群所有资源最大化被使用
- 效率：调度的性能要好，能够尽快地对大批量的 pod 完成调度工作
- 灵活：允许用户根据自己的需求控制调度的逻辑
Sheduler 是作为单独的程序运行的，启动之后会一直监听 API Server，获取 `PodSpec.NodeName` 为空的 pod，对每个 pod 都会创建一个 binding，表明该 pod 应该放到哪个节点上
调度过程
调度分为几个部分：首先是过滤掉不满足条件的节点，这个过程称为 `预选`；然后对通过的节点按照优先级排序，这个是 `优选`；最后从中选择优先级最高的节点。如果中间任何一步骤有错误，就直接返回错误
预选
有一系列的算法可以使用：
- `PodFitsResources`：节点上剩余的资源是否大于 pod 请求的资源
- `PodFitsHost`：如果 pod 指定了 NodeName，检查节点名称是否和 NodeName 匹配
- `PodFitsHostPorts`：节点上已经使用的 port 是否和 pod 申请的 port 冲突
- `PodSelectorMatches`：过滤掉和 pod 指定的 label 不匹配的节点
- `NoDiskConflict`：已经 mount 的 volume 和 pod 指定的 volume 不冲突，除非它们都是只读
如果在 `预选` 过程中没有合适的节点，pod 会一直在 pending`状态，不断重试调度，直到有节点满足条件。经过这个步骤，如果有多个节点满足条件，就继续 `优选` 过程： 按照优先级大小对节点排序
优选
优先级由一系列键值对组成，键是该优先级项的名称，值是它的权重（该项的重要性）。这些优先级选项包括：
- `LeastRequestedPriority`：通过计算 CPU 和 Memory 的使用率来决定权重，使用率越低权重越高。换句话说，这个优先级指标倾向于资源使用比例更低的节点
- `BalancedResourceAllocation`：节点上 CPU 和 Memory 使用率越接近，权重越高。这个应该和上面的一起使用，不应该单独使用
- `ImageLocalityPriority`：倾向于已经有要使用镜像的节点，镜像总大小值越大，权重越高
通过算法对所有的优先级项目和权重进行计算，得出最终的结果
自定义调度器
除了 kubernetes 自带的调度器，你也可以编写自己的调度器。通过 `spec:schedulername` 参数指定调度器的名字，可以为 pod 选择某个调度器进行调度。比如下面的 pod 选择 `my-scheduler` 进行调度，而不是默认的 `default-scheduler`：
apiVersion: v1 kind: Pod metadata: name: test-scheduler labels: name: test-scheduler spec: schedulername: test-scheduler containers: - name: pod-with-second-annotation-container image: wangyanglinux/myapp:v2
亲和性
亲和性/反亲和性调度策略比较如下：
| 调度策略 | 匹配标签 | 操作符 | 拓扑域支持 | 调度目标
| nodeAffinity | 主机 | In, NotIn, Exists, DoesNotExist, Gt, Lt | 否 | 指定主机 |
| podAffinity | POD | In, NotIn, Exists, DoesNotExist | 是 | POD与指定POD同一拓扑域 |
| podAnitAffinity | POD | In, NotIn, Exists, DoesNotExist | 是 | POD与指定POD不在同一拓扑域 |
键值运算关系
- In： label 的值在某个列表中
- NotIn：label 的值不在某个列表中
- Gt： label 的值大于某个值
- Lt： label 的值小于某个值
- Exists：某个 label 存在
- DoesNotExist：某个 label 不存在
NodeAffinity：Node亲和性调度
- preferredDuringSchedulingIgnoredDuringExecution：软策略
- requiredDuringSchedulingIgnoredDuringExecution：硬策略
requiredDuringSchedulingIgnoredDuringExecution (硬限制)资源清单
apiVersion: v1 kind: Pod metadata: name: affinity labels: app: node-affinity-pod spec: containers: - name: with-node-affinity image: wangyanglinux/myapp:v1 affinity: //亲和性 nodeAffinity: //节点亲和 requiredDuringSchedulingIgnoredDuringExecution: //硬限制 nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/hostname //节点的label operator: NotIn //取反 values: - k8s-node02 //节点lable的value，pod将不会运行在node02上
preferredDuringSchedulingIgnoredDuringExecution(软限制) 资源清单
apiVersion: v1 kind: Pod metadata: name: affinity labels: app: node-affinity-pod spec: containers: - name: with-node-affinity image: wangyanglinux/myapp:v1 affinity: nodeAffinity: preferredDuringSchedulingIgnoredDuringExecution: //软限制，尽可能优先匹配，如果未匹配到，也会调度到其他节点 - weight: 1 //权重，定义匹配的优先级 preference: matchExpressions: - key: source operator: In //运算符 values: - qikqiak
软限制与硬限制合起来
apiVersion: v1 kind: Pod metadata: name: affinity labels: app: node-affinity-pod spec: containers: - name: with-node-affinity image: wangyanglinux/myapp:v1 affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: # 先匹配硬限制 nodeSelectorTerms: - matchExpressions: - key: disktype
operator: NotIn values: - hdd preferredDuringSchedulingIgnoredDuringExecution: # 匹配完硬限制后，尽量部署到node01节点，也可以匹配lable - weight: 1 preference: matchExpressions: - key: kubernetes.io/hostname operator: In values: - k8s-node01
测试阶段
给节点打一些标签
[root@master-1 hostpath]# kubectl get node --show-labels NAME STATUS ROLES AGE VERSION LABELS master-1 Ready <none> 28d v1.20.15 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,diskType=ssd,kubernetes.io/arch=amd64,kubernetes.io/hostname=master-1,kubernetes.io/master=true,kubernetes.io/os=linux,zone=east node-1 Ready <none> 28d v1.20.15 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,cpuType=gpu,kubernetes.io/arch=amd64,kubernetes.io/hostname=node-1,kubernetes.io/os=linux,zone=north node-2 Ready <none> 28d v1.20.15 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=node-2,kubernetes.io/os=linux,mem=64Gi,zone=south
Pod 亲和性
pod.spec.affinity.podAffinity/podAntiAffinity
- preferredDuringSchedulingIgnoredDuringExecution：软策略
- requiredDuringSchedulingIgnoredDuringExecution：硬策略
拓扑域概念：可以实现pod容灾调度
基本原则参考文档：https://support.huaweicloud.com/usermanual-cce/cce_10_0893.html
容灾调度：https://support.huaweicloud.com/bestpractice-cce/cce_bestpractice_00220.html
在容器部署要实现高可用，可参考如下几点：
- 集群选择3个控制节点的高可用模式。
- 创建节点选择在不同的可用区，在多个可用区（AZ）多个节点的情况下，根据自身业务需求合理的配置自定义调度策略，可达到资源分配的最大化。
- 创建多个节点池，不同节点池部署在不同可用区，通过节点池扩展节点。
- 工作负载创建时设置实例数需大于2个。
- 设置工作负载亲和性规则，尽量让Pod分布在不同可用区、不同节点上。
拓扑域：
拓扑域（topologyKey）通过节点的标签和标签值先圈定调度的节点范围，然后再通过标签名、操作符、标签值确定亲和/反亲和的对象，最后根据目标对象所处的拓扑域进行调度。
- 如果标签指定为kubernetes.io/hostname，此时标签值为节点名称，则将不同名称的节点划分为不同的拓扑域，由于节点名称不可重复，此时一个拓扑域中仅包含一个节点，因此可以实现单个节点级别的负载亲和性调度。
- 如果指定标签为kubernetes.io/os，此时标签值为节点的操作系统类型，则将不同操作系统的节点划分为不同的拓扑域，此时一个拓扑域中可能包含多个节点，因此可以将多个节点作为一个整体进行负载亲和性调度。
pod亲和性调度匹配顺序与规则
例如，通信频繁的前端应用Pod和后端应用Pod可优先调度到同一个节点或同一个可用区，减少网络延迟。工作负载亲和/反亲和的示意如下：
- 首先，拓扑域（根据topologyKey划分）通过节点的标签和标签值划分节点范围，将节点分为不同的拓扑域。
例如，topologyKey为prefer，表示可以通过节点标签prefer划分拓扑域。拓扑域1的范围为带有prefer=true标签的节点，拓扑域2的范围为带有prefer=false标签的节点，拓扑域3的范围为不带prefer标签的节点。
- 然后，根据工作负载标签名、操作符、标签值确定需要亲和/反亲和的工作负载对象。
- 最后，调度器选择目标工作负载所处的拓扑域进行亲和性调度，或者选择不存在目标工作负载的拓扑域进行反亲和性调度。
示例中，带有app=backend的工作负载在拓扑域1中，因此，亲和app=backend工作负载在调度时，可以调度到拓扑域1中。同理，反亲和app=backend工作负载在调度时，只能调度到拓扑域2或3中。
工作负载亲和/反亲和示意图
测试阶段：
使用lable划分拓扑域模拟多机房部署[root@master-1 conf]# kubectl label node master-1 topology.kubernetes.io/zone=zone1 node/master-1 labeled [root@master-1 conf]# kubectl label node node-1 topology.kubernetes.io/zone=zone2 node/node-1 labeled [root@master-1 conf]# kubectl label node node-2 topology.kubernetes.io/zone=zone3 node/node-2 labeled [root@master-1 conf]# kubectl get node -L topology.kubernetes.io/zone,kubernetes.io/hostname NAME STATUS ROLES AGE VERSION ZONE HOSTNAME master-1 Ready <none> 29d v1.20.15 zone1 master-1 node-1 Ready <none> 29d v1.20.15 zone2 node-1 node-2 Ready <none> 29d v1.20.15 zone3 node-2 [root@master-1 hostpath]# kubectl get node --show-labels NAME STATUS ROLES AGE VERSION LABELS master-1 Ready <none> 29d v1.20.15 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,diskType=ssd,kubernetes.io/arch=amd64,kubernetes.io/hostname=master-1,kubernetes.io/master=true,kubernetes.io/os=linux,os=centos,topology.kubernetes.io/zone=zone1 node-1 Ready <none> 29d v1.20.15 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,cpuType=gpu,kubernetes.io/arch=amd64,kubernetes.io/hostname=node-1,kubernetes.io/os=linux,os=centos,topology.kubernetes.io/zone=zone2 node-2 Ready <none> 29d v1.20.15 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=node-2,kubernetes.io/os=linux,mem=64Gi,os=centos,topology.kubernetes.io/zone=zone3
同一个namespace亲和性调度
调度清单配置示例
affinity: podAntiAffinity: # 反亲和 requiredDuringSchedulingIgnoredDuringExecution: # 硬限制，如果多个，必须完全满足所有硬限制 - labelSelector: matchExpressions: - key: app operator: In values: - redis namespaces: - app topologyKey: diskType # 根据节点标签划分拓扑域，如果kv完全相同，则属于同一个拓扑域 preferredDuringSchedulingIgnoredDuringExecution: # 软限制 - weight: 50 podAffinityTerm: labelSelector: matchExpressions: - key: app operator: In values: - backend namespaces: - app topologyKey: kubernetes.io/zone # 以zone标签划分拓扑域，如果这个zone有运行app=backend的pod，则尽可能不要调度到这个域。
创建工作负载，然后查看Pod所在的节点。
[root@master-1 hostpath]# kubectl get pod -n app -owide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES backend-8dd8454bf-bjtcx 1/1 Running 0 21m 10.244.84.154 node-1 <none> <none> nginx-configmap-7dc9697896-whzrs 1/1 Running 0 7s 10.244.84.163 node-1 <none> <none> nginx-configmap-7dc9697896-xmdqq 0/1 Running 0 7s 10.244.84.158 node-1 <none> <none> redis-86cc584c4-wlm2k 1/1 Running 0 26m 10.244.39.26 master-1 <none> <none>
将Pod数量增加到6，可以看到Pod被调度到了没有app=redis的节点，并且软限制反亲和 尽可能也没调度到app=backend的节点上
[root@master-1 hostpath]# kubectl get pod -n app -owide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES backend-8dd8454bf-bjtcx 1/1 Running 0 17m 10.244.84.154 node-1 <none> <none> nginx-configmap-696d6576d4-9s5h8 1/1 Running 0 37s 10.244.247.18 node-2 <none> <none> nginx-configmap-696d6576d4-ck4gq 0/1 Init:0/1 0 2s <none> node-2 <none> <none> nginx-configmap-696d6576d4-hgm7v 1/1 Running 0 37s 10.244.84.144 node-1 <none> <none> nginx-configmap-696d6576d4-kkdrc 1/1 Running 0 2m21s 10.244.247.12 node-2 <none> <none> nginx-configmap-696d6576d4-vghrr 1/1 Running 0 2m21s 10.244.247.16 node-2 <none> <none> redis-86cc584c4-wlm2k 1/1 Running 0 22m 10.244.39.26 master-1 <none> <none>
修改亲和性限制
affinity: podAntiAffinity: #preferredDuringSchedulingIgnoredDuringExecution: requiredDuringSchedulingIgnoredDuringExecution: #- weight: 50 # podAffinityTerm: - labelSelector: matchExpressions: - key: app operator: In values: - redis namespaces: - app topologyKey: diskType # 实际上可以理解为一个划分拓扑域的字段 podAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 50 podAffinityTerm: labelSelector: matchExpressions: - key: app operator: In values: - backend namespaces: - app topologyKey: topology.kubernetes.io/zone
创建2个pod
[root@master-1 hostpath]# kubectl get pod -n app -owide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES backend-8dd8454bf-bjtcx 1/1 Running 0 21m 10.244.84.154 node-1 <none> <none> nginx-configmap-7dc9697896-whzrs 1/1 Running 0 7s 10.244.84.163 node-1 <none> <none> nginx-configmap-7dc9697896-xmdqq 0/1 Running 0 7s 10.244.84.158 node-1 <none> <none> redis-86cc584c4-wlm2k 1/1 Running 0 26m 10.244.39.26 master-1 <none> <none>
扩容到6个，可以看到根据pod亲和性，已经大部分调度到跟backend一个域了。
[root@master-1 hostpath]# kubectl scale deployment nginx-configmap -n app --replicas=6 deployment.apps/nginx-configmap scaled [root@master-1 hostpath]# kubectl get pod -n app -owide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES backend-8dd8454bf-bjtcx 1/1 Running 0 22m 10.244.84.154 node-1 <none> <none> nginx-configmap-7dc9697896-44gmb 1/1 Running 0 21s 10.244.247.8 node-2 <none> <none> nginx-configmap-7dc9697896-dx477 1/1 Running 0 21s 10.244.247.3 node-2 <none> <none> nginx-configmap-7dc9697896-hhnvk 0/1 PodInitializing 0 2s 10.244.84.164 node-1 <none> <none> nginx-configmap-7dc9697896-whzrs 1/1 Running 0 37s 10.244.84.163 node-1 <none> <none> nginx-configmap-7dc9697896-xmdqq 1/1 Running 0 37s 10.244.84.158 node-1 <none> <none> nginx-configmap-7dc9697896-xzc5p 1/1 Running 0 21s 10.244.84.166 node-1 <none> <none> redis-86cc584c4-wlm2k 1/1 Running 0 26m 10.244.39.26 master-1 <none> <none>
两种经典调度方案
1. 服务间亲和性调度
affinity: # 设置调度策略 podAffinity: # 工作负载亲和性调度规则 requiredDuringSchedulingIgnoredDuringExecution: # 表示必须满足的调度策略 - topologyKey: prefer # 根据节点标签划分拓扑域，示例中prefer为自定义标签 labelSelector: # 根据工作负载标签选择满足条件的工作负载 matchExpressions: # 工作负载标签匹配规则 - key: app # 工作负载标签的键为app operator: In # 表示存在values列表中的值即满足规则 values: # 工作负载标签的值列表 - backend preferredDuringSchedulingIgnoredDuringExecution: # 表示尽量满足的调度策略 - weight: 100 # 使用尽量满足策略时可设置优先级，取值为1-100，数值越大优先级越高 podAffinityTerm: # 使用尽量满足策略时的亲和项 topologyKey: topology.kubernetes.io/zone # 根据节点标签划分拓扑域，以节点的可用区为粒度 labelSelector: matchExpressions: - key: app operator: In values: - backend
上述示例中的工作负载调度时，
1. 必须满足规则会根据prefer标签划分节点拓扑域，如果当拓扑域中某个节点运行着后端Pod（标签为app=backend），即使该拓扑域中并非所有节点均运行了后端Pod，前端Pod（标签为app=frontend）同样会部署在此拓扑域中。
2. 而尽量满足规则根据topology.kubernetes.io/zone划分拓扑域，以节点的可用区为粒度进行调度，表示尽量将前后端部署至同一可用区的节点。
2. 容灾调度
affinity: podAntiAffinity: # 工作负载反亲和性调度规则 requiredDuringSchedulingIgnoredDuringExecution: # 表示必须满足的调度策略 - topologyKey: kubernetes.io/hostname # 根据节点标签划分拓扑域 labelSelector: # Pod标签匹配规则 matchExpressions: # 工作负载标签的键为app - key: app # 工作负载标签的键为app operator: In # 表示存在values列表中的值即满足规则 values: # 工作负载标签的值列表 - frontend preferredDuringSchedulingIgnoredDuringExecution: # 表示尽量满足的调度策略 - weight: 100 # 使用尽量满足策略时可设置优先级，取值为1-100，数值越大优先级越高 podAffinityTerm: # 使用尽量满足策略时的亲和项 topologyKey: topology.kubernetes.io/zone # 根据节点标签划分拓扑域,这个域有这个标签的pod，我就不调度了 labelSelector: matchExpressions: - key: app operator: In values: - frontend
以上示例中定义了反亲和规则
1. 必须满足的规则表示根据kubernetes.io/hostname标签划分节点拓扑域。由于拥有kubernetes.io/hostname标签的节点中，每个节点的标签值均不同，因此一个拓扑域中只有一个节点。当一个拓扑域中（此处为一个节点）已经存在frontend标签的Pod时，该拓扑域不会被继续调度具有相同标签的Pod。
2. 而尽量满足规则根据topology.kubernetes.io/zone划分拓扑域，以节点的可用区为粒度进行调度，表示尽量将Pod分布至不同可用区的节点。
补充：
- maxSkew: 1 用于指定pod在各个zone调度时能忍受的最大不均衡数，值越大，表示能接受的不均衡调度越大，值越小，表示各个zone调度的pod越均衡。
跨namespace亲和性调度
CrossNamespacePodAffinity 是 Kubernetes 的 ResourceQuota 作用域之一，用于限制那些设置了跨命名空间的 Pod 亲和性或反亲和性规则的 Pod。以下是如何在 Pod 中应用 跨命名空间 Pod（反）亲和性的详细说明和示例。
跨命名空间的 Pod（反）亲和性规则允许 Pod 引用其他命名空间中的 Pod 标签。
apiVersion: v1 kind: Pod metadata: name: pod-with-affinity namespace: app spec: affinity: podAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchLabels: app: backend topologyKey: "kubernetes.io/hostname" namespaces: - shared-namespace # 引用另一个命名空间 containers: - name: busybox image: busybox command: ["sh", "-c", "sleep 1000"]
效果：
Pod 将被调度到与 shared-namespace 中标签为 app: backend 的 Pod 位于同一节点的地方。
Pod 设置跨命名空间的反亲和性
apiVersion: v1 kind: Pod metadata: name: pod-with-antiaffinity namespace: app spec: affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchLabels: app: frontend topologyKey: "kubernetes.io/hostname" namespaces: - shared-namespace # 引用另一个命名空间 containers: - name: busybox image: busybox command: ["sh", "-c", "sleep 1000"]
效果：Pod 将被调度到与 shared-namespace 中标签为 app: frontend 的 Pod 不在同一主机的地方。
ResourceQuota 配置示例
apiVersion: v1 kind: ResourceQuota metadata: name: cross-namespace-affinity-quota namespace: app spec: hard: pods: "5" # 限制跨命名空间亲和性 Pod 的数量 scopes: - CrossNamespacePodAffinity # 匹配跨命名空间亲和性规则的 Pod
效果：
- 限制
app命名空间中设置了跨命名空间亲和性或反亲和性的 Pod 总数量不超过5。
【推荐】国内首个AI IDE，深度理解中文开发场景，立即下载体验Trae
【推荐】编程新体验，更懂你的AI，立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包，你的智能百科全书，全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell：AI 加持，快人一步
· 使用C#创建一个MCP客户端
· 分享一个免费、快速、无限量使用的满血 DeepSeek R1 模型，支持深度思考和联网搜索！
· ollama系列1：轻松3步本地部署deepseek，普通电脑可用
· 基于 Docker 搭建 FRP 内网穿透开源项目（很简单哒）
· 按钮权限的设计及实现