本文分享自華為雲社群《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多叢集系統的上限，同時多叢集系統的分析理論以及測試方法仍處于方興未艾的階段，下一步我們将繼續優化多叢集系統的測試工具，系統性地整理測試方法，以覆寫更大的規模和更多的典型場景。
關注#華為雲開發者聯盟# 點選下方，第一時間了解華為雲新鮮技術~
華為雲部落格_大資料部落格_AI部落格_雲計算部落格_開發者中心-華為雲