Kubernetes scheduler学习笔记

Kubernetes scheduler是一个策略丰富、拓扑感知、工作负载特定的功能,显著影响可用性、性能和容量。为了能更好的使用它,所以从源码的角度,对它进行一个全方位的分析与学习。

简介

Kubernetes是一个强大的编排工具,可以用来很方便的管理许多台机器,为了使机器的资源利用率提高,同时也尽可能的把压力分摊到各个机器上,这个职责就是由scheduler来完成的。

Kubernetes scheduler是一个策略丰富、拓扑感知、工作负载特定的功能,显著影响可用性、性能和容量。

为了能更好的使用它,所以从源码的角度,对它进行一个全方位的分析与学习。

scheduler的功能不多,但逻辑比较复杂,里面有很多考虑的因素,总结下来大致有如下几点:

  • Leader选主,确保集群中只有一个scheduler在工作,其它只是高可用备份实例。通过endpoint:kube-scheduler作为仲裁资源。
  • Node筛选,根据设置的条件、资源要求等,匹配出所有满足分配的Node结点。
  • 最优Node选择。在所有满足条件的Node中,根据定义好的规则来打分,取分数最高的。如果有相同分数的,则采用轮询方式。
  • 为了响应高优先级的资源分配,增加了抢占功能。scheduler有权删除一些低优先级的Pod,以释放资源给高优先级的Pod来使用。

功能说明

代码看下来比较困难,下面将分几个场景来描述scheduler工作的过程:

1、环境说明(假设3台机器,分别是8C16G)

场景一:资源分配——最基本的功能

2、先分配一个请求2C4G的Pod:A

场景二:机器负载均衡——评分机制

3、再分配一个请求2C4G的Pod:B(尽管node1上还有空闲资源可分配B,但node2和node3空闲资源更多,打分更高,所以分配到了node2<选择node2还是node3,是由schedule轮询选择的>。)

4、同理,如果再分配一个C,scheduler会优先分配到node3上

场景三:资源抢占——特权机制

5、现在3个Node上都分配了2C4G,就是都剩余6C12G,如果我这个时候分配一个8C12G的Pod:D,在同优先级的情况下,D将不会分配,处于Pending状态,因为三台机器都资源不足。

6、如果这个时候,我给D设置一个高的优先级,schedule会删除一台机器上的Pod,比如A,然后资源足够了,将D分配到node1上,再将A分配到node2或node3上(这里分配是一个类似,因为三台都是一样的)

7、下面实战一把,详细试验下scheduler的抢占过程:

我有一个Deployment,有3个复本,分别分配到两台机器上。(为什么用这个例子,是为了说明,抢占一定会发生在10-10-40-89上,因为要删除的Pod最少)

这个时候,我创建一个高优先级的Deployment:

快速查询,能看到下面的阶段:

第一步,将要分配的testpc-745cc7867-fqbp2设置为“提名Pod”,这个名字后面会再出现,同时删除原10-10-40-89上的testpod,由于截的比较慢,下图中新的testpod已经在10-10-88-99上创建了。

第二步,提名Pod将会分配到对应的结点上(等待Terminating状态的Pod释放完资源后)。

第三步,资源足够,Pod正常Running。

最后展示下watch情况下的事件:

测试我共有两个yaml文件,如下:

testpod.yaml:

    apiVersion: extensions/v1beta1
    kind: Deployment
    metadata:
      annotations:
        deployment.kubernetes.io/revision: "1"
      labels:
        k8s-app: testpod
      name: testpod
    spec:
    progressDeadlineSeconds: 600
      replicas: 3
      revisionHistoryLimit: 10
      selector:
        matchLabels:
          k8s-app: testpod
      template:
        metadata:
          labels:
            k8s-app: testpod
        spec:
          containers:
          - image: nginx:1.17
            imagePullPolicy: IfNotPresent
            name: nginx
            ports:
            - containerPort: 80
              name: nginx
              protocol: TCP
            resources:
              requests:
                cpu: 1
                memory: 2Gi

testpc.yaml:

apiVersion: scheduling.k8s.io/v1beta1
kind: PriorityClass
metadata:
  name: high-priority
value: 1000000000
globalDefault: false
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  annotations:
    deployment.kubernetes.io/revision: "1"
  labels:
    k8s-app: testpc
  name: testpc
spec:
  progressDeadlineSeconds: 600
  replicas: 1
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      k8s-app: testpc
  template:
    metadata:
      labels:
        k8s-app: testpc
    spec:
      containers:
      - image: nginx:1.17
        imagePullPolicy: IfNotPresent
        name: nginx
        ports:
        - containerPort: 80
          name: nginx
          protocol: TCP
        resources:
          requests:
            cpu: 6
            memory: 2Gi
      priorityClassName: high-priority

场景四:关系户——亲和与反亲和

scheduler在分配Pod时,考虑的要素很多,亲和性和反亲和,是一个比较常用的,在这里做一个典型来讲讲。

比如在上图中,我新的Pod:D,要求不能和A在一台机器上,和B的互斥打分是100,和C的互斥打分是10。表示说,D一定不能和A在一台机器,尽可能不和B、C在同一台机器,实在没办法时(资源不足),D更倾向于和C在一起。

样例:

podAntiAffinity:
  preferredDuringSchedulingIgnoredDuringExecution:
  - weight: 100
    podAffinityTerm:
      labelSelector:
        matchExpressions:
        - key: security
          operator: In
          values:
          - S2
      topologyKey: kubernetes.io/hostname

通过对这四个应用场景的分析,对它的功能有了一个初步的了解。要想更全面、深入的了解它的功能,需要从它的源码来着手。下面将从源码层面来做深入分析。

代码分析

scheduler总体结构

scheduler的配置,基本都是采用默认配置,图中列出了它的配置加载流程,基本都是加载它自身的默认配置。

server.Run为它的主体逻辑,之后会详细讲解。

重要配置讲解

图中,单独列出了两个config配置:

1、disablePreemption:

scheduler有个抢占功能。当Pod调度发现无可用资源时,它会将比该Pod优先级低的Pod删除,以释放资源给它来调度。disablePreemption默认为false,表示开启抢占,如果需要关闭,则设置为true。

2、既然说到优先级,所以我还列出来了优先级的设置方法

Kubernetes中有个单独的优先级的资源,叫:PriorityClass,通过下面这个yaml,能创建一个PriorityClass。

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 1000000
globalDefault: false
description: "This priority class should be used for XYZ service pods only."

然后可将这个PriorityClass关联到Pod上:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
 priorityClassName: high-priority

这样就完成的Pod优先级的设置。如果不设置,Pod默认是同一优先级(为0)。

特别注意:

static Pod比较特殊,需要直接设置priority,因为kubelet是根据priority来判断。

scheduler启动流程

通过深入分析server.Run,可看到如下流程:

server.Run还是有一部分的配置处理流程。

schedulerConfig中,根据默认的参数,加载了两大块内容:predicate、priority函数。

  • predicate函数用于做Pod是否可分配到Node上的检查函数
  • priority函数,则用于选优。当可分配的Node有多个时,这个时候就会根据priority函数来给node打分,最终调度到分数最高的Node上。

Kubernetes提供了这些默认的判断函数:

predicate:

1、CheckNodeConditionPredicate

we really don’t want to check predicates against unschedulable nodes.

检查Node状态:是否处于可调度状态等。

-----> 遍历nodeInfo中Node的所有状况:

  • 如果Node类型为ready,并且状态不是True,则认为结点为notReady
  • 如果Node类型为OutOfDisk,并且状态不是False,则认为结点OutOfDisk
  • 如果Node类型为NetworkUnavailable,并且状态不是False,则认为结点状态为:NetworkUnavailable

检查Node的spec,如果是UnSchedulable,则认为结点为UnSchedulable。

以上检查都通过,则返回匹配成功

2、PodFitsHost

we check the pod.spec.nodeName.

检查pod.spec.nodeName是否匹配。

----> 如果Pod未指定NodeName,则返回匹配成功。

检查Node的名字,如果与Pod指定的同名,则匹配成功,否则返回:nodeName不匹配。

3、PodFitsHostPorts

we check ports asked on the spec.

检查服务端口是否被占用。

-----> 如果元数据metadata中有定义需要的podPorts,则直接从元数据中取,否则从Pod的所有容器中获取需要的port。

如果需要的port为空,则返回匹配成功。

从nodeInfo中获取当前已经使用的port,如果有冲突,则返回:端口不匹配,否则返回匹配成功。

4、PodMatchNodeSelector

check node label after narrowing search.

检查label是否匹配。

------> 如果Pod中定义了NodeSelector,则根据选择来匹配Node的labels,如果不匹配,则返回NodeSelectorNotMatch。

如果Pod的Affinity中定义了NodeAffinity,则检查结点亲和关系:

  • 如果未定义requiredDuringSchedulingIgnoredDuringExecution,则直接返回匹配。
  • 如果定义了requiredDuringSchedulingIgnoredDuringExecution.nodeSelectorTerms,则里面有一个匹配,则匹配。否则认为不匹配。

特别的:如果nodeSelectorTerms为nil,则全不匹配;如果nodeSelectorTerms不为nil,但是空的切片,则全不匹配;同样,nodeSelectorTerms中的MatchExpressions,如果为nil或者是空切片,也不匹配。

5、PodFitsResources

this one comes here since it’s not restrictive enough as we do not try to match values but ranges.

-----> 检查Node的allowedPodNumber是否超过,如果超过,增加超限错误(此处未直接返回,会把所有错误检查完一次性返回)。

检查元数据中是否有定义podRequest、ignoredExtendedResources,如果定义了,则从元数据中取。否则从Pod中每个容器中取:先检查所有container中所有需要的资源总合,再检查initContainer中,如果有资源比总合还大,则取较大的为所需要的资源。

如果需要的资源都为0,则返回检查结果。

获取Node的可用资源,检查需要新申请的资源+已申请的资源是否超过可用资源,如果超过,则记录资源不足。

检查所有Pod扩展资源,并判断扩展资源是否需要检查(ignoredExtendedResources),如果需要检查,则判断资源是否足够,不足够则记录失败。

返回检查结果(如果无失败,是检查成功)。

6、NoDiskConflict

Following the resource predicate, we check disk.

----> 遍历Pod所有存储、Node下的所有Pod,检查是否有存储冲突:

如果Pod无存储(无GCE、AWS、RBD、ISCSI),则检查通过。

7、PodToleratesNodeTaints

check toleration here, as node might have toleration.

-----> 检查结点是否容忍taint环境:

参数:Pod中定义的容忍规则:tolerations,Node中的环境状态:taints,筛选规则:取effect为NoSchedule、NoExecute的。

如果Node无taints,返回匹配成功。

遍历所有taints,如果taint不满足筛选规则,则跳过检查。

遍历所有的容忍规则,检查是否有规则是允许结点的taint状态。检查步骤:

  • 如果effect为空,则检查通过。否则要相同
  • 如果key为空,则检查通过,否则要相同
  • 如果operator为Exists,则检查通过,如果为空或者是Equal,则要相同,否则不通过

8、PodToleratesNodeNoExecuteTaints

check toleration here, as node might have toleration.

-----> 检查规则同上相似,只是筛选规则变了:取effect为NoExecute的。

9、CheckNodeLabelPresence

labels are easy to check, so this one goes before.

------> 检查label是否存在,不关心值。可设置label存在与不存在。

只有在scheduler.CreateFromConfig(policy)才会初始化该检查,在RegisterCustomFitPredicate中注册,默认无该检查。

10、checkServiceAffinity

-----> 检查服务类同关系。

如果一个Pod的服务调度到有label:"region=foo"的Node,之后有相同服务的Pod都会调度到该Node。

11、MaxPDVolumeCountPredicate

-----> 检查挂载的卷个数是不是超标,只支持:ESB:39,GCE:16,AzureDisk:16。

12、VolumeNodePredicate

-----> 无

13、VolumeZonePredicate

-----> 检查存储区域划分:

检查Node中是否有label:failure-domain.beta.kubernetes.io/zone或者failure-domain.beta.kubernetes.io/region,如果有,则检查Pod存储情况。

遍历Pod需要的存储信息:

根据PVC名字获取PVC信息,取出PVC对应的PV名字,如果没有名字(表示还未绑定PV),获取PVC的StorageClassName,如果处理正在绑定中,则跳过不检查,否则返回匹配失败(因为PVC绑定失败)。

绑定成功的,根据pvName获取对应的PV信息,检查PV的标签,如果PV有上面两个标签(zone、region),检查PV的值中(值可能有多个,用__分隔),是否包含Node对应标签的值,如果没有包含,则返回匹配失败。

14、CheckNodeMemoryPressurePredicate

doesn’t happen often.

-----> 检查Node内存压力。

15、CheckNodeDiskPressurePredicate

doesn’t happen often.

16、InterPodAffinityMatches

Most expensive predicate to compute.

默认有这些打分函数(priority):

SelectorSpreadPriority:根据相同的RC和服务拆分,使每个Node具有相同服务或RC的Pod尽量少,spreads pods by minimizing the number of pods (belonging to the same service or replication controller) on the same node.

InterPodAffinityPriority:根据Pod共性来分配,pods should be placed in the same topological domain (e.g. same node, same rack, same zone, same power domain, etc.).

LeastRequestedPriority:选择比较闲的node,Prioritize nodes by least requested utilization.

BalancedResourceAllocation:从资源分配平衡性来考虑分配,Prioritizes nodes to help achieve balanced resource usage.

NodePreferAvoidPodsPriority:用于用户自定义分配,权重10000起,方便用户来指定。0的时候不起作用。用户通过这个来指定:scheduler.alpha.kubernetes.io/preferAvoidPods Set this weight large enough to override all other priority functions.

NodeAffinityPriority:根据结点关系来分配,Prioritizes nodes that have labels matching NodeAffinity.

TaintTolerationPriority:根据pod设置的容忍项来分配,Prioritizes nodes that marked with taint which pod can tolerate.

最终,死循环进入:scheduleOne,真正开始schedule的调度流程。

Schedule调度流程

先讲主流程:

主流程分为以下8步:

1、从Pod队列中取出一个需要调度的Pod

2、尝试调度该Pod

3、调度失败,则尝试抢占Pod

4、调度成功后,尝试做volumes绑定

5、由于reserve插件暂时未启用,暂未分析

6、尝试将Pod分配到Node上

7、真正实现绑定。第4步和第6步中,都只是对schedule的cache的操作,先确保对cache的操作能完成,最终在第7步,异常实现将cache中的修改应用到apiserver中。如果应用失败,会将pod的分配信息从cache中清除,重新进行scheduler。

8、最复杂也最核心的,就是第2步和第3步,下面分别进行分析。

调度Pod流程

调度Pod,就是尝试将Pod分配到Node上,流程如下:

共有7点,将逐步分析:

1、Pod基本检查,检查Pod是否有了对应的PVC,这里只是检查PVC是否存在,不关心绑定过程

2、取出所有Node列表

3、将nodeInfo应用到缓存中。全局nodeInfo中保存了当前Node的真实数据信息,而cache中会有调度过程的假设分析的信息。

4、检查Pod是否可调度到Node上,返回可调度的Node列表

a) 这里的检查,是针对前面初始化时,注册的predicate函数,如果有不符合,则认为不可调度。

b) 这里会尝试两次,之所以两次,是因为有“提名Pod”的存在。暂时先不管“提名Pod”哪来的,后面会讲到。提名Pod,就是说,这个Pod已经分配到Node上,但它还未应用到Kubernetes环境,目前只是占着这个坑位,要调度的Pod,在调度的过程中,也需要考虑它所占的资源。

c) 第一次时,会先把优先级大于当前Pod的提名Pod分配到Node中(添加到一个临时的nodeInfo中),然后检查所有的predicat函数是否通过。

d) 第二次时,不添加提名Pod,再检查所有的predicate函数。之所以有第二次,是因为提名Pod实际还并不存在,有些Pod亲和性可能会判断有误。

e) 当然,如果没有提名Pod,则不需要第二次判断。

5、如果找不到,则返回失败。如果只找到一个,则返回该Node。

6、当找到多个Node时,会去给Node打分,打分规则如下:

a) 如果没有定义打分规则,则返回所有分数都为1。schedule默认是有打分函数的,前面初始化中有讲。

b) 运行早期老版本的打分函数。早期就是单纯的一个function,运行后得到打分结果。

c) 新版本,将打分函数拆分成两步,map和reduce,先按16个并发运行map,之后运行reduce统计执行结果。

d) 这里还预留了扩展支持。

e) 最终返回打分结果。

7、根据打分结果,选择Node。

a) 先取出得分最高的Node列表

b) 然后按round-robin的方式选择Node

由于相同最高分的Node可能有多个,genericScheduler采用round-robin的方式:它自己记录一个全局的lastNodeIndex,如何num为当前有相同最高分的节点数,则用lastNodeIndex % num来选取本次节点的下标,之后lastNodeIndex加1,实现轮询调度。

到此,Pod的调度流程分析完成。当中有个特别的东西:提名Pod(NominatedPod),它的出现和下面讲的抢占流程有关。

Pod抢占流程

抢占的流程,比调度复杂一些,主要分两大步:抢占分析和抢占。第一步是检查是不是能完成抢占,第二步是执行抢占(删除Pod)。

抢占检查

1、检查Pod是否可以发起抢占:如果Pod是提名Pod(已经预分配到Node),并且该Node上有处于terminating的Pod p,并且p的优先级小于当前Pod,则不允许发起抢占。

2、获取所有Node清单。

3、获取可能的Node。检查调度失败原因,如果是nodeNotReady这种原因,则Node不参与抢占。

这些都是不参与抢占的:

predicates.ErrNodeSelectorNotMatch,
predicates.ErrPodAffinityRulesNotMatch,
predicates.ErrPodNotMatchHostName,
predicates.ErrTaintsTolerationsNotMatch,
predicates.ErrNodeLabelPresenceViolated,
predicates.ErrNodeNotReady,
predicates.ErrNodeNetworkUnavailable,
predicates.ErrNodeUnderDiskPressure,
predicates.ErrNodeUnderPIDPressure,
predicates.ErrNodeUnderMemoryPressure,
predicates.ErrNodeUnschedulable,
predicates.ErrNodeUnknownCondition,
predicates.ErrVolumeZoneConflict,
predicates.ErrVolumeNodeConflict,
predicates.ErrVolumeBindConflict

4、如果可抢占的Node没有,则结束。

5、获取pdb列表:pdb is PodDisruptionBudget. 这个是预算的定义,比如statefulset定义了3个复本,而我们定义了,允许其中1个Pod可以挂掉

6、获取通过抢占(删除一些Pod),能完成调度的Node列表
a) 将比当前Pod优先级低的Pod全部从nodeInfoCopy中删除,然后尝试去调度

b) 如果调度失败,则表示无法抢占。(因为不能删除比它优先级高的)

c) 将要删除的Pod,根据pdb进行拆分:nonViolatingVictim和violatingVictim。说明见图中

d) 然后尝试将violatingVictim中的Pod一个个加进去,尝试能不能调度。numViolatingVictim中记录不通过数

e) 然后尝试将nonViolatingVictim中的Pod一个个加进去,尝试能不能调度。victims记录不通过的Pod信息

f) 返回victims和numViolatingVictim

7、extenders扩展保留

8、从可抢占的Node列表中,选择最合适的一个Node。按如下规则进行选择:

a) node pdb violations最小。就是上面返回的numViolatingVictim

b) 如果只有一个Node满足,则返回该Node

c) 比较Node中victims中优先级的最高值,取最小的那个。最高:取的是单个Node中,优先级的最高值。最小:取的是所有Node中的最小值

d) 如果只有一个,则返回该Node

e) 取Node中victims优先级总和最小的

f) 如果只有一个,则返回该Node

g) 取Node中victims的Pod数最小的

h) 返回第一个

9、如果无合适的,则结束

10、获取比当前优先级小的提名Pod

11、返回Node信息,需要删除的Pod列表,优先级小的提名Pod

到此,抢占检查结束。得到期望调度的Node、要调度到这个Node上,需要删除的Pod列表、以及比当前Pod优先级小的提名Pod。

抢占执行流程(找到了期望的Node才会进入)

1、将当前Pod,变更为提名Pod,对应的Node为期望的Node。这里就是提名Pod出现的原因。

2、将提名Pod信息更新到apiServer

3、遍历victims(抢占流程返回的需要删除的Pod列表),删除Pod,并记录event

4、遍历nominatedPodsToClear(抢占返回的比当前Pod优先级小的提名Pod),清空提名Pod配置,并更新apiServer

到此,调度流程分析完成。

作者:李龙辉,沃趣科技高级开发工程师,IT从业多年,多年的C、Go语言开发经验,主要负责基于Kubernetes的RDS平台QFusion的研发,熟悉云计算及Kubernetes技术体系。

参考:https://kubernetes.io/docs/concepts/configuration/pod-priority-preemption/

发表评论

电子邮件地址不会被公开。 必填项已用*标注