GKE adds VPA decision logs in Public Preview to expose vertical autoscaling choices

GKE launches VPA decision logs in Public Preview

Google's GKE team has introduced a Public Preview of VerticalPodAutoscaler (VPA) logs, a feature that streams structured records of the autoscaler's sizing decisions into Cloud Logging. According to a Google Cloud post on dev.to, the capability is available on clusters running GKE version 1.36.0-gke.1601000 or newer.

Until now, engineers who delegated CPU and memory sizing to the VPA had few ways to see why the controller acted. Standard Kubernetes events are transient, often disappearing within an hour, and kubectl describe vpa provides only a snapshot. The post describes the resulting blind spot in practical terms: if a pod was evicted during an overnight batch job, or an in-place resize failed because the node lacked capacity, reconstructing the cause the next morning was difficult.

How the logging works

VPA logs are emitted by the vpa-controller control plane component and land in Cloud Logging under the container.googleapis.com/vpa-controller log destination, as part of the KCP_VPA control-plane logging component. Each entry arrives as structured JSON describing the target workload, the evaluation state and the calculated resource bounds.

The post documents four operation types:

• UPDATE_RECOMMENDATION — emitted roughly once per minute per VPA object, recording the raw recommendation: lower bound, upper bound, target, uncapped target and a confidence rating.
• EVICT_POD — logged when the updater evicts a pod to apply new resource requests under Recreate mode, or as a fallback when an in-place resize fails.
• APPLY_RECOMMENDATION_ON_EVICTION — logged when a replacement pod receives resized requests during admission.
• APPLY_RECOMMENDATION_IN_PLACE — logged when VPA adjusts a running pod's requests and limits without a restart under InPlaceOrRecreate mode.

Every entry carries a state — SUCCEEDED, SKIPPED or FAILED — plus a reason string. When an operation succeeds, the reason explains whether the applied values diverged from the raw recommendation because of policy caps or Autopilot compute ratios. A confidence field separates LOW, meaning the recommender has processed fewer than 10 metric samples, from HIGH, meaning 10 or more samples and a more mature usage profile.

Enabling the feature and querying the logs

Activation is a cluster-level logging change made through the Google Cloud CLI: KCP_VPA is added to the --logging flag alongside SYSTEM when creating a cluster, or appended to an existing cluster's configuration with an update command. The post cautions operators to carry over their currently configured logging components during updates so nothing is accidentally disabled, and notes that a describe command can confirm KCP_VPA is active.

Once enabled, the events can be searched in Logs Explorer. The post offers example filters: selecting on the control-plane resource type and a workload name surfaces all decision events for that workload; filtering on operation and state reveals skipped or failed in-place resizes; and filtering UPDATE_RECOMMENDATION entries by LOW confidence audits recommendations built on thin data. Site reliability teams can use these queries to diagnose scaling anomalies, measure how often resizes occur, and identify workloads that need longer profiling before automated actuation is trusted.

Why it matters

Automated rightsizing has always carried a trust problem: handing pod sizing to a controller means accepting evictions and resizes whose justification is invisible. Persistent, structured decision logs turn that opaque process into an audit trail — operators can see why a pod was evicted, whether a recommendation was clipped by policy or Autopilot ratios, and how confident the recommender was in its numbers.

The post positions the feature alongside existing Horizontal Pod Autoscaler logging, giving teams visibility across both scaling dimensions, and frames it as groundwork for intent-based workload management, where automated agents and governance pipelines need a complete historical record of vertical scaling decisions before they can safely act on them. The main constraint is availability: as a Public Preview it requires a recent GKE version, so it mainly benefits operators already on, or able to upgrade to, 1.36.0-gke.1601000 or newer.