摘要：本文結合Karmada社群對大規模場景的思考，揭示Karmada穩定支援100個大規模叢集、管理超過50萬個節點和200萬個Pod背後的原理
本文分享自華為雲社群《Karmada百倍叢集規模多雲基礎設施體系揭秘》，作者： 雲容器大未來 。
隨著雲原生技術在越來越多的企業和組織中的大規模落地，如何高效、可靠地管理大規模資源池以應對不斷增長的業務挑戰成為了當下雲原生技術的關鍵挑戰。
在過去的很長一段時間內，不同廠商嘗試透過擴充套件單叢集的規模來擴充套件資源池。然而，Kubernetes社群很早就釋出了大規模叢集的最佳實踐，其中包括幾項關鍵資料：節點數不超過5k，Pod數不超過150k，單個節點的Pod數量不超過110 k等。這側面說明了支援超大規模的叢集不是Kubernetes社群主要努力的方向。同時，以單叢集的方式擴充套件資源池通常需要定製Kubernetes的原生元件，這在增加了架構複雜度的同時也帶來了不少弊端：
（1）叢集運維複雜度急劇增加。
（2）與社群演進方向相左，後續的維護成本上升，升級路徑不清晰。
（3）單叢集本質上屬於單個故障域，叢集故障時將導致無法控制爆炸半徑。
而多叢集技術能在不侵入修改Kubernetes單叢集的基礎上橫向擴充套件資源池的規模，在擴充套件資源池的同時降低了企業的運維管理等成本。此外，多叢集系統天然支援多故障域，符合多數業務場景，如多地資料中心、CDN就近提供服務等。
Karmada作為CNCF首個多雲容器編排專案，提供了包括Kubernetes原生API支援、多層級高可用部署、多叢集故障遷移、多叢集應用自動伸縮、多叢集服務發現等關鍵特性，致力於讓使用者輕鬆管理無限可伸縮的資源池，為企業提供從單叢集到多雲架構的平滑演進方案。
隨著以Karmada為代表的多叢集架構在企業的逐步落地，大規模場景下多叢集系統的效能問題往往是使用者的核心關注點之一。本文將圍繞以下幾個問題，結合Karmada社群對大規模場景的思考，揭示Karmada穩定支援100個大規模叢集、管理超過50萬個節點和200萬個Pod背後的原理。
（1） 如何衡量一個多叢集系統資源池的維度與閾值？
（2） 對多叢集系統進行大規模環境的壓測時，我們需要觀測哪些指標？
（3） Karmada是如何支撐100個大規模K8s叢集並納管海量應用的？
（4） 在Karmada的生產落地過程中，有哪些最佳實踐和引數最佳化手段可以參考？
多叢集系統資源池的維度與閾值
當前，業界對於多雲資源池的Scalability尚未達成統一標準，為此，Karmada社群結合企業使用者的實踐，率先對這一問題進行了深入探索。一個多叢集系統資源池規模不單指叢集數量，實際上它包含很多維度的測量標準，在不考慮其他維度的情況下只考慮叢集數量是毫無意義的。在若干因素中，社群按照優先順序將其描述為以下三個維度：
（1） 叢集數量。叢集數量是衡量一個多叢集系統資源池規模和承載能力最直接且最重要的維度。
（2） 資源（API物件）數量。對於多叢集系統的控制面來說，儲存並不是無限的，在控制面建立的資源物件的數量和總體大小受限於系統控制面的儲存，也是制約多叢集系統資源池規模的重要維度。這裡的資源物件不僅指下發到成員叢集的資源模板，而且還包括叢集的排程策略、多叢集服務等資源。
（3） 叢集規模。叢集規模是衡量一個多叢集系統資源池規模不可忽視的維度。一方面，叢集數量相等的情況下，單個叢集的規模越大，整個多叢集系統的資源池越大。另一方面，多叢集系統的上層能力依賴系統對叢集的資源畫像，例如在多叢集應用的排程過程中，叢集資源是不可或缺的一個因素。綜上所述，單叢集的規模與整個多叢集系統息息相關，但單叢集的規模同樣不是制約多叢集系統的限制因素。使用者可以透過最佳化原生的Kubernetes元件的方式來提升單叢集的叢集規模，達到擴大整個多叢集系統的資源池的目的，但這不是衡量多叢集系統效能的關注點。在叢集的標準配置中，Node與Pod毫無疑問是其中最重要的兩個資源，Node是計算、儲存等資源的最小載體，而Pod數量則代表著一個叢集的應用承載能力。
大規模場景下多叢集系統的效能指標
在多叢集系統的大規模落地程式中，如何衡量多叢集聯邦的服務質量是一個不可避免的問題。在參考了Kubernetes社群的SLI(Service Level Indicator)/SLO(Service Level Objectives)和多叢集系統的落地應用後，Karmada社群定義了以下SLI/SLO來衡量大規模場景下多叢集聯邦的服務質量。
API Call Latency
注：API呼叫時延仍然是衡量基於Kubernetes的多叢集系統服務質量的關鍵指標。Karmada相容Kubernetes原生API，使用者除了使用原生API建立K8s的資源模板外，也可以使用Karmada自有API來建立多叢集策略和訪問跨叢集的資源。
Resource Distribution Latency
Cluster Registration Latency
注：叢集註冊時延是從叢集註冊到控制面到叢集在聯邦側可用的時延，它反映了控制面接入叢集以及管理叢集的生命週期的效能。但它在某種程度上取決於控制面如何收整合員叢集的狀態。因此，我們不會對這個指標進行強制的限制。
Resource Usage
注：資源使用量是多叢集系統中非常重要的指標，我們希望在納管海量的叢集和資源的同時消耗盡量少的系統資源。但由於不同的多叢集系統提供的上層服務不同，因此對於不同的系統，其對資源的要求也會不同。因此，我們不會對這個指標進行強制的限制。
Karmada百倍叢集規模基礎設施揭秘
Karmada社群在結合對上述兩個問題的思考以及使用者在落地過程中的反饋後，測試了Karmada同時管理100個5K節點和2w Pod的Kubernetes叢集的場景。本文不詳細描述具體的測試環境資訊與測試過程，而是側重於對測試結果進行分析
在整個測試過程中，API呼叫時延均符合上述定義的SLI/SLO。
圖一：只讀API（cluster-scope）呼叫時延
圖二：只讀API(namespace-scope)呼叫時延
圖三：只讀API(resource-scope)呼叫時延
圖四：Mutating API呼叫時延
Karmada在百倍叢集規模下，仍能做到快速的API響應，這取決於Karmada獨特的多雲控制面架構。事實上，Karmada在架構設計之初就採用了關注點分離的設計理念，使用Kubernetes原生API來表達叢集聯邦資源模板，使用可複用的策略API來表達多叢集的管理策略，同時控制面的資源模板作為應用的模板，不會在控制面生成具體的Pod。不同叢集的應用在控制面的對映（Work物件）透過名稱空間來進行安全隔離。完整的API工作流如下圖所示。如此設計，不僅可以讓Karmada能夠輕鬆整合Kubernetes的生態, 同時也大大減少了控制面的資源數量和承載壓力。基於此，控制面的資源數量不取決於叢集的數量，而是取決於多叢集應用的數量。
此外，Karmada的架構極具簡潔性和擴充套件性。karmada-apiserver作為控制面的入口與kube-apiserver類似，即使是在百倍叢集規模下，Karmada仍能保持快速API響應。
Karmada支援透過命令列快速接入叢集，以及叢集的全生命週期管理。Karmada會實時採集叢集心跳和狀態，其中叢集狀態包括叢集版本、支援的API列表、叢集健康狀態以及叢集資源使用量等。其中，Karmada會基於叢集資源使用量對成員叢集進行建模，這樣排程器可以更好地為應用選擇資源足夠的目標叢集。在這種情況下，叢集註冊時延與叢集的規模息息相關。下表展示了加入一個5,000節點的叢集直至它可用所需的時延。你可以透過關閉叢集資源建模來使叢集註冊時延與叢集的大小無關，在這種情況下，叢集註冊時延這個指標將小於2s。
Cluster Registration Latency:
Karmada支援多模式的叢集統一接入，在Push模式下，Karmada控制面直連成員叢集的kube-apiserver，而在Pull模式下，Karmada將在成員叢集中安裝agent元件，並委託任務給它。因此Push模式多用於公有云的K8s叢集，需要暴露APIServer在公網中，而Pull模式多用於私有云的K8s叢集。下表展示了Karmada在不同模式下下發一個應用到成員叢集所需的時延。
Resource Distribution Latency:
結論：我們容易得出，不論是Push模式還是Pull模式，Karmada都能高效地將資源下發到成員叢集中。
在Karmada演進的數個版本中，大規模場景下使用Karmada管理多雲應用的資源消耗一直是使用者比較關注的問題。Karmada社群做了許多工作來減少Karmada管理大型叢集的資源使用量，比如我們最佳化了Informer的快取，剔除了資源無關的節點、Pod後設資料；減少了控制器內不必要的型別轉換等等。相較於1.2版本，當前Karmada在大規模叢集場景下減少了85%的記憶體消耗和32%的CPU消耗。下圖展示了不同模式下Karmada控制面的資源消耗情況。
Push模式：
Pull模式：
總的來說，系統消耗的資源在一個可控制面的範圍，其中Pull模式在記憶體使用上有明顯的優勢，而在其他資源上相差的不大。
Karmada大規模環境下的最佳實踐
Karmada支援效能引數的可配置化，使用者可以透過調整元件的引數來調整同一時間段內併發處理Karmada內部物件的數量、系統的吞吐量等以最佳化效能。同時Karmada在不同模式下的效能瓶頸並不相同，以下著重對此進行分析。
在Push模式中，控制面的資源消耗主要集中在karmada-controller-manager（約70%），而Karmada控制面基座（etcd/karmada-apiserver）的壓力不大。
結合karmada-apiserver的qps以及karmada-etcd的請求時延我們可以看出karmada-apiserver的請求量保持在一個較低的水平。在Push模式中，絕大多數的請求來自karmada-controller-manager。因此我們可以透過調整karmada-controller-manager的--concurrent-work-syncs來調整同一時間段併發work的數量來提升應用下發的速度，也可以配置--kube-api-qps和--kube-api-burst這兩個引數來控制Karmada控制面的整體流控。
在Pull模式中，控制面的資源消耗主要集中在karmada-apiserver，而不是karmada-controller-manager。
結合karmada-apiserver的qps以及karmada-etcd的請求時延我們可以看出karmada-apiserver的請求量保持在一個較高的水平。在Pull模式中，每個成員叢集的karmada-agent需要維持一條與karmada-apiserver通訊的長連線。我們很容易得出：在下發應用至所有叢集的過程中請求總量是karmada-agent中配置的N倍(N=#Num of clusters)。因此，在大規模Pull模式叢集的場景下，Pull模式在資源下發/狀態收集方面有更好的效能，但同時需要考慮控制面的抗壓能力以及各個karmada-agent和控制面的整體流控。
當前，Karmada提供了叢集資源模型的能力來基於叢集空閒資源做排程決策。在資源建模的過程中，它會收集所有叢集的節點與Pod的資訊。這在大規模場景下會有一定的記憶體消耗。如果使用者不使用這個能力，使用者可以關閉叢集資源建模來進一步減少資源消耗。
總結
根據上述測試結果分析，Karmada可以穩定支援100個大規模叢集，管理超過50萬個節點和200萬個Pod。在Karmada落地程式中，使用者可以根據使用場景選擇不同的部署模式，透過引數調優等手段來提升整個多叢集系統的效能。
受限於測試環境和測試工具，上述測試尚未測試到Karmada多叢集系統的上限，同時多叢集系統的分析理論以及測試方法仍處於方興未艾的階段，下一步我們將繼續最佳化多叢集系統的測試工具，系統性地整理測試方法，以覆蓋更大的規模和更多的典型場景。