Kubernetes In-Place Pod Resize

Source: Dev.to

Background

About six years ago, while operating a large Java‑based platform in Kubernetes, I noticed a recurring problem: our services required significantly higher CPU and memory during application startup. Heavy use of Spring Beans and AutoConfiguration forced us to set inflated resource requests and limits just to survive bootstrap, even though those resources were mostly unused afterwards.

This workaround never felt right. As an engineer, I wanted a solution that reflected the actual lifecycle of an application rather than its worst moment.

I opened an issue in the Kubernetes repository describing the problem and proposing an approach to adjust pod resources dynamically without restarts. The issue received little discussion but quietly accumulated interest over time (13 👍 emoji reactions). Every few months an automation bot attempted to mark it as stale, and each time I removed the label. This went on for nearly six years…

Until the release of Kubernetes 1.35, where the In‑Place Pod Resize feature was marked as stable.

What In‑Place Pod Resize Brings

In‑Place Pod Resize allows Kubernetes to update CPU and memory requests and limits without restarting pods, whenever it is safe to do so. This significantly reduces unnecessary restarts caused by resource changes, leading to fewer disruptions and more reliable workloads.

For applications whose resource needs evolve over time—especially after startup—this feature provides a long‑missing building block.

Impact on VerticalPodAutoscaler

The new resizePolicy field is configured at the pod‑spec level. While it is technically possible to change pod resources manually, doing so does not scale. In practice, this feature should be driven by a workload controller.

At the moment, the only controller that supports in‑place pod resize is the Vertical Pod Autoscaler (VPA).

There are two enhancement proposals that enable this behavior:

1. AEP‑4016: Support for in‑place updates in VPA – introduces the InPlaceOrRecreate update mode.
2. AEP‑7862: CPU Startup Boost – temporarily boosts a pod by giving it more CPU during startup. This is conceptually similar to the approach proposed in my original issue.

Example: Deployment + VPA using both AEP features

apiVersion: apps/v1
kind: Deployment
metadata:
  name: example
spec:
  replicas: 1
  selector:
    matchLabels:
      app: example
  template:
    metadata:
      labels:
        app: example
    spec:
      containers:
        - name: app
          image: my-heavy-java-app:stable
          ports:
            - containerPort: 80
          resources:
            requests:
              cpu: 1000m
              memory: 1024Mi
            limits:
              cpu: 2000m
              memory: 2048Mi
---
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: example-vpa
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: example
  updatePolicy:
    updateMode: InPlaceOrRecreate
  resourcePolicy:
    containerPolicies:
      - containerName: app
        minAllowed:
          cpu: "250m"
          memory: "512Mi"
        maxAllowed:
          cpu: "3000m"
          memory: "8192Mi"
        # The CPU boosted resources can go beyond maxAllowed.
        startupBoost:
          cpu:
            type: Factor
            quantity: "2"

With this configuration the pod will have doubled CPU requests and limits during startup. During the boost period no resizing will happen. Once the pod reaches the Ready state, the VPA controller scales CPU down to the currently recommended value. After that, VPA continues operating normally, with the key difference that resource updates are applied in place whenever possible.

Limitations

Does this feature fully solve the problem described above? Only partially.

1. Runtime constraints – Java and Python runtimes do not currently support resizing memory limits without a restart. This limitation exists outside of Kubernetes and is tracked in the OpenJDK project via an open ticket.

   

2. Memory limit decreases – Kubernetes does not yet support decreasing memory limits, even with In‑Place Pod Resize enabled. This is a known limitation documented in the enhancement proposal for memory limit decreases.

   In‑place Pod Resize – memory‑limit decreases

As a result, while in‑place Pod Resize effectively addresses CPU‑related startup spikes, memory resizing remains an open problem.

Final thoughts

In‑place Pod Resize gives a foundation for cool new features like StartupBoost and makes use of VPA more reliable. While important gaps remain—such as memory‑decrease support and a scheduling race condition—this change represents a meaningful step forward.

For workloads with distinct startup and steady‑state phases, Kubernetes is finally beginning to model reality more closely.