Kubernetes 1.35 stabilizes resource changes on existing Pods

Changing the resources assigned to a process does not necessarily require replacing the process. Kubernetes has historically coupled many such changes to Pod replacement, which makes a resource adjustment also a lifecycle event for the application. In-place resizing separates those operations where the workload and runtime can support it.

The Kubernetes 1.35 announcement graduates in-place CPU and memory updates to general availability. The feature allows resource settings to change on an existing Pod. This is useful for stateful processes and batch workloads whose replacement can have costs beyond the time required to start a container.

The stable API does not mean every resource change completes immediately or every application can use a new memory allocation without restarting. The versioned 1.35 Pod API definitions describe resize policy and the difference between requested and enacted resources. Those distinctions make the feature understandable as an asynchronous operation.

I like this extension of Kubernetes reconciliation. Desired resource settings can change while the Pod retains its identity, and the system reports progress toward applying them. The value comes from representing the transition as well as allowing the edit.

Pod identity and process continuity are different promises

An in-place update keeps the resource change associated with the existing Pod. A container may still need a restart depending on its resize policy and runtime support. The API makes that policy explicit per resource instead of assuming that every process handles a changing allocation identically.

ContainerResizePolicy names either cpu or memory and chooses a ResourceResizeRestartPolicy. The default is NotRequired. The alternative RestartContainer tells Kubernetes to stop and start the container when applying the resource change. This is a choice about how to enact the update, not the Pod's ordinary response to process failure.

The API comments identify applications with a fixed memory setting, such as a Java process configured through an explicit heap-size option, as a reason to require restart. Increasing a container's limit does not rewrite the application's command-line options or change every internal sizing decision it made at startup.

NotRequired also needs a precise reading. The definition says Kubernetes attempts to resize without restarting when possible, but may restart when it cannot enact the change otherwise. Runtime support is one example. Treating the policy name as an unconditional no-restart guarantee would exceed the contract written in the API.

These are useful distinctions for applications that retain substantial state in memory. Keeping the Pod is valuable, but a process restart can still discard local state. The desired operational behavior needs to account for both identity continuity and the selected restart semantics.

Resize policy describes the application boundary

The following fragment belongs within an existing container specification. It illustrates different choices for CPU and memory, without prescribing resource quantities or a complete workload manifest.

resizePolicy:
  - resourceName: cpu
    restartPolicy: NotRequired
  - resourceName: memory
    restartPolicy: RestartContainer

This declaration asks Kubernetes to apply CPU changes without requiring restart when it can, while explicitly restarting the container for a memory resize. The example expresses a workload contract. Whether it is appropriate depends on how the actual process discovers and uses its available resources.

The distinction is especially relevant when a process sizes worker pools or caches once. A larger resource limit changes what the platform permits. It does not necessarily change the workload's own demand or its interpretation of available capacity. Vertical resource management needs both sides of that relationship to be understood.

The release's claim about reducing disruption applies where resources can be updated without replacement. It should not be turned into a claim that applications adapt automatically. The API supplies the mechanism and policy. The workload still determines what useful work the adjusted resources permit.

Accepting a request is not the same as applying it

The Pod API has separate resize conditions for pending work and work in progress. PodResizePending indicates that the specification has changed but kubelet has not allocated the resources. PodResizeInProgress indicates allocation has happened but kubelet has not enacted every required change.

Both conditions can be present when a new request arrives while a previous resize is still underway. That case matters for an automated client issuing repeated updates. A later desired value does not erase the fact that an earlier transition is already in progress on the node.

The versioned API also exposes resources in container status. That field represents the requests and limits successfully enacted on the running container after startup or resize. Reading only the desired specification would miss this distinction. The requested value is an instruction, while status reports what the node has actually applied.

This is a practical application of Kubernetes' asynchronous model. An API response accepting new desired state is evidence that the update was recorded. It is not evidence that node-side work has finished. A client that reports completion immediately after the edit would be making a stronger claim than the update response supplies.

I consider that observable transition necessary for useful automation. An autoscaler needs a way to distinguish a new target from the resources already available to the process. Otherwise it can make another decision using an assumption that the previous one has completed.

Generation tracking makes the observation attributable

Kubernetes 1.35 also stabilizes generation tracking for Pods. The announcement explains that metadata.generation advances with specification updates, and status.observedGeneration identifies the generation kubelet has seen and processed. Individual conditions also carry their own observedGeneration.

This connects a reported observation to the specification it describes. Without that relationship, a client can read a healthy condition after an edit without knowing whether the condition predates the edit. The resource operation needs both the status and the revision to which that status applies.

Generation tracking does not replace resource status. Seeing a specification and completing every action it requests are separate facts. The enacted resource values and resize conditions still explain the node's progress. The generation makes those observations interpretable in the presence of subsequent updates.

Consider an observer that submits another CPU adjustment while memory changes are still being applied. A status read can contain useful information about the earlier operation without proving the later target is complete. The API explicitly allows pending and in-progress resize conditions to coexist for this situation. Comparing the relevant generations prevents an old observation from being attributed to the newest edit. Comparing enacted requests and limits then identifies the actual resource state, which is the information a resource-management client needs before claiming that the adjustment has reached the container. These checks describe the operation's semantics rather than requiring another replacement Pod to provide a visible completion signal.

The release announcement explicitly connects the earlier lack of reliable Pod update tracking to in-place vertical scaling. That relationship explains why these features belong in the same operational discussion. Allowing mutation creates a need to identify which mutation an observer has processed.

A resource update has a different scope from a template update

The stable mechanism concerns resource changes to existing Pods. The broader workload definition still matters because controllers create Pods from their templates. A system managing resources needs to distinguish a change aimed at a particular live Pod from the desired settings for Pods created later.

That distinction is already visible in the release's history. Earlier vertical changes through workload templates could trigger replacement. In-place support adds a way to adjust the existing allocation, which is useful precisely because changing a live instance and asking a controller for a new instance are different operations.

Neither operation eliminates capacity constraints. The resize conditions explicitly represent a phase before the node allocates resources. A desired increase cannot be treated as available merely because it has been submitted. The workload remains associated with a node whose ability to enact the new request is part of the transition.

This also changes the evidence needed to describe a successful resource action. For replacement, the observer looks for the desired new workload instances. For an in-place change, it needs the existing Pod's current generation and the resources enacted for its containers. The unit of observation changes with the operation.

The stable contract gives resource controllers a more precise choice. They can request a supported CPU or memory adjustment on an existing Pod and observe its application, with restart behavior expressed in the container policy. That allows vertical management to preserve a Pod where appropriate while retaining explicit evidence about which resource values have reached the running workload.