在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的總體布局,保障應用的高可用性。
策略 | 策略說明 | 適用情境 |
一種較為簡單的定向調度機制,使用標籤(Label)的索引值對對節點進行打標,然後在Pod配置中使用節點選取器(NodeSelector)的方式,將Pod調度至帶有相應Label的節點上。 例如,您可以使用NodeSelector調度應用至指定節點或調度應用至指定節點池。 | 基礎的節點選擇功能,但無法支援更複雜的調度功能,例如軟性調度規則等。 | |
相較於NodeSelector更靈活、更精細的Pod的調度策略。例如,節點親和性(Node Affinity)支援配置硬性調度規則( | 基礎的節點選擇功能。親和性可以根據節點的某些特性(例如地區、機型、硬體設定等)指定Pod應該運行在哪些節點上;反親和性可以指定Pod不應該運行在某些特定節點上,以實現跨節點分散部署,提升應用的可用性。 | |
汙點(Taint)主要由鍵(key)、值(value)和效果(effect)組成,常見的效果包括 | ||
通過Pod標籤來指定Pod應該調度或不被調度到某些節點上。例如,與節點親和性類似, |
|
ACK提供的調度策略
如果Kubernetes原生調度策略無法滿足您更為複雜的業務訴求,例如指定不同執行個體資源的順序擴容及逆序縮容、 基於節點實際資源使用方式的負載感知調度,在離線混部架構下的QoS保障、Pod的重調度及重調度後的負載平衡等,您可以參照下文選擇ACK提供的調度策略。
配置調度資源優先順序
適用角色:叢集營運人員
說明:如果您的ACK叢集中存在不同種類的執行個體資源,例如ECS和ECI,且不同資源有不同的付費類型,例如訂用帳戶、隨用隨付和搶佔執行個體等,推薦您配置調度資源優先順序,指定應用執行個體Pod被調度到不同類型節點資源的順序,並實現逆序縮容。
策略 | 策略說明 | 典型情境 | 參考文檔 |
自訂彈性資源優先順序調度 | 支援在應用發布或擴容過程中自訂 應用縮容時,叢集也會優先刪除ECI上的Pod,釋放ECI的節點資源,然後刪除隨用隨付ECS上的Pod,最後再刪除訂用帳戶ECS上的Pod。 |
|
任務調度
適用角色:叢集營運人員
說明:Kubernetes調度器能夠根據預設的規則決定將Pod放置在哪個節點上運行,但並不適用於批處理任務下Pod的協同調度。在此基礎上,ACK為批次運算的任務支援了Gang Scheduling、Capacity Scheduling能力。
策略 | 策略說明 | 典型情境 | 參考文檔 |
Gang Scheduling | 可在並發系統中將All-or-Nothing作業中多個相關聯的進程調度到不同處理器上同時運行,即相關Pod要麼全部被調度,要麼都不被調度,防止因部分進程的異常而導致整個關聯進程組阻塞的問題。 |
| |
Capacity Scheduling | 允許叢集為特定的命名空間或使用者組預留一定的資源容量,並在叢集資源緊張時,通過資源共用的方式來提升整體資源的利用率。 | 多租戶情境下,不同租戶使用資源的周期和方式不同,造成叢集的整體資源使用率較低,期望在固定資源分派的基礎上允許資源的借用和回收。 |
親和性調度
適用角色:叢集營運人員
說明:您可以基於Kubernetes原生調度策略將工作負載調度至指定的執行個體資源上,例如FPGA節點、Arm節點等。在此基礎上,ACK叢集還進一步豐富了調度能力,讓Pod可以在多個不同的拓撲域上重試,直至找到一個能夠滿足整個作業的拓撲域。
策略 | 策略說明 | 典型情境 | 參考文檔 |
拓撲感知調度 | 調度器為作業添加Gang調度標識,限制Pod必須同時獲得所需的資源,並結合拓撲感知調度能力實現Pod,直到找到一個能夠滿足整個作業拓撲域的功能。 您還可以使用節點池的部署集能力,將Pod調度到屬於同一低延時部署集的ECS執行個體中,進一步提高作業效能。 | 機器學習或巨量資料分析類作業中,Pod與Pod間通常有較大的網路通訊需求。期望能讓作業在多個拓撲域上重試,直至找到能夠提供足夠資源的拓撲域,減少作業的執行時間。 | |
調度工作負載至FPGA節點 | 通過 | 異構計算情境下,為了有效利用FPGA裝置,期望將工作負載調度到具有FPGA裝置的節點上。 | |
調度工作負載至Arm節點 | ACK叢集預設會將所有工作負載調度到x86架構的Worker節點。您可以通過 | 叢集中既有Arm節點,又有非Arm節點(例如x86節點),期望只相容Arm架構的工作負載能夠調度到Arm節點,多架構鏡像優先調度到Arm節點。 |
負載感知調度
適用角色:叢集營運人員、應用開發人員
說明:Kubernetes原生調度策略下,調度器主要基於資源的分配情況進行調度,即通過檢查Pod的資源Requests與節點上尚未被分配的資源來確定是否應該在此節點上運行該Pod。但節點的利用率會隨著時間、叢集環境、工作負載的流量或請求等動態變化,Kubernetes調度器並不能感知節點實際的資源負載情況。
策略 | 策略說明 | 典型情境 | 參考文檔 |
負載感知調度 | 通過參考節點負載的歷史統計並對新調度Pod進行預估,ACK調度器可以感知節點真實使用的資源量,將Pod優先調度到負載較低的節點,實現節點負載平衡的目標,避免出現因單個節點負載過高而導致的應用程式或節點故障。 | 對請求壓力或訪問延遲等指標有明確的要求、對資源品質較為敏感的延時敏感型應用。 |
推薦您搭配使用負載熱點打散重調度功能使用,防止Pod調度完成後叢集再次出現負載極不均衡的情況。
QoS感知調度
適用角色:叢集營運人員、應用開發人員
說明:您可以為Pod配置特定的QoS(Quality of Service)類,包括Guaranteed、Burstable、BestEffort。在節點資源不足時,kubelet可以根據Pod的QoS類決定驅逐的順序。針對不同QoS類的應用,ACK提供差異化的SLO(Service Level Objectives)功能,以提升延遲敏感型應用的效能表現和服務品質,同時儘可能保證低優任務的資源使用。
策略 | 策略說明 | 典型情境 | 參考文檔 |
CPU Burst | 受CPU Limit機制的約束,作業系統會按照一定的時間周期約束資源使用,導致容器可能遭遇資源分派的限流,即CPU Throttled。CPU Burst功能可以讓容器在空閑時積累一些CPU時間片,用於滿足突發時的資源需求,以提升容器效能、降低延遲指標,進而提升應用的服務品質。 |
| |
CPU拓撲感知調度 | 針對效能敏感型應用,將Pod固定在節點上的CPU核心運行,緩解因CPU環境切換、跨NUMA訪存導致的應用效能下降問題。 |
| |
GPU拓撲感知調度 | 叢集中同時部署了多張GPU卡時,多個GPU密集型工作負載的Pod同時運行時,Pod之間可能會爭搶節點的GPU資源,導致Pod在不同的GPU之間(甚至是NUMA Node之間)頻繁地切換,影響程式效能。GPU拓撲感知調度能夠將工作負載適當地分配到不同GPU卡上,減少跨越NUMA節點的記憶體訪問,提升應用效能和響應速度。 |
| |
動態資源超賣 | 將叢集中已指派但未使用的資源量化並提供給低優先順序任務使用,以實現對叢集資源的超賣。需要結合以下單機QoS策略使用,以避免應用間的效能幹擾。
| 需要通過混部的方式提升叢集資源使用率。典型的在離線混部的情境包括機器學習訓練和推理、巨量資料批次工作和資料分析、線上服務和離線備份服務等。 | |
動態修改Pod資源參數 | 在Kubernetes 1.27及更早版本中,如需在Pod運行中臨時修改容器參數,只能更新PodSpec後重新提交,這種方式會觸發Pod刪除重建。ACK支援在不重啟Pod的情況下,修改CPU、記憶體、磁碟IO等單機隔離參數。 | 僅適用於Pod資源(CPU、記憶體資源)的臨時性調整。 |
重調度
適用角色:叢集營運人員、應用開發人員
說明:Kubernetes調度器會根據當前的叢集狀態決定如何將一個Pod調度到合適的節點上。但叢集的狀態會不斷變化,出於某些原因,您可能需要將運行中的Pod移動到其他節點,即將Pod重調度到其他節點。
策略 | 策略說明 | 典型情境 | 參考文檔 |
重調度 | 在叢集利用率不均而產生熱點節點、節點屬性變化導致存量Pod調度規則不匹配等情境下,您可能需要將部署在某個節點上調度不合理的Pod重新調度到另一個節點,確保Pod在最佳節點上運行,從而保障叢集的高可用性和工作負載的高效運行。 |
| |
負載熱點打散重調度 | 將負載感知調度和熱點打散重調度結合使用,不僅能夠即時感知叢集內節點負載的變化,還能自動最佳化超過負載水位安全閾值的節點,防止出現負載極端不均衡的情況。 |
相關計費
使用ACK提供的調度功能時,除涉及的叢集管理費用、相關雲產品資源產生的計費外,調度組件還會產生如下費用。
ACK預設調度器由kube-scheduler組件提供,為控制面組件,安裝和使用均為免費。
ACK的資源調度最佳化能力和重調度能力基於ack-koordinator組件實現。ack-koordinator組件本身的安裝和使用是免費的,但在部分情境中可能產生額外的費用。更多資訊,請參見ack-koordinator(ack-slo-manager)。
常見問題
如果您在使用調度功能時遇到問題,可參見調度FAQ進行排查。
相關文檔
關於調度組件kube-scheduler、ack-koordinator的介紹和變更記錄,請參見kube-scheduler、ack-koordinator(ack-slo-manager)。
如需自訂kube-scheduler的行為,使得Pod的調度更符合期望,請參見使用調度器自訂參數。
調度情境下的最佳實務,例如在離線混部技術架構下如何保障服務品質、實現穩定的資源超賣等,請參見調度功能最佳實務。
您可以搭配啟用成本洞察功能,瞭解叢集資源使用量及成本分布,擷取成本節約建議,從而提升叢集資源使用率。更多資訊,請參見成本洞察概述。
如需實現GPU的共用調度、顯存隔離等能力,請參見共用GPU調度概述。
關於虛擬節點的調度方案,請參見虛擬節點調度方案對比及介紹。