排程器配置

特性狀態： Kubernetes v1.25 [穩定]

您可以透過編寫一個配置檔案，並將其路徑作為命令列引數傳遞，來定製 kube-scheduler 的行為。

排程 Profile 允許您配置 kube-scheduler 中排程的不同階段。每個階段都在一個擴充套件點上公開。外掛透過實現一個或多個這些擴充套件點來提供排程行為。

您可以透過執行 kube-scheduler --config <檔名> 來指定排程 Profile，使用 KubeSchedulerConfiguration v1 結構。

最小配置如下所示：

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

注意

KubeSchedulerConfiguration v1beta3 在 v1.26 中已棄用，並在 v1.29 中移除。請將 KubeSchedulerConfiguration 遷移到 v1。

Profile

您可以配置單個 kube-scheduler 例項來執行多個 Profile。

擴充套件點

排程發生在多個階段，這些階段透過以下擴充套件點公開：

queueSort：這些外掛提供一個排序函式，用於對排程佇列中的待處理 Pod 進行排序。每次只能啟用一個佇列排序外掛。
preFilter：這些外掛用於在過濾之前預處理或檢查關於 Pod 或叢集的資訊。它們可以將 Pod 標記為不可排程。
filter：這些外掛等同於排程策略中的 Predicates，用於過濾掉不能執行該 Pod 的節點。Filters 按配置的順序呼叫。如果一個 Pod 未透過所有 Filter，則標記為不可排程。
postFilter：當沒有找到可行的節點供 Pod 使用時，將按配置順序呼叫這些外掛。如果任何 postFilter 外掛將 Pod 標記為可排程，則不會呼叫其餘外掛。
preScore：這是一個資訊性的擴充套件點，可用於進行預評分工作。
score：這些外掛為已透過過濾階段的每個節點提供一個分數。然後，排程器將選擇總分數最高的節點。
reserve：這是一個資訊性的擴充套件點，用於通知外掛何時為給定 Pod 預留了資源。外掛還實現了一個 Unreserve 呼叫，該呼叫會在 Reserve 期間或之後失敗時被呼叫。
permit：這些外掛可以阻止或延遲 Pod 的繫結。
preBind：這些外掛在 Pod 繫結之前執行任何所需的工作。
bind：外掛將 Pod 繫結到節點。bind 外掛按順序呼叫，一旦其中一個完成繫結，其餘外掛將被跳過。至少需要一個 bind 外掛。
postBind：這是一個資訊性的擴充套件點，在 Pod 繫結後被呼叫。
multiPoint：這是一個僅配置欄位，允許同時啟用或停用外掛在所有適用的擴充套件點上的功能。

對於每個擴充套件點，您可以停用特定的預設外掛或啟用您自己的外掛。例如：

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

您可以使用 `*` 作為 `disabled` 陣列中的名稱，以停用該擴充套件點的所有預設外掛。如果您願意，還可以使用此功能來重新排列外掛的順序。

排程外掛

以下外掛預設啟用，並實現了一個或多個擴充套件點：

ImageLocality：優先選擇已經擁有 Pod 所執行容器映象的節點。擴充套件點：score。
TaintToleration：實現汙點和容忍。實現擴充套件點：filter、preScore、score。
NodeName：檢查 Pod 規約的節點名稱是否與當前節點匹配。擴充套件點：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。
注意
當 StorageCapacityScoring 功能啟用時，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。

多個 Profile

您可以配置 kube-scheduler 來執行多個 Profile。每個 Profile 都有一個關聯的排程器名稱，並且可以在其擴充套件點中配置不同的外掛集。

使用以下示例配置，排程器將執行兩個 Profile：一個使用預設外掛，另一個停用所有評分外掛。

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

想要根據特定 Profile 進行排程的 Pod 可以在其 .spec.schedulerName 中包含相應的排程器名稱。

預設情況下，會建立一個名為 default-scheduler 的 Profile。此 Profile 包含上述預設外掛。當宣告多個 Profile 時，每個 Profile 都需要一個唯一的排程器名稱。

如果 Pod 未指定排程器名稱，則 kube-apiserver 將其設定為 default-scheduler。因此，必須存在一個具有此排程器名稱的 Profile 才能排程這些 Pod。

注意

Pod 的排程事件的 `reportingController` 是其 `spec.schedulerName`。Leader election 的事件使用列表中第一個 Profile 的排程器名稱。

有關更多資訊，請參閱 Event API Reference 下的 reportingController 部分。

注意

所有 Profile 在 queueSort 擴充套件點中必須使用相同的外掛，並具有相同的配置引數（如果適用）。這是因為排程器只有一個待處理 Pod 佇列。

適用於多個擴充套件點的外掛

從 kubescheduler.config.k8s.io/v1beta3 開始，Profile 配置中增加了一個欄位 multiPoint，允許輕鬆地在多個擴充套件點上啟用或停用外掛。multiPoint 配置的目的是簡化使用者和管理員在使用自定義 Profile 時所需的配置。

考慮一個名為 MyPlugin 的外掛，它實現了 preScore、score、preFilter 和 filter 擴充套件點。要為 MyPlugin 在其所有可用擴充套件點上啟用它，Profile 配置如下：

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 在內部啟用。但是，仍然可以透過單獨的擴充套件點來靈活地重新配置預設值（例如，順序和 Score 權重）。例如，考慮兩個 Score 外掛 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 外掛時，其一般優先順序如下：

特定擴充套件點的執行順序靠前，其設定將覆蓋其他地方的任何設定。
透過 MultiPoint 手動配置的外掛及其設定
預設外掛及其預設設定

為了演示上述層次結構，以下示例基於這些外掛：

外掛	擴充套件點
`DefaultQueueSort`	`QueueSort`
`CustomQueueSort`	`QueueSort`
`DefaultPlugin1`	`Score`, `Filter`
`DefaultPlugin2`	`Score`
`CustomPlugin1`	`Score`, `Filter`
`CustomPlugin2`	`Score`, `Filter`

這些外掛的有效示例配置如下：

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 配置的靈活性以及它與現有擴充套件點配置方法的無縫整合。