Kubernetes调度详解

Kubernetes调度详解

原作者 张伟@天云软件


经过六个月的持续优化,kubernetes宣布1.2版本已经可以支持1000+节点的群集,并且有相当出色的响应能力,这对kubernetes来说是一个重大的改进。随着Kubernetes集群规模的扩大,Kubernetes调度器作为集群的大脑,在如何提高集群的资源利用率、保证集群中服务的稳定运行中也会变得越来越重要。本文将从调度流程、调度算法、资源限制几个方面详细介绍Kubernetes调度器。

Kubernets调度器

Kubernets Scheduler主要负责的工作是:接受API Server创建的新Pod,并为其安排一个主机,将信息写入etcd中。当然在这个过程中要处理的事情远远没有这么简单,需要综合考虑多种决策因素,比如把同一个replication controller的Pod分配到不同的主机上,防止因主机节点宕机对业务造成较大冲击;以及如何考虑资源均衡,从而提升整个集群的资源使用率等。

调度流程

Kubernetes调度器通过API Server查找还未分配主机的Pod,并尝试为这些Pod分配主机,这个过程如下图所示:

Kubernetes调度详解_第1张图片

  • 客户端提交创建请求,可以通过API Server的Restful API,也可以使用kubectl命令行工具。支持的数据类型包括JSON和YAML。

  • API Server处理用户请求,存储Pod数据到etcd。

  • 调度器通过API Server查看未绑定的Pod。尝试为Pod分配主机。

  • 过滤主机:调度器用一组规则过滤掉不符合要求的主机。比如Pod指定了所需要的资源量,那么可用资源比Pod需要的资源量少的主机会被过滤掉。

  • 主机打分:对第一步筛选出的符合要求的主机进行打分,在主机打分阶段,调度器会考虑一些整体优化策略,比如把容一个Replication Controller的副本分布到不同的主机上,使用最低负载的主机等。

  • 选择主机:选择打分最高的主机,进行binding操作,结果存储到etcd中。

  • 所选主机对于的kubelet根据调度结果执行Pod创建操作。

调度算法

Kubernetes通过一组规则,为每一个未调度的Pod选择一个主机,如调度流程中介绍,Kubernetes的调度算法主要包括两个方面,过滤主机和主机打分。

Kubernetes调度器的源码位于kubernetes/plugin/中,大体的代码目录结构如下所示:

|--kubernetes  
  |--plugin  
     |--cmd    //kub-scheduler启动函数在cmd包中  
     |--pkg     //调度相关的具体实现  
        |--scheduler  
           |--algorithm  
               |--predicates    //主机筛选策略  
               |--priorities       //主机打分策略  
           |--algorithmprovider  
               |--defaults        //定义默认的调度器

过滤主机的目的是过滤掉不符合Pod要求的主机,现在kubernetes中实现的过滤规则主要包括以下几种(在kubernetes/plugin/pkg/scheduler/algorithm/predicates中实现):

  • NoDiskConflict:检查在此主机上是否存在卷冲突。如果这个主机已经挂载了卷,其它同样使用这个卷的Pod不能调度到这个主机上。GCE, Amazon EBS, and Ceph RBD使用的规则如下:

    • GCE允许同时挂载多个卷,只要这些卷都是只读的。

    • Amazon EBS不允许不同的Pod挂载同一个卷。

    • Ceph RBD不允许任何两个pods分享相同的monitor,match pool和 image。

  • NoVolumeZoneConflict:检查给定的zone限制前提下,检查如果在此主机上部署Pod是否存在卷冲突。假定一些volumes可能有zone调度约束, VolumeZonePredicate根据volumes自身需求来评估pod是否满足条件。必要条件就是任何volumes的zone-labels必须与节点上的zone-labels完全匹配。节点上可以有多个zone-labels的约束(比如一个假设的复制卷可能会允许进行区域范围内的访问)。目前,这个只对PersistentVolumeClaims支持,而且只在PersistentVolume的范围内查找标签。处理在Pod的属性中定义的volumes(即不使用PersistentVolume)有可能会变得更加困难,因为要在调度的过程中确定volume的zone,这很有可能会需要调用云提供商。

  • PodFitsResources:检查主机的资源是否满足Pod的需求。根据实际已经分配的资源量做调度,而不是使用已实际使用的资源量做调度。

  • PodFitsHostPorts:检查Pod内每一个容器所需的HostPort是否已被其它容器占用。如果有所需的HostPort不满足需求,那么Pod不能调度到这个主机上。

  • HostName:检查主机名称是不是Pod指定的HostName。

  • MatchNodeSelector:检查主机的标签是否满足Pod的nodeSelector属性需求。

  • MaxEBSVolumeCount:确保已挂载的EBS存储卷不超过设置的最大值。默认值是39。它会检查直接使用的存储卷,和间接使用这种类型存储的PVC。计算不同卷的总目,如果新的Pod部署上去后卷的数目会超过设置的最大值,那么Pod不能调度到这个主机上。

  • MaxGCEPDVolumeCount:确保已挂载的GCE存储卷不超过设置的最大值。默认值是16。规则同上。

可以通过配置修改Kubernetes默认支持的过滤规则。

经过过滤后,再对符合需求的主机列表进行打分,最终选择一个分值最高的主机部署Pod。Kubernetes用一组优先级函数处理每一个待选的主机(在kubernetes/plugin/pkg/scheduler/algorithm/priorities中实现)。每一个优先级函数会返回一个0-10的分数,分数越高表示主机越“好”, 同时每一个函数也会对应一个表示权重的值。最终主机的得分用以下公式计算得出:

finalScoreNode = (weight1 * priorityFunc1) + (weight2 * priorityFunc2) + ... + (weightn * priorityFuncn) 

现在支持的优先级函数包括以下几种:

  • LeastRequestedPriority:如果新的pod要分配给一个节点,这个节点的优先级就由节点空闲的那部分与总容量的比值(即(总容量-节点上pod的容量总和-新pod的容量)/总容量)来决定。CPU和memory权重相当,比值最大的节点的得分最高。需要注意的是,这个优先级函数起到了按照资源消耗来跨节点分配pods的作用。计算公式如下:

    cpu((capacity - sum(requested)) * 10 / capacity) + memory((capacity - sum(requested)) * 10 / capacity) / 2 
    
  • BalancedResourceAllocation:尽量选择在部署Pod后各项资源更均衡的机器。BalancedResourceAllocation不能单独使用,而且必须和LeastRequestedPriority同时使用,它分别计算主机上的cpu和memory的比重,主机的分值由cpu比重和memory比重的“距离”决定。计算公式如下:

    score = 10 - abs(cpuFraction-memoryFraction)*10
    
  • SelectorSpreadPriority:对于属于同一个service、replication controller的Pod,尽量分散在不同的主机上。如果指定了区域,则会尽量把Pod分散在不同区域的不同主机上。调度一个Pod的时候,先查找Pod对于的service或者replication controller,然后查找service或replication controller中已存在的Pod,主机上运行的已存在的Pod越少,主机的打分越高。

  • CalculateAntiAffinityPriority:对于属于同一个service的Pod,尽量分散在不同的具有指定标签的主机上。

  • ImageLocalityPriority:根据主机上是否已具备Pod运行的环境来打分。ImageLocalityPriority会判断主机上是否已存在Pod运行所需的镜像,根据已有镜像的大小返回一个0-10的打分。如果主机上不存在Pod所需的镜像,返回0;如果主机上存在部分所需镜像,则根据这些镜像的大小来决定分值,镜像越大,打分就越高。

  • NodeAffinityPriority(Kubernetes1.2实验中的新特性):Kubernetes调度中的亲和性机制。Node Selectors(调度时将pod限定在指定节点上),支持多种操作符(In, NotIn, Exists, DoesNotExist, Gt, Lt),而不限于对节点labels的精确匹配。另外,Kubernetes支持两种类型的选择器,一种是“hard(requiredDuringSchedulingIgnoredDuringExecution)”选择器,它保证所选的主机必须满足所有Pod对主机的规则要求。这种选择器更像是之前的nodeselector,在nodeselector的基础上增加了更合适的表现语法。另一种是“soft(preferresDuringSchedulingIgnoredDuringExecution)”选择器,它作为对调度器的提示,调度器会尽量但不保证满足NodeSelector的所有要求。

多层次资源限制

Kubernetes包含多种资源限制,用来控制Container、Pod和多租户级别的资源共享。
Kubernetes调度详解_第2张图片

每一个容器都可以指定spec.container[].resources.limits.cpuspec.container[].resources.limits.memoryspec.container[].resources.requests.cpuspec.container[].resources.requests.memory。 对容器的资源限制是可选的,可以通过修改集群配置设置默认的资源限制属性。

LimitRange是在namespace级别设置的pod容量限制。所有在对应的命名空间中的Pod,都会受到LimitRange的资源限制。

Pod的每一类资源限制是Pod中对应的资源类型限制的总和,在调度的过程中调度器使用这个总和值和主机上可用容量做比较,决定主机是否满足资源需求。这种调度属于静态的资源调度,即使主机上的真实负载很低,只要容量限制不满足需求,也不能在主机上部署Pod。

Resource Quota是在命名空间级别设置的资源限制,主要是解决多租户共享资源的问题。Resource Quota中的cpu指对应的命名空间中所有Pod可以使用的cpu的总和,memory指对应的命名空间中所有Pod可以使用的memory的总和。

结语

Kubernetes的调度器是完全插件化的实现,可以很方便的集成其它的调度器进行扩展。目前的调度器包含多个级别的资源限制,但是调度相关的实现相对简单,使用一些静态的规则去做调度,对于提升集群资源使用率、保障业务的QoS效果不是很明显。

Kubernetes调度器以后可能支持使用不同的调度器去调度不同的任务,这个实验中的新特性对于有多种类型业务混合部署在Kubernetes集群中的用户会有很大帮助。

Kubernetes正在开发中的QoS借鉴Borg的成熟经验,重点关注提高集群资源利用率的问题,这个特性非常值得期待,具体内容将在下次分享。

你可能感兴趣的:(kubernetes)