k8s调度 原理_Kubernetes的调度机制

k8s的调度机制

scheduler组件

k8s调度器会将pod调度到资源满足要求并且评分最高的node上。我们可以使用多种规则比如:1.设置cpu、内存的使用要求;2.增加node的label,并通过pod.Spec.NodeSelector进行强匹配;3.直接设置pod的nodeName,跳过调度直接下发。

k8s 1.2加入了一个实验性的功能:affinity。意为亲和性。这个特性的设计初衷是为了替代nodeSelector,并扩展更强大的调度策略。

调度器的工作机制是这样的:

一、预备工作

1、缓存所有的node节点,记录他们的规格:cpu、内存、磁盘空间、gpu显卡数等;

2、缓存所有运行中的pod,按照pod所在的node进行区分,统计每个node上的pod request了多少资源。request是pod的QoS配置,可以参考之前的文章。

3、list & watch pod资源,当检查到有新的Pending状态的pod出现,就将它加入到调度队列中。

4、调度器的worker组件从队列中取出pod进行调度。

二、调度过程

1、先将当前所有的node放入队列;

2、执行predicates算法,对队列中的node进行筛选。这里算法检查了一些pod运行的必要条件,包括port不冲突、cpu和内存资源QoS(如果有的话)必须满足、挂载volume(如果有的话)类型必须匹配、nodeSelector规则必须匹配、硬性的affinity规则(下文会提到)必须匹配、node的状态(condition)必须正常,taint_toleration硬规则(下文会提到)等等。

2、执行priorities算法,对队列中剩余的node进行评分,这里有许多评分项,各个项目有各自的权重:整体cpu,内存资源的平衡性、node上是否有存在要求的镜像、同rs的pod是否有调度、node affinity的软规则、taint_toleration软规则(下文会提到)等等。

3、最终评分最高的node会被选出。即代码中suggestedHost, err := sched.schedule(pod)一句(plugin/pkg/scheduler/scheduler.go)的返回值。

4、调度器执行assume方法,该方法在pod调度到node之前,就以“该pod运行在目标node上” 为场景更新调度器缓存中的node 信息,也即预备工作中的1、2两点。这么做是为了让pod在真正调度到node上时,调度器也可以同时做后续其他pod的调度工作。

5、调度器执行bind方法,该方法创建一个Binding资源,apiserver检查到创建该资源时,会主动更新pod的nodeName字段。完成调度。

nodeSelector

举例:apiVersion: v1kind: Podmetadata:  name: nginx  labels:    env: testspec:  containers:

- name: nginx    image: nginx    imagePullPolicy: IfNotPresent  nodeSelector:    disktype: ssd

上面这个pod会且仅会被调度到带有disktype: ssd这个label的node上。这是一种强规则,没有妥协,必须遵守。

affinity 和 anti-affinity有亲和性规则,那么反亲和性规则肯定也要有。

亲和性规则实现了更丰富的规则表达方式。并且包含了nodeSelector的硬规则和另一种软规则。

软规则是一种优先规则,如果没有符合这个优先规则的节点,它仍然会被进行调度。

node亲和性

node亲和性和nodeSelector类似,通过label进行可调度node的过滤,现在有两种node亲和性:requiredDuringSchedulingIgnoredDuringExecution 和 preferredDuringSchedulingIgnoredDuringExecution:

requiredDuringSchedulingIgnoredDuringExecution

强规则。和nodeSelector完全相同,以label进行强制的约束。需要指出的是:目前,如果一个node在运行时label发生了变化,变化后和其上运行的pod的requiredDuringSchedulingIgnoredDuringExecution 不再匹配,这个node上的pod也不会被驱逐,这个功能会在以后被改进,届时会增加一种类型RequiredDuringSchedulingRequiredDuringExecution。

preferredDuringSchedulingIgnoredDuringExecution

软规则。举例来说:我们要将某个容器尽可能地调度到可用域X中,但如果不存在这个可用域或者可用域无法再运行pod,调度器也允许这个pod被调度到其他可用域。

以下是一个包含了强规则和软规则的案例:apiVersion: v1kind: Podmetadata:  name: with-node-affinityspec:  affinity:    nodeAffinity:      requiredDuringSchedulingIgnoredDuringExecution:        nodeSelectorTerms:

- matchExpressions:

- key: kubernetes.io/e2e-az-name            operator: In            values:

- e2e-az1

- e2e-az2      preferredDuringSchedulingIgnoredDuringExecution:

- weight: 1

preference:          matchExpressions:

- key: another-node-label-key            operator: In            values:

- another-node-label-value  containers:

- name: with-node-affinity    image: gcr.io/google_containers/pause:2.0

该案例表明,这个pod只允许被调度到带有kubernetes.io/e2e-az-name=e2e-az1或e2e-az2的label的node上,也即只允许被调度到e2e-az1或者e2e-az2两个可用域中;另外,pod要尽量调度到包含another-node-label-key的值为another-node-label-value的node上。

matchExpressions结构记录各种表达式,一个表达式包含key,operator,values,分别表示关键字、关键字匹配关系、关键字匹配值。匹配关系包括:In,NotIn,Exists,DoesNotExist,Gt,Lt。NotIn和DoesNotExist是node anti-affinity的一种表现。

如果一个pod的描述信息中同时包含了nodeSelector和nodeAffinity,那么调度时两个规则都要满足。

如果一个nodeAffinity中包含了多条nodeSelectorTerms, 调度器只需要满足其中一条; 如果一个 nodeSelectorTerms中记录了多条matchExpressions,那么调度器要满足所有的matchExpressions

inter-pod affinity 和 anti-affinity

这两个特性都包含在1.4版本中,上面的亲和性是node亲和性,这个就是pod亲和性,简而言之,要把pod调度到某个node上,这个node上已有的pod能满足、或尽量满足某些条件。这个特性用pod.spec.affinity.podAffinity和pod.spec.affinity.podAntiAffinity来表示。

pod亲和性的规则可以这么表示:

这个pod应该(或者不应该)运行在节点X上,X上必须已经运行了一个或多个满足规则Y的pod。规则Y的表达方式类似于一个labelSelector并关联了一个namespace列表:namespaces(若没有则表示“allnamespaces”),X可能是node或一个az,我们通过字段topologyKey来规划X,即所有的X都要满足topologyKey相同,一般topologyKey是一个label的key。

为什么要有namespace列表?因为和node不同,pod是有分namespace的,因此pod的label也是有分namespace的。在这种情况下,规则Y必须要指明自己这个规则要适用于哪些namespace。比如node上运行的是hy这个namespace下的pod,即便pod的label和规则Y的nodeSelector都相同,我们也视为不符合规则。

和node亲和性一样,pod亲和性也包含两个(硬规则和软规则):requiredDuringSchedulingIgnoredDuringExecution: 硬规则。

preferredDuringSchedulingIgnoredDuringExecution:

举个例子:apiVersion: v1kind: Podmetadata:  name: with-pod-affinityspec:  affinity:    podAffinity:      requiredDuringSchedulingIgnoredDuringExecution:

- labelSelector:          matchExpressions:

- key: security            operator: In            values:

- S1        topologyKey: failure-domain.beta.kubernetes.io/zone    podAntiAffinity:      preferredDuringSchedulingIgnoredDuringExecution:

- weight: 100

podAffinityTerm:          labelSelector:            matchExpressions:

- key: security              operator: In              values:

- S2          topologyKey: kubernetes.io/hostname  containers:

- name: with-pod-affinity    image: gcr.io/google_containers/pause:2.0

上面的pod模板使用了podAffinity的硬规则和podAntiAffinity的软规则。podAffinity规则中topologyKey是zone,也就是可用域,说明这条规则可以规划处调度到的域,首先,node上必须至少有一个running状态的pod包含key为security,value为S1的label。只要满足这个条件,那么这个node和其同一个域(拥有相同的failure-domain.beta.kubernetes.io/zone 为key,且值相同的label)的node均会被调度。

podAntiAffinity规则中topologyKey是hostname,表明该规则约定了某种node尽量不会被调度到,这种node上已经运行了包含key为security,value为S2的label的pod。

假如现在有node a,b,c,其中a和b拥有相同的zone,且b上运行了一个pod,这个pod有一个label,key为security,value为S1。那么我们创建如上的一个亲和性规则的3副本时,三个副本都会被调度到a或者b上。假如b上同时运行了一个pod,这个pod有一个label,key为security,value为S2,那么所有的副本都会调度到node a上。

taint toleration

node 可以被打上污点标记,并配置污点容忍策略。而pod的描述信息中如果包含了相同的污点容忍策略,就可以被调度到这个node上,反之则不可、或尽量不允许。

硬性规则

给node a 打上污点 name=huang, 策略为不可调度:

kubectl taint nodes a name=huang:NoSchedule

若我创建的pod中包含如下描述:tolerations:

- key: "name"

operator: "Equal"

value: "huang"

effect: "NoSchedule"

则这个pod可以容忍有这类污点的node,即可以调度到node a,当然,也可以用如下的描述:tolerations:

- key: "name"

operator: "Exist"

effect: "NoSchedule"

类似的硬性规则体现在effect字段中,还有NoExecute,它比NoSchedule更严格,不止pod不能调度上去,node上原有的pod如果不能容忍污点,就会被驱逐(eviction),配合字段tolerationSeconds可以规定这些会被驱逐的pod能在node上呆多久。

软规则

除了NoExecute,NoSchedule,还有一条软规则:PreferNoSchedule.配置effect=PreferNoSchedule后,没有相关污点策略的pod会尽量避免调度到该node上。

你可能感兴趣的:(k8s调度,原理)