常用的预选机制

  • CheckNodeCondition: 检查节点本身是否正常，磁盘网络等是否可用。
  • GeneralPredicates：不是一个单独的预选策略，包含好几个预选策略。
    • HostName: 检查Pod对象是否定义了pod.spec.hostname, 如果定义了，检查节点的hostname是否与pod定义的这个值相匹配。pod.spec.hostname这个属性并不是定义这个Pod运行在有相同hostname值的节点上。意思在对应的节点上，这个pod名称还没有被使用，要不然在一个节点上Pod是不允许同名的。因为某些Pod名称是固定的，不是随机生成的。
    • PodFitsHostPorts: pods.spec.containers.ports.hostPort，port能适配节点的端口。如果Pod中容器上定义了pods.spec.containers.ports.hostPort属性，指定绑定在节点的哪个端口上，如果你的节点这个端口已经被占用了，显然这个节点不符合条件了。
    • MatchNodeSelector: pods.spec.nodeSelector
    • PodFitsResources: 检查Pod的资源需求是否能被节点所满足，运行此Pod的最低配置是否满足。
  • NoDiskConflict: 检查Pod依赖的存储卷是否能满足需求; 但是这个不是默认启用的策略。
  • PodToleratesNodeTaints: 检查Pod上的spec.tolerations可容忍的污点是否完全包含节点上的污点;
  • PodToleratesNodeNoExecuteTaints: 等后面讲污点和容忍度的时候在解释。检查Pod上的spec.tolerations可容忍的污点是否完全包含节点上定义的NoExecute类型的污点。污点有3重属性。就是本来pod能接纳这个节点的污点，在上面跑着，但是后来节点污点改了，改成Pod里面不包含的污点了，所以pod此时不能接纳这个节点了，默认是可以继续在节点运行的，但是NoExecute意味着不能容忍，会驱离Pod的。这个预选策略默认是不启用的。
  • CheckNodeLabelPresence: 检查节点上指定标签的存在性。取决于用户定义，标签是用户自己定义的。这个预选策略默认不是启用的。
  • CheckServiceAffinity: pod可能会属于一个或多个service，根据当前Pod对象所属的service已有的其他pod对象，其中有一部分已经调度到这个节点上了，有些节点并没有运行此service关联的Pod。将相同service的pod对象尽可能放置在同一个节点上。这个默认不是启用的。
  • MaxEBSVolumeCount：检查节点上已挂载的EBS存储卷的数量是否超出了最大设定值。EBS是亚马逊的弹性块存储。如果你的k8s使用EBS存储卷，一般来讲一个节点上最多只能挂载39个存储卷。有定义，默认就是39个。
  • MaxGCEPDVolumeCount：google的GCE存储
  • MaxAzureDiskVolumeCount：亚马逊的存储AzureDisk –这3个都是启用的，这3个都是CNCF成员
  • CheckVolumeBinding: 检查节点上已绑定和未绑定的pvc是否满足Pod对象的存储卷需求
  • NoVolumeZoneConflict: Zone，机房逻辑范围划分
  • CheckNodeMemoryPressure：检查节点内存是否存在压力。如果一个节点上内存资源已经比较紧缺了，表示这节点不符合条件，肯定是倾向压力不大节点。
  • CheckNodePIDPressure：检查节点PID数量压力多大，PID资源紧缺。
  • CheckNodeDiskPressure：磁盘IO是否过大
  • MatchInterPodAffinity：Pod和Pod之间也是有亲和性。检查节点是否满足Pod的亲和性或反亲和性。到底用哪个，取决于你定义的是亲和性还是反亲和性。

调度器默认启用了的预选策略，是要检查所有启用了的预选策略。满足所有启用了的预选策略，节点才是满足条件的。

常用的优选函数

  • LeastRequested: 最少请求的节点。计算比率的。
  • BalancedResourceAllocation: CPU和内存资源被占用率相近的胜出;
  • NodePreferAvoidPods:
    节点倾向不要运行pods，根据节点是否有注解存在。如果给定的节点没有以下这个注解信息，得分为10，而且权重为1万，权重非常高。
    节点注解信息“scheduler.alpha.kubernetes.io/preferAvoidPods”
  • TaintToleration: 将Pod对象的spec.tolerations列表项与节点的taints列表项进行匹配度检查,匹配条目越多, 意味着节点污点越多，得分越低;
  • SeletorSpreading: 标签选择器分散度。查找与当前Pod对象匹配的sevice、replication controller、ReplicaSet、StatefulSet等，看看与这些选择器匹配到的现存的Pod对象所在的节点有哪些个，已经运行此类pod对象越少的节点得分越高。spread：散开。
  • InterPodAffinity: Pod亲和性。遍历Pod对象的亲和性条目，并将那些能够匹配到给定节点的条目的权重相加，结果值越大，得分越高。用pod自己去评估每个节点，能在多大程度上满足这个pod的亲和性，假如第一个节点它有两条能满足，第二个节点有三条能满足，显然第二个节点得分越高。
  • NodeAffinity: 节点亲和性。根据Pod中的nodeSelector对节点进行检查，能成功匹配的数量越多，得分越高。
  • MostRequested: LeastRequested相反。两者不能同时使用。
  • NodeLabel: 节点标签。根据节点是否拥有特定标签来评估得分。只关注标签，不关注值，标签存在就得分。
  • ImageLocality: 根据满足当前Pod对象需求的已有镜像的体积大小之和。比如一个Pod内有3个容器，节点上镜像都有的得分最高。事实上不是这么算的，根据镜像体积来算的。
    最后三个默认没有启用。

预选是一票否决，只要有一个策略不满足，节点就不符合了。
优选函数是计算总得分的。每个函数都评估，然后将函数得分加起来