Under the hood: Kubernetes In-place Pod Resize
Historically, changing a pod’s resource requests or limits required deleting and recreating the pod. This disruptive process triggered container restarts, cache invalidation, and node rescheduling overhead.
To fix that, CPU startup boost builds on Kubernetes In-place Pod Resize (IPPR).
Tracked under KEP-1287, IPPR introduced dynamic, in-place resource mutation. Introduced as Alpha in Kubernetes 1.27, promoted to Beta in v1.33, and graduating to General Availability (GA) in v1.35, IPPR allows the Kubernetes control plane and kubelet to update container CPU and memory requests on running pods without restarting the container process.
GKE leverages IPPR within the VPA to apply startup CPU boosts at pod admission and smoothly step them down post-readiness.
How CPU startup boost works (pod lifecycle overview)
CPU startup boost operates across three distinct phases:
-
Admission phase: When you deploy a pod, the VPA admission webhook intercepts the creation request. It calculates the elevated CPU request based on your policy (e.g., 2x multiplier or +2 vCPUs) and injects the boosted CPU request along with tracking annotations into the pod spec.
-
Startup phase: The pod is scheduled and initialized with the boosted CPU allocation. Your application completes class loading, JIT compilation, or module parsing at top speed without experiencing CPU throttling.
-
Unboosting phase: As soon as the pod’s readinessProbe passes (plus any configured durationSeconds cooldown delay), the VPA updater issues an in-place resize request. The CPU request steps back down to your baseline level while the container continues running uninterrupted.
Prerequisites and availability
CPU startup boost is available today in preview on GKE:
-
GKE version: Version 1.36.0-gke.4447000 or later on Standard and Autopilot clusters.
-
Cluster Modes: Enabled natively on GKE Autopilot (VPA is active by default). On GKE Standard, simply ensure Vertical Pod Autoscaling (VPA) is enabled.
-
Workload Support: Works with standard Kubernetes controllers, including Deployments and StatefulSets.
Getting started: Configuring CPU startup boost
Configuring CPU startup boost is as simple as adding a startupBoost section to your VerticalPodAutoscaler manifest.
Example 1: Pod-level boost with fixed steady-state (updateMode: “Off”)
If you want to use VPA purely for startup boost while keeping steady-state CPU requests locked to your manifest definitions, set updateMode to “Off”:
