k8s的集群调度:

k8s的集群调度:

Scheduler:负责调度资源,把pod调度到node节点

预算策略

优先策略

  1. 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端口

List-watch机制:

调度的过程和策略:

如何来把pod分配到node:

Scheduler是集群的调度器,他的意义就是把pod分配到集群的节点

以下几个问题:

  1. 公平:每个节点都能够公平的分配资源
  2. 资源高效利用:集群当中的资源可以被最大化使用
  3. 效率:调度的性能要好,能够尽快的完成大批量的调度工作
  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---->node1,检测主机名是否存在,存在要和pod指定的名称匹配,这才能调度过去
  3. Podselectormatches:pod选择器匹配,创建pod时可以根据node节点的标签来进行匹配,查找指定的node节点上标签是否存在,存在的标签是否匹配
  4. Nodiskconflict:无磁盘冲突,确保已挂载的卷,与pod的卷不发生冲突,除了只读模式。

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

Node1 node2 node3

问:经过预算策略,上述三个节点都满足,那该怎么办?----》进入优先策略

优选策略:

Leastrequestedpriority:最低请求优先级,通过算法计算节点上的CPU和内存使用率,确定节点的权重,使用率越低的节点相应的权重越高,调度时会更倾向于使用率低的节点,为了实现资源的合理的利用

Balanceresourceallocation:平横资源分配,考虑CPU和内存的使用率,给节点赋予权重,权重算的是CPU和内存使用率接近,使用率越接近,权重越高,和上面的Leastrequestedpriority一起使用,

例如:

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

Node2 CPU和内存使用率:50:50

Node2在被调度时会被优先选择

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

例如:

Nginx:1.22

Node1:无

Node2:有

Node2的优先级比较高

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

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

指定节点:

Spec参数设置

问:它走不走scheduler的调度策略

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

如何对标签进行指定

指定标签:

spec

nodeSelector:

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

实现:查看节点的标签

手动添加自定义标签:

查看已经部署的服务的标签:

选择标签部署我们的pod:

标签选择要走scheduler调度算法的

亲和性:

节点亲和性:

Pod亲和性:

软策略和应策略:

Node节点的亲和性:

软策略:preferredDuringSchedulingIgnoredDuringExecution

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

硬策略:

****选择pod时,声明了硬策略,必须满足硬条件,****必须部署在node01.可以理解成一个强制的要求

Pod的亲和性:

软策略

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

Pod nginx1 node1

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

硬策略:requiredDuringSchedulingIgnoredDuringExecution

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

Pod nginx1 node1

Pod nginx nginx必须要和nginx的亲和性匹配,只能往node01

键值的运算关系:

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

In:在

Notin:不在

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

选择label的值不在node节点上

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

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

****Exsts:****存在,选择标签镜像,值不考虑

doesNoteExist:不存在,选择不具有指定标签的对象,值不考虑

Lt和gt只能比较整数值,亲和性策略根据标签来进行选择

硬策略:

还是要经过scheduler

修改键值对算法

删除标签:

强制覆盖标签:

演示:

Lt和gt只能比较整数值,亲和性策略根据标签来进行选择

小于612的部署

运行yml脚本报错:

指定键值对的算法为Exist或者DoesNotExist不能使用values字段

修正版

软策略的写法:

根据硬策略修改:

多个软策略:以权重高为标的

硬策略和软策略联合:

多个软策略看权重,权重高执行指定的软策略,硬策略,先满足硬策略,再满足软策略,硬策略无法满足,软策略一个都不执行

面试题:

你在部署pod的时候如何选择策略:

Node的亲和性:性能不一致,尽量把pod往性能高的多部署,软策略,节点故障,或者节点维护中,又要部署业务,只能选择硬策略,把故障节点剔除

举例说明:

如上图所示,如果性能有差别,可以使用软策略,部署在四核八G当中

相关推荐
内核程序员kevin2 小时前
TCP Listen 队列详解与优化指南
linux·网络·tcp/ip
朝九晚五ฺ7 小时前
【Linux探索学习】第十四弹——进程优先级:深入理解操作系统中的进程优先级
linux·运维·学习
自由的dream7 小时前
Linux的桌面
linux
xiaozhiwise7 小时前
Makefile 之 自动化变量
linux
Kkooe8 小时前
GitLab|数据迁移
运维·服务器·git
wuxingge8 小时前
k8s1.30.0高可用集群部署
云原生·容器·kubernetes
久醉不在酒8 小时前
MySQL数据库运维及集群搭建
运维·数据库·mysql
志凌海纳SmartX9 小时前
趋势洞察|AI 能否带动裸金属 K8s 强势崛起?
云原生·容器·kubernetes
锅总9 小时前
nacos与k8s service健康检查详解
云原生·容器·kubernetes