In place Resize of Pods 2025 Updates

In this lesson we cover Kubernetes’ in-place resizing of Pod resources — what it is, how it differs from the default behavior, how to enable and use it, and its current limitations. Understanding in-place resizing is useful before diving into higher-level tools such as the Vertical Pod Autoscaler.

Default behavior: delete-and-recreate

By default, changing resource requests or limits in a Deployment’s Pod template causes Kubernetes to terminate the existing Pod and create a new one with the updated resources. This can be disruptive for stateful or long-running workloads. Example Deployment manifest with explicit resource requests and limits:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app
        image: nginx
        resources:
          requests:
            cpu: "250m"
            memory: "256Mi"
          limits:
            cpu: "1"
            memory: "512Mi"

Any change to resources.requests or resources.limits in the Pod template will normally trigger a Pod replacement (delete + recreate).

In-place resizing: what it does

In-place resizing allows certain resource fields on running containers to be changed without deleting the Pod. When supported and enabled, kubelet applies the change on the running container (or restarts only the container if required by policy) instead of recreating the entire Pod. To control this behavior the Pod spec gains a resizePolicy field (when in-place scaling is available). The resizePolicy can be used to indicate whether changes to a specific resource require restarting the container. Example: allow CPU changes without a container restart, but require restarts for memory changes:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app
        image: nginx
        resizePolicy:
        - resourceName: cpu
          restartPolicy: NotRequired
        - resourceName: memory
          restartPolicy: RestartContainer
        resources:
          requests:
            cpu: "250m"
            memory: "256Mi"
          limits:
            cpu: "500m"
            memory: "512Mi"

In the example above, CPU updates can be applied in-place (NotRequired) while memory updates will restart the container (RestartContainer).

Enabling the feature

In-place pod vertical scaling is gated by the InPlacePodVerticalScaling feature gate in many Kubernetes releases. You must enable it on control-plane components (e.g., kube-apiserver) and on kubelet processes where applicable. Example startup flag:

# Example: enable on components via their --feature-gates flag
--feature-gates=InPlacePodVerticalScaling=true

Enable the InPlacePodVerticalScaling feature gate on both control-plane components (kube-apiserver) and kubelet processes where applicable. Exact steps depend on how your cluster is provisioned (kubeadm, managed control plane, kind, minikube, etc.).

Updating the Pod template (example)

Once the feature gate is enabled and the resizePolicy allows it, patching the Deployment’s Pod template can request a resource change that kubelet attempts to apply in-place. Example patch to increase the CPU request:

kubectl patch deployment my-app --patch '{
  "spec": {
    "template": {
      "spec": {
        "containers": [
          {
            "name": "my-app",
            "resources": {
              "requests": { "cpu": "1" }
            }
          }
        ]
      }
    }
  }
}'

If in-place resizing is permitted by policy and node conditions, the container’s CPU can be increased without deleting the Pod. Memory changes may trigger a container restart depending on the configured restartPolicy and whether the new limit is feasible relative to current usage.

How in-place resizing behaves in practice

Only CPU and memory are supported for in-place updates.
Pod QoS class is not changed by in-place updates (QoS remains the same).
You cannot remove or unset previously set resource requests/limits via in-place updates.
A requested decrease in memory that would set the limit below current usage cannot be applied until usage falls below the requested limit; the resize may remain pending.
Init containers and ephemeral containers are not supported by the in-place resizing mechanism.

For the latest behavior and default settings in your Kubernetes version, consult the official release notes and documentation:

Limitations and considerations

Limitation	Details
Supported resources	Only `cpu` and `memory` can be resized in-place.
QoS class	Pod QoS class cannot be changed via in-place updates.
Init/ephemeral containers	Init containers and ephemeral containers are not supported.
Removing resources	You cannot remove previously set requests or limits with an in-place update.
Decreasing memory	Memory limits cannot be lowered below current usage; decreases will remain pending until feasible.

A dark-themed slide titled "Limitations" that lists five container resizing constraints. The points note that only CPU and memory can be changed, Pod QoS class can’t change, init/ephemeral containers can’t be resized, resource requests/limits can’t be removed once set, and memory limits can’t be lowered below current usage.

Important: As of current upstream support, Windows Pods are not supported for in-place resizing. Also verify whether your cluster (especially managed control planes) exposes the InPlacePodVerticalScaling feature gate or provides an alternative configuration mechanism.

Introduction

Core Concepts

Scheduling

Logging & Monitoring

Application Lifecycle Management

Cluster Maintenance

Security

Storage

Networking

Design and Install a Kubernetes Cluster

Install "Kubernetes the kubeadm way"

Troubleshooting

Helm Basics (2025 Updates)

Kustomize Basics (2025 Updates)

Other Topics

Mock Exams

In place Resize of Pods 2025 Updates

Default behavior: delete-and-recreate

In-place resizing: what it does

Enabling the feature

Updating the Pod template (example)

How in-place resizing behaves in practice

Limitations and considerations

Watch Video

​Default behavior: delete-and-recreate

​In-place resizing: what it does

​Enabling the feature

​Updating the Pod template (example)

​How in-place resizing behaves in practice

​Limitations and considerations

Watch Video

Default behavior: delete-and-recreate

In-place resizing: what it does

Enabling the feature

Updating the Pod template (example)

How in-place resizing behaves in practice

Limitations and considerations