十分钟搞懂K8S的亲和与反亲和调度

云计算
本文主要快速讲解Kubernetes的亲和性调度和反亲和性调度,通过理论结合实际的方式,让理解更深刻。

本文主要快速讲解Kubernetes的亲和性调度和反亲和性调度,通过理论结合实际的方式,让理解更深刻。

首先来个一句话总结:亲和性调度就像关系亲密的闺蜜,你去哪儿我也去哪儿。反亲和性调度就像赌气的两个孩子,赌气永远不在一起玩儿。更多解释和实战详见下文。花10分钟看到最后,你肯定会有收获。

1、调度Pod的主要方式

Pod调度到指定Node的方式主要有4种:

  • nodeName调度:直接在Pod的yaml编排文件中指定nodeName,调度到指定name的节点上。
  • nodeSelector调度:直接在Pod的yaml编排文件中指定nodeSelector,调度到带有指定label的节点上。
  • 污点(Taints)和容忍度(Tolerations)调度:详见文章《5分钟搞懂K8S的污点和容忍度(理论+实战)》。主要通过在Node节点上打污点,然后在Pod的yaml编排文件中配置容忍度,来实现调度。
  • 亲和-反亲和调度:见下文讲解。

2、为什么需要亲和调度

有了nodeName调度、nodeSelector调度、污点(Taints)和容忍度(Tolerations)调度,为什么还需要亲和-反亲和调度呢?

为了更灵活更复杂的调度方式。比如有些场景想把2个Pod 调度到一台节点上,有的场景为了隔离性高可用性想把2个Pod分开到不同节点上,或者有的场景想把Pod调度到指定的一些特点节点上。

3、亲和调度的前置概念(重要)

  • label在K8S中是非常重要的概念,不管是什么场景,只要和选择、筛选相关的,基本是用label字段来匹配的。
  • 亲和性和反亲和性的调度,筛选的条件依旧用的是Node的label字段。
  • 不管是Node亲和性调度,还是Pod亲和性调度,被调度的主体都是Pod。都是讲的Pod根据亲和规则调度到某个节点,或者Pod跟随别的Pod调到到某个节点(比如Pod1跟随Pod2,Pod2被调度到B节点,那么Pod1也被调度到B节点)。
  • Node亲和性调度 和  Pod亲和性调度 的配置都是写在 编排Pod的yaml里。因为被调度的主体是Pod。
  • Node亲和性调度是指Pod和Node的亲密关系。
  • Pod亲和性调度是指Pod和Pod的亲密关系。
  • 硬亲和:亲和规则只有一种,必须符合该规则。
  • 软亲和:规则有多种,每个权重不同,根据权重优先级去选择一个规则。
  • Node亲和性调度的图示如下,Pod亲和性调用和Pod反亲和性调用也类似。

4、亲和调度的具体概念

Affinity的中文意思是亲近,用来表述亲和性调度再合适不过了。

亲和性调度:就好像Node(或者Pod)和Pod是关系很好的闺蜜,Pod说,“只要符合这种label的Node(Pod)都是我的好闺蜜,闺蜜在哪儿我就去哪儿”。

反亲和性调度:就好像2个Pod是赌气的2个孩子,互相对着干,一个往东,另一随便去哪个方向就是不往东,他们不会去到同一个地方。

4.1、记住这3种调度关系

亲和性调度 和 反亲和性调度的关系就3种:

  • node亲和调度:硬亲和、软亲和
  • pod亲和调度:硬亲和、软亲和
  • pod反亲和调度:硬亲和、软亲和

4.2、记住这2种亲和表达式

不管是Node亲和 还是Pod亲和,他们都有2种亲和性表达方式:

  • RequiredDuringSchedulingIgnoredDuringExecution:是硬亲和的方式,必须满足指定的规则才可以把Pod调度到该Node上。这里注意Required这个词,中文意思必须的。
  • PreferredDuringSchedulingIgnoredDuringExecution:是软亲和的方式,强调优先满足某个规则,然后根据优先的规则,将Pod调度到节点上。这里注意Preferred这个词,中文意思是首选,用来说明选择规则的优先级,确实比较合适。

这两个字段也比较长,我们来做下拆解,将RequiredDuringSchedulingIgnoredDuringExecution拆解为RequiredDuringScheduling和IgnoredDuringExecution。

  • RequiredDuringScheduling:定义的规则必须强制满足(Required)才会把Pod调度到节点上。
  • IgnoredDuringExecution:已经在节点上运行的Pod不需要满足定义的规则,即使去除节点上的某个标签,那些需要节点包含该标签的Pod依旧会在该节点上运行。或者这么理解:如果Pod所在的节点在Pod运行期间标签被删除了,不再符合该Pod的节点亲和性规则,那也没关系,该Pod 还能继续在该节点上运行。

4.3、表达式中的操作符

亲和性表达方式需要用到如下几个可选的操作符operator:

  • In:标签的值在某个列表中
  • NotIn:标签的值不在某个列表中
  • Exists:存在某个标签
  • DoesNotExist:不存在某个标签
  • Gt:标签的值大于某个值(字符串比较)
  • Lt:标签的值小于某个值(字符串比较)

这些操作符里,虽然没有排斥某个节点的功能,但是用这几个标签也可以变相的实现排斥的功能。

4.4、作用域topologyKey

topologyKey很多地方解释为拓扑建,很是费解。实际上就是个作用域的概念。

topologyKey配置了一个label的key,那么存在这个key对应的label的所有Node就在同一个作用域里。

5、实战

理论知识讲解完毕,接下来通过实战加深理解。你可以按照步骤操作实践。

5.1、nodeName调度

比如要将Pod调度到nodeName是k8s-worker-2的节点上

apiVersion: v1
kind: Pod
metadata:
  name: webapp
  namespace: demo
  labels:
    app: webapp
spec:
  nodeName: 'k8s-worker-2'
  containers:
    - name: webapp
      image: nginx
      ports:
        - containerPort: 80

5.2、nodeSelector调度

比如要将Pod调度到具有"special-app"="specialwebapp"的label节点上。

查看节点信息:

kubectl describe node k8s-worker-2

Pod的yaml编排文件:

apiVersion: v1
kind: Pod
metadata:
  name: webapp
  namespace: demo
  labels:
    app: webapp
spec:
  nodeSelector:
    # 选择调度到具有这个label的节点
    "special-app": "specialwebapp"
  containers:
    - name: webapp
      image: nginx
      ports:
        - containerPort: 80

查看Pod被调度到哪台机器上:

kubectl get pod -n demo -o wide

5.3、Node亲和调度

Node的亲和调度是指,Node和Pod的关系。

硬亲和

定义Pod-Node的硬亲和yaml文件:pod_node_required_affinity.yaml。文件内容如下:

apiVersion: v1
kind: Pod
metadata:
  name: webapp
  namespace: demo
  labels:
    app: webapp
spec:
  containers:
    - name: webapp
      image: nginx
      ports:
        - containerPort: 80
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
          - matchExpressions:
              - key: app
                operator: In
                values:
                  - backend

给k8s-worker-3节点添加label:

kubectl label node k8s-worker-3 app=backend

查看k8s-worker-3节点的label情况:

kubectl get node k8s-worker-3 --show-labels

图片

执行上面的yaml部署Pod,可以看到Pod已经被调度到k8s-worker-3节点上。

软亲和

软亲和调度,主要就是加入了多个规则,每个设置了权重,yaml文件如下:

apiVersion: v1
kind: Pod
metadata:
  name: webapp
  namespace: demo
  labels:
    app: webapp
spec:
  containers:
    - name: webapp
      image: nginx
      ports:
        - containerPort: 80
  affinity:
    nodeAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
        - weight: 80
          preference:
            matchExpressions:
              - key: app2
                operator: Exists
        - weight: 20
          preference:
            matchExpressions:
              - key: app
                operator: In
                values:
                  - backend2

删除之前的Pod,删除之前的k8s-worker-3节点的label,再给k8s-worker-2节点的增加app2=backend的label。

kubectl delete pod webapp -n demo
kubectl label node k8s-worker-3 app-
kubectl label node k8s-worker-2 app2=backend

部署上面的软亲和yaml文件,可以看到Pod被调度到了k8s-worker-2节点。

5.4、Pod亲和调度

Pod亲和调度,是指Pod和Pod之间的关系。

硬亲和

比如Pod1跟随Pod2,Pod2被调度到B节点,那么Pod1也被调度到B节点。

所以这里准备2个Pod。Pod1使用上面的例子,让Pod1采用Node硬亲和调度到k8s-worker-3节点。然后再部署Pod2,让它跟随Pod1,也会被调度到k8s-worker-3节点。

准备Pod2的yaml编排文件pod_pod_required_affinity.yaml,如下:

apiVersion: v1
kind: Pod
metadata:
  name: webapp-1
  namespace: demo
  labels:
    app: webapp-1
spec:
  containers:
    - name: webapp
      image: nginx
      ports:
        - containerPort: 80
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        - topologyKey: kubernetes.io/hostname
          labelSelector:
            matchExpressions:
              - key: app
                operator: In
                values:
                  - webapp

可以看到Pod2跟随Pod1,也被调度到了k8s-worker-3节点。

软亲和

软亲和和硬亲和类似,只是多了权重,你可以自行尝试。

5.5、Pod反亲和调度

反亲和的硬亲和

接着上面的例子,继续准备Pod3的yaml编排文件,如下:

apiVersion: v1
kind: Pod
metadata:
  name: webapp-2
  namespace: demo
  labels:
    app: webapp-2
spec:
  containers:
    - name: webapp
      image: nginx
      ports:
        - containerPort: 80
  affinity:
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        - topologyKey: kubernetes.io/hostname
          labelSelector:
            matchExpressions:
              - key: app
                operator: In
                values:
                  - webapp

使用Pod反亲和的方式,让Pod3和Pod1不会部署在一起。部署完毕后,查看结果,Pod3因为反亲和被调度到了k8s-worker-2节点。

图片

反亲和的软亲和

反亲和的软亲和 和 硬亲和类似,只是多了权重,你可以自行尝试。

6、总结

本文主要快速讲解Kubernetes的亲和性和反亲和性调度。读完本文你需要记住以下3点:

  • 亲和性 和 反亲和性的调度,筛选的条件使用的是Node(Pod)的label字段。
  • 亲和性调度:就好像Node(Pod)和Pod是关系很好的闺蜜,Pod说,“只要符合这种label的Node(Pod)都是我的好闺蜜,闺蜜在哪儿我就去哪儿”。
  • 反亲和性调度:就好像2个Pod是赌气的2个孩子,互相对着干,一个往东,另一随便去哪个方向就是不往东,他们不会去到同一个地方。
责任编辑:华轩 来源: 不焦躁的程序员
相关推荐

2023-09-24 22:47:42

Kubernetes亲和性

2024-01-29 13:03:02

2019-09-16 09:14:51

2019-04-01 14:59:56

负载均衡服务器网络

2020-12-11 09:40:10

DevOpsCICD

2024-01-29 00:20:00

GolangGo代码

2024-01-12 08:03:29

k8s配置持久化

2021-03-03 11:36:57

Java 8Java 15Java

2020-12-17 06:48:21

SQLkafkaMySQL

2015-09-06 09:22:24

框架搭建快速高效app

2023-11-30 10:21:48

虚拟列表虚拟列表工具库

2012-07-10 01:22:32

PythonPython教程

2023-06-07 08:27:10

Docker容器

2022-06-07 14:31:09

K8S网络模型容器网络

2023-11-09 14:44:27

Docker镜像容器

2015-11-06 11:03:36

2022-04-13 22:01:44

错误监控系统

2021-07-29 08:57:23

ViteReact模块

2023-12-08 13:19:00

前端Reactour流行库

2022-06-16 07:31:41

Web组件封装HTML 标签
点赞
收藏

51CTO技术栈公众号