ACK叢集節點伸縮概述 - Container Service for Kubernetes

當叢集的容量規劃無法滿足應用Pod調度時，您可以使用ACK提供的節點伸縮功能，自動擴縮節點資源以進行調度容量的補充。ACK目前提供節點自動調整與節點即時彈性兩種彈性方案，後者相較於前者有著更快的彈性速度、更高的交付效率和更低的使用門檻。

閱讀前提示

為了讓您更好地瞭解ACK提供的節點伸縮方案，並結合您的業務訴求進行方案選型，建議您在啟用節點伸縮能力前閱讀本篇概述。

閱讀本文前，推薦您參見Kubernetes官方文檔瞭解手動伸縮、自動調整、水平伸縮、垂直伸縮等伸縮概念。

工作原理

在Kubernetes中，節點伸縮的工作原理與傳統意義上基於使用率閾值的模型有所差別。這也是從傳統IDC或其他編排系統遷移到Kubernetes叢集後往往需要解決的問題。

傳統的Auto Scaling模型基於使用率實現。例如，一個叢集中有3個節點，當叢集中的節點CPU、記憶體使用量率超過特定的閾值時，系統將擴容新的節點。但這種模式存在以下問題。

閾值是如何選擇與判斷的？

在一個叢集中，部分熱點節點的利用率可能較高，而其他節點的利用率可能較低。

如果根據整個叢集的平均資源使用率來決定是否Auto Scaling，使得熱點節點的差異被平均，那麼會造成對熱點節點的擴縮不夠及時。
如果依據最高的節點利用率來決定是否Auto Scaling，那麼會造成彈出資源的浪費，影響叢集的整體服務。

彈出執行個體後如何緩解壓力？

在Kubernetes叢集中，應用以Pod為最小單元部署在叢集的不同節點上。當一個Pod資源使用率較高時，即使該Pod所在的節點或者叢集觸發了彈性擴容，但該應用的Pod數量以及Pod對應的Limit並沒有發生變化，節點負載的壓力也無法轉移到新擴容的節點上。

如何判斷以及執行執行個體的縮容？

如果基於資源使用率的方式判斷節點是否縮容，那麼很有可能出現Request（資源請求）較大、但Usage（實際資源使用）很小的Pod被驅逐。當叢集中這種類型的Pod較多時，會佔用叢集大量的調度資源，導致部分Pod無法調度。

基於以上問題，ACK通過節點伸縮（資源層）和工作負載伸縮（調度層）兩層彈性模型來解決。節點伸縮基於資源的使用率來觸發應用副本的變化，也就是調度單元的變化。以下介紹技術細節。

如何判斷節點的彈出？

節點伸縮會監聽Pod是否處於調度失敗的狀態，以判斷是否需要觸發擴容。當Pod由於調度資源不足而調度失敗時，節點伸縮會開始類比調度，計算在開啟彈性的節點池中哪個節點池可為這些Pod提供所需的節點資源，並在滿足需求時彈出相應的節點。

說明

類比調度時將一個開啟彈性的節點池作為一個的抽象節點，開啟彈性的節點池中配置的機型規格對應會成為抽象節點的CPU、記憶體或GPU的容量，且其配置的Label、Taint也會成為抽象節點的Label與Taint。類比調度器會在調度類比時，將該抽象節點納入調度參考範圍。符合調度條件時，調度模擬器會計算所需的節點數目，驅動節點池彈出節點。

如何判斷節點的縮容？

節點伸縮僅縮容開啟了彈性的節點池中的節點，無法管理靜態節點（不在開啟了彈性的節點池中的其他節點）。每個節點會單獨判斷是否進行縮容。當任意一個節點的調度利用率低於所設定的調度閾值時，就會觸發縮容判斷。此時，節點伸縮會嘗試類比驅逐節點上的負載，判斷當前節點是否可以排水。部分特殊的Pod（例如kube-system命名空間的非DaemonSet Pod、PDB控制的Pod等）則會跳過該節點而選擇其他的候選節點。當節點發生驅逐時，會先進行排水，將節點上的Pod驅逐到其他的節點，然後再下線該節點。

多個開啟彈性的節點池之間如何選擇？

不同開啟彈性的節點池之間，實際上相當於不同的抽象節點之間的選擇。和調度策略一樣，開啟彈性的節點池之間也存在打分機制。彈性組件首先篩選符合調度策略的節點，然後進一步根據affinity等親和性策略進行選擇。

如果基於上述策略無法選擇合適的節點，預設情況下節點自動調整會通過least-waste的策略進行選擇。least-waste策略的核心是類比彈出節點後，找到剩餘資源最少的節點。

說明

當有一個開啟彈性的GPU節點池和開啟彈性的CPU節點池同時可以彈出生效時，預設CPU會優先於GPU彈出。

而預設情況下，節點即時彈性會通過比較庫存和成本進行選擇，以在多個可行的擴容方案中選擇庫存保障較高且成本較低的方案。

如何提高Auto Scaling的成功率？

Auto Scaling的成功率主要取決於以下兩個因素：

調度策略是否滿足
配置開啟彈性的節點池後，您需要先確認該節點池可以承載的Pod的調度策略範圍。如果無法直接判斷，您可以通過nodeSelector直接選擇節點池的Label，來進行預彈類比。
資源配置是否充分
當類比調度通過後，系統會選擇開啟彈性的節點池，以彈出執行個體。但開啟彈性的節點池中配置的ECS規格庫存會直接影響是否可以成功彈出執行個體。因此，推薦您配置多個可用性區域、多個不同機型組合，以提高彈出成功率。

如何提高Auto Scaling的速度？

方法一：使用極速模式加速彈出速度。當開啟彈性的節點池預熱後（已完成一次擴容和一次縮容），節點池即可進入極速伸縮模式。更多資訊，請參見啟用節點自動調整。
方法二：使用自訂鏡像的方式，以Alibaba Cloud Linux 3作為基礎鏡像，大大提升IaaS層的資源交付速度（50%）。更多資訊，請參見彈性最佳化之自訂鏡像。

彈性方案：節點自動調整與節點即時彈性

節點伸縮指資源層彈性，即當叢集的容量規劃無法滿足應用Pod調度時，自動擴縮節點資源，以進行調度容量的補充。ACK在節點伸縮層面提供兩種彈性方案。

方案介紹

重要

本文中提供的彈性測量資料為理論值，均基於彈性最佳化的自訂鏡像實現，實際資料以您的實際業務環境為準。關於自訂鏡像的更多資訊，請參見彈性最佳化之自訂鏡像。
節點即時彈性需要白名單許可權開啟。如需使用，請提交工單並描述您的業務情境進行申請。

方案	實現組件	說明
方案一：節點自動調整	cluster-autoscaler組件	以輪詢的方式，周期性地維護和檢查叢集狀態，以發現滿足擴縮容條件的情況，從而自動擴縮容叢集節點。
方案二：節點即時彈性	節點即時彈性組件	一個基於事件驅動的節點伸縮控制器。在大規模叢集（例如彈性節點池中節點數大於100，或彈性節點池數大於20）和連續多次彈性擴容等情境下，能夠保證更好的彈性資源交付。伸縮速度（即從Pod首次調度失敗到Pod調度成功的耗時）穩定在45s、成功率可達99%、資源片段度降低約30%。同時，在擴縮容自訂策略上有更好的擴充性。

方案對比

如果您的叢集節點池已開啟自動Auto Scaling且節點池的伸縮模式為非極速模式，節點即時彈性可相容原彈性節點池的語義與行為，並支援所有類型的應用無感開啟與使用。所以，本小節重點闡述節點即時彈性相較於節點自動調整的最佳化特性。

最佳化特性	節點自動調整	節點即時彈性
伸縮速度與效率	單次伸縮時，標準模式的伸縮速度約為60s，極速模式為50s。	通過事件驅動的機制來觸發擴縮行為，結合阿里雲的ContainerOS能力進行彈性加速，伸縮速度大約為45±10s。
	當達到1分鐘的伸縮量級時，伸縮速度會遇到瓶頸，並且在不同規模（多節點池）、不同情境（連續伸縮）下，彈性速度也會有比較明顯的抖動。例如，當節點池數量超過100時，伸縮速度將衰減為100～150s。	不會隨著節點池的規模與Pod的規模的增大而產生明顯的衰減，更適用於對彈性交付速度高的情境。
	使用輪詢式模型，且受制於對叢集狀態維護的依賴，彈性靈敏度最低為5s。	基於事件驅動，使用響應式模型，彈性靈敏度為1～3s。
資源交付確定性	雲上資源的庫存變化較為頻繁。由於執行個體規格組合問題、庫存不足等原因，節點自動調整的彈性成功率在97%左右。	支援庫存自動選擇策略，可根據您配置的篩選條件與順序，從阿里雲上千個執行個體規格組合中過濾無庫存的執行個體規格，並選擇最為合適的規格進行擴容，或在庫存不足時補償合格規格。這大大降低了營運人員選擇規格的壓力，同時提升了交付的成功率，可達99%。
	支援按照節點池配置的規格擴容相同類型的規格。在類型不同時，會選擇最小的規格進行擴容。	支援擴容不同類型的規格。
	資源交付失敗時，會進行周期性重試，手段較為滯後。	資源交付失敗時，支援庫存預警能力，提前通知規格組合的潛在風險。
使用及營運門檻	相較於節點自動調整，節點即時彈性的使用門檻更低。主要體現在以下方面。節點池配置維護：節點即時彈性能夠根據執行個體屬性在多規格和多可用性區域中自動選擇執行個體，容納等待調度的Pod。但在節點自動調整模式下，您需要自我維護節點池各項配置，以保證Pod的正常調度。因此，當Pods配置發生變更時，往往意味著對應節點池配置也需要更新。節點營運：對於開發人員來說，在擴縮容過程中，相關異常都可以通過Pod事件同步，他們只需管理Pod的生命週期。功能拓展：支援擴充機制，例如結合Descheduler準備彈性資源。節點即時彈性支援無侵入式地將資源供給策略、節點生命週期管理與您的自訂行為進行聯動，提供更多二次開發的可能性。
調度策略	除支援節點自動調整所有的調度特性之外，節點即時彈性還支援以下特性： Topology：常用於滿足跨可用性區域維度高可用需求。 Pod Disruption Budgets：可限制在同一時間因自願幹擾導致的多副本應用中發生宕機的Pod數量。
調度策略	節點即時彈性支援根據Pod選擇最優裝箱策略（Bin Packing）和預綁定（PreBind）策略（自訂特性），可將調度片段率最佳化30%。

節點即時彈性的使用限制

在評估節點即時彈性方案時，您需要同時瞭解節點即時彈性的使用限制。

不支援極速模式
一個節點池單批擴容節點的個數不可超過180個
不支援以下自訂參數
- 禁止縮容
- 自訂GPU縮容閾值
- 自訂擴容策略

方案選型建議

參見前文的方案對比與節點即時彈性的使用限制，如果您的業務對彈性速度、資源交付確定性和使用及營運成本要求相對較低，且無法容忍節點即時彈性的使用限制時，節點自動調整可能能夠滿足您的業務需求。但如果您有以下業務訴求，我們更推薦您使用節點即時彈性。

叢集規模較大，例如彈性節點池中節點數大於100，或彈性節點池數大於20叢集規模變大時，節點自動調整的擴容效率會明顯衰減，而節點即時彈性的效能波動較小。
對資源交付速度，即彈性速度，有更高要求。單次伸縮情境下，標準模式下的節點自動調整的彈性速度為60s左右，而節點即時彈性為45s左右。
業務負載批次不可控，對同一個彈性節點池通常有連續擴容的需求。連續伸縮模式下，節點自動調整的效能會衰減且抖動較為明顯，而節點即時彈性仍然能實現45s左右的伸縮速度。

注意事項

配額與限制

在專用網路下建立的單個路由表可建立的自訂路由數限額是200條。如需更大的配額，請前往配額中心提交申請。關於其他資源的配額限制及升配詳情，請參見依賴底層雲產品配額限制。
請合理配置開啟自動調整的節點池的最大執行個體數，保證此範圍內的節點所依賴的資源和配額充足，例如合理規劃VPC網段、交換器等網路資源，以避免節點擴容失敗。配置開啟自動調整的節點池的最大執行個體數，請參見配置執行個體數量。關於ACK的網路規劃，請參見Kubernetes叢集網路規劃。
節點伸縮功能不支援訂用帳戶付費類型的節點。如需建立開啟自動調整的節點池，請勿選擇付費類型為訂用帳戶。如需為已有節點池開啟自動調整，請確保節點池內沒有訂用帳戶付費類型的節點。

依賴資源的維護

選擇綁定EIP時，請勿通過ECS控制台直接刪除節點伸縮擴容出的ECS節點，否則會導致EIP無法自動釋放。

後續閱讀

根據前文的方案介紹和差異對比，您可以選擇啟用節點自動調整、啟用節點即時彈性。
如在使用節點伸縮過程中遇到問題，您可以參見Auto ScalingFAQ進行自排查。