Cluster Autoscaler 千节点可扩展性测试报告解读：1000 节点 × 30 Pod 的规模承诺与验证方法

Cluster Autoscaler 千节点可扩展性测试报告解读：1000 节点 × 30 Pod 的规模承诺与验证方法

【免费下载链接】autoscalerAutoscaling components for Kubernetes项目地址: https://gitcode.com/GitHub_Trending/au/autoscaler

本文以 cluster-autoscaler/proposals/scalability_tests.md 为核心，系统解读 Kubernetes Cluster Autoscaler（CA）在 GA 版本所声明的可扩展性目标——1000 节点、每节点 30 个 Pod——背后的定义、测试环境、六大测试场景与实测结论，并对照当前仓库中的 kubemark 云提供商实现与 FAQ 中的 SLO 说明进行源码级印证。读完本文，你将理解 CA"规模化到什么程度才算达标"的评判标准、如何借助 kubemark 以低成本搭建千节点测试集群，以及该规模承诺的适用前提与边界。

一、为什么需要一份可扩展性测试报告

作为 Cluster Autoscaler 走向 GA（正式发布）的一部分，项目团队需要向用户量化承诺这一组件在多大规模的集群上依然可用。仓库根目录的 cluster-autoscaler/README.md 在特性清单中明确写着 "Support for 1000 nodes running 30 pods each"，并直接指向本测试报告作为依据；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不是一份内部实验记录，而是对外发布的规模承诺依据文档：它定义了"CA 扩展到 1000 节点"的确切含义、用于度量的性能指标、测试环境的搭建方式，以及支撑该结论的实测数据。

二、"CA 可扩展到 1000 节点"的确切定义

该文档首先澄清了一个容易模糊的概念——什么才算"可扩展"：

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 在目标规模下保持响应，能够在合理时间窗内完成集群的扩容（scale up）与缩容（scale down）。文档进一步解释了为什么要强调这一点：

• 若 CA 失去响应，可能被 liveness probe（存活探针）杀掉；
• 或者无法在需要时提供/释放计算资源，导致集群无法承载新增工作负载；
• 或者由于没有及时缩容而产生更高的云厂商账单。

可见，可扩展性不仅是"功能正确"，更是"时效正确"——CA 必须在用户可感知的延迟范围内对集群状态变化作出反应。

三、预期性能标准：单次迭代 30 秒上限

为了把"反应时间短"落实为可测量的指标，文档定义了**迭代（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

一次迭代 = 一次完整的"集群状态分析 → 判断是否需要调整集群规模 → 执行相应调整"循环。CA 能否及时响应，直接取决于单次迭代的耗时。由此给出量化标准：

迭代时长的上限设定为 30 秒。

从当前仓库源码看，这一"迭代"正是 cluster-autoscaler/main.go 中主循环所执行的核心动作：loop.RunAutoscalerOnce(ctx, autoscaler, healthCheck, lastRun)在autoscalingOpts.ScanInterval定时触发下反复运行，而循环内部即为一次完整的伸缩决策处理。换言之，30 秒的上限直接约束的就是这条主循环路径上的分析-决策-调整总耗时。

四、测试环境：kubemark + GCP 的千节点模拟集群

在真实公有云上直接拉起 1000 台节点做压测成本极高。为此，本报告使用了 Kubernetes 社区的可扩展性测试利器kubemark，在 GCP 上构建了一套约 1000 节点的测试集群。原文给出的具体配置如下：

组件	规格	说明
1 个 master	1 核 VM	外部集群控制面
17 个节点	8 核 VM，每核最多运行 8 个 Kubemark 节点	承载 Hollow Node
1 个 Kubemark master	32 核 VM	kubemark 集群控制面
1 台独立 VM	—	专用于运行 Cluster Autoscaler

这套拓扑的精髓在于用少量真实 VM 模拟出千节点规模的假象：真实集群中只有 18 台机器，但通过 kubemark 的 Hollow Node 机制，在逻辑上呈现为 1000 个 K8s 节点，从而以极低成本触发 CA 的全部伸缩逻辑。

仓库中的 cluster-autoscaler/proposals/kubemark_integration.md 对这一机制给出了更完整的背景说明：

• kubemark 环境包含两个集群：外部集群（external cluster，如 GCE 上的普通集群）与运行其上的 kubemark 集群（拥有独立的 master）；
• **Hollow Node（空心节点）**以 Pod 形式运行在外部集群中，由 Replication Controller 统一创建与管控；
• 每个 Hollow Node 对应一个逻辑节点，使 CA 看到的是一个"节点数万级"的大集群，而实际占用的物理资源极小。

CA 侧对应的实现位于 cluster-autoscaler/cloudprovider/kubemark/kubemark_linux.go（注意：该云提供商仅在 Linux 上编译，见 kubemark_other.go 中的桩实现，非 Linux 平台直接klog.Fatal提示 only supported on Linux）。从源码结构看，其关键设计包括：

• ProviderName = "kubemark"，并通过builder.RegisterCloudProvider注册，甚至被设为默认云提供商；
• BuildKubemark同时维护两个 client：一个连接外部集群（InClusterConfig），另一个连接 kubemark 集群（优先读取/kubeconfig/cluster_autoscaler.kubeconfig），并各自建立 informer 与KubemarkController；
• NodeGroup 通过dynamic.SpecFromString(value, true)解析命令行传入的--nodes={MIN}:{MAX}:{NG_LABEL_VALUE}规格来构建，minSize/maxSize直接决定伸缩边界；
• IncreaseSize通过SetNodeGroupSize增加目标规模，DeleteNodes在低于MinSize时拒绝删除，DecreaseTargetSize只允许缩减尚未创建完成的节点——这与 kubemark_integration.md 中"以 singleton Replication Controller 方式管理节点"的设计一一对应。

关于 NodeGroup 的组织方式，kubemark_integration.md 明确：同一 NodeGroup 的节点通过标签autoscaling.k8s.io/nodegroup标识，CA 启动时会解析--nodes={MIN}:{MAX}:{NG_LABEL_VALUE}，若集群中该标签的节点不足{MIN}个则自动补齐。这样即便 CA 重启或崩溃，NodeGroup 的归属关系也不会丢失。

五、测试执行与指标采集方法

所有测试场景共享同一套通用负载目标：约 1000 个节点、每节点约 30 个 Pod。执行方式为：

During each test scenario we have collected iteration duration histogram.

即在每个场景运行期间持续采集迭代时长直方图（iteration duration histogram），用迭代时长的分布来评估 CA 的响应性。这与第三节定义的 30 秒迭代上限形成闭环：30 秒是阈值，直方图数据则是判定依据。

六、六大测试场景详解

文档共设计了 6 个场景，按方向分为 3 个 Scale-up（扩容）与 3 个 Scale-down（缩容），覆盖了集群负载突发变化的典型形态。

6.1 [Scale-up] 从零开始扩容（Scales up at all）

• 场景：集群已饱和，新创建的 Pod 必须依赖扩容才能运行，模拟集群中的突发活动潮；
• 起始状态：1 个节点上运行 2 个 Pod，节点已满（无法再容纳新 Pod）；
• 操作：调度约 30 000 个新 Pod（触发扩容到 1000 节点、每节点 30 Pod）；
• 预期结果：集群达到 1000 节点，所有 Pod 运行，所有节点满载。

该场景验证的是 CA 扩容链路的最基本情况——能否在饱和集群中为大规模 Pod 洪峰完成从 1 到 1000 的扩容。

6.2 [Scale-up] 在承接既有扩容负载的同时继续扩容

• 场景：集群已饱和，分两批创建 Pod，两批之间有小间隔，模拟 CA 正在扩容时又迎来新一轮活动突发；
• 起始状态：1 节点、2 Pod，节点已满；
• 操作：先调度约 21 000 个新 Pod（触发扩容到 700 节点）→ 等待约 1.5 分钟 → 再调度约 9 000 个新 Pod（触发扩容到 1000 节点）；
• 预期结果：集群达到 1000 节点，所有 Pod 运行，所有新节点满载。

该场景比 6.1 更严苛：CA 必须在"上一轮扩容尚未完成"的中间态继续响应新一轮扩容请求，验证其状态机的连续性。

6.3 [Scale-down] 缩容空节点

• 场景：集群中存在大量空节点，等待 CA 自动缩容，模拟集群活动度的骤降；
• 起始状态：700 个 Pod 运行在 700 个节点上（节点约 70% 满），集群共 1000 节点；
• 操作：不做任何事；
• 预期结果：300 个节点被移出集群。

该场景验证 CA 的闲置节点回收能力——直接决定云账单的高低。

6.4 [Scale-down] 缩容低利用率节点

• 场景：集群存在大量低利用率节点，等待 CA 缩容，同时迫使 CA 计算如何重调度 Pod；
• 起始状态：52 000 个 Pod 运行在 1000 个节点上，其中 300 个节点约 30% 满、700 个节点约 70% 满，节点组最小规模 = 970；
• 操作：不做任何事；
• 预期结果：30 个节点被移出集群。

与 6.3 的"空节点直接删"不同，本场景中节点上仍有 Pod，CA 必须基于模拟调度器评估"这些 Pod 能否搬到其余节点"，只有搬得走才会缩容，因此对计算开销的考验更大（节点规模、Pod 数量均为所有场景之最）。

6.5 [Scale-down] 不缩容"低利用率但不可移除"的节点

• 场景：集群存在大量低利用率但无法移除的节点，模拟带有不可移除节点的活动骤降；
• 起始状态：1000 个 Pod 运行在 1000 个节点上，其中 700 个节点 90% 满，300 个节点约 30% 满（因 host port 冲突等原因低利用率却不可移除）；
• 操作：不做任何事；
• 预期结果：集群规模不变，所有 Pod 继续运行。

该场景验证的是缩容逻辑的保守面——不能为了缩容而破坏正在运行的 Pod，即使节点利用率很低，只要 Pod 无法迁移就必须保持原状。

6.6 [Scale-up] 忽略不可调度 Pod，继续调度可调度 Pod

• 场景：创建不可调度的 Pod 不应影响可调度 Pod 的调度；
• 起始状态：1 节点上运行 1 个 Pod，另有 1000 个不可调度 Pod 处于 Pending；
• 操作：调度 30 000 个 Pod（触发扩容到 1000 节点、每节点 30 Pod）；
• 预期结果：集群规模 1000，所有可调度 Pod 运行，不可调度 Pod 保持 Pending。

该场景验证 CA 不会因 Pending 池中存在"永远无法满足"的 Pod（如资源请求超出任何节点上限）而阻塞或拖慢正常 Pod 的扩容路径。

七、测试结果与最终结论

文档给出的结论非常直接：

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 个场景全部达成预期结果（扩容达 1000 节点、缩容精确到目标节点数、不可移除节点不被误删、不可调度 Pod 不阻塞正常调度）；
• 所有测试中的实测最大迭代时长低于 10 秒，远优于预设的 30 秒上限；
• 据此正式声明：Cluster Autoscaler（GA 版）可扩展到 1000 节点、平均每节点 30 个 Pod。

八、与 SLO 及性能预期的衔接

这份测试报告的价值不止于一次性的压测，它还直接支撑了 cluster-autoscaler/FAQ.md 中对外公布的性能 SLO。FAQ 在 "What are the Service Level Objectives for Cluster Autoscaler?" 一节中说明：

• CA 的核心 SLO 是延迟时间：从 Pod 被调度器标记为不可调度，到 CA 向云厂商发出扩容请求的间隔；
• 在可扩展性测试中，目标是在大集群下最大 20 秒延迟；
• 据此向用户给出的实际预期为：小集群（<100 节点、每节点 ≤30 Pod）延迟不超过 30 秒、平均约 5 秒；大集群（100～1000 节点）延迟不超过 60 秒、平均约 15 秒。

同时 FAQ 也点明了达成该性能的前提条件，与本文报告的适用边界一脉相承：

• 所有 Pod不得使用 Pod affinity/anti-affinity——FAQ 明确指出当前调度器中 affinity 谓词的实现比其它所有谓词加起来还慢约 3 个数量级，会令 CA 在大集群上难以可用；
• 大集群中建议为 CA Pod 预留完整 1 核 CPU，将 CA 放在过载节点上无法达到声明的性能；
• 没有对超过 1000 节点的集群进行过性能测试，支持更大规模并非 1.0 的目标。

这些说明既界定了本报告的测试边界，也为用户在生产环境复现该性能水平提供了可操作的约束条件。

九、局限性与适用前提总结

基于文档本身及仓库佐证材料，读者在引用"1000 节点 × 30 Pod"这一结论时应同时知悉其适用前提：

1. 测试载体为 kubemark 模拟集群（基于 kubemark_integration.md 描述的外部集群 + Hollow Node 方案），并非真实云厂商实例，云厂商侧的节点供应延迟不计入 CA 迭代时长；
2. 测试平台为 GCP/GCE，其他云厂商（如 AWS）由于缺少相应测试基础设施，并未纳入标准开发与发布流程的性能验证（见 FAQ.md）；
3. 测试上限即 1000 节点，超过该规模没有性能数据支撑；
4. 该承诺依赖kubemark 云提供商在 Linux 环境下运行，其他平台仅有桩实现；
5. 迭代时长 30 秒是设计上限，实测最大值 <10 秒是特定负载形态下的结果，不代表所有场景。

十、如何在仓库中进一步深入

若想复现或深入理解本测试，可在当前仓库中按以下路径继续探索：

• scalability_tests.md —— 本文所解读的原始报告；
• kubemark_integration.md —— kubemark 云提供商的集成设计（Hollow Node、NodeGroup 标签、--nodes配置）；
• kubemark_linux.go —— kubemark CloudProvider 的 Linux 实现（双集群 client、NodeGroup 增删、min/max 边界校验）；
• main.go —— CA 主循环与RunAutoscalerOnce，即"迭代"的执行入口；
• FAQ.md —— 由本测试衍生的 SLO 与性能预期说明；
• README.md —— "1000 nodes running 30 pods each" 特性声明的对外入口；
• e2e/cluster_size_autoscaling.go 与 e2e/e2e_test.go —— 面向真实集群的端到端伸缩验证，可作为理解测试执行方式的补充材料。

综上，这份可扩展性测试报告为 Cluster Autoscaler 的 GA 承诺提供了完整的方法论与数据支撑：以"迭代时长 ≤ 30 秒"作为响应性度量，以 kubemark 低成本构建千节点模拟环境，以六个覆盖扩容/缩容极端形态的场景完成验证，最终以"实测最大迭代时长 < 10 秒"的结论确立了 1000 节点 × 30 Pod 的规模化能力基线。对使用者而言，理解其定义、测试设计与适用边界，远比记住一个"1000 节点"的数字更有价值。

【免费下载链接】autoscalerAutoscaling components for Kubernetes项目地址: https://gitcode.com/GitHub_Trending/au/autoscaler