Kubernetesscheduler学习笔记是怎样的
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的配置,基本都是采用默认配置,图中列出了它的配置加载流程,基本都是加载它自身的默认配置。
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步:
从Pod队列中取出一个需要调度的Pod。
尝试调度该Pod。
调度失败,则尝试抢占Pod。
调度成功后,尝试做volumes绑定。
由于reserve插件暂时未启用,暂未分析。
尝试将Pod分配到Node上。
真正实现绑定。第4步和第6步中,都只是对schedule的cache的操作,先确保对cache的操作能完成,最终在第7步,异常实现将cache中的修改应用到apiserver中。如果应用失败,会将pod的分配信息从cache中清除,重新进行scheduler。
最复杂也最核心的,就是第2步和第3步,下面分别进行分析。
调度Pod流程
调度Pod,就是尝试将Pod分配到Node上,流程如下:
Pod基本检查,检查Pod是否有了对应的PVC,这里只是检查PVC是否存在,不关心绑定过程。
取出所有Node列表。
将nodeInfo应用到缓存中。全局nodeInfo中保存了当前Node的真实数据信息,而cache中会有调度过程的假设分析的信息。
检查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,则不需要第二次判断。
如果找不到,则返回失败。如果只找到一个,则返回该Node。
当找到多个Node时,会去给Node打分,打分规则如下:
a) 如果没有定义打分规则,则返回所有分数都为1。schedule默认是有打分函数的,前面初始化中有讲。
b) 运行早期老版本的打分函数。早期就是单纯的一个function,运行后得到打分结果。
c) 新版本,将打分函数拆分成两步,map和reduce,先按16个并发运行map,之后运行reduce统计执行结果。
d) 这里还预留了扩展支持。
e) 最终返回打分结果。
根据打分结果,选择Node。
a) 先取出得分最高的Node列表。
b) 然后按round-robin的方式选择Node。
由于相同最高分的Node可能有多个,genericScheduler采用round-robin的方式:它自己记录一个全局的lastNodeIndex,如何num为当前有相同最高分的节点数,则用lastNodeIndex % num来选取本次节点的下标,之后lastNodeIndex加1,实现轮询调度。
到此,Pod的调度流程分析完成。当中有个特别的东西:提名Pod(NominatedPod),它的出现和下面讲的抢占流程有关。
Pod抢占流程
抢占的流程,比调度复杂一些,主要分两大步:抢占分析和抢占。第一步是检查是不是能完成抢占,第二步是执行抢占(删除Pod)。
抢占检查
检查Pod是否可以发起抢占:如果Pod是提名Pod(已经预分配到Node),并且该Node上有处于terminating的Pod p,并且p的优先级小于当前Pod,则不允许发起抢占。
获取所有Node清单。
获取可能的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 如果可抢占的Node没有,则结束。
获取pdb列表:pdb is PodDisruptionBudget. 这个是预算的定义,比如statefulset定义了3个复本,而我们定义了,允许其中1个Pod可以挂掉。
获取通过抢占(删除一些Pod),能完成调度的Node列表。 a) 将比当前Pod优先级低的Pod全部从nodeInfoCopy中删除,然后尝试去调度。 b) 如果调度失败,则表示无法抢占。(因为不能删除比它优先级高的) c) 将要删除的Pod,根据pdb进行拆分:nonViolatingVictim和violatingVictim。说明见图中。 d) 然后尝试将violatingVictim中的Pod一个个加进去,尝试能不能调度。numViolatingVictim中记录不通过数。 e) 然后尝试将nonViolatingVictim中的Pod一个个加进去,尝试能不能调度。victims记录不通过的Pod信息。 f) 返回victims和numViolatingVictim。 extenders扩展保留。 从可抢占的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) 返回第一个。 如果无合适的,则结束。 获取比当前优先级小的提名Pod。 返回Node信息,需要删除的Pod列表,优先级小的提名Pod。
到此,抢占检查结束。得到期望调度的Node、要调度到这个Node上,需要删除的Pod列表、以及比当前Pod优先级小的提名Pod。
抢占执行流程(找到了期望的Node才会进入)
将当前Pod,变更为提名Pod,对应的Node为期望的Node。这里就是提名Pod出现的原因。 将提名Pod信息更新到apiServer。 遍历victims(抢占流程返回的需要删除的Pod列表),删除Pod,并记录event。 遍历nominatedPodsToClear(抢占返回的比当前Pod优先级小的提名Pod),清空提名Pod配置,并更新apiServer。
到此,调度流程分析完成。
关于Kubernetes scheduler学习笔记是怎样的问题的解答就分享到这里了,希望以上内容可以对大家有一定的帮助,如果你还有很多疑惑没有解开,可以关注创新互联行业资讯频道了解更多相关知识。
分享文章:Kubernetesscheduler学习笔记是怎样的
文章来源:http://scyanting.com/article/jiiipp.html