调度策略

kube-scheduler 根据调度策略指定的断言(predicates)优先级(priorities) 分别对节点进行过滤和打分

你可以通过执行 kube-scheduler --policy-config-file <filename>kube-scheduler --policy-configmap <ConfigMap> 设置并使用调度策略

断言

以下断言实现了过滤接口:

  • PodFitsHostPorts:检查 Pod 请求的端口(网络协议类型)在节点上是否可用。
  • PodFitsHost:检查 Pod 是否通过主机名指定了 Node。
  • PodFitsResources:检查节点的空闲资源(例如,CPU和内存)是否满足 Pod 的要求。
  • NoVolumeZoneConflict:给定该存储的故障区域限制, 评估 Pod 请求的在节点上是否可用。
  • NoDiskConflict:根据 Pod 请求的卷是否在节点上已经挂载,评估 Pod 和节点是否匹配。
  • MaxCSIVolumeCount:决定附加 CSI 卷的数量,判断是否超过配置的限制。
  • CheckNodeMemoryPressure:如果节点正上报内存压力,并且没有异常配置,则不会把 Pod 调度到此节点上。
  • CheckNodePIDPressure:如果节点正上报进程 ID 稀缺,并且没有异常配置,则不会把 Pod 调度到此节点上。
  • CheckNodeDiskPressure:如果节点正上报存储压力(文件系统已满或几乎已满),并且没有异常配置,则不会把 Pod 调度到此节点上。
  • CheckNodeCondition:节点可用上报自己的文件系统已满,网络不可用或者 kubelet 尚未准备好运行 Pod。 如果节点上设置了这样的状况,并且没有异常配置,则不会把 Pod 调度到此节点上。
  • PodToleratesNodeTaints:检查 Pod 的容忍 是否能容忍节点的污点
  • CheckVolumeBinding:基于 Pod 的卷请求,评估 Pod 是否适合节点,这里的卷包括绑定的和未绑定的 PVCs 都适用。

优先级

以下优先级实现了打分接口:

  • LeastRequestedPriority:偏向最少请求资源的节点。 换句话说,节点上的 Pod 越多,使用的资源就越多,此策略给出的排名就越低。
  • MostRequestedPriority:支持最多请求资源的节点。 该策略将 Pod 调度到整体工作负载所需的最少的一组节点上。
  • RequestedToCapacityRatioPriority:使用默认的打分方法模型,创建基于 ResourceAllocationPriority 的 requestedToCapacity。
  • BalancedResourceAllocation:偏向平衡资源使用的节点。
  • NodePreferAvoidPodsPriority:根据节点的注解 scheduler.alpha.kubernetes.io/preferAvoidPods 对节点进行优先级排序。 你可以使用它来暗示两个不同的 Pod 不应在同一节点上运行。
  • NodeAffinityPriority:根据节点亲和中 PreferredDuringSchedulingIgnoredDuringExecution 字段对节点进行优先级排序。 你可以在将 Pod 分配给节点中了解更多。
  • TaintTolerationPriority:根据节点上无法忍受的污点数量,给所有节点进行优先级排序。 此策略会根据排序结果调整节点的等级。
  • ImageLocalityPriority:偏向已在本地缓存 Pod 所需容器镜像的节点。
  • ServiceSpreadingPriority:对于给定的 Service,此策略旨在确保该 Service 关联的 Pod 在不同的节点上运行。 它偏向把 Pod 调度到没有该服务的节点。 整体来看,Service 对于单个节点故障变得更具弹性。
  • EqualPriority:给予所有节点相等的权重。

接下来

最后修改 September 22, 2020 at 10:32 PM PST: translate content/zh/docs/reference/scheduling/policies.md (22ddf4f82)