# Resize a running Pod's CPU and memory without recreating it

> A reporting Pod is throttled and its cache keeps getting OOMKilled. Fix both live with in-place Pod resize, stable since Kubernetes 1.35.

Level: Intermediate · Topic: Workloads · About 12 minutes
Try it in the browser: https://k8wiz.com/playground/resize-a-pod-in-place

The playground is a simulated Kubernetes cluster that runs in the browser. kubectl output and errors follow the real ones.

## The situation

reporter is a single Pod with two containers. worker is held at its 500m CPU limit, and cache needs about 300Mi but may only use 256Mi, so it keeps getting OOMKilled. The Pod holds a warm dataset that takes a long time to rebuild, so recreating it is the last resort.

In-place Pod resize is stable since Kubernetes 1.35: you change CPU and memory on a running Pod through its resize subresource, and each container's `resizePolicy` says whether the change needs a restart.

## Objectives

1. Find what's wrong with each container (`kubectl top pod reporter --containers` and `kubectl describe pod reporter`)
2. Try changing the resources the old way (`kubectl edit` or a plain `kubectl patch`)
3. Give worker a 1 CPU limit without restarting it
4. Give cache a 512Mi limit and stop the OOMKills
5. reporter is still the Pod it was at the start

## Hints

1. `kubectl top pod reporter --containers` shows worker pinned at its CPU limit. `kubectl describe pod reporter` shows cache's Last State: OOMKilled.
2. A normal edit of a Pod's resources is refused. Use the resize subresource: `kubectl patch pod reporter --subresource resize -p '{"spec":{"containers":[{"name":"worker","resources":{"limits":{"cpu":"1"}}}]}}'`.
3. `kubectl get pod reporter -o yaml` shows what the kubelet applied under `status.containerStatuses[].resources`, the new `metadata.generation` with `status.observedGeneration`, and a PodResizePending condition when the node can't fit the request.
4. cache's resizePolicy says a memory change needs a restart, so the kubelet restarts that container, not the Pod. Raise its memory request and limit together, for example to 384Mi and 512Mi.

## Solution

```bash
kubectl top pod reporter --containers
```
```bash
kubectl describe pod reporter | grep -A3 'Last State'
```
```bash
kubectl patch pod reporter -p '{"spec":{"containers":[{"name":"worker","resources":{"limits":{"cpu":"1"}}}]}}'
```
```bash
kubectl patch pod reporter --subresource resize -p '{"spec":{"containers":[{"name":"worker","resources":{"requests":{"cpu":"500m"},"limits":{"cpu":"1"}}}]}}'
```
```bash
kubectl patch pod reporter --subresource resize -p '{"spec":{"containers":[{"name":"cache","resources":{"requests":{"memory":"384Mi"},"limits":{"memory":"512Mi"}}}]}}'
```
```bash
sleep 5
```
```bash
kubectl get pod reporter -o jsonpath='{.metadata.generation} {.status.observedGeneration}'
```

## What it teaches

- Since Kubernetes 1.35, a running Pod's CPU and memory can change in place through the resize subresource. The rest of the Pod spec stays immutable.
- Each container's `resizePolicy` decides what a change costs: `NotRequired` applies it live, `RestartContainer` restarts only that container. The Pod, its IP and its other containers stay.
- The kubelet applies a resize only when the node has room. Otherwise the Pod gets a PodResizePending condition: Deferred until room frees up, Infeasible if the node is too small.
- `metadata.generation` and `status.observedGeneration`, stable in 1.35 too, show whether the kubelet has acted on your last change.