ACK叢集支援的調度Scheduling, 策略 - Container Service for Kubernetes

在Kubernetes叢集中，調度（Scheduling）指調度器組件（kube-scheduler）根據資源規劃將Pod分配到最合適的節點上，以實現應用高可用、提高叢集資源使用率等。ACK針對不同工作負載提供了更靈活、更豐富的調度策略，包括任務調度、拓撲感知調度、QoS感知調度、重調度等。

閱讀前提示

本文面向叢集營運人員（包括叢集資源管理員）和應用開發人員提供叢集調度方案。您可以根據您的業務情境和角色選擇合適的調度策略。
- 叢集營運人員：關注叢集成本和資源極大化利用，並確保叢集高可用性和節點間的負載平衡，避免單點故障。
- 應用開發人員：希望簡便地部署和管理應用，並根據效能要求擷取所需資源（如CPU、GPU、記憶體）。
為了更好地使用ACK提供的調度策略，建議您在使用前參見Kubernetes官方文檔瞭解調度器（Scheduler）、節點標籤（Label）、驅逐（Evict）、拓撲分布約束（Topology Spread Constraints）等基本概念。
此外，ACK Scheduler的預設調度策略與社區Kubernetes調度器保持一致，包括Filter（過濾）和Score（評分）兩個環節。

Kubernetes原生調度策略

Kubernetes原生的調度策略可以分為節點調度策略和Pod間（Inter-Pod）調度策略。

節點調度策略：聚焦於節點的特性和資源情況，讓Pod能夠被調度到符合其需求的節點上。
Pod間調度策略：聚焦於如何控制Pod之間的分布和定位，以最佳化Pod的總體布局，保障應用的高可用性。

策略	策略說明	適用情境
nodeSelector	使用標籤（Label）的索引值對對節點進行打標，然後在Pod配置中通過節點選取器（NodeSelector）將Pod調度至帶有相應Label的節點上。例如，可使用NodeSelector調度應用至指定節點或調度應用至指定節點池。	基礎的節點選擇功能，但無法支援更複雜的調度功能，例如軟性調度規則等。
nodeAffinity	相較於NodeSelector更靈活、更精細的Pod的調度策略，支援配置硬性調度規則（`requiredDuringSchedulingIgnoredDuringExecution`）和軟性的調度規則（`preferredDuringSchedulingIgnoredDuringExecution`）。	可根據節點特性（例如地區、機型、硬體設定等）指定Pod運行位置；反親和性可實現跨節點分散部署。
汙點和容忍	汙點（Taint）主要由鍵（key）、值（value）和效果（effect）組成，常見的效果包括`NoSchedule`、`PreferNoSchedule`和`NoExecute`。節點打上汙點後，只有聲明了與節點汙點匹配的容忍（Tolerations）的Pod才允許調度到此節點上。	為特定應用保留專用節點資源，例如為AI/ML工作負載預留GPU節點。 ACK還支援為節點池添加汙點或標籤，使得某些應用可以調度到指定節點池，請參見建立和管理節點池。基於汙點和容忍的Pod驅逐，例如為不健康的節點添加`NoExecute`的汙點。
podAffinity和podAntiAffinity	通過Pod標籤指定Pod是否應該被調度到某些節點上，支援配置硬性調度規則（`requiredDuringSchedulingIgnoredDuringExecution`）和軟性調度規則（`preferredDuringSchedulingIgnoredDuringExecution`）。	讓協同Pod調度到相同或臨近的節點，從而減少網路延遲、提高通訊效率。將關鍵應用分散在不同節點或故障域上。

ACK提供的調度策略

如果Kubernetes原生調度策略無法滿足您更為複雜的業務需求，例如指定不同執行個體資源的順序擴容及逆序縮容、基於節點實際資源使用方式的負載感知調度等，您可以參照下文選擇ACK提供的調度策略。

配置調度資源優先順序

適用角色：叢集營運人員
說明：如果叢集中存在不同種類的執行個體資源，例如ECS和ECI，且付費類型不同（訂用帳戶、隨用隨付和搶佔執行個體等），推薦配置調度資源優先順序，指定應用執行個體Pod被調度到不同類型節點資源的順序，並實現逆序縮容。

策略

策略說明

典型情境

參考文檔

自訂彈性資源優先順序調度

支援在應用發布或擴容過程中自訂ResourcePolicy，設定應用Pod被調度到不同類型節點資源的順序，例如先調度到訂用帳戶ECS，再調度到隨用隨付ECS，最後調度到ECI。

應用縮容時也支援逆序縮容，例如優先刪除ECI Pod，然後刪除隨用隨付ECS上的Pod，最後再刪除訂用帳戶ECS上的Pod。

指定優先使用或避免使用的節點，平衡叢集中節點的資源使用率。
應用對節點效能要求高時，優先讓應用Pod調度到較高效能的節點上。
應用對節點效能要求不高時，優先讓應用Pod調度到搶佔式執行個體或有剩餘計算資源的節點，降低資源使用成本。

自訂彈性資源優先順序調度

任務調度

適用角色：叢集營運人員
說明：調度器能夠根據預設的規則決定將Pod放置在哪個節點上運行，但並不適用於批處理任務下Pod的協同調度。在此基礎上，ACK為批次運算任務支援了Gang Scheduling、Capacity Scheduling能力。

策略	策略說明	典型情境	參考文檔
Gang Scheduling	相關Pod要麼全部被調度，要麼都不被調度，防止因部分進程的異常而導致整個關聯進程組阻塞的問題。	批次工作：作業中有多個相互依賴的工作群組，需要同時處理。分散式運算：例如機器學習訓練任務或其他需要嚴格協調啟動並執行分布式應用。高效能運算：作業可能需要整套的資源同時可用才能開始執行。	使用Gang scheduling
Capacity Scheduling	為特定的命名空間或使用者組預留一定的資源容量，並在叢集資源緊張時，通過資源共用提升整體資源使用率。	多租戶情境下，不同租戶使用資源的周期和方式不同，造成叢集的整體資源使用率較低，期望在固定資源分派的基礎上允許資源的借用和回收。	使用Capacity Scheduling

拓撲感知調度

適用角色：叢集營運人員
說明：在機器學習和巨量資料分析類作業中，Pod間通常有較大的網路通訊需求。預設情況下，調度器會將Pod均勻打散在叢集中，導致作業時間變長。原生的節點或Pod親和調度方式無法在多個不同的拓撲域上進行重試，且節點上僅有可用性區域層級的標籤。

策略說明

典型情境

參考文檔

調度器為作業添加Gang調度標識，限制Pod必須同時獲得所需的資源，並結合拓撲感知調度能力實現Pod，直到找到一個能夠滿足整個作業拓撲域的功能。

您還可以使用節點池的部署集能力，將Pod調度到屬於同一低延時部署集的ECS執行個體中，進一步提高作業效能。

機器學習或巨量資料分析類作業中，Pod與Pod間通常有較大的網路通訊需求。期望能讓作業在多個拓撲域上重試，直至找到能夠提供足夠資源的拓撲域，減少作業的執行時間。

負載感知調度

適用角色：叢集營運人員、應用開發人員
說明：原生調度策略下，調度器主要基於資源的分配情況進行調度，即通過檢查Pod的資源Requests與節點上尚未被分配的資源來決定Pod的調度。但節點的利用率會隨著時間、叢集環境、工作負載的流量或請求等動態變化，原生調度器並不能感知節點實際的資源負載情況。

策略說明	典型情境	參考文檔
通過參考節點負載的歷史統計並對新調度Pod進行預估，ACK調度器可以感知節點真實使用的資源量，將Pod優先調度到負載較低的節點，實現節點負載平衡的目標，避免出現因單個節點負載過高而導致的應用程式或節點故障。	對請求壓力或訪問延遲等指標有明確的要求、對資源品質較為敏感的延時敏感型應用。	使用負載感知調度

推薦搭配使用負載熱點打散重調度使用，防止Pod調度完成後叢集再次出現負載極不均衡的情況。

QoS感知調度

適用角色：叢集營運人員、應用開發人員
說明：為Pod配置特定的QoS（Quality of Service）類，包括Guaranteed、Burstable、BestEffort。節點資源不足時，kubelet可以根據QoS類決定Pod的驅逐順序。ACK提供差異化的SLO（Service Level Objectives）功能，以提升延遲敏感型應用的效能表現和服務品質，同時儘可能保證低優任務的資源使用。

策略	策略說明	典型情境	參考文檔
CPU Burst	受CPU Limit機制的約束，作業系統會按照一定的時間周期約束資源使用，導致容器可能遭遇資源分派的限流，即CPU Throttled。CPU Burst功能可以讓容器在空閑時積累一些CPU時間片，用於滿足突發時的資源需求，以提升容器效能、降低延遲指標，進而提升應用的服務品質。	容器應用在啟動載入階段CPU資源消耗較高，但在載入完成後的日常狀態下其CPU用量相對正常的情境。 CPU資源需求可能會突然增長，需要快速應對突增的業務流量，例如電商、線上遊戲等Web服務和應用。	啟用CPU Burst效能最佳化策略
CPU拓撲感知調度	針對效能敏感型應用，將Pod固定在節點上的CPU核心運行，緩解因CPU環境切換、跨NUMA訪存導致的應用效能下降問題。	應用尚未完成對雲原生情境的適配，例如在設定線程數量時未考慮容器規格（而是整機物理核心數量），導致應用出現效能下降問題。應用運行在神龍裸金屬（Intel、AMD）等多核機器上，且出現大量因跨NUMA訪存帶來的應用效能下降問題。應用對CPU環境切換十分敏感，無法承受因此帶來的效能抖動。	啟用CPU拓撲感知調度
GPU拓撲感知調度	叢集中同時部署了多張GPU卡時，多個GPU密集型工作負載的Pod同時運行時，Pod之間可能會爭搶節點的GPU資源，導致Pod在不同的GPU之間（甚至是NUMA Node之間）頻繁地切換，影響程式效能。GPU拓撲感知調度能夠將工作負載適當地分配到不同GPU卡上，減少跨越NUMA節點的記憶體訪問，提升應用效能和響應速度。	需要在大規模分散式運算中實現高效的資料轉送和處理，例如高效能運算。機器學習和深度學習，需要大量GPU資源進行學習和訓練，併合理將訓練任務分配到各個 GPU。圖形渲染和遊戲開發，需要合理地分配渲染任務至不同的GPU。	GPU拓撲感知調度啟用NUMA拓撲感知調度
動態資源超賣	將叢集中已指派但未使用的資源量化並提供給低優先順序任務使用，以實現對叢集資源的超賣。需要結合以下單機QoS策略使用，以避免應用間的效能幹擾。彈性資源限制：在整機資源用量安全水位下，控制低優先順序Pod可使用的CPU資源量，保障節點內容器穩定運行。容器CPU QoS：基於容器的QoS等級，優先保障高優先順序應用的CPU效能。容器記憶體QoS：基於容器的QoS等級，優先保障高優先順序應用Pod的記憶體效能，延遲其觸發整機記憶體回收的時間。容器L3 Cache及記憶體頻寬隔離：基於容器的QoS等級，優先保障高優先順序應用L3 cache和MBA記憶體頻寬等資源的使用。	需要通過混部的方式提升叢集資源使用率。典型的在離線混部的情境包括機器學習訓練和推理、巨量資料批次工作和資料分析、線上服務和離線備份服務等。	啟用動態資源超賣啟用CPU資源彈性限制式能力啟用容器CPU QoS 啟用容器記憶體QoS 啟用容器L3 Cache及記憶體頻寬隔離在離線混部最佳實務
動態修改Pod資源參數	在Kubernetes 1.27及更早版本中，如需在Pod運行中臨時修改容器參數，只能更新PodSpec後重新提交，這種方式會觸發Pod刪除重建。ACK支援在不重啟Pod的情況下，修改CPU、記憶體、磁碟IO等單機隔離參數。	僅適用於Pod資源（CPU、記憶體資源）的臨時性調整。	動態修改Pod的資源參數

重調度

適用角色：叢集營運人員、應用開發人員
說明：叢集的狀態會不斷變化，出於某些原因，您可能需要將運行中的Pod移動到其他節點，即將Pod重調度到其他節點。

策略	策略說明	典型情境	參考文檔
重調度	在叢集利用率不均而產生熱點節點、節點屬性變化導致存量Pod調度規則不匹配等情境下，您可能需要將部署在某個節點上調度不合理的Pod重新調度到另一個節點，確保Pod在最佳節點上運行，從而保障叢集的高可用性和工作負載的高效運行。	叢集的工作負載分布不均，造成某些節點過載，例如在離線混部情境下不同應用被調度到同一節點上。叢集的總體資源使用率較低，期望下線部分節點以節約成本。叢集存在大量資源片段，導致叢集資源總量充足，但單節點上資源不足。節點新增或移除了汙點或標籤。	重調度啟用重調度功能
負載熱點打散重調度	將負載感知調度和熱點打散重調度結合使用，不僅能夠即時感知叢集內節點負載的變化，還能自動最佳化超過負載水位安全閾值的節點，防止出現負載極端不均衡的情況。		使用負載熱點打散重調度

常見問題

如果您在使用調度功能時遇到問題，可參見調度FAQ進行排查。

Container Service for Kubernetes：調度概述