调度策略

    你可以通过执行 或 kube-scheduler --policy-configmap <ConfigMap> 设置并使用。

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

    • PodFitsHostPorts：检查 Pod 请求的端口（网络协议类型）在节点上是否可用。

    • PodFitsHost：检查 Pod 是否通过主机名指定了 Node。

    • PodFitsResources：检查节点的空闲资源（例如，CPU和内存）是否满足 Pod 的要求。

    • MatchNodeSelector：检查 Pod 的节点选择算符 和节点的 是否匹配。

    • NoVolumeZoneConflict：给定该存储的故障区域限制， 评估 Pod 请求的卷在节点上是否可用。

    • NoDiskConflict：根据 Pod 请求的卷是否在节点上已经挂载，评估 Pod 和节点是否匹配。

    • CheckNodePIDPressure：如果节点正上报进程 ID 稀缺，并且没有异常配置，则不会把 Pod 调度到此节点上。

    • CheckNodeDiskPressure：如果节点正上报存储压力（文件系统已满或几乎已满），并且没有异常配置，则不会把 Pod 调度到此节点上。

    • CheckNodeCondition：节点可用上报自己的文件系统已满，网络不可用或者 kubelet 尚未准备好运行 Pod。 如果节点上设置了这样的状况，并且没有异常配置，则不会把 Pod 调度到此节点上。

    • PodToleratesNodeTaints：检查 Pod 的 是否能容忍节点的污点。

    • CheckVolumeBinding：基于 Pod 的卷请求，评估 Pod 是否适合节点，这里的卷包括绑定的和未绑定的 都适用。

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

    • SelectorSpreadPriority：属于同一 Service、 或 ReplicaSet 的 Pod，跨主机部署。

    • InterPodAffinityPriority：实现了 的优先级。

    • LeastRequestedPriority：偏向最少请求资源的节点。 换句话说，节点上的 Pod 越多，使用的资源就越多，此策略给出的排名就越低。

    • RequestedToCapacityRatioPriority：使用默认的打分方法模型，创建基于 ResourceAllocationPriority 的 requestedToCapacity。

    • BalancedResourceAllocation：偏向平衡资源使用的节点。

    • NodePreferAvoidPodsPriority：根据节点的注解 scheduler.alpha.kubernetes.io/preferAvoidPods 对节点进行优先级排序。 你可以使用它来暗示两个不同的 Pod 不应在同一节点上运行。

    • NodeAffinityPriority：根据节点亲和中 PreferredDuringSchedulingIgnoredDuringExecution 字段对节点进行优先级排序。 你可以在将 Pod 分配给节点中了解更多。

    • TaintTolerationPriority：根据节点上无法忍受的污点数量，给所有节点进行优先级排序。 此策略会根据排序结果调整节点的等级。

    • ImageLocalityPriority：偏向已在本地缓存 Pod 所需容器镜像的节点。

    • ServiceSpreadingPriority：对于给定的 Service，此策略旨在确保该 Service 关联的 Pod 在不同的节点上运行。 它偏向把 Pod 调度到没有该服务的节点。 整体来看，Service 对于单个节点故障变得更具弹性。

    • ：给予所有节点相等的权重。

    • EvenPodsSpreadPriority：实现了 的优先级排序。