k8s的集群调度

发布时间:2024年01月08日
  1. list-watch

???k8s集群当中,通过list-watch的机制进行每个组件的协作,保持数据同步。每个组件之间的解耦。

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

创建一个pod 叫 nginx ???镜像是nginx1.22

创建成功之后,kubectl ?get ?pod ??kubectl ?describe ??pod ?nginx --------->etcd的数据库当中。

list-watch -----会在每一步把监听的消息(apiserver:6443)----controller manager,scheduler

Kubeelet ?etcd都会监听。

Apiserver:64443端口。

如何来吧pod分配到node节点。

2,调度的过程和策略:

??Scheduler是k8s集群的调度器,把pod分配到集群的节点。

以下几个问题:

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

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

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

创建pod的节点时。有两个策略。先执行预算策略,在执行优先策略,这两部的操作都必须成功,否则立刻返回报错。也就是说,部署的node必须满足这两个策略。

预算策略:

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

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

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

Node1 ??node2 ??node3

经过预算策略,上述三个节点都满足条件,那就进入--------->优选策略。

优选策略:

  1. leastrequestedpriority:最低请求优先级,通过算法计算节点上的CPU和内存使用率,确定节点的权重,使用率越低的节点相应的权重越高。调度时会更倾向于使用率的节点。实现资源合理的利用。
  2. Balanceresourceallocation:平衡资源分配,CPU和内存的使用率,给节点赋予权重。权重算的是CPU和内存使用率接近,权重越高。和上面的leastrequestedpriority最低请求优先级一起使用。

?node2在被调度时会被优先。

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

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

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

人工指定节点

1,指定节点

Spec参数设置:

nodeName:node02

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

2,指定标签:

Spec

??nodeSelector

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

亲和性

node亲和性:

Pod亲和性:

软策略和硬策略:

Node节点的亲和性:

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

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

键值的运算关系:

标签,都是根据标签来选择亲和性。

In:在

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

Notin:不在

选择label的值不在node节点上。

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

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

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

DoesNotExist:选择不具有指定标签的对象。值不考虑。

Gt ?和 Lt 只能比较正数

亲和性策略更具标签来进行选择。

Pod亲和性:

preferredDuringSchedulingIgnoredDuringExecution软策略

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

RequireDuringSchedulingIgnoredDuringExecution硬策略

要求调度器将pod调度到其他pod的亲和性的匹配的节点上。必须是。

节点上的标签进行删除:

强制性覆盖:

软策略:

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

硬策略:

先满足硬策略,再满足软策略。

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