點可擴展性測試報告解讀：1000 節(jié)點 × 30 Pod 的規(guī)模承諾與驗證方法)
Cluster Autoscaler 千節(jié)點可擴展性測試報告解讀1000 節(jié)點 × 30 Pod 的規(guī)模承諾與驗證方法【免費下載鏈接】autoscalerAutoscaling components for Kubernetes項目地址: https://gitcode.com/GitHub_Trending/au/autoscaler本文以 cluster-autoscaler/proposals/scalability_tests.md 為核心系統(tǒng)解讀 Kubernetes Cluster AutoscalerCA在 GA 版本所聲明的可擴展性目標(biāo)——1000 節(jié)點、每節(jié)點 30 個 Pod——背后的定義、測試環(huán)境、六大測試場景與實測結(jié)論并對照當(dāng)前倉庫中的 kubemark 云提供商實現(xiàn)與 FAQ 中的 SLO 說明進(jìn)行源碼級印證。讀完本文你將理解 CA規(guī)模化到什么程度才算達(dá)標(biāo)的評判標(biāo)準(zhǔn)、如何借助 kubemark 以低成本搭建千節(jié)點測試集群以及該規(guī)模承諾的適用前提與邊界。一、為什么需要一份可擴展性測試報告作為 Cluster Autoscaler 走向 GA正式發(fā)布的一部分項目團隊需要向用戶量化承諾這一組件在多大規(guī)模的集群上依然可用。倉庫根目錄的 cluster-autoscaler/README.md 在特性清單中明確寫著 Support for 1000 nodes running 30 pods each并直接指向本測試報告作為依據(jù)cluster-autoscaler/FAQ.md 也在回答 How mature is Cluster Autoscaler? 時提到 It was tested that CA scales well. CA should handle up to 1000 nodes running 30 pods each. Our testing procedure is described here。因此scalability_tests.md不是一份內(nèi)部實驗記錄而是對外發(fā)布的規(guī)模承諾依據(jù)文檔它定義了CA 擴展到 1000 節(jié)點的確切含義、用于度量的性能指標(biāo)、測試環(huán)境的搭建方式以及支撐該結(jié)論的實測數(shù)據(jù)。二、CA 可擴展到 1000 節(jié)點的確切定義該文檔首先澄清了一個容易模糊的概念——什么才算可擴展Cluster Autoscaler scales up to a certain number of nodes if it stays responsive. It performs scale up and scale down operations on the cluster within reasonable time frame.即可擴展意味著 CA 在目標(biāo)規(guī)模下保持響應(yīng)能夠在合理時間窗內(nèi)完成集群的擴容scale up與縮容scale down。文檔進(jìn)一步解釋了為什么要強調(diào)這一點若 CA 失去響應(yīng)可能被 liveness probe存活探針殺掉或者無法在需要時提供/釋放計算資源導(dǎo)致集群無法承載新增工作負(fù)載或者由于沒有及時縮容而產(chǎn)生更高的云廠商賬單?？梢娍蓴U展性不僅是功能正確更是時效正確——CA 必須在用戶可感知的延遲范圍內(nèi)對集群狀態(tài)變化作出反應(yīng)。三、預(yù)期性能標(biāo)準(zhǔn)單次迭代 30 秒上限為了把反應(yīng)時間短落實為可測量的指標(biāo)文檔定義了**迭代iteration**這一核心概念every iteration (cluster state analysis to see if cluster size needs to be changed and according adjustment of the cluster size) needs to finish relatively quickly一次迭代 一次完整的集群狀態(tài)分析 → 判斷是否需要調(diào)整集群規(guī)模 → 執(zhí)行相應(yīng)調(diào)整循環(huán)。CA 能否及時響應(yīng)直接取決于單次迭代的耗時。由此給出量化標(biāo)準(zhǔn)迭代時長的上限設(shè)定為 30 秒。從當(dāng)前倉庫源碼看這一迭代正是 cluster-autoscaler/main.go 中主循環(huán)所執(zhí)行的核心動作loop.RunAutoscalerOnce(ctx, autoscaler, healthCheck, lastRun)在autoscalingOpts.ScanInterval定時觸發(fā)下反復(fù)運行而循環(huán)內(nèi)部即為一次完整的伸縮決策處理。換言之30 秒的上限直接約束的就是這條主循環(huán)路徑上的分析-決策-調(diào)整總耗時。四、測試環(huán)境kubemark GCP 的千節(jié)點模擬集群在真實公有云上直接拉起 1000 臺節(jié)點做壓測成本極高。為此本報告使用了 Kubernetes 社區(qū)的可擴展性測試?yán)鱧ubemark在 GCP 上構(gòu)建了一套約 1000 節(jié)點的測試集群。原文給出的具體配置如下組件規(guī)格說明1 個 master1 核 VM外部集群控制面17 個節(jié)點8 核 VM每核最多運行 8 個 Kubemark 節(jié)點承載 Hollow Node1 個 Kubemark master32 核 VMkubemark 集群控制面1 臺獨立 VM—專用于運行 Cluster Autoscaler這套拓?fù)涞木柙谟谟蒙倭空鎸?VM 模擬出千節(jié)點規(guī)模的假象真實集群中只有 18 臺機器但通過 kubemark 的 Hollow Node 機制在邏輯上呈現(xiàn)為 1000 個 K8s 節(jié)點從而以極低成本觸發(fā) CA 的全部伸縮邏輯。倉庫中的 cluster-autoscaler/proposals/kubemark_integration.md 對這一機制給出了更完整的背景說明kubemark 環(huán)境包含兩個集群外部集群external cluster如 GCE 上的普通集群與運行其上的 kubemark 集群擁有獨立的 master**Hollow Node空心節(jié)點**以 Pod 形式運行在外部集群中由 Replication Controller 統(tǒng)一創(chuàng)建與管控每個 Hollow Node 對應(yīng)一個邏輯節(jié)點使 CA 看到的是一個節(jié)點數(shù)萬級的大集群而實際占用的物理資源極小。CA 側(cè)對應(yīng)的實現(xiàn)位于 cluster-autoscaler/cloudprovider/kubemark/kubemark_linux.go注意該云提供商僅在 Linux 上編譯見 kubemark_other.go 中的樁實現(xiàn)非 Linux 平臺直接klog.Fatal提示 only supported on Linux。從源碼結(jié)構(gòu)看其關(guān)鍵設(shè)計包括ProviderName kubemark并通過builder.RegisterCloudProvider注冊甚至被設(shè)為默認(rèn)云提供商BuildKubemark同時維護(hù)兩個 client一個連接外部集群InClusterConfig另一個連接 kubemark 集群優(yōu)先讀取/kubeconfig/cluster_autoscaler.kubeconfig并各自建立 informer 與KubemarkControllerNodeGroup 通過dynamic.SpecFromString(value, true)解析命令行傳入的--nodes{MIN}:{MAX}:{NG_LABEL_VALUE}規(guī)格來構(gòu)建minSize/maxSize直接決定伸縮邊界IncreaseSize通過SetNodeGroupSize增加目標(biāo)規(guī)模DeleteNodes在低于MinSize時拒絕刪除DecreaseTargetSize只允許縮減尚未創(chuàng)建完成的節(jié)點——這與 kubemark_integration.md 中以 singleton Replication Controller 方式管理節(jié)點的設(shè)計一一對應(yīng)。關(guān)于 NodeGroup 的組織方式kubemark_integration.md 明確同一 NodeGroup 的節(jié)點通過標(biāo)簽autoscaling.k8s.io/nodegroup標(biāo)識CA 啟動時會解析--nodes{MIN}:{MAX}:{NG_LABEL_VALUE}若集群中該標(biāo)簽的節(jié)點不足{MIN}個則自動補齊。這樣即便 CA 重啟或崩潰NodeGroup 的歸屬關(guān)系也不會丟失。五、測試執(zhí)行與指標(biāo)采集方法所有測試場景共享同一套通用負(fù)載目標(biāo)約 1000 個節(jié)點、每節(jié)點約 30 個 Pod。執(zhí)行方式為During each test scenario we have collected iteration duration histogram.即在每個場景運行期間持續(xù)采集迭代時長直方圖iteration duration histogram用迭代時長的分布來評估 CA 的響應(yīng)性。這與第三節(jié)定義的 30 秒迭代上限形成閉環(huán)30 秒是閾值直方圖數(shù)據(jù)則是判定依據(jù)。六、六大測試場景詳解文檔共設(shè)計了 6 個場景按方向分為 3 個 Scale-up擴容與 3 個 Scale-down縮容覆蓋了集群負(fù)載突發(fā)變化的典型形態(tài)。6.1 [Scale-up] 從零開始擴容Scales up at all場景集群已飽和新創(chuàng)建的 Pod 必須依賴擴容才能運行模擬集群中的突發(fā)活動潮起始狀態(tài)1 個節(jié)點上運行 2 個 Pod節(jié)點已滿無法再容納新 Pod操作調(diào)度約 30 000 個新 Pod觸發(fā)擴容到 1000 節(jié)點、每節(jié)點 30 Pod預(yù)期結(jié)果集群達(dá)到 1000 節(jié)點所有 Pod 運行所有節(jié)點滿載。該場景驗證的是 CA 擴容鏈路的最基本情況——能否在飽和集群中為大規(guī)模 Pod 洪峰完成從 1 到 1000 的擴容。6.2 [Scale-up] 在承接既有擴容負(fù)載的同時繼續(xù)擴容場景集群已飽和分兩批創(chuàng)建 Pod兩批之間有小間隔模擬 CA 正在擴容時又迎來新一輪活動突發(fā)起始狀態(tài)1 節(jié)點、2 Pod節(jié)點已滿操作先調(diào)度約 21 000 個新 Pod觸發(fā)擴容到 700 節(jié)點→ 等待約 1.5 分鐘 → 再調(diào)度約 9 000 個新 Pod觸發(fā)擴容到 1000 節(jié)點預(yù)期結(jié)果集群達(dá)到 1000 節(jié)點所有 Pod 運行所有新節(jié)點滿載。該場景比 6.1 更嚴(yán)苛CA 必須在上一輪擴容尚未完成的中間態(tài)繼續(xù)響應(yīng)新一輪擴容請求驗證其狀態(tài)機的連續(xù)性。6.3 [Scale-down] 縮容空節(jié)點場景集群中存在大量空節(jié)點等待 CA 自動縮容模擬集群活動度的驟降起始狀態(tài)700 個 Pod 運行在 700 個節(jié)點上節(jié)點約 70% 滿集群共 1000 節(jié)點操作不做任何事預(yù)期結(jié)果300 個節(jié)點被移出集群。該場景驗證 CA 的閑置節(jié)點回收能力——直接決定云賬單的高低。6.4 [Scale-down] 縮容低利用率節(jié)點場景集群存在大量低利用率節(jié)點等待 CA 縮容同時迫使 CA 計算如何重調(diào)度 Pod起始狀態(tài)52 000 個 Pod 運行在 1000 個節(jié)點上其中 300 個節(jié)點約 30% 滿、700 個節(jié)點約 70% 滿節(jié)點組最小規(guī)模 970操作不做任何事預(yù)期結(jié)果30 個節(jié)點被移出集群。與 6.3 的空節(jié)點直接刪不同本場景中節(jié)點上仍有 PodCA 必須基于模擬調(diào)度器評估這些 Pod 能否搬到其余節(jié)點只有搬得走才會縮容因此對計算開銷的考驗更大節(jié)點規(guī)模、Pod 數(shù)量均為所有場景之最。6.5 [Scale-down] 不縮容低利用率但不可移除的節(jié)點場景集群存在大量低利用率但無法移除的節(jié)點模擬帶有不可移除節(jié)點的活動驟降起始狀態(tài)1000 個 Pod 運行在 1000 個節(jié)點上其中 700 個節(jié)點 90% 滿300 個節(jié)點約 30% 滿因 host port 沖突等原因低利用率卻不可移除操作不做任何事預(yù)期結(jié)果集群規(guī)模不變所有 Pod 繼續(xù)運行。該場景驗證的是縮容邏輯的保守面——不能為了縮容而破壞正在運行的 Pod即使節(jié)點利用率很低只要 Pod 無法遷移就必須保持原狀。6.6 [Scale-up] 忽略不可調(diào)度 Pod繼續(xù)調(diào)度可調(diào)度 Pod場景創(chuàng)建不可調(diào)度的 Pod 不應(yīng)影響可調(diào)度 Pod 的調(diào)度起始狀態(tài)1 節(jié)點上運行 1 個 Pod另有 1000 個不可調(diào)度 Pod 處于 Pending操作調(diào)度 30 000 個 Pod觸發(fā)擴容到 1000 節(jié)點、每節(jié)點 30 Pod預(yù)期結(jié)果集群規(guī)模 1000所有可調(diào)度 Pod 運行不可調(diào)度 Pod 保持 Pending。該場景驗證 CA 不會因 Pending 池中存在永遠(yuǎn)無法滿足的 Pod如資源請求超出任何節(jié)點上限而阻塞或拖慢正常 Pod 的擴容路徑。七、測試結(jié)果與最終結(jié)論文檔給出的結(jié)論非常直接Cluster Autoscaler in GA version fulfills all the expected results of all the listed test scenarios. Furthermore the maximum measured iteration duration for all these tests is below 10s.即6 個場景全部達(dá)成預(yù)期結(jié)果擴容達(dá) 1000 節(jié)點、縮容精確到目標(biāo)節(jié)點數(shù)、不可移除節(jié)點不被誤刪、不可調(diào)度 Pod 不阻塞正常調(diào)度所有測試中的實測最大迭代時長低于 10 秒遠(yuǎn)優(yōu)于預(yù)設(shè)的 30 秒上限據(jù)此正式聲明Cluster AutoscalerGA 版可擴展到 1000 節(jié)點、平均每節(jié)點 30 個 Pod。八、與 SLO 及性能預(yù)期的銜接這份測試報告的價值不止于一次性的壓測它還直接支撐了 cluster-autoscaler/FAQ.md 中對外公布的性能 SLO。FAQ 在 What are the Service Level Objectives for Cluster Autoscaler? 一節(jié)中說明CA 的核心 SLO 是延遲時間從 Pod 被調(diào)度器標(biāo)記為不可調(diào)度到 CA 向云廠商發(fā)出擴容請求的間隔在可擴展性測試中目標(biāo)是在大集群下最大 20 秒延遲據(jù)此向用戶給出的實際預(yù)期為小集群100 節(jié)點、每節(jié)點 ≤30 Pod延遲不超過 30 秒、平均約 5 秒大集群1001000 節(jié)點延遲不超過 60 秒、平均約 15 秒。同時 FAQ 也點明了達(dá)成該性能的前提條件與本文報告的適用邊界一脈相承所有 Pod不得使用 Pod affinity/anti-affinity——FAQ 明確指出當(dāng)前調(diào)度器中 affinity 謂詞的實現(xiàn)比其它所有謂詞加起來還慢約 3 個數(shù)量級會令 CA 在大集群上難以可用大集群中建議為 CA Pod 預(yù)留完整 1 核 CPU將 CA 放在過載節(jié)點上無法達(dá)到聲明的性能沒有對超過 1000 節(jié)點的集群進(jìn)行過性能測試支持更大規(guī)模并非 1.0 的目標(biāo)。這些說明既界定了本報告的測試邊界也為用戶在生產(chǎn)環(huán)境復(fù)現(xiàn)該性能水平提供了可操作的約束條件。九、局限性與適用前提總結(jié)基于文檔本身及倉庫佐證材料讀者在引用1000 節(jié)點 × 30 Pod這一結(jié)論時應(yīng)同時知悉其適用前提測試載體為 kubemark 模擬集群基于 kubemark_integration.md 描述的外部集群 Hollow Node 方案并非真實云廠商實例云廠商側(cè)的節(jié)點供應(yīng)延遲不計入 CA 迭代時長測試平臺為 GCP/GCE其他云廠商如 AWS由于缺少相應(yīng)測試基礎(chǔ)設(shè)施并未納入標(biāo)準(zhǔn)開發(fā)與發(fā)布流程的性能驗證見 FAQ.md測試上限即 1000 節(jié)點超過該規(guī)模沒有性能數(shù)據(jù)支撐該承諾依賴kubemark 云提供商在 Linux 環(huán)境下運行其他平臺僅有樁實現(xiàn)迭代時長 30 秒是設(shè)計上限實測最大值 10 秒是特定負(fù)載形態(tài)下的結(jié)果不代表所有場景。十、如何在倉庫中進(jìn)一步深入若想復(fù)現(xiàn)或深入理解本測試可在當(dāng)前倉庫中按以下路徑繼續(xù)探索scalability_tests.md —— 本文所解讀的原始報告kubemark_integration.md —— kubemark 云提供商的集成設(shè)計Hollow Node、NodeGroup 標(biāo)簽、--nodes配置kubemark_linux.go —— kubemark CloudProvider 的 Linux 實現(xiàn)雙集群 client、NodeGroup 增刪、min/max 邊界校驗main.go —— CA 主循環(huán)與RunAutoscalerOnce即迭代的執(zhí)行入口FAQ.md —— 由本測試衍生的 SLO 與性能預(yù)期說明README.md —— 1000 nodes running 30 pods each 特性聲明的對外入口e2e/cluster_size_autoscaling.go 與 e2e/e2e_test.go —— 面向真實集群的端到端伸縮驗證可作為理解測試執(zhí)行方式的補充材料。綜上這份可擴展性測試報告為 Cluster Autoscaler 的 GA 承諾提供了完整的方法論與數(shù)據(jù)支撐以迭代時長 ≤ 30 秒作為響應(yīng)性度量以 kubemark 低成本構(gòu)建千節(jié)點模擬環(huán)境以六個覆蓋擴容/縮容極端形態(tài)的場景完成驗證最終以實測最大迭代時長 10 秒的結(jié)論確立了 1000 節(jié)點 × 30 Pod 的規(guī)?；芰€。對使用者而言理解其定義、測試設(shè)計與適用邊界遠(yuǎn)比記住一個1000 節(jié)點的數(shù)字更有價值?！久赓M下載鏈接】autoscalerAutoscaling components for Kubernetes項目地址: https://gitcode.com/GitHub_Trending/au/autoscaler創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考 Cluster Autoscaler 千節(jié)點可擴展性測試報告解讀：1000 節(jié)點 × 30 Pod 的規(guī)模承諾與驗證方法
Cluster Autoscaler 千節(jié)點可擴展性測試報告解讀1000 節(jié)點 × 30 Pod 的規(guī)模承諾與驗證方法【免費下載鏈接】autoscalerAutoscaling components for Kubernetes項目地址: https://gitcode.com/GitHub_Trending/au/autoscaler本文以 cluster-autoscaler/proposals/scalability_tests.md 為核心系統(tǒng)解讀 Kubernetes Cluster AutoscalerCA在 GA 版本所聲明的可擴展性目標(biāo)——1000 節(jié)點、每節(jié)點 30 個 Pod——背后的定義、測試環(huán)境、六大測試場景與實測結(jié)論并對照當(dāng)前倉庫中的 kubemark 云提供商實現(xiàn)與 FAQ 中的 SLO 說明進(jìn)行源碼級印證。讀完本文你將理解 CA規(guī)模化到什么程度才算達(dá)標(biāo)的評判標(biāo)準(zhǔn)、如何借助 kubemark 以低成本搭建千節(jié)點測試集群以及該規(guī)模承諾的適用前提與邊界。一、為什么需要一份可擴展性測試報告作為 Cluster Autoscaler 走向 GA正式發(fā)布的一部分項目團隊需要向用戶量化承諾這一組件在多大規(guī)模的集群上依然可用。倉庫根目錄的 cluster-autoscaler/README.md 在特性清單中明確寫著 Support for 1000 nodes running 30 pods each并直接指向本測試報告作為依據(jù)cluster-autoscaler/FAQ.md 也在回答 How mature is Cluster Autoscaler? 時提到 It was tested that CA scales well. CA should handle up to 1000 nodes running 30 pods each. Our testing procedure is described here。因此scalability_tests.md不是一份內(nèi)部實驗記錄而是對外發(fā)布的規(guī)模承諾依據(jù)文檔它定義了CA 擴展到 1000 節(jié)點的確切含義、用于度量的性能指標(biāo)、測試環(huán)境的搭建方式以及支撐該結(jié)論的實測數(shù)據(jù)。二、CA 可擴展到 1000 節(jié)點的確切定義該文檔首先澄清了一個容易模糊的概念——什么才算可擴展Cluster Autoscaler scales up to a certain number of nodes if it stays responsive. It performs scale up and scale down operations on the cluster within reasonable time frame.即可擴展意味著 CA 在目標(biāo)規(guī)模下保持響應(yīng)能夠在合理時間窗內(nèi)完成集群的擴容scale up與縮容scale down。文檔進(jìn)一步解釋了為什么要強調(diào)這一點若 CA 失去響應(yīng)可能被 liveness probe存活探針殺掉或者無法在需要時提供/釋放計算資源導(dǎo)致集群無法承載新增工作負(fù)載或者由于沒有及時縮容而產(chǎn)生更高的云廠商賬單?？梢娍蓴U展性不僅是功能正確更是時效正確——CA 必須在用戶可感知的延遲范圍內(nèi)對集群狀態(tài)變化作出反應(yīng)。三、預(yù)期性能標(biāo)準(zhǔn)單次迭代 30 秒上限為了把反應(yīng)時間短落實為可測量的指標(biāo)文檔定義了**迭代iteration**這一核心概念every iteration (cluster state analysis to see if cluster size needs to be changed and according adjustment of the cluster size) needs to finish relatively quickly一次迭代 一次完整的集群狀態(tài)分析 → 判斷是否需要調(diào)整集群規(guī)模 → 執(zhí)行相應(yīng)調(diào)整循環(huán)。CA 能否及時響應(yīng)直接取決于單次迭代的耗時。由此給出量化標(biāo)準(zhǔn)迭代時長的上限設(shè)定為 30 秒。從當(dāng)前倉庫源碼看這一迭代正是 cluster-autoscaler/main.go 中主循環(huán)所執(zhí)行的核心動作loop.RunAutoscalerOnce(ctx, autoscaler, healthCheck, lastRun)在autoscalingOpts.ScanInterval定時觸發(fā)下反復(fù)運行而循環(huán)內(nèi)部即為一次完整的伸縮決策處理。換言之30 秒的上限直接約束的就是這條主循環(huán)路徑上的分析-決策-調(diào)整總耗時。四、測試環(huán)境kubemark GCP 的千節(jié)點模擬集群在真實公有云上直接拉起 1000 臺節(jié)點做壓測成本極高。為此本報告使用了 Kubernetes 社區(qū)的可擴展性測試?yán)鱧ubemark在 GCP 上構(gòu)建了一套約 1000 節(jié)點的測試集群。原文給出的具體配置如下組件規(guī)格說明1 個 master1 核 VM外部集群控制面17 個節(jié)點8 核 VM每核最多運行 8 個 Kubemark 節(jié)點承載 Hollow Node1 個 Kubemark master32 核 VMkubemark 集群控制面1 臺獨立 VM—專用于運行 Cluster Autoscaler這套拓?fù)涞木柙谟谟蒙倭空鎸?VM 模擬出千節(jié)點規(guī)模的假象真實集群中只有 18 臺機器但通過 kubemark 的 Hollow Node 機制在邏輯上呈現(xiàn)為 1000 個 K8s 節(jié)點從而以極低成本觸發(fā) CA 的全部伸縮邏輯。倉庫中的 cluster-autoscaler/proposals/kubemark_integration.md 對這一機制給出了更完整的背景說明kubemark 環(huán)境包含兩個集群外部集群external cluster如 GCE 上的普通集群與運行其上的 kubemark 集群擁有獨立的 master**Hollow Node空心節(jié)點**以 Pod 形式運行在外部集群中由 Replication Controller 統(tǒng)一創(chuàng)建與管控每個 Hollow Node 對應(yīng)一個邏輯節(jié)點使 CA 看到的是一個節(jié)點數(shù)萬級的大集群而實際占用的物理資源極小。CA 側(cè)對應(yīng)的實現(xiàn)位于 cluster-autoscaler/cloudprovider/kubemark/kubemark_linux.go注意該云提供商僅在 Linux 上編譯見 kubemark_other.go 中的樁實現(xiàn)非 Linux 平臺直接klog.Fatal提示 only supported on Linux。從源碼結(jié)構(gòu)看其關(guān)鍵設(shè)計包括ProviderName kubemark并通過builder.RegisterCloudProvider注冊甚至被設(shè)為默認(rèn)云提供商BuildKubemark同時維護(hù)兩個 client一個連接外部集群InClusterConfig另一個連接 kubemark 集群優(yōu)先讀取/kubeconfig/cluster_autoscaler.kubeconfig并各自建立 informer 與KubemarkControllerNodeGroup 通過dynamic.SpecFromString(value, true)解析命令行傳入的--nodes{MIN}:{MAX}:{NG_LABEL_VALUE}規(guī)格來構(gòu)建minSize/maxSize直接決定伸縮邊界IncreaseSize通過SetNodeGroupSize增加目標(biāo)規(guī)模DeleteNodes在低于MinSize時拒絕刪除DecreaseTargetSize只允許縮減尚未創(chuàng)建完成的節(jié)點——這與 kubemark_integration.md 中以 singleton Replication Controller 方式管理節(jié)點的設(shè)計一一對應(yīng)。關(guān)于 NodeGroup 的組織方式kubemark_integration.md 明確同一 NodeGroup 的節(jié)點通過標(biāo)簽autoscaling.k8s.io/nodegroup標(biāo)識CA 啟動時會解析--nodes{MIN}:{MAX}:{NG_LABEL_VALUE}若集群中該標(biāo)簽的節(jié)點不足{MIN}個則自動補齊。這樣即便 CA 重啟或崩潰NodeGroup 的歸屬關(guān)系也不會丟失。五、測試執(zhí)行與指標(biāo)采集方法所有測試場景共享同一套通用負(fù)載目標(biāo)約 1000 個節(jié)點、每節(jié)點約 30 個 Pod。執(zhí)行方式為During each test scenario we have collected iteration duration histogram.即在每個場景運行期間持續(xù)采集迭代時長直方圖iteration duration histogram用迭代時長的分布來評估 CA 的響應(yīng)性。這與第三節(jié)定義的 30 秒迭代上限形成閉環(huán)30 秒是閾值直方圖數(shù)據(jù)則是判定依據(jù)。六、六大測試場景詳解文檔共設(shè)計了 6 個場景按方向分為 3 個 Scale-up擴容與 3 個 Scale-down縮容覆蓋了集群負(fù)載突發(fā)變化的典型形態(tài)。6.1 [Scale-up] 從零開始擴容Scales up at all場景集群已飽和新創(chuàng)建的 Pod 必須依賴擴容才能運行模擬集群中的突發(fā)活動潮起始狀態(tài)1 個節(jié)點上運行 2 個 Pod節(jié)點已滿無法再容納新 Pod操作調(diào)度約 30 000 個新 Pod觸發(fā)擴容到 1000 節(jié)點、每節(jié)點 30 Pod預(yù)期結(jié)果集群達(dá)到 1000 節(jié)點所有 Pod 運行所有節(jié)點滿載。該場景驗證的是 CA 擴容鏈路的最基本情況——能否在飽和集群中為大規(guī)模 Pod 洪峰完成從 1 到 1000 的擴容。6.2 [Scale-up] 在承接既有擴容負(fù)載的同時繼續(xù)擴容場景集群已飽和分兩批創(chuàng)建 Pod兩批之間有小間隔模擬 CA 正在擴容時又迎來新一輪活動突發(fā)起始狀態(tài)1 節(jié)點、2 Pod節(jié)點已滿操作先調(diào)度約 21 000 個新 Pod觸發(fā)擴容到 700 節(jié)點→ 等待約 1.5 分鐘 → 再調(diào)度約 9 000 個新 Pod觸發(fā)擴容到 1000 節(jié)點預(yù)期結(jié)果集群達(dá)到 1000 節(jié)點所有 Pod 運行所有新節(jié)點滿載。該場景比 6.1 更嚴(yán)苛CA 必須在上一輪擴容尚未完成的中間態(tài)繼續(xù)響應(yīng)新一輪擴容請求驗證其狀態(tài)機的連續(xù)性。6.3 [Scale-down] 縮容空節(jié)點場景集群中存在大量空節(jié)點等待 CA 自動縮容模擬集群活動度的驟降起始狀態(tài)700 個 Pod 運行在 700 個節(jié)點上節(jié)點約 70% 滿集群共 1000 節(jié)點操作不做任何事預(yù)期結(jié)果300 個節(jié)點被移出集群。該場景驗證 CA 的閑置節(jié)點回收能力——直接決定云賬單的高低。6.4 [Scale-down] 縮容低利用率節(jié)點場景集群存在大量低利用率節(jié)點等待 CA 縮容同時迫使 CA 計算如何重調(diào)度 Pod起始狀態(tài)52 000 個 Pod 運行在 1000 個節(jié)點上其中 300 個節(jié)點約 30% 滿、700 個節(jié)點約 70% 滿節(jié)點組最小規(guī)模 970操作不做任何事預(yù)期結(jié)果30 個節(jié)點被移出集群。與 6.3 的空節(jié)點直接刪不同本場景中節(jié)點上仍有 PodCA 必須基于模擬調(diào)度器評估這些 Pod 能否搬到其余節(jié)點只有搬得走才會縮容因此對計算開銷的考驗更大節(jié)點規(guī)模、Pod 數(shù)量均為所有場景之最。6.5 [Scale-down] 不縮容低利用率但不可移除的節(jié)點場景集群存在大量低利用率但無法移除的節(jié)點模擬帶有不可移除節(jié)點的活動驟降起始狀態(tài)1000 個 Pod 運行在 1000 個節(jié)點上其中 700 個節(jié)點 90% 滿300 個節(jié)點約 30% 滿因 host port 沖突等原因低利用率卻不可移除操作不做任何事預(yù)期結(jié)果集群規(guī)模不變所有 Pod 繼續(xù)運行。該場景驗證的是縮容邏輯的保守面——不能為了縮容而破壞正在運行的 Pod即使節(jié)點利用率很低只要 Pod 無法遷移就必須保持原狀。6.6 [Scale-up] 忽略不可調(diào)度 Pod繼續(xù)調(diào)度可調(diào)度 Pod場景創(chuàng)建不可調(diào)度的 Pod 不應(yīng)影響可調(diào)度 Pod 的調(diào)度起始狀態(tài)1 節(jié)點上運行 1 個 Pod另有 1000 個不可調(diào)度 Pod 處于 Pending操作調(diào)度 30 000 個 Pod觸發(fā)擴容到 1000 節(jié)點、每節(jié)點 30 Pod預(yù)期結(jié)果集群規(guī)模 1000所有可調(diào)度 Pod 運行不可調(diào)度 Pod 保持 Pending。該場景驗證 CA 不會因 Pending 池中存在永遠(yuǎn)無法滿足的 Pod如資源請求超出任何節(jié)點上限而阻塞或拖慢正常 Pod 的擴容路徑。七、測試結(jié)果與最終結(jié)論文檔給出的結(jié)論非常直接Cluster Autoscaler in GA version fulfills all the expected results of all the listed test scenarios. Furthermore the maximum measured iteration duration for all these tests is below 10s.即6 個場景全部達(dá)成預(yù)期結(jié)果擴容達(dá) 1000 節(jié)點、縮容精確到目標(biāo)節(jié)點數(shù)、不可移除節(jié)點不被誤刪、不可調(diào)度 Pod 不阻塞正常調(diào)度所有測試中的實測最大迭代時長低于 10 秒遠(yuǎn)優(yōu)于預(yù)設(shè)的 30 秒上限據(jù)此正式聲明Cluster AutoscalerGA 版可擴展到 1000 節(jié)點、平均每節(jié)點 30 個 Pod。八、與 SLO 及性能預(yù)期的銜接這份測試報告的價值不止于一次性的壓測它還直接支撐了 cluster-autoscaler/FAQ.md 中對外公布的性能 SLO。FAQ 在 What are the Service Level Objectives for Cluster Autoscaler? 一節(jié)中說明CA 的核心 SLO 是延遲時間從 Pod 被調(diào)度器標(biāo)記為不可調(diào)度到 CA 向云廠商發(fā)出擴容請求的間隔在可擴展性測試中目標(biāo)是在大集群下最大 20 秒延遲據(jù)此向用戶給出的實際預(yù)期為小集群100 節(jié)點、每節(jié)點 ≤30 Pod延遲不超過 30 秒、平均約 5 秒大集群1001000 節(jié)點延遲不超過 60 秒、平均約 15 秒。同時 FAQ 也點明了達(dá)成該性能的前提條件與本文報告的適用邊界一脈相承所有 Pod不得使用 Pod affinity/anti-affinity——FAQ 明確指出當(dāng)前調(diào)度器中 affinity 謂詞的實現(xiàn)比其它所有謂詞加起來還慢約 3 個數(shù)量級會令 CA 在大集群上難以可用大集群中建議為 CA Pod 預(yù)留完整 1 核 CPU將 CA 放在過載節(jié)點上無法達(dá)到聲明的性能沒有對超過 1000 節(jié)點的集群進(jìn)行過性能測試支持更大規(guī)模并非 1.0 的目標(biāo)。這些說明既界定了本報告的測試邊界也為用戶在生產(chǎn)環(huán)境復(fù)現(xiàn)該性能水平提供了可操作的約束條件。九、局限性與適用前提總結(jié)基于文檔本身及倉庫佐證材料讀者在引用1000 節(jié)點 × 30 Pod這一結(jié)論時應(yīng)同時知悉其適用前提測試載體為 kubemark 模擬集群基于 kubemark_integration.md 描述的外部集群 Hollow Node 方案并非真實云廠商實例云廠商側(cè)的節(jié)點供應(yīng)延遲不計入 CA 迭代時長測試平臺為 GCP/GCE其他云廠商如 AWS由于缺少相應(yīng)測試基礎(chǔ)設(shè)施并未納入標(biāo)準(zhǔn)開發(fā)與發(fā)布流程的性能驗證見 FAQ.md測試上限即 1000 節(jié)點超過該規(guī)模沒有性能數(shù)據(jù)支撐該承諾依賴kubemark 云提供商在 Linux 環(huán)境下運行其他平臺僅有樁實現(xiàn)迭代時長 30 秒是設(shè)計上限實測最大值 10 秒是特定負(fù)載形態(tài)下的結(jié)果不代表所有場景。十、如何在倉庫中進(jìn)一步深入若想復(fù)現(xiàn)或深入理解本測試可在當(dāng)前倉庫中按以下路徑繼續(xù)探索scalability_tests.md —— 本文所解讀的原始報告kubemark_integration.md —— kubemark 云提供商的集成設(shè)計Hollow Node、NodeGroup 標(biāo)簽、--nodes配置kubemark_linux.go —— kubemark CloudProvider 的 Linux 實現(xiàn)雙集群 client、NodeGroup 增刪、min/max 邊界校驗main.go —— CA 主循環(huán)與RunAutoscalerOnce即迭代的執(zhí)行入口FAQ.md —— 由本測試衍生的 SLO 與性能預(yù)期說明README.md —— 1000 nodes running 30 pods each 特性聲明的對外入口e2e/cluster_size_autoscaling.go 與 e2e/e2e_test.go —— 面向真實集群的端到端伸縮驗證可作為理解測試執(zhí)行方式的補充材料。綜上這份可擴展性測試報告為 Cluster Autoscaler 的 GA 承諾提供了完整的方法論與數(shù)據(jù)支撐以迭代時長 ≤ 30 秒作為響應(yīng)性度量以 kubemark 低成本構(gòu)建千節(jié)點模擬環(huán)境以六個覆蓋擴容/縮容極端形態(tài)的場景完成驗證最終以實測最大迭代時長 10 秒的結(jié)論確立了 1000 節(jié)點 × 30 Pod 的規(guī)?；芰€。對使用者而言理解其定義、測試設(shè)計與適用邊界遠(yuǎn)比記住一個1000 節(jié)點的數(shù)字更有價值?！久赓M下載鏈接】autoscalerAutoscaling components for Kubernetes項目地址: https://gitcode.com/GitHub_Trending/au/autoscaler創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考