这是本节的多页打印视图。 点击此处打印.

返回本页常规视图.

调度

1 - 调度策略

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：给予所有节点相等的权重。

接下来

2 - 调度器配置

FEATURE STATE: Kubernetes v1.19 [beta]

你可以通过编写配置文件，并将其路径传给 kube-scheduler 的命令行参数，定制 kube-scheduler 的行为。

调度模板（Profile）允许你配置 kube-scheduler 中的不同调度阶段。每个阶段都暴露于某个扩展点中。插件通过实现一个或多个扩展点来提供调度行为。

你可以通过运行 kube-scheduler --config <filename> 来设置调度模板， 使用 KubeSchedulerConfiguration (v1beta1) 结构体。

最简单的配置如下：

apiVersion: kubescheduler.config.k8s.io/v1beta1
kind: KubeSchedulerConfiguration
clientConnection:
  kubeconfig: /etc/srv/kubernetes/kube-scheduler/kubeconfig

配置文件

通过调度配置文件，你可以配置 kube-scheduler 在不同阶段的调度行为。 每个阶段都在一个扩展点中公开。 调度插件通过实现一个或多个扩展点，来提供调度行为。

你可以配置同一 kube-scheduler 实例使用多个配置文件。

扩展点

调度行为发生在一系列阶段中，这些阶段是通过以下扩展点公开的：

  1. QueueSort：这些插件对调度队列中的悬决的 Pod 排序。 一次只能启用一个队列排序插件。
  1. PreFilter：这些插件用于在过滤之前预处理或检查 Pod 或集群的信息。 它们可以将 Pod 标记为不可调度。
  1. Filter：这些插件相当于调度策略中的断言（Predicates），用于过滤不能运行 Pod 的节点。 过滤器的调用顺序是可配置的。 如果没有一个节点通过所有过滤器的筛选，Pod 将会被标记为不可调度。
  1. PreScore：这是一个信息扩展点，可用于预打分工作。
  1. Score：这些插件给通过筛选阶段的节点打分。调度器会选择得分最高的节点。
  1. Reserve：这是一个信息扩展点，当资源已经预留给 Pod 时，会通知插件。 这些插件还实现了 Unreserve 接口，在 Reserve 期间或之后出现故障时调用。
  1. Permit：这些插件可以阻止或延迟 Pod 绑定。
  1. PreBind：这些插件在 Pod 绑定节点之前执行。
  1. Bind：这个插件将 Pod 与节点绑定。绑定插件是按顺序调用的，只要有一个插件完成了绑定，其余插件都会跳过。绑定插件至少需要一个。
  1. PostBind：这是一个信息扩展点，在 Pod 绑定了节点之后调用。

对每个扩展点，你可以禁用默认插件或者是启用自己的插件，例如：

apiVersion: kubescheduler.config.k8s.io/v1beta1
kind: KubeSchedulerConfiguration
profiles:
  - plugins:
      score:
        disabled:
        - name: NodeResourcesLeastAllocated
        enabled:
        - name: MyCustomPluginA
          weight: 2
        - name: MyCustomPluginB
          weight: 1

你可以在 disabled 数组中使用 * 禁用该扩展点的所有默认插件。 如果需要，这个字段也可以用来对插件重新顺序。

调度插件

  1. UnReserve：这是一个信息扩展点，如果一个 Pod 在预留后被拒绝，并且被 Permit 插件搁置，它就会被调用。

调度插件

下面默认启用的插件实现了一个或多个扩展点：

  • ImageLocality：选择已经存在 Pod 运行所需容器镜像的节点。

    实现的扩展点：Score。

  • TaintToleration：实现了污点和容忍。

    实现的扩展点：Filter，Prescore，Score。

  • NodeName：检查 Pod 指定的节点名称与当前节点是否匹配。

    实现的扩展点：Filter。

  • NodePorts：检查 Pod 请求的端口在节点上是否可用。

    实现的扩展点：PreFilter，Filter。

  • NodePreferAvoidPods：基于节点的 注解 scheduler.alpha.kubernetes.io/preferAvoidPods 打分。

    实现的扩展点：Score。

  • PodTopologySpread：实现了 Pod 拓扑分布。

    实现的扩展点：PreFilter，Filter，PreScore，Score。

  • NodeUnschedulable：过滤 .spec.unschedulable 值为 true 的节点。

    实现的扩展点：Filter。

  • NodeResourcesFit：检查节点是否拥有 Pod 请求的所有资源。

    实现的扩展点：PreFilter，Filter。

  • NodeResourcesBalancedAllocation：调度 Pod 时，选择资源使用更为均衡的节点。

    实现的扩展点：Score。

  • NodeResourcesLeastAllocated：选择资源分配较少的节点。

    实现的扩展点：Score。

  • VolumeBinding：检查节点是否有请求的卷，或是否可以绑定请求的卷。 实现的扩展点: PreFilter、Filter、Reserve、PreBind 和 Score。
    说明： 当 VolumeCapacityPriority 特性被启用时，Score 扩展点也被启用。 它优先考虑可以满足所需卷大小的最小 PV。

  • VolumeRestrictions：检查挂载到节点上的卷是否满足卷提供程序的限制。

    实现的扩展点：Filter。

  • VolumeZone：检查请求的卷是否在任何区域都满足。

    实现的扩展点：Filter。

  • NodeVolumeLimits：检查该节点是否满足 CSI 卷限制。

    实现的扩展点：Filter。

  • EBSLimits：检查节点是否满足 AWS EBS 卷限制。

    实现的扩展点：Filter。

  • GCEPDLimits：检查该节点是否满足 GCP-PD 卷限制。

    实现的扩展点：Filter。

  • AzureDiskLimits：检查该节点是否满足 Azure 卷限制。

    实现的扩展点：Filter。

  • PrioritySort：提供默认的基于优先级的排序。

    实现的扩展点：QueueSort。

  • DefaultBinder：提供默认的绑定机制。

    实现的扩展点：Bind。

  • DefaultPreemption：提供默认的抢占机制。

    实现的扩展点：PostFilter。

你也可以通过组件配置 API 启用以下插件（默认不启用）:

  • NodeResourcesMostAllocated：选择已分配资源多的节点。

    实现的扩展点：Score。

  • RequestedToCapacityRatio：根据已分配资源的某函数设置选择节点。

    实现的扩展点：Score。

  • CinderVolume：检查该节点是否满足 OpenStack Cinder 卷限制。

    实现的扩展点：Filter。

  • NodeLabel：根据配置的 标签 过滤节点和/或给节点打分。

    实现的扩展点：Filter，Score。

  • ServiceAffinity：检查属于某个 服务（Service） 的 Pod 与配置的标签所定义的节点集是否适配。 这个插件还支持将属于某个 Service 的 Pod 分散到各个节点。

    实现的扩展点：PreFilter，Filter，Score。

多配置文件

你可以配置 kube-scheduler 运行多个配置文件。 每个配置文件都有一个关联的调度器名称，并且可以在其扩展点中配置一组不同的插件。

使用下面的配置样例，调度器将运行两个配置文件：一个使用默认插件，另一个禁用所有打分插件。

apiVersion: kubescheduler.config.k8s.io/v1beta1
kind: KubeSchedulerConfiguration
profiles:
  - schedulerName: default-scheduler
  - schedulerName: no-scoring-scheduler
    plugins:
      preScore:
        disabled:
        - name: '*'
      score:
        disabled:
        - name: '*'

对于那些希望根据特定配置文件来进行调度的 Pod，可以在 .spec.schedulerName 字段指定相应的调度器名称。

默认情况下，将创建一个调度器名为 default-scheduler 的配置文件。 这个配置文件包括上面描述的所有默认插件。 声明多个配置文件时，每个配置文件中调度器名称必须唯一。

如果 Pod 未指定调度器名称，kube-apiserver 将会把调度器名设置为 default-scheduler。 因此，应该存在一个调度器名为 default-scheduler 的配置文件来调度这些 Pod。

说明：

Pod 的调度事件把 .spec.schedulerName 字段值作为 ReportingController。 领导者选举事件使用列表中第一个配置文件的调度器名称。

说明：

所有配置文件必须在 QueueSort 扩展点使用相同的插件，并具有相同的配置参数（如果适用）。 这是因为调度器只有一个保存 pending 状态 Pod 的队列。

接下来