Kubernetes 1.32 Released: In-Place Pod Resize Goes Stable

Kubernetes 1.32 ships the long-awaited stable graduation of in-place pod vertical scaling, the GA of sidecar containers, and a clean-up of legacy beta APIs that have lingered since 2020. For platform teams running large clusters, this release reduces the cost of right-sizing workloads from "schedule a maintenance window and bounce every pod" to "patch the resources field and watch the kubelet adjust the cgroup live." This guide walks through the headline features, the breaking removals, and what to test before upgrading.

In-place pod resize: what changed

Before 1.32, changing a pod's CPU or memory request required deleting the pod and letting the controller recreate it elsewhere — disruptive for stateful workloads, slow for big JVMs, and impossible during a sustained traffic peak. The InPlacePodVerticalScaling feature gate now defaults on, allowing you to patch resources.requests and resources.limits directly on a running pod:

kubectl patch pod my-app --subresource resize --patch '
spec:
  containers:
  - name: app
    resources:
      requests: { cpu: "500m", memory: "1Gi" }
      limits:   { cpu: "1",    memory: "2Gi" }'

The kubelet adjusts the container's cgroup limits without restarting the process. For memory increases this is always safe; for memory decreases the kernel may not honour the new limit until pages are freed. CPU changes take effect immediately.

The resize policies

Each container can declare what to do per resource:

spec:
  containers:
  - name: app
    resizePolicy:
    - resourceName: cpu
      restartPolicy: NotRequired
    - resourceName: memory
      restartPolicy: RestartContainer    # safer for some workloads

"RestartContainer" still avoids pod recreation and node rescheduling — it just restarts the single container in place. For a Java app that resizes its heap based on cgroup limits at startup, this is the right policy.

Sidecar containers go GA

Native sidecars — declared as init containers with restartPolicy: Always — have moved from beta to stable. They start before regular containers, stay running for the pod's lifetime, and terminate after the main containers exit. Logging agents, service-mesh proxies, and secret-rotation daemons finally have a first-class lifecycle:

spec:
  initContainers:
  - name: log-shipper
    image: vector:latest
    restartPolicy: Always       # this makes it a sidecar
  containers:
  - name: app
    image: my-app:v1

The pod's Ready status now correctly accounts for sidecars. Job pods complete cleanly even when sidecars do not exit on their own.

Memory QoS via cgroups v2

Clusters running cgroups v2 (the default on RHEL 9, Ubuntu 22.04+) get richer memory accounting. memory.high is now set based on a percentage of memory.max, providing soft pressure before OOM. Tune via the memoryQoS kubelet feature flag.

Multi-cluster Services and Gateway API maturity

Cross-cluster service discovery is now sufficient for most production multi-region patterns without a service mesh. Gateway API graduated GA in a previous release; 1.32 adds GRPCRoute and finer-grained policy attachment.

Removals that may break you

• flowcontrol.apiserver.k8s.io/v1beta3 — use v1.
• Legacy in-tree storage drivers continue to be removed; ensure the CSI migration for AWS EBS, GCE PD, Azure Disk, and OpenStack Cinder is complete.
• The --keep-terminated-pod-volumes kubelet flag is gone.
• Several beta annotations on Service and EndpointSlice that were superseded by spec fields are removed.

Upgrade preflight

kubectl version --short
kubectl get apiservices | grep -i v1beta
kubectl deprecations --since 1.30 -A         # pluto / kubectl-deprecations
kubectl get csidrivers
kubectl get nodes -o wide                     # confirm runtime versions

Check controller manifests for the resize subresource permission — if your custom controllers patch pod spec, they may need updated RBAC.

Operational recipes

Right-size at 02:00 with no disruption: a controller that watches metrics-server and patches the resize subresource when actual usage diverges from request by more than 30%. Without 1.32 this required either VPA in "recreate" mode or an out-of-band scheduler.

Cost reclamation: shrink overprovisioned long-running batch jobs from 16 GiB to 4 GiB without restart. The job continues, the cluster reclaims the difference, the pod has the same name and IP.

Caveats

• The resize subresource respects pod QoS class. Burstable pods can be resized freely; Guaranteed pods that drop a request below their limit silently change QoS class — observe in kubectl describe pod.
• Memory shrink can fail if the working set exceeds the new limit. Plan for graceful application-level GC before resizing down.
• Some CRDs with admission webhooks still reject pod patches — test in staging before production rollout.

Compatibility checklist

1. Cluster on cgroups v2 (kernel 5.4+, recommended 5.10+).
2. Container runtime: containerd 1.7+, CRI-O 1.32+.
3. kubelet feature gates: defaults are fine; verify InPlacePodVerticalScaling=true.
4. Metrics server up to date for accurate resize decisions.
5. VPA, if installed, updated to a release that knows about the resize subresource.

Kubernetes 1.32 is a quiet but high-impact release for platform teams. In-place resize alone justifies the upgrade for any team with stateful workloads, big JVMs, or strict cost-control requirements. Read the deprecation notes carefully, exercise the resize subresource in staging, and you will spend less time bouncing pods this quarter than in any quarter since you adopted Kubernetes.