2026 年 9 月 23 日 Google Cloud 给 GKE 的 HPA 加上内置 PromQL 指标，免装外部适配器，每 15 秒轮询一次。 前置部署 Forward Deployed Engineer（FDE）在客户现场最常被要求兑现的承诺，是「业务量上来时集群自己扛住」。前置部署 Forward Deployed Engineer（FDE）交付的 Kubernetes 平台，扩缩容的输入信号几乎从来不只有 CPU 与内存：推理服务要看每秒查询数与 KV 缓存占用，订单系统要看消息队列积压，Web 服务要看响应时间的 95 分位。前置部署 Forward Deployed Engineer（FDE）过去要让水平自动扩缩器读懂这些信号，必须在客户集群里多装一层 Prometheus 适配器，而这层适配器也是最容易在深夜出问题的一层。本条把 Google Cloud 在 2026 年 9 月给出的内置做法拆成可以直接抄的配置，并写明它现在还不覆盖什么。 ## 一、一句话结论 GKE 现在可以只用两个 Kubernetes 对象，把任意 PromQL 指标接到水平自动扩缩器上：一个 AutoscalingMetric 声明取哪条指标，一个 HorizontalPodAutoscaler 声明读到多少就扩。前置部署 Forward Deployed Engineer（FDE）在客户现场要交付的扩缩容，从「装一个适配器并长期维护它」变成「写两个 YAML 并验证它」。 ## 二、原来的做法：四步链路加一道 IAM 迷宫 Google Cloud 在 2026 年 3 月 6 日的官方博客里，把改造前的链路写成了四步。 - 第一步，让 Pod 把指标导出到某个监控后端。 - 第二步，在集群里装一个中间人：custom-metrics-stackdriver-adapter 或 prometheus-adapter，由它在监控后端与 HPA 之间做翻译。 - 第三步，走通 IAM：启用 Workload Identity Federation、创建 Cloud IAM 服务账号、创建 Kubernetes 服务账号并加注解、用 IAM policy binding 把两者绑定、再授予具体角色，五项缺一不可。 - 第四步，承担运行风险：扩缩容逻辑从此依赖可观测性栈的可用性，指标摄入变慢或适配器失败，扩缩容就一起停。 官方对第四步的措辞很直接：这形成了一种循环依赖，而多数 IT 实践不推荐这种配置，因为它让排障变复杂、并削弱服务的整体韧性。原文还提到，正因为配置自定义指标扩缩一向笨重且容易出错，不少团队干脆改用第三方方案，而第三方方案又要跟着 GKE 的升级周期同步。 ## 三、新做法：AutoscalingMetric 直连 Cloud Monitoring 与托管 Prometheus 2026 年 9 月 23 日的公告把范围从「Pod 自己暴露的指标」扩到「任何能用 PromQL 表达的指标」。HPA 现在可以直接消费 Cloud Monitoring 里、由 Google Managed Service for Prometheus 承载的指标，不再需要第三方适配器；官方说明这条路径复用了此前支撑 Pod 级指标的 AutoscalingMetric 接入层。 控制器的行为值得单独记一笔，因为它决定了资源开销：控制器运行在 GKE 控制平面上，只有当某个 PromQL 指标被真正请求时，才会在用户节点上拉起系统 Pod；如果没有任何 Prometheus 指标被配置，控制器直接关停，不留常驻开销。 配套的时间数字有三个：新的自动扩缩指标系统每 15 秒轮询一次后端；此前把自定义指标直连 HPA 的那次改造已把指标读取延迟压到 5 秒；官方称这套链路是高性能、低延迟的自动扩缩管道。 ## 四、第一步：声明 AutoscalingMetric 资源 官方给的第一个样例是把 Pub/Sub 订阅的未确认消息数当作扩缩容信号： ```yaml apiVersion: autoscaling.gke.io/v1beta1 kind: AutoscalingMetric metadata: name: gmp-metric spec: metrics: - promql: name: pubsub-queue-depth query: | { "pubsub.googleapis.com/subscription/num_undelivered_messages", subscription_id="my-subscription" } ``` 三个字段的含义要分清：metadata.name 是自定义资源的名字，spec.metrics[].promql.name 是这条指标在 GKE 内部的名字，query 才是 PromQL 本体。Cloud Monitoring 的指标名带 googleapis.com 前缀，标签选择器写在花括号里，样例用的是 subscription_id。 ## 五、第二步：把指标挂到 HPA 上 定义完成后，在标准的水平自动扩缩器里引用它，引用格式是三段式：autoscaling.gke.io 加竖线加自定义资源名、再加竖线加指标名。官方给出的全局聚合值场景配置是： ```yaml apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: worker-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: worker-deployment maxReplicas: 10 metrics: - type: External external: metric: name: autoscaling.gke.io|gmp-metric|pubsub-queue-depth target: type: AverageValue averageValue: 100 ``` 官方样例里 averageValue 旁边的那行注释是「维持每个 Pod 约 100 条队列深度」。三段式里任何一段写错，资源名、指标名或前缀对不上，引用都会落空；原文没有给出这种情形下的具体报错文案，排查时以「HPA 读不到指标」为起点更省时间。 ## 六、第三步：按 Pod 维度扩缩 单一聚合值适合队列深度、连接池这类全局信号。如果每个 Pod 各有自己的指标值，例如每个副本的内存占用或活跃请求数，就要走 Pod 维度。官方给的前提很明确：PromQL 必须带上 Pod 名字的标签，并在 AutoscalingMetric 里把 type 设为 Pods。 ```yaml apiVersion: autoscaling.gke.io/v1beta1 kind: AutoscalingMetric metadata: name: per-pod-stored-metric spec: metrics: - promql: name: container-memory-metric query: | sum by ("pod") (avg_over_time({"container_memory_working_set_bytes"}[5m])) type: Pods ``` 这一段里有两个可以直接复用的写法：sum by ("pod") 决定结果按 Pod 聚合，avg_over_time 配 [5m] 决定用 5 分钟滚动窗口而不是瞬时值。官方强调 PromQL 相对原生 gauge 的价值就在这里：可以跨时间窗口做平均、算 rate、算直方图分位。 ## 七、官方点名的三类场景 - 按 Pub/Sub 主题里未确认的消息数扩缩工作池。 - 按 Cloud Monitoring 或 Prometheus 里的每秒查询数扩缩推理服务。 - 按实测响应时间的 95 分位扩缩 Web 服务集群。 三类场景的共同点是信号都不在 CPU 和内存里。前置部署 Forward Deployed Engineer（FDE）在需求确认阶段可以把这三条当模板问客户：业务上最先到瓶颈的是队列、是吞吐，还是尾延迟。答案决定 PromQL 怎么写，也决定扩容是加副本还是加机器。 ## 八、常见坑与排查顺序 下面六条都是从官方两份配置示例的结构里直接读出来的规则，不是经验猜测；原文并未逐条给出报错文案。 1. 三段式引用必须完整。autoscaling.gke.io、资源名、指标名少一段或名字对不上，HPA 就取不到值，排查从 HPA 的事件与 AutoscalingMetric 对象的状态两头对。 2. Pod 维度必须带 Pod 标签。没有 sum by ("pod") 这类按 Pod 聚合的写法，就把 type 写成 Pods，语义不成立。 3. 查询窗口要显式写。想要滚动平均或速率就必须写区间选择器，只给一个瞬时值等于放弃 PromQL 相对原生 gauge 的全部好处。 4. 指标名的来源要分清。官方样例里 Cloud Monitoring 形态是 pubsub.googleapis.com/subscription/num_undelivered_messages，而容器内存这类来自自建或托管 Prometheus 的形态是 container_memory_working_set_bytes，两者写法不同。 5. 预览阶段读不到自建 Prometheus。当前只覆盖 Cloud Monitoring 与 Google Managed Service for Prometheus，自建 Prometheus 服务器是官方给出的 GA 计划项，不在预览范围内。 6. 权限依赖同项目。GKE 的 Default Node Service Agent 天然拥有同项目内 Cloud Monitoring 与托管 Prometheus 的读权限，跨项目或自定义最小权限节点的场景要重新确认。 ## 九、状态与适用条件 - 状态是预览，不是正式可用；官方明确把自建 Prometheus 支持放在 GA 阶段。 - 轮询周期是 15 秒，低于这个粒度的抖动不会被扩缩容动作看到。 - 指标来源限定在 Cloud Monitoring 与 Google Managed Service for Prometheus。 - 权限模型按同项目内的默认节点服务代理设计，这是官方口径下「无需额外 IAM 服务账号、密钥或联邦参数」的前提。 - 适用信号是能用 PromQL 表达的任何数值指标，包括速率、平均与分位；不适用的是无法量化成数值的业务判断。 ## 十、成本：为什么移除适配器能省钱 官方在 2026 年 3 月 6 日那篇里给了两条成本口径。第一，不再为只用于扩缩容决策的指标支付摄入费用。第二，更精确、更快的扩缩响应本身节省算力。 运维成本的下降是结构性的：不再有需要安装、配置、打补丁、监控的第三方组件，不再有读取外部系统的中间 Pod，也就不再有它们引入的额外失败点。前置部署 Forward Deployed Engineer（FDE）在报价时可以把这条写清楚：省掉的不是一笔许可费，而是一条需要长期值守的链路。 ## 十一、与缩容到零的衔接 同一条公告里提到，内置 PromQL 指标可以配合 HPA 的缩容到零能力使用：队列空了就把副本降到零，需要快速从零恢复时用 CapacityBuffers API。这套缓冲能力在 Google Cloud 2026 年 6 月 2 日的官方博客里有独立说明：暂停态的缓冲节点把节点状态存到磁盘、释放算力与内存成本，只保留持久盘与 IP 的费用，节点恢复比新建节点快 2 到 3 倍；缓冲节点的挂起等待时间默认 5 分钟，刷新频率默认 24 小时；在官方基准里它把 Agent Sandbox 的调度延迟做到亚秒级，同时相对完全超额配置的最大节省幅度达到 90%；Unico 的首席架构师公开的客户口径是从几分钟降到 30 秒。 ## 十二、回滚与退出 - 配置层回滚：删掉 HPA 里的那条指标条目，或直接删除 AutoscalingMetric 对象，扩缩容立刻回到只按 CPU 与内存决策；控制器在没有 PromQL 指标时自动关停，不残留常驻组件。 - 换后端退出：当前不支持自建 Prometheus，若客户已经以自建 Prometheus 为准，短期内应继续沿用原有适配器方案，等正式可用再迁移。 - 双轨窗口：两套机制可以并存，先用新路径跑双轨对比，确认读数与扩缩动作一致后再拆除适配器。 - 爆炸半径：整套改动只涉及扩缩容的读数来源，不触碰 Pod 自身代码与业务逻辑，因此回滚的影响范围限于副本数。 ## 十三、局限与未覆盖场景 - 功能处于预览状态，官方未公布正式可用的时间表，生产环境引入前要按预览功能的支持策略评估。 - 自建 Prometheus 未覆盖，这是官方明确留下的空缺，而很多客户的指标恰恰在自建实例里。 - 15 秒轮询是硬下界，秒级突发流量无法被这条链路感知。 - 跨项目与非默认权限模型未覆盖，官方说明的前提是同项目下的默认节点服务代理。 - 原文没有给出延迟、准确率或成本的前后量化对比表，全文可引用的量化指标只有 5 秒读取延迟与 15 秒轮询周期两项，其余为定性描述。 - 未覆盖多集群、多项目的指标聚合策略，也没有说明指标缺失时的降级行为。 ## 十四、实用结论 该行动的是三类人：把推理服务、队列消费者或 Web 服务放在 GKE 上、当前还依赖 prometheus-adapter 或 custom-metrics-stackdriver-adapter 的团队；需要为客户交付自动扩缩的 FDE；以及因为适配器故障做过事故复盘、想把这条链路从架构里拿掉的人。前置部署 Forward Deployed Engineer（FDE）可以把这条公告的价值理解为：扩缩容信号从一项集成工程降级成了一份配置清单。 具体做法五步。第一步，先确认前提：指标在 Cloud Monitoring 或托管 Prometheus 里，节点使用默认服务代理。第二步，写一个 AutoscalingMetric，spec.metrics[].promql.name 取一个稳定且可复用的短名。第三步，在 HPA 里用三段式引用，全局聚合信号用 type: External 配 averageValue，逐 Pod 信号在 AutoscalingMetric 里加 type: Pods 并用 sum by ("pod")。第四步，先用 kubectl describe hpa 观察读数是否出现，再观察副本数变化，不要一上来就把 maxReplicas 开到生产上限。第五步，把 PromQL 的窗口与阈值写进配置管理，并和业务方约定扩缩边界。 适用条件：指标可由 PromQL 表达、来源为 Cloud Monitoring 或托管 Prometheus、节点权限为项目内默认模型、业务能接受 15 秒的响应粒度。前置部署 Forward Deployed Engineer（FDE）在把这条链路写进交付文档时，应同时写明这三项前提，因为它们决定了客户环境能不能用。 回滚方式：删除 HPA 中的指标条目或删除 AutoscalingMetric 对象即可；如需回到适配器方案，重新部署原适配器并按原 IAM 绑定恢复，两条路径互不破坏对方。 ## 十五、与本站既有条目的差异 本站此前关于 Kubernetes 自动扩缩的条目只有一条，讲的是垂直 Pod 自动扩缩器 VPA 1.8.0 的 admission-controller 索引优化，作用对象是把单个 Pod 的资源请求调准。本条讲的是水平自动扩缩器的指标来源改造，作用对象是副本数由什么信号决定。两条针对的组件、信号与配置对象都不同。前置部署 Forward Deployed Engineer（FDE）可以按「先把单个 Pod 的资源调准，再决定副本数按什么信号动」的顺序使用这两条。 ## 原始来源 原始来源： https://cloud.google.com/blog/products/containers-kubernetes/native-support-for-prometheus-metrics-in-gke/ https://cloud.google.com/blog/products/containers-kubernetes/gke-now-supports-custom-metrics-natively https://cloud.google.com/blog/products/containers-kubernetes/gke-standby-buffers-speed-up-autoscaling-for-less-spend https://docs.cloud.google.com/kubernetes-engine/docs/how-to/autoscale-using-metrics#define-custom-metrics-promql