Stop Over-Provisioning for Startup: GKE's New CPU Startup Boost

The trade-off: Startup speed vs. idle waste

Every team running heavy, latency-sensitive workloads on Kubernetes is forced to choose between two frustrating compromises:

Size for startup, pay for it forever. Set the CPU request high enough to get through initialization quickly, even though the app only needs minimal CPU once it's warm. That request sits there around the clock. It's what the scheduler uses to place the Pod, what the cluster autoscaler uses to decide whether to add nodes, and what you get billed for. Across a few hundred replicas, the tradeoff between faster startup and ongoing waste adds up quickly.

Size for steady-state, suffer on startup. Set the request to match actual runtime usage, and accept that every restart, every rolling deployment, every node upgrade means a slow crawl to readiness. Under CPU throttling, a JVM warm-up that should take 5 seconds can stretch to 30 or more. That means slower rollouts, slower scale-out during HPA events, and potential latency spikes for users.

Neither is really acceptable. CPU startup boost is built to close that gap.

What CPU startup boost actually solves

CPU startup boost is a new capability of GKE's Vertical Pod Autoscaler (VPA), currently in Preview. It lets you temporarily increase a container's CPU request during Pod initialization, then automatically scale it back down to the baseline without restarting the container.

Resource-hungry runtimes (Java, Node.js, and Python with heavy imports) get the CPU headroom they need only when they need it, during initialization. Your baseline request can reflect real steady-state usage rather than a compromise padded for the first few seconds of a Pod's life. Because the scale-down from boosted to baseline uses Kubernetes' in-place Pod resize (IPPR) rather than a Pod eviction and recreation, the container keeps running the whole time.

This works alongside VPA's usual job of recommending and applying long-term resource sizing. Startup boost is really just a short-lived override layered on top of whatever baseline VPA (or you) has already established.

How it works, and how to configure it

Full walkthrough here: Accelerate application startup with CPU startup boost.

CPU startup boost is defined by adding a startupBoost block to your VerticalPodAutoscaler object. You can apply it at the Pod level, so every container gets the same boost, or at the container level, to target specific containers or exclude specific ones from a Pod-wide boost.

It only fires on Pod creation. If a container restarts later, say after an OOMKill while the Pod itself stays alive, the boost doesn't re-apply. The admission webhook that injects the boost runs only at initial Pod admission.

The boost type can be a multiplier or a fixed quantity. type: "Factor" scales the baseline CPU request by a multiplier (factor: 2 doubles it); type: "Quantity" adds a fixed amount of CPU on top of baseline.

It works alongside VPA's update modes, not instead of them. Run it with updateMode: "Off" if you want the boost behavior and nothing else, or pair it with updateMode: "InPlaceOrRecreate" if you also want VPA to continue adjusting resources based on ongoing usage.

To configure a Pod-level boost, use one of the following options.

Pod-level boost, VPA actuation off

Use this when you want the boost and nothing more — VPA won't apply any other resource recommendations.

apiVersion: "autoscaling.k8s.io/v1"
kind: VerticalPodAutoscaler
metadata:
  name: example-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: example
  updatePolicy:
    updateMode: "Off"
  startupBoost:
    cpu:
      type: "Factor"
      factor: 2
      durationSeconds: 10

Every container in the Pod receives 2x its baseline CPU request for the first 10 seconds after the Pod reaches Ready, after which GKE resizes it back down in place.

Pod-level boost, with ongoing VPA management

Use this when you want both the startup boost and continuous, in-place resource right-sizing afterward.

apiVersion: "autoscaling.k8s.io/v1"
kind: VerticalPodAutoscaler
metadata:
  name: example-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: example
  updatePolicy:
    updateMode: "InPlaceOrRecreate"
  startupBoost:
    cpu:
      type: "Factor"
      factor: 2
      durationSeconds: 10

Same boost behavior, but updateMode: "InPlaceOrRecreate" means VPA keeps recommending and applying resource changes over the Pod's lifetime, attempting in-place resizes first before falling back to recreation.

Container-level boost, targeting one container

Useful when a Deployment has a sidecar or utility container that doesn't need the startup CPU spike. You scope the boost to just the container that needs it via resourcePolicy.containerPolicies.

apiVersion: "autoscaling.k8s.io/v1"
kind: VerticalPodAutoscaler
metadata:
  name: example-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: example
  updatePolicy:
    updateMode: "Off"
  resourcePolicy:
    containerPolicies:
    - containerName: "boosted-container-name"
      mode: "Off"
      startupBoost:
        cpu:
          type: "Quantity"
          quantity: "2"

Here, boosted-container-name gets an extra 2 vCPUs on top of its baseline request during startup — a fixed quantity rather than a multiplier.

Opting a container out of a Pod-level boost

The inverse case: a Pod-level boost is set, but one container shouldn't be boosted along with everything else.

apiVersion: "autoscaling.k8s.io/v1"
kind: VerticalPodAutoscaler
metadata:
  name: example-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: example
  updatePolicy:
    updateMode: "InPlaceOrRecreate"
  startupBoost:
    cpu:
      type: "Factor"
      factor: 2
  resourcePolicy:
    containerPolicies:
    - containerName: "disable-cpu-boost-for-this-container"
      startupBoost:
        cpu:
          type: "Factor"
          factor: 1

The Pod-level boost applies a 2x factor to everything by default, but the container policy overrides that to a factor of 1 for the named container.