推出 GKE 待机缓冲区：以更低成本提升节点启动速度

标题：GKE 待机缓冲区加速自动扩缩容，降低支出

来源网址：https://cloud.google.com/blog/products/containers-kubernetes/gke-standby-buffers-speed-up-autoscaling-for-less-spend/

发布时间：2026-06-01

Markdown 内容： 应用所有者和平台工程师长期以来面临一个艰难的选择：要么过度配置资源以确保快速启动，从而导致高昂成本；要么最小化成本，但不得不忍受缓慢的冷启动。

我们很高兴宣布一种解决此权衡问题的方案：Google Kubernetes Engine 待机缓冲区。该功能建立在今年早些时候推出的 GKE 活跃缓冲区 基础之上，后者是 Kubernetes CapacityBuffers API 的原生实现，可轻松预置随时可用的容量以应对流量激增，为新 Pod 提供近乎零延迟的启动体验。然而，活跃缓冲区仍需在性能与成本之间做出权衡。新的 GKE 待机缓冲区通过为您的 GKE 集群维护低成本、已暂停的容量缓冲区来帮助缓解这一问题。其成本开销仅为个位数百分比，GKE 待机缓冲区可让您以几乎可忽略的成本开销实现工作负载的近乎即时调度。这对各类工作负载均适用——通用型、代理型及介于两者之间的所有类型。

在相同流量负载下，未启用待机缓冲区的集群经历了严重的延迟峰值，P50、P95 和 P99 指标被卡在 4 至 6 分钟之间。相反，启用了待机缓冲区的集群保持了仅个位数秒的 P50 延迟，而其 P95 和 P99 指标短暂飙升至一分钟，随后迅速恢复到个位数秒。两种设置的可分配核心成本相似，使得缓冲区方法效率更高。

**问题：高成本与高延迟**

传统上，使用标准 Kubernetes 的自动扩缩容虽然有效，但速度较慢。流量激增或批处理作业要求集群自动扩缩器配置新节点，导致 Pod 处于挂起状态。为避免延迟，您不得不采用笨拙的变通方案，例如降低 Horizontal Pod Autoscaler（HPA）阈值或管理所谓的“气球 Pod”。这些变通方案代价高昂：

• 管理气球 Pod 在操作上复杂，需要手动配置并持续维护优先级类和资源请求，以确保其正常运行。

• 降低 HPA 阈值会增加空闲（浪费）空间，且该空间随节点池规模线性增长。

GKE 活跃缓冲区和待机缓冲区均允许以声明式方式定义容量，从而消除对笨重且运维负担沉重的变通方案的需求。

此外，GKE 待机缓冲区通过将节点状态存储到磁盘、释放计算和内存成本，仅保留持久磁盘和 IP 地址成本，从而降低基础设施成本。再结合活跃缓冲区，您可以实现近乎即时的 Pod 调度，其性能接近过度配置，但价格却非常实惠。

视频 3

**活跃缓冲区与待机缓冲区协同工作**

所有 GKE 容量缓冲区的工作原理类似于 YouTube 等平台上的视频流媒体。通过主动尝试在需求到来前预置和管理可用容量（类似于预先下载视频内容），GKE 可确保资源在需要时随时可用。

随着本次发布，这两种容量缓冲区可协同工作：

• 活跃缓冲区：集群自动扩缩器会在现有集群节点上预留足够容量以容纳预定义数量的 Pod，并在必要时配置额外节点。选择此即用型缓冲区，为对延迟最敏感的工作负载提供容量。

• 待机缓冲区：节点预先配置并完全初始化，包含必要的组件（如 Kubernetes DaemonSets），并有时间预加载镜像，然后被暂停，底层计算容量被释放以节省成本。当需求激增时，这些节点恢复速度比创建全新节点快 2-3 倍，弥合了冷启动与始终在线容量之间的差距。

活跃缓冲区覆盖初始激增，直到待机缓冲区恢复。系统优先从待机缓冲区补充活跃缓冲区。待机缓冲区处理延长负载并防止节点冷启动过慢。当待机缓冲区重新填充时，它们最初会进入活跃状态一段可配置的时间，之后再被暂停，从而在持续流量负载期间提供额外的活跃容量支持。

**早期基准测试**

在我们的测试中，使用待机缓冲区使我们能够以比完全过度配置低高达 90% 的成本，实现低于一秒的 Agent Sandbox 调度延迟。

**针对业务需求优化**

企业始终面临优化资源消耗并简化运营的压力。我们认识到，组织需要更智能的工具来管理偶发性和突发性工作负载，因此我们努力快速交付待命缓冲区。如今，无论您运行的是代理、批处理作业、CI/CD 流水线、游戏服务器还是突发性工作负载，GKE 容量缓冲区都能让您动态平衡性能与成本。您终于可以定义自己的“保险策略”以应对流量激增，而无需为此支付高昂费用。借助 GKE 待命缓冲区，您可以：

1. 规避冷启动： 由待命缓冲区挂起的节点恢复速度比新建节点快 2-3 倍，从而在流量激增和持续负载期间降低 Pod 调度延迟。

1. 享受更低的成本： 待命缓冲区的成本仅为活跃容量的一小部分，因为底层虚拟机处于挂起状态。您只需为存储和 IP 地址付费，而非完整的计算时长。

1. 获得声明式控制： 使用简单、原生的声明式 CapacityBuffers API 替代复杂的气球 Pod 变通方案，明确指定所需的余量，其余交由 GKE 处理。

_“使用 GKE 待命容量缓冲区后，我们的就绪时间从数分钟缩短至 30 秒，且价格非常实惠。”_

_- Pedro Spagiari，Unico 首席架构师_

**开始使用**

准备好提升性能并节省成本了吗？

• 首先，在集群中定义一个 CapacityBuffer 资源，以指定目标缓冲区大小。

• 尝试在待命缓冲区与活跃缓冲区之间取得平衡：待命缓冲区可降低持续负载下的 Pod 调度延迟，活跃缓冲区则可应对即时不可预测的容量需求。

让我们来看一个如何为 Deployment 配置缓冲区并同时使用自定义 ComputeClasses 的示例。

基础设置

首先进行一些基本设置，创建命名空间：

然后，创建一个自定义 ComputeClass（可选）：

定义缓冲区单元大小

您可以使用 PodTemplate 作为缓冲区单元大小的参考。您也可以为特定部署或任何定义了 scale 子资源 的对象创建缓冲区。

创建缓冲区

最后，通过引用我们的 PodTemplate 创建一个 CapacityBuffer 对象。此处，您创建一个包含 50 CPU 和 50 GB 内存的待命缓冲区：

以及一个包含七个 5 CPU 和 5 GB 内存的活跃缓冲区（可选）：

最后，将上述对象应用到您的集群中。完成！

现在，任何能够调度到缓冲区预留空间中的现有或未来部署都将受益于更快的 Pod 调度延迟。

测试缓冲区

您可以检查缓冲区的状态。在 Kubernetes 中，挂起的节点可通过条件 Suspended 识别。

预期输出如下，并等待待命缓冲区进入挂起状态。

要测试缓冲区，请创建一个部署并对其进行扩缩容。

将此部署扩缩至两个副本，使其分配到活跃缓冲区以实现即时调度。随后，活跃缓冲区会立即从待命缓冲区补充。同时，待命缓冲区开始预配新节点。

如果您进一步将部署扩缩至 50 个副本，所有副本将在节点恢复后调度到待命缓冲区。用于补充待命缓冲区的新节点在短时间内充当活跃缓冲区，提供临时的活跃待命增强。因此，在此期间将部署进一步扩缩至 100 个副本时，您可能会发现新副本受益于即时调度。

**GKE 待命缓冲区最佳实践**

使用 GKE 待命缓冲区时，请考虑以下几点：

1. 定义足够大的待命缓冲区，以覆盖您预期遇到的持续负载，使缓冲区能够在后台从冷启动状态补充。足够大的待命缓冲区可将最大 Pod 调度延迟降至节点恢复所需的时间——约 30 秒。

1. 当缓冲区开始被使用并补充时，新的缓冲区节点最初会进入活跃状态，之后再挂起。这有助于在持续负载期间提升活跃容量。

1. 如果您的应用要求最低的 Pod 调度延迟，请定义足够大的活跃缓冲区，以覆盖在待命缓冲区节点恢复前可能出现的任何初始峰值。系统优先通过消耗待命缓冲区来补充活跃缓冲区。足够大的活跃缓冲区和待命缓冲区可帮助您以远低于过度预配的成本实现一秒钟内的 Pod 调度延迟。

1. 尝试不同的缓冲区大小，以获得最适合您工作负载的结果。

为此，我们创建了一个模拟器，帮助您根据性能目标调整缓冲区大小，详见 https://github.com/gke-labs/buffers-simulator。

**亲自尝试！**

GKE 中的活跃缓冲区和待命缓冲区提供了一种原生解决方案，通过维护温热和待命容量缓冲区，实现低延迟且经济高效的工作负载扩缩容。通过规避缓慢的节点冷启动，缓冲区帮助性能关键型应用应对突发流量高峰。该功能用简单、声明式的 API 替代了复杂的手动变通方案（如气球 Pod），并支持固定、百分比或资源限制型缓冲策略，帮助您以经济高效的方式维持严格的服务级别目标，而无需为峰值过度预配资源。

备用缓冲区适用于运行版本 1.36.0-gke.2253000 或更高版本的 GKE 集群。如需开始使用缓冲区，请参阅文档。

发布于

• 容器与 Kubernetes
• GKE