Kubernetes resizing changed in 2025. Your rollout still needs a plan.

Two milestones in one year

In May 2025, the Kubernetes project announced in-place Pod resizing at beta in version 1.33, enabled by default. In December, it announced graduation to stable in version 1.35. The feature allows container CPU and memory resources to change in a running Pod, often without restarting a container.

That is a 2025 version history, not advice to choose one of those versions for a new cluster today. Check documentation and support information for your actual cluster and runtime before planning a rollout.

A request is not the same as an applied change

The 1.35 announcement distinguishes desired resources in the container specification from resources currently configured in container status. The beta announcement describes pending and in-progress resize conditions, including cases where a node cannot immediately grant a request. Resource updates use the Pod resize subresource.

Our operational takeaway is to observe the resulting workload state, rather than treat a submitted update as proof that the requested capacity exists. A dashboard or automation should distinguish intention, progress, and outcome. That pattern applies beyond Kubernetes: cloud changes also need a reconciliation and verification step.

Pick the workload before the mechanism

For a first evaluation, we recommend choosing a workload with understandable resource behavior and a documented operational owner. Write down why changing resources in place might help. Is the problem startup demand, variable load, or inefficient allocation? If the benefit is unclear, the feature is not yet a useful project.

• Record resource demand and service behavior under a representative load.
• Define an acceptable change in latency, errors, and restart behavior.
• Evaluate a modest change in a non-production environment.
• Observe actual resource state and application behavior after the request.
• Record what happened when the environment could not satisfy the request.

This is a suggested experiment checklist, not a benchmark or a claim that every workload can resize without disruption.

Turn the experiment into a supported workflow

If the experiment is useful, define the supported inputs and the review needed to use it. We would document who can request a change, what resource bounds apply, how the system reports progress, and when a person should intervene.

Put the documentation beside the workflow. A developer should not need to infer which version-specific behavior was assumed by an old runbook. Keep the cluster and runtime requirements visible, and revisit them as your environment changes.

For a platform engineering engagement, the deliverable is not simply a command that works once. It is a repeatable path with ownership, validation, and enough context for the next engineer to operate it. That is also the intended role of approved workflows in Evolith Portal.