从CNCF基金会的成立,到Kubernetes社区蓬勃发展,历经6载,17年异军突起,在mesos、swarm等项目角逐中,拔得头筹,继而一统容器编排,其成功的关键缘由可归纳为如下几点:node
虽然针对kubernetes的介绍已经比较多了,可是云原生仍是Kubernetes项目的发展都已经迈入深水区,于是今天zouyee为你们带来《kuberneter调度由浅入深》,但愿经过接下来的五篇文章,让各位可以系统深刻的了解kubernetes调度系统,该系列对应版本为1.20.+
,今天带来《Kubernetes调度系统由浅入深系列:初探》算法
在开始前,先来看看Kubernetes的架构示意图,其中控制平面包含如下三大组件:kube-scheduler、kube-apiserver、kube-controller-manager。kubelet及kube-proxy组件的分析咱们后续单独成章进行讲解,如今咱们能够简单给理解上述组件的难易程度排个序,kube-apiserver、kubelet、kube-scheduler、kube-controller-manager、kube-proxy。api
{%note danger%}markdown
如上所述,kube-scheduler
是K8S系统的核心组件之一,其主要负责Pod的调度,其监听kube-apiserver,查询未分配 Node的Pod(未分配、分配失败及尝试屡次没法分配),根据配置的调度策略,将Pod调度到最优的工做节点上,从而高效、合理的利用集群的资源,该特性是用户选择K8S系统的关键因素之一,帮助用户提高效率、下降能耗。架构
{%endnote%}函数
kube-scheduler
负责将Pod 调度到集群内的最佳节点(基于相应策略计算出的最佳值)上,它监听 kube-apiserver
,查询还未分配节点 的 Pod,而后根据调度策略为这些 Pod 分配节点,执行绑定节点的操做(更新Pod的nodeName字段)。性能
在上述过程当中,须要考虑如下问题:spa
为解决上述的问题,kube-scheduler
经过聚集节点资源、节点地域、节点镜像、Pod调度等信息综合决策,确保Pod分配到最佳节点,如下为kube-scheduler
的主要目标:插件
首先咱们经过下面的总体的交互图,来构建Pod调度的直观感觉。命令行
上述以建立一个Pod为例,简要介绍调度流程:
用户经过命令行建立Pod(选择直接建立Pod而不是其余workload,是为了省略kube-controller-manager)
kube-apiserver通过对象校验、admission、quota等准入操做,写入etcd
kube-apiserver将结果返回给用户
同时kube-scheduler一直监听节点、Pod事件等(流程1)
kube-scheduler将spec.nodeName的pod加入到调度队列中,进行调度周期(该周期即位后续介绍内容)(流程2-3)
kube-scheduler将pod与得分最高的节点进行binding操做(流程4)
kube-apiserver将binding信息写入etcd
kubelet监听分配给本身的Pod,调用CRI接口进行Pod建立(该部份内容后续出系列,进行介绍)
kubelet建立Pod后,更新Pod状态等信息,并向kube-apiserver上报
kube-apiserver写入数据
kube-scheduler
的工做任务是根据各类调度算法将Pod绑定(bind)到最合适的工做节点,整个调度流程分为两个阶段:过滤和评分。流程示意图以下所示。
注:之前称之为predicate与priorities,当前统称为过滤与评分,实际效果一致
过滤:输入是全部节点,输出是知足预选条件的节点。kube-scheduler
根据过滤策略过滤掉不知足的节点。例如,若是某节点的资源不足或者不知足预选策略的条件如“节点的标签必须与Pod的Selector一致”时则没法经过过滤。
**评分:**输入是经过过滤阶段的节点,评分时会根据评分算法为经过过滤的节点进行打分,选择得分最高的节点。例如,资源越充足、负载越小的节点可能具备越高的排名。
通俗点说,调度的过程就是在回答两个问题:1. 候选节点有哪些?2. 其中最适合的是哪个?
若是在过滤阶段没有节点知足条件,Pod会一直处在Pending状态直到出现知足的节点,在此期间调度器会不断的进行重试。若是有多个节点评分一致,那么kube-scheduler
任意选择其一。
注:Pod首先进入调度队列,失败后进入backoff,屡次失败后进入unschedule,该部份内容后续介绍。
当前支持两种方式配置过滤、评分算法:
1. Scheduling Policies:经过文件或者configmap配置Predicate算法(过滤)和 Priorities算法(评分)的算法
2. Scheduling Profiles:当前调度系统为插拔架构,其将调度周期分为 `QueueSort`、`PreFilter`、`Filter`、`PreScore`、`Score`、`Reserve`、`Permit`、`PreBind`、`Bind`、`PostBind`等阶段,经过定制调度周期中不一样阶段的插件行为来实现自定义。
复制代码
下面简单介绍一下经过Scheduling Policies方式配置
pkg/scheduler/framework/plugins/legacy_registry.go
预选(Precates)
算法名称 | 算法含义 |
---|---|
MatchInterPodAffinity | 检查pod资源对象与其余pod资源对象是否符合亲和性规则 |
CheckVolumeBinding | 检查节点是否知足pod资源对象的pvc挂载需求 |
GeneralPredicates | 检查节点上pod资源对象数量的上线,以及CPU 内存 GPU等资源是否符合要求 |
HostName | 检查Pod指定的NodeName是否匹配当前节点 |
PodFitsHostPorts | 检查Pod容器所需的HostPort是否已被节点上其它容器或服务占用。若是已被占用,则禁止Pod调度到该节点 |
MatchNodeSelector | 检查Pod的节点选择器是否与节点的标签匹配 |
PodFitsResources | 检查节点是否有足够空闲资源(例如CPU和内存)来知足Pod的要求 |
NoDiskConflict | 检查当前pod资源对象使用的卷是否与节点上其余的pod资源对象使用的卷冲突 |
PodToleratesNodeTaints | 若是当前节点被标记为taints,检查pod资源对象是否能容忍node taints |
CheckNodeUnschedulable | 检查节点是否可调度 |
CheckNodeLabelPresence | 检查节点标签是否存在 |
CheckServiceAffinity | 检查服务亲和性 |
MaxCSIVolumeCountPred | 若是设置了featuregate (attachvolumelimit)功能,检查pod资源对象挂载的csi卷是否超出了节点上卷的最大挂载数量 |
NoVolumeZoneConflict | 检查pod资源对象挂载pvc是否属于跨区域挂载,由于gce的pd存储或aws的ebs卷都不支持跨区域挂载 |
EvenPodsSpreadPred | 一组 Pod 在某个 TopologyKey 上的均衡打散需求 |
注:其中 MaxEBSVolumeCountPred、 MaxGCEPDVolumeCountPred MaxAzureDiskVolumeCountPred、MaxCinderVolumeCountPred 等云厂商相关预选算法已经废弃
优选(Priorities)
算法名称 | 算法含义 |
---|---|
EqualPriority | 节点权重相等 |
MostRequestedPriority | 偏向具备最多请求资源的节点。这个策略将把计划的Pods放到整个工做负载集所需的最小节点上运行。 |
RequestedToCapacityRatioPriority | 使用默认的资源评分函数模型建立基于ResourceAllocationPriority的requestedToCapacity。 |
SelectorSpreadPriority | 将属于相同service rcs rss sts 的pod尽可能调度在不一样的节点上 |
ServiceSpreadingPriority | 对于给定的服务,此策略旨在确保Service的Pods运行在不一样的节点上。总的结果是,Service对单个节点故障变得更有弹性。 |
InterPodAffinityPriority | 基于亲和性(affinity)和反亲和性(anti-affinity)计算分数 |
LeastRequestdPriority | 偏向使用较少请求资源的节点。换句话说,放置在节点上的Pod越多,这些Pod使用的资源越多,此策略给出的排名就越低。 |
BalancedRequestdPriority | 计算节点上cpu和内存的使用率,使用率最均衡的节点最优 |
NodePreferAvoidPodsPriority | 基于节点上定义的注释(annotaion)记分,注释中若是定义了alpha.kubernetes.io/preferAvoidPods则会禁用ReplicationController或者将ReplicaSet的pod资源对象调度在该节点上 |
NodeAffinityPriority | 基于节点亲和性计算分数 |
TaintTolerationPriority | 基于污点(taint)和容忍度(toleration)是否匹配计算分数 |
ImageLocalityPriority | 基于节点上是否已经下拉了运行pod资源对象的镜像计算分数 |
EvenPodsSpreadPriority | 用来指定一组符合条件的 Pod 在某个拓扑结构上的打散需求 |
更多云原生相关内容,请关注公众号:DCOS。