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.

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

k8s的集群调度_第1张图片

监听:

list-watch------会在每一步把监听的消息(APIserver:6443)-------------controller manager,schedule,kubelet,etcd都会监听

apiserver:6443端口来监听

如何来把pod分配到node.

2、调度的过程和策略:

schedule是k8s集群的调度器,把pod分配搭配集群的节点。

有以下几个问题:

1、公平,每个节点都能够分配到资源

2、资源高效利用:集群当中的每个资源都可以被最大化使用

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

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

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

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

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

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

预算策略:

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

1、podfitsresources:pod适应资源,检查节点上的剩余资源是否满足pod请求的资源。主要是cpu和内存。

2、podfitshost:适应主机,如果pod指定了node的name,nginx1 pod------>node01,检测主机名是否存在,存在要和pod指定的名称匹配。这样才能调度过去。

3、podselectormatches:pod选择器匹配,创建pod的时候可以根据node的标签来进行匹配。查找

指定的node节点上的标签是否存在,存在的标签是否匹配。

4、nodiskconflict:无磁盘冲突,确保已挂载的卷于pod的卷不发生冲突,除非目录是只读,就会覆盖。

node1

nginx1 pod /opt/nginx1

nginx2 pod /opt/nginx1

冲突了,会看node2上有没有,然后部署在node2节点上。

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

若node1 node2 node3

经过预算策略,上述三个节点都满足条件,那该怎么办?------>进行优选。

优选策略:

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

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

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

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

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

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

node2在被调度时会被优先。

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

nginx1.22

node1 无

node2 有

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

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

指定节点:

spec参数设置:

nodeName:node02(node节点的名称)

注:如果指定了节点,在参数中设置了nodeName,指定了节点的名称,会跳过scheduler的调度

策略,这个规则是强制匹配。(不走调度算法)

k8s的集群调度_第2张图片

k8s的集群调度_第3张图片

k8s的集群调度_第4张图片

指定标签:

spec

nodeSelector:

自定义标签

kubectl label nodes master01 test1=a

kubectl label nodes node01 test2=b

kubectl label nodes node01 test3=c

查看标签:

12:02

kubectl get nodes --show-labels

k8s的集群调度_第5张图片

选择标签

k8s的集群调度_第6张图片

k8s的集群调度_第7张图片

k8s的集群调度_第8张图片

k8s的集群调度_第9张图片

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

亲和性:

node节点亲和性

pod亲和性

软策略和硬策略

node节点的亲和性:

preferredDuringSchedulingIgnoredDuringExecution软策略:

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

requiredDuringSchedulingIgnoredDuringExecution硬策略:

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

pod的亲和性:

preferredDuringSchedulingIgnoredDuringExecution软策略:

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

pod nginx1 node01

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

requiredDuringSchedulingIgnoredDuringExecution硬策略:

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

pod nginx1 node01

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

键值的运行关系:

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

In:在

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

Notin:不再

选择label的值不再node节点上

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

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

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

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

spec:

  containers:

    -image:nginx:1.22

      name: nginx

  affinity:

#选择亲和性的部署方式:

    nodeAffinity:

#选择的是node节点的亲和性

      re

        nodeSelectorTerms:

#选择了亲和性的策略,nodeSelectorTerms你要选择哪个node作为硬策略。匹配的节点的标签。

          matchExpressions:

#定义一个符合我要选择的node节点的信息

          - key: test3

          poerator: In

#指定键值对的算法

          values:

           - c

Exist or DoesNotExist不能使用vlaue字段

k8s的集群调度_第10张图片

k8s的集群调度_第11张图片

k8s的集群调度_第12张图片

k8s的集群调度_第13张图片

k8s的集群调度_第14张图片

软策略

选择node节点的亲和性改为软策略

加上权重值

preference

选择节点的倾向,尽量满足要求而不是一定。

总结:

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

硬策略:

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

问题:

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

node的亲和性:

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

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

你可能感兴趣的:(kubernetes,java,docker)