Kubernetes Scheduler的Predicates和Priorities Policies解读

本文是对Kubernetes V1.5 Scheduler 的预选策略Predicates Policies和优选策略Priorities Policies的含义解读，并附有部分样例代码代码解析。关于kubernetes调度器更全面的解析见我的其他博客：Kubernetes Scheduler源码分析, Kubernetes Scheduler原理解析

Predicates Policies分析

在/plugin/pkg/scheduler/algorithm/predicates.go中实现了以下的预选策略：

• 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。规则同上。

下面是NoDiskConflict的代码实现，其他Predicates Policies实现类似，都得如下函数原型：

type FitPredicate func(pod *v1.Pod, meta interface{}, nodeInfo *schedulercache.Nod