About this scenario
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
- Find what's wrong with each container
- Try changing the resources the old way
- Give worker a 1 CPU limit without restarting it
- Give cache a 512Mi limit and stop the OOMKills
- reporter is still the Pod it was at the start
What you'll practice
- 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.
How the playground works
The cluster runs entirely in your browser: a simulated API server, scheduler, kubelets and controllers, with virtual nodes in three zones. kubectl output follows the real formats, errors use the real messages, and the add-ons (CSI storage, Traefik, Envoy Gateway, cert-manager, Flux, Argo CD) behave like their real counterparts for the common paths. It's a simulation, so some behavior is simplified. Your progress is saved in this browser.