调度器配置

FEATURE STATE: Kubernetes v1.19 [beta]

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

你可以通过运行 kube-scheduler --config <filename> 来设置调度配置, 配置文件使用组件配置的 API (v1alpha1v1alpha2)。 v1alpha2 可以配置 kube-scheduler 运行多个配置文件

最简单的配置如下:

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:实现了污点和容忍

    实现的扩展点:FilterPrescoreScore

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

    实现的扩展点:Filter

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

    实现的扩展点:PreFilterFilter

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

    实现的扩展点:Score

  • PodTopologySpread:实现了 Pod 拓扑分布

    实现的扩展点:PreFilterFilterPreScoreScore

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

    实现的扩展点:Filter

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

    实现的扩展点:PreFilterFilter

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

    实现的扩展点:Score

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

    实现的扩展点:Score

  • VolumeBinding:检查节点是否有请求的卷,或是否可以绑定请求的卷。

    实现的扩展点: PreFilterFilterReservePreBind

  • 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

  • NodeResourceLimits:选择满足 Pod 资源限制的节点。

    实现的扩展点:PreScoreScore

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

    实现的扩展点:Filter

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

    实现的扩展点:FilterScore

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

    实现的扩展点:PreFilterFilterScore

多配置文件

你可以配置 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 扩展点使用相同的插件,并具有相同的配置参数(如果适用)。 这是因为调度器只有一个的队列保存悬决的 Pod。

接下来

最后修改 September 24, 2020 at 5:42 PM PST: translate content/zh/docs/reference/scheduling/config.md (dc71c947b)