How to Vertically Scale Kubernetes Pods Without Restarting

Background

Prior to Kubernetes 1.27 the .spec.containers[*].resources fields (requests and limits) are immutable. Changing CPU or memory therefore requires recreating the pod, which triggers a restart and a brief service interruption.

Traditional method (Kubernetes < 1.27 or feature disabled)

The controller’s pod template (e.g., Deployment, StatefulSet, ReplicaSet) is edited, causing a rolling update that creates new pods with the updated resources and terminates the old ones.

Edit the controller resource directly: kubectl edit deployment my-app Or patch it with a JSON payload:

kubectl patch deployment my-app -p '{"spec":{"template":{"spec":{"containers":[{"name":"my-app-container","resources":{"requests":{"cpu":"500m","memory":"512Mi"},"limits":{"cpu":"750m","memory":"1Gi"}}}]}}}}'

Kubernetes performs a rolling update: new pod is created, old pod is terminated, traffic is shifted to the new pod.

Drawback : a pod restart is inevitable, which may violate zero‑downtime requirements.

Modern method (Kubernetes ≥ 1.27 with InPlacePodVerticalScaling enabled)

Feature overview

1.27 – InPlacePodVerticalScaling introduced as Alpha.

1.28 – Graduated to Beta, more stable.

How it works:

The API server allows direct modification of .spec.containers[*].resources on a live pod.

Kubelet updates the underlying cgroup quotas dynamically.

No container process restart occurs.

Prerequisites

Kubernetes version ≥ 1.27 (1.28+ recommended).

Feature gate enabled on the API server and kubelet: --feature-gates=InPlacePodVerticalScaling=true Pod must be managed by a controller (Deployment, StatefulSet, ReplicaSet, Job). Bare pods are not supported.

Operational methods

Method 1: kubectl patch pod

kubectl patch pod my-pod-name -p '{"spec":{"containers":[{"name":"my-container","resources":{"requests":{"cpu":"500m","memory":"512Mi"},"limits":{"cpu":"1","memory":"1Gi"}}}]}}'

Method 2: kubectl edit pod kubectl edit pod my-pod-name Edit the spec.containers[*].resources section and save.

Verification

Inspect pod events for resize messages: kubectl describe pod my-pod-name Look for messages such as Resizing container my-container and Container my-container resource limits updated in-place.

Confirm the resources were updated in the pod manifest: kubectl get pod my-pod-name -o yaml On the node, verify the cgroup values reflect the new limits, e.g.:

cat /sys/fs/cgroup/cpu/.../cpu.cfs_quota_us</code><code>cat /sys/fs/cgroup/memory/.../memory.limit_in_bytes

Limitations and pitfalls

Resource adjustment limits : CPU can be increased or decreased; memory can only be increased (decreasing memory could cause OOMKill).

Scheduler behavior : The scheduler does not re‑evaluate the pod after an in‑place update, so the pod stays on its original node even if the node becomes over‑committed.

Controller overwrite : Direct pod edits affect only the current instance. A subsequent rolling update from the controller will revert the changes unless the controller’s pod template is also updated.

Runtime compatibility : CRI‑O and containerd support the feature; older Docker or mismatched CRI implementations may require testing.

Interaction with autoscalers : Combine Vertical Pod Autoscaler (VPA) with InPlace scaling for optimal results. Avoid running HPA and VPA on the same pod to prevent conflicts.

Security policies : PodSecurityPolicy, OPA, or Gatekeeper rules may block resource modifications. Ensure RBAC permissions allow the operation.

Best‑practice recommendations

Production strategy : CPU can be scaled up or down; memory only up. For stateful services use a StatefulSet together with a PodDisruptionBudget to maintain high availability.

Monitoring & alerts : Use Prometheus to monitor CPU and memory usage. Configure OOMKill alerts, e.g.:

kube_pod_container_status_last_terminated_reason{reason="OOMKilled"}

Automation : Enable the Vertical Pod Autoscaler (VPA) and let it perform in‑place adjustments. Keep stateless workloads on HPA to avoid VPA/HPA conflicts.

Conclusion

For Kubernetes versions prior to 1.27 vertical scaling can only be achieved by restarting pods. Starting with Kubernetes 1.27 (Alpha) and 1.28 (Beta) the InPlacePodVerticalScaling feature gate allows direct, in‑place modification of pod resources without restarting the container process. In production, ensure that controller pod templates are kept in sync, consider scheduler implications, monitor resource usage, and respect security policies to use the feature safely.