k8s--集群调度(kube-scheduler)

2024-01-08 17:48:17

了解kube-scheduler

由之前博客可知kube-scheduler是k8s中master的核心组件之一

scheduler:负责调度资源。把pod调度到node节点。他有两种策略:

预算策略:人为部署,指定node节点去部署新建的pod

优先策略:通过算法选择一个负载最小,资源最充沛的资源去部署。

k8s中List-watch

k8s集群当中,通过list-watch的机制进行每个组的写作,保持数据同步。这种设计可以实现每个组件之间的解耦(解耦:减少每个组件之间的关联性)。

kubectl来配置文件,向APIServer发送命令----apiserver把命令发送到各个组件。

kubectl run nginx --image=nginx:1.22-------apiserver------controller manager------scheduler-------kubelet.。

创建成功之后,kubectl get pod kubectl describe pod nginx-------保存到etcd当中

以上过程是list-watch会在每一步把监听的消息(APIserver:6443)-------controller manager,scheduler,kubelet,etcd都会监听apiserver:6443

工作流程图:

注意:在创建 Pod 的工作就已经完成了后,为什么 kubelet 还要一直监听呢?原因很简单,假设这个时候 kubectl 发命令,要扩充 Pod 副本数量,那么上面的流程又会触发一遍,kubelet 会根据最新的 Pod 的部署情况调整 Node 的资源。又或者 Pod 副本数量没有发生变化,但是其中的镜像文件升级了,kubelet 也会自动获取最新的镜像文件并且加载。
?

2.调度的过程和策略

scheduler是k8s集群的调取器,把pod分配到集群的节点。

以下几个问题需要考虑:

1.公平:每个节点都能够分配资源。

2.资源高效利用:集群当中的资源可以被最大化利用

3.效率:调度的性能要搞好。能够尽快的完成大批量的pod的调度工作。

4.灵活:允许用户根据自己的需求,控制和改变调度的逻辑。

scheduler是一个单独运行的程序,启动之后就会一直监听APIserver,获取报文中的字段:spec.modeName

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

创建pod到节点时,有两个策略:先执行预算策略再执行优先策略。这两步都必须成功,否则立刻返回报错。

也就是说,部署的node,必须满足这两个策略。

预算策略:

predicate自带一些算法来选择node节点(scheduler自带的算法策略。不需人工干预)

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

只有上述策略完成,才回到优先策略。如果预算策略都不满足,pod将始终处于pending状态,不断地重试调度,直到有节点满足条件为止。

如果node1,node2,node3经过预算策略,上述三个节点都满足条件----》优先策略

优先策略

leastreaquestedpriority:

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

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

balancersourceallocation:

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

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

举个例子,有node1,node2两个节点,资源分别是:

node1 cpu和内存使用率: 20:60

node2 cpu和内存使用率: 50:50

node2再被调度时会被优先

imagelocalitypriority:

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

以上这些策略scheduler自带的算法。

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

总的来说:

预选策略 :通过调度算法过滤掉不满足条件的Node节点

优选策略 :通过优先级选项给满足调度条件的Node节点进行优先级权重排序,最终选择优先级最高的Node节点来调度Pod

如何指定节点部署

指定节点配置需要在spec模块中参数设置:

nodeName:node02

首先,我们为了防止缩进错误,用生成的yaml文件修改:

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx
  name: nginx2
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
    template:
      metadata:
        labels:
          app: nginx
      spec:
        containers:
        - image: nginx:1.22
          name: nginx
        nodeName: node02

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

如何指定标签部署

我们可以通过以下命令查看node的标签

kubectl get nodes --show-labels

我们可以在命令行给node添加标签

kubectl label nodes node02 test3=c

已经部署的服务器的标签

已经部署的服务器的标签

节点资源不够会进入pending

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

k8s集群的亲和性

软策略和硬策略

node节点亲和性:

preferredDuringSchedulingIgnoredDuringExecution软策略:

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

requiredDuringSchedulingIgnoredDuringExecution硬策略:

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

pod的亲和性

preferredDuringSchedulingIgnoredDuringExecution软策略

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

pod nginx1 node01

pod nginx2 node02 希望和nginx1部署在一个节点,尽量满足

requiredDuringSchedulingIgnoredDuringExecution硬策略

pod nginx1 node01

pod nginx2 node02 必须要和nginx的亲和性匹配,只能往node01。

键值的运算关系

标签:都是根据标签开选择亲和性。

In:在

选择的标签值在node节点上存在。

Notin:不在

选择label的值不在node节点上

Gt:大于,大于选择的标签值

Lt:小于,小于选择标签值。

Exists:存在,选择标签对象,值不考虑。

DoesNotExit:选择不具有指定表

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx
  name: nginx2
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      nodeSelector:
        test01: a
      containers:
      - image: nginx:1.22
        name: nginx
      affinity:
#选择亲和性部署方式
        nodeAffintity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
选择了亲和性nodeSelectorsTerms你要选择哪个nodez作为node为硬策略,匹配的节点标签
            - matchExpressions:
定义一个符合我要选择的node节点的信息
              - key: test3
                operator: In(NotIn)
指定键值对的算法
                values:
                - c
                
wq

删除标签

kubectl label nodes node01 test2-

              - key: memory
                operator: Gt
                values:
                - "612"
wq                
kubectl label nodes node02 memory=1000

Gt:大于,大于选择的标签值

Lt:小于,小于选择标签值。

只能比较整数值

亲和性策略根据标签来选择。

Exists:存在,选择标签对象,值不考虑。

DoesNotExit:选择不具有指定表

              - key: memory
                operator: Exists
                values:
                - "612"
wq
kubectl apply -f test1.yaml
会报错,因为不能有值

所以:
              - key: memory
                operator: Exists
指定键值对的算法为Exists  or  DoesNotExists不能使用values字段。

软策略

     affinity:
#选择亲和性部署方式
        nodeAffintity:
          preferredDuringSchedulingIgnoredDuringExecution:
         -weight: 1
选择软策略之后要加上权重
         preference:
选择节点的倾向,尽量满足要求而不是一定。        
选择了亲和性nodeSelectorsTerms你要选择哪个nodez作为node为硬策略,匹配的节点标签
            - matchExpressions:
定义一个符合我要选择的node节点的信息
              - key: memory
                operator: DoesNotExist

                
wq

多个软策略通过什么匹配?

      affinity:
#选择亲和性部署方式
        nodeAffintity:
          preferredDuringSchedulingIgnoredDuringExecution:
         - weight: 1
 
选择软策略之后要加上权重
         preference:
选择节点的倾向,尽量满足要求而不是一定。        
选择了亲和性nodeSelectorsTerms你要选择哪个nodez作为node为硬策略,匹配的节点标签
            - matchExpressions:
定义一个符合我要选择的node节点的信息
              - key: memory
                operator: DoesNotExist
                preferredDuringSchedulingIgnoredDuringExecution:
         - weight: 10
           preference:
             matchExpressions:
             - key: memory
               operator: In
               values:
               - "500"
               
多个软策略以权重高的为标的

软硬策略结合的话结果是什么?

      affinity:
        nodeAffintity:
          preferredDuringSchedulingIgnoredDuringExecution:
         - weight: 1
 
         preference:
            - matchExpressions:
              - key: memory
                operator: Exists
               values:
               - "1000"
                requiredDuringSchedulingIgnoredDuringExecution:
           nodeSelectorTerms:
           - matchExpressions:
             - key: memory
               operator: In
               values:
               - "500"
               
               wq
               
kubectl apply -f test1.yaml

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

硬策略:先满足硬策略,硬策略一个都不满足才会执行软策略。

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

node亲和性:性能不一致,我尽量把pod往性能高的多部署,软策略

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

举例子:

4/8G 4/8G 2/4G

node1 node2 node3

性能不一致的时候最好使用软策略

如果其中一个node 挂了,可以使用硬策略来指定部署。

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