2026 年 9 月 23 日，Google Cloud 博客发布 GKE 1.37 的原生缩容到零能力，面向批量处理器、事件驱动 worker 与开发环境等间歇运行的负载，让它们缩容到零副本、停止消耗资源，并在需求回升时基于 GKE capacity buffer 快速重启。官方把这项能力定位为云原生弹性伸缩的一种替代方案，强调它是托管服务、无需额外组件。
间歇负载为何长期占用算力
Kubernetes 极大改进了资源管理，但对运行并不连续的负载仍不理想：批量处理器、事件驱动 worker 与开发环境在等待任务时依旧占用计算资源，推高云成本。长期以来的主流做法是引入 KEDA（Kubernetes Event-Driven Autoscaling）实现缩容到零，但官方指出它会给环境增加复杂度——需要管理 ScaledObject CRD 与 operator，大型集群的 YAML 配置可能超过 1 万行，且轮询间隔与跳数会增加冷启动延迟。
GKE 1.37 的做法
GKE 1.37 把缩容到零直接内置到控制平面：工作负载可完全缩容到零副本，需求返回时借助 GKE capacity buffer 快速重启，从而把“始终在线的基础设施成本”与“工作负载就绪”解耦。官方对比表显示，GKE 方案是托管服务、无需额外组件，使用原生 HPA 与 CRD，配置精简；内部化的信号路径也缩短了反应时间。这意味着容器编排平台自身承担了原先由第三方组件完成的弹性职责。
对云成本与平台团队的影响
对平台工程与基础设施团队而言，把缩容到零纳入托管能力，既减少了需要自维护的组件数量，也让弹性伸缩策略更集中、更易审计。对成本敏感的业务，间歇型负载在空闲期不再计费，可直接改善 FinOps 指标；对开发环境这类按需使用的场景，重启速度则决定了开发者的等待体验。
使用建议
官方建议先从批量任务、事件驱动 worker 与开发环境这类负载入手验证，评估冷启动可接受的延迟上限与 capacity buffer 的预留规模，再逐步替换既有的 KEDA 配置。迁移过程中应保留原有的指标与告警，确认缩容到零不会影响下游依赖方的超时假设。
小结
Google Cloud 于 2026 年 9 月 23 日为 GKE 1.37 引入原生缩容到零，以托管服务、原生 HPA 配置与 capacity buffer 快速重启为看点，是云原生基础设施领域弹性伸缩方向的一次重要演进。