Google Kubernetes Engine now lets the Horizontal Pod Autoscaler consume Prometheus‑style metrics directly from Cloud Monitoring, using native PromQL queries. By eliminating the need for external adapters, the change reduces latency, simplifies configuration, and removes a layer of operational and IAM complexity for teams that already rely on GKE custom metrics.
What Changed in GKE Autoscaling
Earlier this year GKE added native support for custom pod metrics, allowing metrics to be sent straight to the HorizontalPodAutoscaler without an external collector. The latest update extends that capability to Prometheus metrics: the platform’s controller can evaluate PromQL expressions against metrics stored in Cloud Monitoring via the Google Managed Service for Prometheus. The result of the query is fed to the HPA as an AutoscalingMetric resource. During the preview phase the feature works with managed Prometheus data; a future general‑availability release will also accept self‑hosted Prometheus endpoints.
Impact on Platform Operations
Previously, scaling on complex signals—such as Pub/Sub backlog size, inference service QPS, or high‑percentile response latency—required deploying a Stackdriver Custom Metrics Adapter or a Prometheus adapter. Those adapters added three notable burdens:
- Management overhead: platform owners had to install, configure, patch, and monitor additional pods.
- Reliability risk: the adapter pods formed an extra failure point in the autoscaling feedback loop.
- IAM complexity: secure communication demanded mapping Kubernetes service accounts to Cloud service accounts with appropriate permissions.
The new built‑in path removes these adapters. The controller lives on the GKE control plane and only launches a system pod on user nodes when a PromQL‑based AutoscalingMetric is present. If no such metric is defined, the controller remains idle, meaning no extra resource consumption.
Security and IAM Considerations
Because the metric collection now occurs inside the managed control plane, the explicit service‑account mapping required for third‑party adapters is no longer necessary. This reduces the surface area for permission mis‑configurations. However, the underlying Cloud Monitoring data still respects the existing IAM policies governing read access to metric resources, so teams must ensure that the service accounts used by the HPA have the appropriate monitoring.timeSeries.list permission. The shift also means that any compromise of the adapter pods is no longer a vector; the autoscaling path is confined to the GKE control plane and the user node pod that runs only when needed.
Related CloudNinjas coverage: Google Cloud.
What This Means For Practitioners
For AI engineers, platform engineers, and SREs, the immediate benefit is a leaner autoscaling stack: define a AutoscalingMetric with a PromQL expression, and the HPA will react to it without extra components. Operational teams can retire existing adapter deployments, reducing patch cycles and monitoring load. Security teams should review the IAM bindings for the HPA’s service account to confirm it has only the necessary monitoring read scope. Going forward, keep an eye on the GA timeline for self‑hosted Prometheus support, as that will broaden the applicability of this pattern to on‑prem or hybrid environments.
