全部產品
Search
文件中心

Container Service for Kubernetes:使用負載熱點打散重調度

更新時間:Dec 18, 2024

ack-koordinator組件提供負載熱點打散重調度能力,可以感知叢集內節點負載的變化,自動最佳化超過負載水位安全閾值的節點,防止出現負載極端不均衡的情況。本文介紹如何使用負載熱點打散重調度及其進階配置參數。

使用限制

  • 僅支援ACK叢集Pro版。具體操作,請參見建立ACK託管叢集

  • 使用負載熱點打散重調度,需滿足以下版本要求。

    組件

    版本要求

    ACK Scheduler

    v1.22.15-ack-4.0及以上,v1.24.6-ack-4.0及以上

    ack-koordinator

    v1.1.1-ack.1及以上

    Helm

    v3.0及以上

重要
  • 重調度器只負責驅逐,調度過程仍由ACK Scheduler負責。在使用重調度功能時,建議和負載感知調度搭配使用,ACK Scheduler將盡量避免Pod被重新分配到熱點節點。

  • 重調度在執行過程中會先驅逐舊Pod,再建立新Pod。請確保您的應用有充足的冗餘副本,避免驅逐時影響應用可用性。

  • 重調度在驅逐時使用的是Kubernetes標準的驅逐介面,請確保應用Pod自身邏輯具備可重新進入性,不會因驅逐後重新啟動而導致服務受損。

費用說明

ack-koordinator組件本身的安裝和使用是免費的,不過需要注意的是,在以下情境中可能產生額外的費用:

  • ack-koordinator是非託管組件,安裝後將佔用Worker節點資源。您可以在安裝組件時配置各模組的資源申請量。

  • ack-koordinator預設會將資源畫像、精細化調度等功能的監控指標以Prometheus的格式對外透出。若您配置組件時開啟了ACK-Koordinator開啟Prometheus監控指標選項並使用了阿里雲Prometheus服務,這些指標將被視為自訂指標併產生相應費用。具體費用取決於您的叢集規模和應用數量等因素。建議您在啟用此功能前,仔細閱讀阿里雲Prometheus計費說明,瞭解自訂指標的免費額度和收費策略。您可以通過賬單和用量查詢,監控和管理您的資源使用方式。

負載熱點打散重調度介紹

負載感知調度

調度器支援負載感知調度,能夠在調度時選擇負載較低的節點運行新的Pod。節點的利用率會隨著時間、叢集環境變化、工作負載的流量或請求等動態變化,繼而導致叢集內節點間原本負載平衡的情況被打破,甚至有可能出現極端負載不均衡的情況,影響到工作負載運行時品質。ack-koordinator組件提供重調度能力,防止負載出現極端不均衡的情況。通過將負載感知調度和熱點打散重調度結合使用,可以獲得叢集良好的負載平衡效果。關於負載感知調度,請參見使用負載感知調度

Koordinator Descheduler模組工作原理

ack-koordinator組件提供Koordinator Descheduler模組,其中LowNodeLoad外掛程式負責感知負載水位並完成熱點打散重調度工作。與Kubernetes原生的Descheduler的外掛程式LowNodeUtilization不同,LowNodeLoad是根據節點真實利用率決策重調度,而LowNodeUtilization是根據資源分派率決策重調度。

模組執行過程

Koordinator Descheduler模組周期性運行,每個周期內的執行過程分為以下三個階段。

koorle-descheduler執行過程

  1. 資料收集:擷取叢集內的節點和工作負載資訊,以及相關的資源使用率資料。

  2. 策略外掛程式執行。

    下文以LowNodeLoad為例。

    1. 篩選負載熱點節點。關於節點分類,請參見下文LowNodeLoad負載水位參數說明

    2. 遍曆熱點節點,從中篩選可以遷移的Pod,並進行排序。關於Pod打分排序,請參見下文Pod打分策略

    3. 遍曆每個待遷移的Pod,檢查其是否滿足遷移條件,綜合考慮叢集容量、資源使用率水位、副本數比例等約束。詳細資料,請參見下文負載熱點打散重調度策略說明

    4. 若滿足條件則將Pod歸類為待遷移副本,若不滿足則繼續遍曆其他Pod和熱點節點。

  3. 容器驅逐遷移:針對待遷移的Pod發起Evict驅逐操作。關於Evict驅逐,請參見Evict驅逐

LowNodeLoad負載水位參數說明

LowNodeLoad外掛程式有兩個重要的參數。

  • highThresholds負載的熱點水位。僅超過該閾值的節點上的Pod會參與重調度,低於該閾值的節點上的Pod不會被重調度。建議您同時開啟調度器的負載感知調度能力,請參見策略說明。關於兩者如何搭配使用,請參見負載感知調度和熱點打散重調度如何搭配使用?

  • lowThresholds:負載的空閑水位。

如果所有節點水位均高於 lowThresholds,表明此時叢集整體水位偏高,即便有節點水位大於highThresholdsKoordinator Descheduler也不會執行重調度。

以下圖為例,將lowThresholds設定為45%,將highThresholds設定為70%,那麼節點的分類標準如下。同理,如果lowThresholdshighThresholds的值發生變更,節點的分類標準也會相應發生變化。

資源使用率資料預設每分鐘更新一次,粒度為最近5分鐘的平均值。

  • 空閑節點(Idle Node):資源使用率低於45%的節點。

  • 正常節點(Normal Node):資源使用率高於等於45%且低於等於70%的節點。此節點的負載水位區間是期望達到的合理區間範圍。

  • 熱點節點(Hotspot Node):資源使用率高於70%的節點。熱點節點將驅逐一部分Pod,降低負載水位,使其不超過70%。

負載熱點打散重調度策略說明

策略名稱稱

說明

熱點檢查重試次數策略

為了確保熱點識別的準確性,避免部分毛刺監控資料觸發應用頻繁遷移,Koordinator Descheduler支援為熱點檢查配置重試次數。只有節點連續多次觸發閾值時才會被識別為熱點節點。

節點排序策略

在識別到的熱點節點中,Koordinator Descheduler會按資源用量從高到低的順序,依次對節點發起重調度。其中,節點排序過程中會依次比較記憶體資源用量和CPU資源用量,優先選取資源用量更高的節點。

Pod打分策略

對於每個熱點節點,Koordinator Descheduler會對其中的Pod逐個打分排序,依次發起驅逐操作,將其遷移到空閑節點上。比較順序如下:

  1. 優先順序(Priority)更低的Pod,未設定時值為0,表示優先順序最低。

  2. QoS等級更低的Pod。

  3. 對於優先順序、QoS等級相同的Pod,Koordinator Descheduler會綜合考慮資源使用率、啟動時間等因素進行排序。

說明

若您對Pod的驅逐順序有要求,建議您考慮對Pod配置不同的優先順序或QoS。

篩選策略

Koordinator Descheduler模組支援為Pod和Node配置多種篩選參數,方便您在使用過程中進行灰階控制。

  • 按Namespace過濾:指定開啟或關閉某些Namespace下Pod的重調度能力。詳細資料,請參見進階配置中關於evictableNamespaces欄位的描述。

  • 按Pod Selector過濾:指定Pod的Label Selector,選定開啟重調度能力的Pod範圍。詳細資料,請參見進階配置中關於podSelectors欄位的描述。

  • 按Node Selector過濾:指定Node的Label Selector,選定開啟重調度能力的Node範圍。詳細資料,請參見進階配置中關於nodeSelector欄位的描述。

前置檢查策略

Koordinator Descheduler模組支援在Pod遷移前提供前置檢查能力,確保每個Pod的遷移過程盡量安全。

  • 檢查節點親和性和資源調度容量,確保Pod在重調度後,叢集內有可以匹配的Node節點後再發起遷移。檢查的屬性包括Node Affinity、Node Selector、Toleration以及節點未分配的資源容量。

  • 檢查空閑節點實際的資源用量情況,確保節點在收到新Pod後不會觸及熱點水位,避免出現頻繁的抖動問題。

    計算公式:空閑節點實際空閑容量 = (highThresholds - 空閑節點當前負載) * 空閑節點總容量

    計算樣本:假設空閑節點的負載水位是20%,highThresholds是70%,節點CPU總容量為96核。則節點實際空閑容量為48核( (70% - 20%) * 96)。此時,Koordinator Descheduler會確保所有遷移Pod申請的CPU總量(Request)不超過48核。

遷移流量控制策略

為了滿足Pod在遷移過程中應用的高可用要求,Koordinator Descheduler模組還提供多種類型的限制能力,支援配置節點維度、命名空間維度以及工作負載維度下處於遷移狀態Pod的最大數量。此外,它還提供基於時間視窗的流控機制,保證同一Workload下Pod的遷移不會過於頻繁。Koordinator Descheduler同樣相容Kubernetes社區的幹擾預算機制PDB(Pod Disruption Budgets),支援配置更精細的管理原則來保障工作負載的高可用。

可觀測性策略

您可以通過Event觀測重調度的遷移過程,並在詳細資料中查看遷移的具體原因和目前狀態。範例如下。

kubectl get event | grep stress-demo-588f9646cf-7****
55s         Normal    Evicting           podmigrationjob/3bf8f623-4d10-4fc5-ab4e-2bead3c4****   Pod "default/stress-demo-588f9646cf-7****" evicted from node "cn-beijing.10.XX.XX.53" by the reason "node is overutilized, cpu usage(76.72%)>threshold(50.00%)"
22s         Normal    EvictComplete      podmigrationjob/3bf8f623-4d10-4fc5-ab4e-2bead3c4****   Pod "default/stress-demo-588f9646cf-7****" has been evicted
55s         Normal    Descheduled        pod/stress-demo-588f9646cf-7****                       Pod evicted from node "cn-beijing.10.XX.XX.53" by the reason "node is overutilized, cpu usage(76.72%)>threshold(50.00%)"
55s         Normal    Killing            pod/stress-demo-588f9646cf-7****                       Stopping container stress

步驟一:安裝或修改組件ack-koordinator並開啟重調度

未安裝ack-koordinator組件

安裝ack-koordinator組件,並在安裝組件 ack-koordinator(ack-slo-manager)頁面選中ack-koordinator開啟重調度模組。安裝ack-koordinator組件,請參見安裝ack-koordinator組件

已安裝ack-koordinator組件

修改ack-koordinator組件,並在ack-koordinator參數配置頁面選中ack-koordinator開啟重調度模組。修改ack-koordinator組件,請參見修改ack-koordinator組件

步驟二:開啟負載熱點打散重調度外掛程式

  1. 使用如下YAML檔案,建立koord-descheduler-config.yaml。

    koord-descheduler-config.yaml是ConfigMap格式的對象,用於啟用重調度外掛程式LowNodeLoad。

    展開查看YAML檔案內容

    # koord-descheduler-config.yaml
    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: koord-descheduler-config
      namespace: kube-system
    data:
      koord-descheduler-config: |
        # 以下為koord-desheduler系統配置,請保持不變。
        apiVersion: descheduler/v1alpha2
        kind: DeschedulerConfiguration
        leaderElection:
          resourceLock: leases
          resourceName: koord-descheduler
          resourceNamespace: kube-system
        deschedulingInterval: 120s # 執行循環間隔,120s執行一次重調度外掛程式。
        dryRun: false # 全域唯讀模式開關,開啟後Koordinator Descheduler整體不做任何操作。
        # 以上為系統配置。
    
        profiles:
        - name: koord-descheduler
          plugins:
            deschedule:
              disabled:
                - name: "*"
            balance:
              enabled:
                - name: LowNodeLoad # 配置開啟負載熱點打散外掛程式LowNodeLoad。
            evict:
              disabled:
                - name: "*"
              enabled:
                - name: MigrationController # 配置開啟驅逐遷移控制器。
    
          pluginConfig:
          - name: MigrationController # 重調度遷移控制參數。
            args:
              apiVersion: descheduler/v1alpha2
              kind: MigrationControllerArgs
              defaultJobMode: EvictDirectly
    
          - name: LowNodeLoad # 負載熱點打散外掛程式配置。
            args:
              apiVersion: descheduler/v1alpha2
              kind: LowNodeLoadArgs
    
              lowThresholds:  # lowThresholds表示空閑節點的准入水位閾值,判斷條件為“所有資源維度均低於閾值”。
                cpu: 20 # CPU利用率為20%。
                memory: 30  # Memory利用率為30%。
              highThresholds: # highThresholds表示熱點節點的准入水位閾值,判斷條件為“只要有一個資源維度均高於閾值”。
                cpu: 50  # CPU利用率為50%。
                memory: 60 # Memory利用率為60%。
    
              evictableNamespaces: # 參與重調度的Namespace,include和exclude是互斥的,只能配置其中一種。
                include: # include表示只處理下面配置的Namespace。
                  - default
                # exclude: # exclude表示需要排除的Namespace。
                  # - "kube-system"
                  # - "koordinator-system"
  2. 執行如下命令,將配置更新到叢集。

    kubectl apply -f koord-descheduler-config.yaml
  3. 執行如下命令,重啟重調度器模組Koordinator Descheduler

    重啟重調度器模組Koordinator Descheduler後,Koordinator Descheduler會使用修改後的最新配置。

    kubectl -n kube-system scale deploy ack-koord-descheduler --replicas 0
    deployment.apps/ack-koord-descheduler scaled
    kubectl -n kube-system scale deploy ack-koord-descheduler --replicas 1
    deployment.apps/ack-koord-descheduler scaled

步驟三(可選):開啟調度器負載平衡外掛程式

開啟調度器負載平衡外掛程式,以獲得叢集良好的負載平衡效果。具體操作步驟,請參見步驟一:開啟負載感知調度

步驟四:驗證重調度能力

下文以擁有3台104核 396 GB節點的叢集為例進行說明。

  1. 使用如下YAML檔案,建立stress-demo.yaml

    展開查看YAML檔案內容。

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: stress-demo
      namespace: default
      labels:
        app: stress-demo
    spec:
      replicas: 6
      selector:
        matchLabels:
          app: stress-demo
      template:
        metadata:
          name: stress-demo
          labels:
            app: stress-demo
        spec:
          containers:
            - args:
                - '--vm'
                - '2'
                - '--vm-bytes'
                - '1600M'
                - '-c'
                - '2'
                - '--vm-hang'
                - '2'
              command:
                - stress
              image: polinux/stress
              imagePullPolicy: Always
              name: stress
              resources:
                limits:
                  cpu: '2'
                  memory: 4Gi
                requests:
                  cpu: '2'
                  memory: 4Gi
          restartPolicy: Always
  2. 執行如下命令,建立壓測Pod。

    kubectl create -f stress-demo.yaml
    deployment.apps/stress-demo created
  3. 執行如下命令,觀察Pod的狀態,直到它開始運行。

    kubectl get pod -o wide

    預期輸出:

    NAME                           READY   STATUS    RESTARTS   AGE   IP            NODE                    NOMINATED NODE   READINESS GATES
    stress-demo-588f9646cf-s****   1/1     Running   0          82s   10.XX.XX.53   cn-beijing.10.XX.XX.53   <none>           <none>

    可以看到,Pod stress-demo-588f9646cf-s****調度在節點cn-beijing.10.XX.XX.53上。

  4. 提升節點cn-beijing.10.XX.XX.53的負載水位,然後執行如下命令,檢查每個Node節點的負載。

    kubectl top node

    預期輸出:

    NAME                      CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
    cn-beijing.10.XX.XX.215   17611m       17%    24358Mi         6%
    cn-beijing.10.XX.XX.53    63472m       63%    11969Mi         3%

    可以看到,節點cn-beijing.10.XX.XX.53的負載較高,為63%,已經超過配置的熱點水位50%。節點cn-beijing.10.XX.XX.215負載較低,為17%,低於配置的空閑水位20%。

  5. 開啟重調度。具體操作,請參見步驟二:開啟負載熱點打散重調度外掛程式

  6. 執行如下命令,觀察Pod變化。

    等待重調度器檢查熱點節點,並執行驅逐遷移操作。

    說明

    判定為熱點節點的預設條件為連續5次檢查節點均超過熱點水位,即10分鐘。

    kubectl get pod -w

    預期輸出:

    NAME                           READY   STATUS               RESTARTS   AGE     IP           NODE                     NOMINATED NODE   READINESS GATES
    stress-demo-588f9646cf-s****   1/1     Terminating          0          59s   10.XX.XX.53    cn-beijing.10.XX.XX.53     <none>           <none>
    stress-demo-588f9646cf-7****   1/1     ContainerCreating    0          10s   10.XX.XX.215   cn-beijing.10.XX.XX.215    <none>           <none>
  7. 執行如下命令,觀察Event。

    kubectl get event | grep stress-demo-588f9646cf-s****

    預期輸出:

    2m14s       Normal    Evicting            podmigrationjob/00fe88bd-8d4c-428d-b2a8-d15bcdeb****   Pod "default/stress-demo-588f9646cf-s****" evicted from node "cn-beijing.10.XX.XX.53" by the reason "node is overutilized, cpu usage(68.53%)>threshold(50.00%)"
    101s        Normal    EvictComplete       podmigrationjob/00fe88bd-8d4c-428d-b2a8-d15bcdeb****   Pod "default/stress-demo-588f9646cf-s****" has been evicted
    2m14s       Normal    Descheduled         pod/stress-demo-588f9646cf-s****                       Pod evicted from node "cn-beijing.10.XX.XX.53" by the reason "node is overutilized, cpu usage(68.53%)>threshold(50.00%)"
    2m14s       Normal    Killing             pod/stress-demo-588f9646cf-s****                       Stopping container stress

    預期輸出為遷移記錄,可以看出結果符合預期。熱點節點上的Pod被重調度到其他節點。

進階配置參數

Koordinator Descheduler模組進階配置參數介紹

Koordinator Descheduler的所有參數配置以ConfigMap形式提供,以下展示了負載熱點打散重調度的進階配置參數格式。

展開查看YAML檔案內容。

# koord-descheduler-config.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: koord-descheduler-config
  namespace: kube-system
data:
  koord-descheduler-config: |
    # 以下為koord-desheduler系統配置,請保持不變。
    apiVersion: descheduler/v1alpha2
    kind: DeschedulerConfiguration
    leaderElection:
      resourceLock: leases
      resourceName: koord-descheduler
      resourceNamespace: kube-system
    deschedulingInterval: 120s # 執行循環間隔,120s執行一次重調度外掛程式。
    dryRun: false # 全域唯讀模式開關,開啟後koord-descheduler整體不做任何操作。
    # 以上為系統配置。

    profiles:
    - name: koord-descheduler
      plugins:
        deschedule:
          disabled:
            - name: "*"
        balance:
          enabled:
            - name: LowNodeLoad # 配置開啟負載熱點打散外掛程式LowNodeLoad。
        evict:
          disabled:
            - name: "*"
          enabled:
            - name: MigrationController # 配置開啟驅逐遷移控制器。

      pluginConfig:
      - name: MigrationController # 重調度遷移控制參數。
        args:
          apiVersion: descheduler/v1alpha2
          kind: MigrationControllerArgs
          defaultJobMode: EvictDirectly
          maxMigratingPerNode: 1 # 每個節點處於遷移狀態的Pod的最大數量。
          maxMigratingPerNamespace: 1  # 每個Namespace處於遷移狀態的Pod的最大數量。
          maxMigratingPerWorkload: 1 # 每個Workload(例如Deployment)中處於遷移狀態的Pod的最大數量。
          maxUnavailablePerWorkload: 2 # 每個Workload(例如Deployment)最大不可用副本數。
          evictLocalStoragePods: false # 是否允許配置了HostPath或EmptyDir的Pod參與重調度
          objectLimiters:
            workload: # Workload層級Pod遷移的流量控制.預設為首次驅逐後,5分鐘內最多遷移1個副本。
              duration: 5m
              maxMigrating: 1

      - name: LowNodeLoad # 負載熱點打散外掛程式配置。
        args:
          apiVersion: descheduler/v1alpha2
          kind: LowNodeLoadArgs

          lowThresholds:  # lowThresholds表示空閑節點的准入水位閾值,判斷條件為“所有資源維度均低於閾值”。
            cpu: 20 # CPU利用率為20%。
            memory: 30  # Memory利用率為30%。
          highThresholds: # highThresholds表示熱點節點的准入水位閾值,判斷條件為“只要有一個資源維度均高於閾值”。
            cpu: 50  # CPU利用率為50%。
            memory: 60 # Memory利用率為60%。

          anomalyCondition: # 熱點節點檢查配置。
            consecutiveAbnormalities: 5 # 連續多個執行循環檢查中,均超過highThresholds的節點,才會被判定為熱點節點。熱點節點被驅逐後會重新計數。

          evictableNamespaces: # 參與重調度的Namespace。include和exclude是互斥的,只能配置其中一種。
            include: # include表示只處理下面配置的Namespace。
              - default
            # exclude: # exclude表示需要排除的Namespace。
              # - "kube-system"
              # - "koordinator-system"

          nodeSelector: # 只處理指定的部分節點。
            matchLabels:
              alibabacloud.com/nodepool-id: np77f520e1108f47559e63809713ce****

          podSelectors: # 只處理部分類型的Pod。
          - name: lsPods
            selector:
              matchLabels:
                koordinator.sh/qosClass: "LS"

Koordinator Descheduler系統配置

參數

類型

取值

說明

樣本值

dryRun

boolean

  • true

  • false(預設值)

唯讀模式開關,開啟後將不會發起Pod遷移。

false

deschedulingInterval

time.Duration

>0s

重調度執行循環。

120s

驅逐遷移控制配置

參數

類型

取值

說明

樣本值

maxMigratingPerNode

int64

≥0(預設值為2)

每個節點處於遷移狀態的Pod的最大數量。0表示不限制。

2

maxMigratingPerNamespace

int64

≥0(預設不限制)

每個命名空間處於遷移狀態的Pod的最大數量。0表示不限制。

1

maxMigratingPerWorkload

intOrString

≥0(預設值為10%)

每個工作負載(例如Deployment)中處於遷移狀態的Pod的最大數量或百分比。0表示不限制。

若工作負載只有單副本,則不參與重調度。

1或10%

maxUnavailablePerWorkload

intOrString

≥0(預設值為10%),且小於工作負載對應的副本總數

每個工作負載(例如Deployment)最大不可用副本數或百分比。0表示不限制。

1或10%

evictLocalStoragePods

boolean

  • true

  • false(預設值)

是否允許配置了HostPath或EmptyDir的Pod參與重調度。出於安全考慮,預設不開啟。

false

objectLimiters.workload

結構體,資料格式為:

type MigrationObjectLimiter struct {
    Duration time.Duration `json:"duration,omitempty"`
    MaxMigrating *intstr.IntOrString `json:"maxMigrating,omitempty"`
}
  • Duration的值大於0秒(預設值5m

  • MaxMigrating的值≥0(預設值為10%)

工作層級Pod遷移的流量控制。

  • Duration:時間視窗長度,例如5m表示5分鐘。

  • MaxMigrating:副本數量或百分比,可設定為整數或百分比(預設值取自maxMigratingPerWorkload的值)。

objectLimiters:
  workload:
    duration: 5m
    maxMigrating: 1

表示5分鐘內單個工作負載最多遷移1個副本。

LowNodeLoad外掛程式配置

參數

類型

取值

說明

樣本值

highThresholds

map[string]float64

說明

支援CPU和記憶體兩個維度,值的單位為百分比。

[0,100]

負載的熱點水位。僅超過該閾值的節點上的Pod會參與重調度,低於該閾值的節點上的Pod不會被重調度。建議您同時開啟調度器的負載感知調度能力,請參見策略說明。關於兩者如何搭配使用,請參見負載感知調度和熱點打散重調度如何搭配使用?

如果所有節點水位均高於 lowThresholds,表明此時叢集整體水位偏高,即便有節點水位大於highThresholdsKoordinator Descheduler也不會執行重調度。

highThresholds:
  cpu: 55 # CPU利用率熱點水位55%。
  memory: 75 # Memory利用率熱點水位75%。

lowThresholds

map[string]float64

說明

支援CPU和記憶體兩個維度,值的單位為百分比。

[0,100]

負載的空閑水位。

如果所有節點水位均高於 lowThresholds,表明此時叢集整體水位偏高,即便有節點水位大於highThresholdsKoordinator Descheduler也不會執行重調度。

lowThresholds:
  cpu: 25 # CPU利用率空閑水位25%。
  memory: 25 # Memory利用率空閑水位25%。

anomalyCondition.consecutiveAbnormalities

int64

>0(預設值為5)

熱點檢查重試次數。連續多個執行循環檢查後,均超過highThresholds的節點,才會被判定為熱點節點。熱點節點發生驅逐後會重新計數。

5

evictableNamespaces

  • include: string

  • exclude: string

叢集內的命名空間

可以參與重調度的Namespace,不填表示所有Pod均可參與。

支援配置includeexclude策略。兩種策略需二選一。

  • include:只處理指定的Namespace。

  • exclude:只處理指定之外的Namespace。

evictableNamespaces:
  exclude:
    - "kube-system"
    - "koordinator-system"

nodeSelector

metav1.LabelSelector

關於LabelSelector的格式,請參見Labels and Selectors

通過LabelSelector選擇目標節點。

分為兩種方式,一種是指定單個節點池時的配置方式,一個是指定多個節點池時的配置方式。

  • 方式一

    # 只處理指定的單個節點池的機器
    nodeSelector:
      matchLabels:
        alibabacloud.com/nodepool-id: np77f520e1108f47559e63809713ce****
  • 方式二

    # 只處理指定的多個節點池的機器
    nodeSelector:
      matchExpressions:
      - key: alibabacloud.com/nodepool-id
        operator: In
        values:
        - node-pool1
        - node-pool2

podSelectors

由PodSelector組成的List,支援配置多組Pod。PodSelector的資料格式為:

type PodSelector struct {
    name     string
    selector metav1.LabelSelector
}

關於LabelSelector的格式,請參見Labels and Selectors

通過LabelSelector選擇開啟重調度的Pod。

# 只處理LS類型的Pod。
podSelectors:
- name: lsPods
  selector:
    matchLabels:
      koordinator.sh/qosClass: "LS"

常見問題

節點利用率閾值已經達到閾值,但是節點上Pod沒有被驅逐怎麼辦?

出現這種情況時,一般可能是有以下幾種原因,請參考對應的解決方案進行調整。

原因分類

原因描述

解決方案

組件配置未生效

開啟範圍未指定

重調度器配置中包含Pod和節點的開啟範圍配置,請檢查對應的命名空間和節點是否開啟。

重調度器配置修改後未重啟

重調度器配置修改後,需要對其進行重啟才會生效。關於重啟重調度器,請參見步驟二:開啟負載熱點打散重調度外掛程式

節點狀態不滿足條件

節點的平均利用率長時間低於閾值

重調度器會持續對利用率監控一段時間,並對監控資料做平滑均值處理,因此只有節點持續超過閾值才會觸發重調度,預設為10分鐘左右。而kubectl top node返回的利用率只是最近1分鐘的情況。請結合重試次數和執行循環配置綜合觀察節點一段時間的利用率情況,並按需調整配置。

叢集內剩餘的容量不足

在對Pod驅逐前,重調度器會對叢集內其他節點進行檢查,確保容量充足才會進行遷移。例如選擇了一個規格為8 Core 16 G的Pod準備驅逐,而叢集所有節點的空閑容量均低於該值,出於安全考慮重調度器則不會對其遷移。請考慮增加節點,確保叢集容量充足。

工作負載屬性約束限制

工作負載為單副本

為了保證單副本應用的高可用,這類Pod預設不參與重調度。如果您評估此類單副本應用後,希望該Pod參與重調度,請給Pod或者工作負載(如Deployment或StatefulSet)的TemplateSpec中追加Annotation descheduler.alpha.kubernetes.io/evict: "true"

說明

該Annotation配置僅支援v1.2.0-ack1.3及更早版本。

Pod指定了HostPath或EmptyDir

出於安全考慮,這類指定了HostPath或EmptyDir的Pod預設不參與重調度。如果需要對其進行遷移,可以參考evictLocalStoragePods配置允許其參與重調度。詳細資料,請參見驅逐遷移控制配置

不可用或遷移中的副本數量過多

當工作負載(如Deployment或StatefulSet)的不可用或遷移中的副本數超過了限制配置(maxUnavailablePerWorkloadmaxMigrationPerWorkload)時,例如,maxUnavailablePerWorkloadmaxMigrationPerWorkload設定為20%,Deployment的期望副本數設定為10,當前正好有2個Pod正在被驅逐或者正在發布,重調度器就不會對其發起驅逐。請等待Pod驅逐或發布完成,或將以上兩個配置調大。

副本數量約束配置錯誤

當工作負載的副本總數小於等於最大遷移數量配置maxMigrationPerWorkload或最大不可用數量配置maxUnavailablePerWorkload時,出於安全考慮重調度器將不會對其進行重調度。請將以上兩個配置調小或修改為百分比模式。

重調度器頻繁重啟是什麼原因?

重調度器的配置ConfigMap格式錯誤或不存在,請參見進階配置參數檢查ConfigMap檔案內容和格式並進行修改,修改後重啟重調度器。重啟重調度器,請參見步驟二:開啟負載熱點打散重調度外掛程式

負載感知調度和熱點打散重調度如何搭配使用?

開啟熱點打散重調度後,負載熱點上的Pod將會被驅逐。對於上層控制器(例如Deployment)建立的Pod,調度器會根據其配置選擇合適的節點進行調度。為了獲得更好的負載平衡效果,建議您同時為調度器開啟負載感知調度能力,請參見使用負載感知調度

配置時,建議您將負載感知調度中的節點篩選功能參數loadAwareThreshold配置為與熱點打散重調度器的highThresholds參數相同的值,具體請參見策略說明。當節點的負載超過highThresholds時,重調度器將驅逐該節點上的Pod,而調度器則通過loadAwareThreshold拒絕新的Pod被調度到該熱點節點上。否則,經驅逐的Pod可能重新被調度到原來的節點,尤其是在Pod指定了節點調度範圍,但對應的節點數量較少且利用率較為接近時。

重調度參考的利用率演算法是什嗎?

重調度器會持續對利用率監控一段時間,並對監控資料做平滑均值處理,因此只有節點持續超過閾值才會觸發重調度,預設為10分鐘左右。此外對於記憶體資源維度,重調度器參考的記憶體用量排除了page cache,因為這部分資源是可以被作業系統回收的,而通過kubectl top node返回的利用率是包含page cache的,您可以通過使用阿里雲Prometheus監控查看真實的記憶體用量資訊。