调度程序配置

您可以通过编写配置文件并将它的路径作为命令行参数传递来自定义 kube-scheduler 的行为。

调度配置文件允许您在 kube-scheduler 中配置调度的不同阶段。每个阶段都暴露在一个扩展点中。插件通过实现一个或多个这些扩展点来提供调度行为。

您可以通过运行 kube-scheduler --config <filename> 来指定调度配置文件，使用 KubeSchedulerConfiguration v1 结构体。

一个最小的配置如下所示

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

配置文件

调度配置文件允许您在 kube-scheduler 中配置调度的不同阶段。每个阶段都暴露在一个 扩展点 中。 插件 通过实现一个或多个这些扩展点来提供调度行为。

您可以配置单个 kube-scheduler 实例来运行 多个配置文件.

扩展点

调度发生在一系列阶段中，这些阶段通过以下扩展点暴露出来

1. queueSort: 这些插件提供一个排序函数，用于对调度队列中的待处理 Pod 进行排序。一次只能启用一个队列排序插件。
2. preFilter: 这些插件用于在过滤之前预处理或检查有关 Pod 或集群的信息。它们可以将 Pod 标记为不可调度。
3. filter: 这些插件相当于调度策略中的谓词，用于过滤掉无法运行 Pod 的节点。过滤器按配置的顺序调用。如果没有任何节点通过所有过滤器，则 Pod 被标记为不可调度。
4. postFilter: 当没有为 Pod 找到可行的节点时，这些插件按配置的顺序调用。如果任何 postFilter 插件将 Pod 标记为可调度，则不会调用剩余的插件。
5. preScore: 这是一个信息扩展点，可用于执行预评分工作。
6. score: 这些插件为通过过滤阶段的每个节点提供一个分数。然后调度程序将选择具有最高加权分数总和的节点。
7. reserve: 这是一个信息扩展点，在为给定的 Pod 预留资源时通知插件。插件还实现一个 Unreserve 调用，该调用在 Reserve 期间或之后失败的情况下被调用。
8. permit: 这些插件可以阻止或延迟 Pod 的绑定。
9. preBind: 这些插件在 Pod 绑定之前执行任何必要的工作。
10. bind: 插件将 Pod 绑定到节点。bind 插件按顺序调用，一旦一个插件完成绑定，其余插件将被跳过。至少需要一个绑定插件。
11. postBind: 这是一个信息扩展点，在 Pod 绑定后被调用。
12. multiPoint: 这是一个仅配置的字段，允许插件同时为其所有适用的扩展点启用或禁用。

对于每个扩展点，您可以禁用特定的 默认插件 或启用您自己的插件。例如

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

您可以在禁用数组中使用 * 作为名称来禁用该扩展点的所有默认插件。如果需要，这也可以用于重新排列插件的顺序。

调度插件

以下默认启用的插件实现了一个或多个这些扩展点

• ImageLocality: 偏向于已经拥有 Pod 运行的容器镜像的节点。扩展点：score。
• TaintToleration: 实现 污点和容忍。实现扩展点：filter、preScore、score。
• NodeName: 检查 Pod spec 节点名称是否与当前节点匹配。扩展点：filter。
• NodePorts: 检查节点是否有用于请求的 Pod 端口的空闲端口。扩展点：preFilter、filter。
• NodeAffinity: 实现 节点选择器 和 节点亲和性。扩展点：filter、score。
• PodTopologySpread: 实现 Pod 拓扑分布。扩展点：preFilter、filter、preScore、score。
• NodeUnschedulable: 过滤掉已将 .spec.unschedulable 设置为 true 的节点。扩展点：filter。
• NodeResourcesFit: 检查节点是否拥有 Pod 请求的所有资源。分数可以使用三种策略之一：LeastAllocated（默认）、MostAllocated 和 RequestedToCapacityRatio。扩展点：preFilter、filter、score。
• NodeResourcesBalancedAllocation: 偏向于如果 Pod 调度到那里，将获得更平衡的资源使用情况的节点。扩展点：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。
• InterPodAffinity: 实现 Pod 间亲和性和反亲和性。扩展点：preFilter、filter、preScore、score。
• PrioritySort: 提供默认的基于优先级的排序。扩展点：queueSort。
• DefaultBinder: 提供默认的绑定机制。扩展点：bind。
• DefaultPreemption: 提供默认的抢占机制。扩展点：postFilter。

您还可以通过组件配置 API 启用以下默认情况下未启用的插件

• CinderLimits: 检查节点是否可以满足 OpenStack Cinder 卷限制。扩展点：filter。

多个配置文件

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

使用以下示例配置，调度程序将使用两个配置文件运行：一个使用默认插件，另一个禁用所有评分插件。

apiVersion: kubescheduler.config.k8s.io/v1
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。因此，应存在一个具有此调度程序名称的配置文件才能调度这些 Pod。

应用于多个扩展点的插件

从 kubescheduler.config.k8s.io/v1beta3 开始，配置文件配置中有一个额外的字段 multiPoint，它允许轻松地在多个扩展点之间启用或禁用插件。multiPoint 配置的目的是简化用户和管理员在使用自定义配置文件时所需的配置。

假设一个名为 MyPlugin 的插件，它实现了 preScore、score、preFilter 和 filter 扩展点。要为 MyPlugin 的所有可用扩展点启用它，配置文件配置如下所示

apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
  - schedulerName: multipoint-scheduler
    plugins:
      multiPoint:
        enabled:
        - name: MyPlugin

这相当于手动为 MyPlugin 的所有扩展点启用它，如下所示

apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
  - schedulerName: non-multipoint-scheduler
    plugins:
      preScore:
        enabled:
        - name: MyPlugin
      score:
        enabled:
        - name: MyPlugin
      preFilter:
        enabled:
        - name: MyPlugin
      filter:
        enabled:
        - name: MyPlugin

在这里使用 multiPoint 的一个好处是，如果 MyPlugin 在将来实现另一个扩展点，multiPoint 配置将自动为新扩展点启用它。

可以使用该扩展点的 disabled 字段将特定扩展点从 MultiPoint 扩展中排除。这适用于禁用默认插件、非默认插件或使用通配符 ('*') 禁用所有插件。例如，禁用 Score 和 PreScore 的示例如下

apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
  - schedulerName: non-multipoint-scheduler
    plugins:
      multiPoint:
        enabled:
        - name: 'MyPlugin'
      preScore:
        disabled:
        - name: '*'
      score:
        disabled:
        - name: '*'

从 kubescheduler.config.k8s.io/v1beta3 版本开始，所有 默认插件 都通过 MultiPoint 在内部启用。但是，各个扩展点仍然可用，以允许灵活地重新配置默认值（例如排序和评分权重）。例如，考虑两个评分插件 DefaultScore1 和 DefaultScore2，每个插件的权重为 1。可以按如下方式重新排序它们，并使用不同的权重：

apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
  - schedulerName: multipoint-scheduler
    plugins:
      score:
        enabled:
        - name: 'DefaultScore2'
          weight: 5

在此示例中，无需在 MultiPoint 中显式指定插件，因为它们是默认插件。并且在 Score 中指定的唯一插件是 DefaultScore2。这是因为通过特定扩展点设置的插件始终优先于 MultiPoint 插件。因此，此代码段本质上重新排序了这两个插件，而无需显式指定它们。

配置 MultiPoint 插件时的优先级一般层次结构如下：

1. 特定扩展点优先运行，其设置将覆盖其他地方设置的内容。
2. 通过 MultiPoint 手动配置的插件及其设置。
3. 默认插件及其默认设置。

为了演示上述层次结构，以下示例基于这些插件：

这些插件的有效示例配置如下：

apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
  - schedulerName: multipoint-scheduler
    plugins:
      multiPoint:
        enabled:
        - name: 'CustomQueueSort'
        - name: 'CustomPlugin1'
          weight: 3
        - name: 'CustomPlugin2'
        disabled:
        - name: 'DefaultQueueSort'
      filter:
        disabled:
        - name: 'DefaultPlugin1'
      score:
        enabled:
        - name: 'DefaultPlugin2'

请注意，在特定扩展点中重新声明 MultiPoint 插件不会导致错误。重新声明将被忽略（并记录），因为特定扩展点优先。

除了将大部分配置保存在一个位置外，此示例还执行以下操作：

• 启用自定义 queueSort 插件并禁用默认插件。
• 启用 CustomPlugin1 和 CustomPlugin2，它们将在所有扩展点中首先运行。
• 禁用 DefaultPlugin1，但仅针对 filter。
• 重新排序 DefaultPlugin2 以使其在 score 中首先运行（甚至在自定义插件之前）。

在 v1beta3 之前的配置版本中，如果没有 multiPoint，上述代码段等效于以下内容：

apiVersion: kubescheduler.config.k8s.io/v1beta2
kind: KubeSchedulerConfiguration
profiles:
  - schedulerName: multipoint-scheduler
    plugins:

      # Disable the default QueueSort plugin
      queueSort:
        enabled:
        - name: 'CustomQueueSort'
        disabled:
        - name: 'DefaultQueueSort'

      # Enable custom Filter plugins
      filter:
        enabled:
        - name: 'CustomPlugin1'
        - name: 'CustomPlugin2'
        - name: 'DefaultPlugin2'
        disabled:
        - name: 'DefaultPlugin1'

      # Enable and reorder custom score plugins
      score:
        enabled:
        - name: 'DefaultPlugin2'
          weight: 1
        - name: 'DefaultPlugin1'
          weight: 3

虽然这是一个复杂的示例，但它展示了 MultiPoint 配置的灵活性以及它与配置扩展点的现有方法的无缝集成。

调度器配置迁移

• v1beta1 → v1beta2
• v1beta2 → v1beta3
• v1beta3 → v1

下一步

• 阅读 kube-scheduler 参考
• 了解 调度
• 阅读 kube-scheduler 配置 (v1) 参考