【K8S 云原生】Kurbernets集群的调度策略

2024-01-08 18:50:36

目录

一、Kubernetes的list-watch机制

1、List-watch

2、创建pod的过程:

二、scheduler调度的过程和策略:

1、简介

2、预算策略:predicate

3、优先策略:

3.1、leastrequestedpriority:

3.2、balanceresourceallocation:

3.3、imagelocalitypriority:

4、选择的过程:

三、kubernetes对Pod的调度策略

四、定向调度

1、调度策略简介:

2、指定节点:

3、指定标签:

五、亲和性调度:

1、介绍:

2、键值的运算关系:

3、node亲和性实例


一、Kubernetes的list-watch机制

1、List-watch

K8S集群中,通过List-watch机制进行每个组件的协作,保持数据同步。这种设计可以实现每个组件之间的解耦

kubectl配置文件,统一向集群内部apiserver发送命令——通过apiserver把命令发送到各个组件

创建成功之后,kubectl get pod,kubectl describe pod nginx查看信息——在ETCD数据库中

List-watch会在每一步把监听的消息(apiserver:6443)——组件controller-manager、schedule、kubelet、ETCD都会监听apiserver的6443端口

2、创建pod的过程:

二、scheduler调度的过程和策略:

1、简介

scheduler是K8S集群的调度器,把pod分配到集群的节点

调度规则:

  1. 公平,每个节点都能够分配资源
  2. 资源高效利用,集群中的资源可以被最大化使用
  3. 效率:调度的性能要好,能够尽快的完成大批量pod的调度工作
  4. 灵活:允许用户根据自己的需求,控制和改变调度的逻辑

scheduler:负责调度资源,把Pod调度到node节点上

有两种策略:预算策略、优选策略

scheduler是一个单独运行的程序,只要启动之后就会一直监听apiserver。获取报文中的字段:spec中的nodeName字段

创建pod时,为每个pod创建一个binding,表示该往哪个节点上部署

创建pod到节点时,有两个策略

先执行预算策略,在执行优先策略。这两步的操作都必须成功,否则立刻返回报错

部署的node必须满足这两个策略,少一个都不行

2、预算策略:predicate

自带一些算法,选择node节点,是scheduler自带的算法策略,不需要人工干预

  1. podfitsresources:pod的适应策源,检查节点上剩余的资源是否满足pod请求的资源(主要是CPU和内存)
  2. podfitshost:po适应主机,如果pod指定了node的name,检测主机名是否存在,如果存在要和pod指定的名称匹配,这才能调度过去
  3. podselectormarches:pod选择器匹配,创建pod的时候,可以根据node'节点的标签来进行匹配。他查找指定的node节点上标签是否存在。存在的标签是否匹配
  4. nodeskconflict:无磁盘冲突,确保已挂载的卷和pod卷不发生冲突。除非目录是只读

如果预算策略不满足,pod将始终处于pending状态,不断重试调度,直到节点满足条件为止

若三个node节点都满足——>优选策略

3、优先策略:

3.1、leastrequestedpriority:

最低请求优先级,通过算法计算节点上的CPU和内存使用率,确定节点的权重

使用率越低的节点,相应的权重就越高。调度时会更倾向于这些使用率低的节点。实现资源合理的利用

3.2、balanceresourceallocation:

平衡资源分配,算CPU和内存的使用率,给节点赋予权重。权重算的是CPU和内存使用率接近,权重越高。

和上面的最低请求优先级一起使用

举例:

node1 CPU和内存使用率:20 60

node2 CPU和内存使用率:50 50

node2的内存和CPU使用率接近,权重高,会被选择

3.3、imagelocalitypriority:

节点上是否已经有了要部署的镜像。镜像的总数成正比,满足的镜像数越多,权重越好

以上三个策略都是scheduler自带的算法,自动的

4、选择的过程:

先通过预算策略选择出可以部署的节点,在通过优选策略选择出最好的节点,以上都是自带的算法。K8S集群自己来选择

三、kubernetes对Pod的调度策略


在 Kubernetes 中,调度 是指将 Pod 放置到合适的节点上,以便对应节点上的 Kubelet 能够运行这些 Pod。

1)定向调度: 使用 nodeName 字段指定node节点名称;使用 nodeSelector 字段指定node节点的标签;

2)亲和性调度: 使用 节点/Pod 亲和性(NodeAffinity、PodAffinity、PodAntiAffinity);

3)污点与容忍: 使用 节点设置污点,结合 Pod设置容忍。

4)全自动调度:运行在哪个节点上完全由Scheduler经过一系列的算法计算得出;
?

#补充,Pod和node的关系
Node 是 Kubernetes 集群中的工作节点
一个 Node 可以运行多个 Pod,而一个 Pod 只能运行在一个 Node 上
使用标签和选择器可以管理 Node 和 Pod 之间的关系,从而实现灵活的调度和管理。

四、定向调度

1、调度策略简介:


nodeName:指定节点名称,用于将Pod调度到指定的Node上,不经过调度器。

nodeSelector:在 Pod 定义文件的 spec 下的 nodeSelector 字段中设置一个标签选择器,在 Pod 调度的时候,只有具有这些标签的 Node 才会被考虑用来运行这个 Pod。
?

2、指定节点:

spec参数设置:

nodeName: node2

指定了节点,在参数中设置了nodeName,指定了节点的名称,会跳过scheduler的调度策略,这个规则是强制匹配

3、指定标签:

spec参数设置:

nodeSelector:

节点自定义标签:

kubectl label nodes master01 test1=a
kubectl label nodes node01 test2=b
kubectl label nodes node02 test3=c


kubectl get nodes --show-labels
#查看节点的标签

指定节点标签部署pod,是要经过scheduler的算法,如果节点不满足条件,pod会进入pending状态。直到节点满足条件为止

五、亲和性调度:

1、介绍:

两种亲和性:节点亲和性和pod亲和性

两种策略:软策略和硬策略

node节点的亲和性:

preferredDuringSchedulingIgnoredDuringExecution:软策略

选择node节点时,声明了我最好能部署在node01。如果是软策略,他会尽量满足这个条件,不一定会完全部署在node01节点上。

requiredDuringSchedulinglgnoredDuringExecution:硬策略

选择pod时,声明了部署在node1上。如果是硬策略,必须满足硬策略的条件,必须部署在node1上。强制性要求

pod的亲和性:

preferredDuringSchedulingIgnoredDuringExecution:软策略

要求调度器将pod调度到其他pod的亲和性匹配的节点上。可以是,也可以不是,尽量满足

requiredDuringSchedulingIgnoredDuringExecution:硬策略

要求调度器将pod调度到其他pod的亲和性匹配的节点上,强制性满足

2、键值的运算关系:

都是根据标签来选择node或者pod的亲和性

  1. In(大写的i):在,选择的标签值在node节点上存在
  2. Notin:不在,选择label的值不在node节点上
  3. Gt:大于,要大于选择的标签值,只能比较整数
  4. Lt:小于,要小于选择的标签值,只能比较整数
  5. Exists:存在,只是选择标签对象,不考虑值
  6. DoesNotExist:不存在,选择不具有指定标签的对象。不考虑值

3、node亲和性实例

node亲和性的硬策略:

in策略:

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx
  name: nginx

spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx:1.22
        name: nginx
      affinity:
#选择亲和性部署方式
        nodeAffinity:
#选择的是node节点的亲和性
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
#选择了亲和性的策略。nodeSelectorTerms你要选择哪个node作为硬策略。匹配的节点标签
            - matchExpressions:
#定义了一个符合我要选择的node节点信息
              - key: test3
                operator: In
#指定键值对的算法
                values:
                - c

硬限制选择test3=c的节点

Notin:

notin,只要不在test3=c的节点,都能够部署

删除节点上的标签:

kubectl label nodes master01 test1-
kubectl label nodes node01 test2-
kubectl label nodes node02 test3-

更改标签名:

kubectl label nodes node02 ?memory=1000 --overwrite

Gt:?????

?affinity:
????????nodeAffinity:
??????????requiredDuringSchedulingIgnoredDuringExecution:
????????????nodeSelectorTerms:
????????????- matchExpressions:
??????????????- key: memory
????????????????operator: Gt
????????????????values:
????????????????- "612"

大于612节点上部署

Exists:


????

??affinity:
????????nodeAffinity:
??????????requiredDuringSchedulingIgnoredDuringExecution:
????????????nodeSelectorTerms:
????????????- matchExpressions:
??????????????- key: memory
????????????????operator: Exists
#指定键值对的算法为Exists或DoesNotExist,不能使用values字段

DoesNotExist:
?????

?affinity:
????????nodeAffinity:
??????????requiredDuringSchedulingIgnoredDuringExecution:
????????????nodeSelectorTerms:
????????????- matchExpressions:
??????????????- key: memory
????????????????operator: DoesNotExist

软策略:


????

??affinity:
????????nodeAffinity:
??????????preferredDuringSchedulingIgnoredDuringExecution:
??????????- weight: 1
????????????preference:
??????????????matchExpressions:
??????????????- key: memory
????????????????operator: In
????????????????values:
????????????????- "1000"

??????????preferredDuringSchedulingIgnoredDuringExecution:
??????????- weight: 10
????????????preference:
??????????????matchExpressions:
??????????????- key: memory
????????????????operator: In
????????????????values:
????????????????- "500"

多个软策略看权重,权重高,执行指定的软策略

硬策略和软策略一起执行:

先满足硬策略,再考虑软策略。若硬策略无法满足,软策略一个都不会执行

面试题:

你在部署pod的时候选择什么样的策略:

根据node的亲和性:

性能不一致,尽量把pod往性能高的多部署,选择软策略

节点故障或者节点维护中,只能选择硬策略,把故障节点剔除

文章来源:https://blog.csdn.net/koeda1/article/details/135461842
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。