Pod resize completion depends on runtime reporting
Kubernetes' alpha resize guide explains why a changed pod specification is insufficient evidence of applied resources. Runtime support and separate status fields determine what an observer can conclude.
A resource resize can reach a running container without its completion becoming visible in pod status. The May 12 guide to Kubernetes 1.27 in-place resizing identifies that failure mode for containerd versions below 1.6.9. Those versions lack the CRI support needed for full operation. A resize can appear stuck in InProgress, and container status resources never update, even though the runtime may have applied the new values.
That is a useful detail for understanding the feature. A resource change has an execution path and an observation path. The kubelet must request a change, but it must also obtain enough information from the runtime to report what happened. The new mutable specification cannot supply that evidence, because it records intent before the node has completed the operation.
I value Kubernetes' explicit separation of desired and actual state. In-place resizing makes that separation more demanding for monitoring tools. Reading a resource value out of the pod specification is no longer sufficient to describe the running container once a resize has been requested.
Three resource descriptions answer different questions
The guide describes mutable CPU and memory resource fields in each pod container. Patching the running pod specification records the desired resize. The same article says Kubernetes queries the actual requests and limits through the Container Runtime Interface, then reflects the response in pod status. That makes the runtime part of the evidence needed to describe applied resources.
Container status also contains allocatedResources. This records node resources allocated to the container. A separate resources field reports requests and limits configured on the running container. The versioned Kubernetes 1.27 API states that the kubelet updates allocation after admitting a desired resize and uses the other field for successfully enacted resources.
An observer can therefore distinguish a requested increase from an admitted increase and from the settings reported for the running process. Those distinctions explain why two different values are not necessarily contradictory. During reconciliation, a request can exist before its allocation is admitted, and admitted resources can exist before runtime application is complete.
This changes the meaning of a resource dashboard. A display of requested resources can still be correct if labelled as a request. Calling the same value the container's actual allocation makes a stronger claim that the specification cannot support. The guide explicitly directs monitoring tools to the status fields for that reason.
Deferred and infeasible need different responses
Pod status exposes the last requested resize through resize. Proposed acknowledges that the request was validated and recorded. InProgress means the node accepted it and is applying it. These states already distinguish API acceptance from node execution, before considering whether the runtime can report completion.
Deferred means the node cannot grant the request now and will keep retrying. The guide gives another pod leaving and freeing resources as a way that the request could later become possible. Infeasible signals that the node cannot accommodate the request, for example when it exceeds what the node can ever allocate to a pod.
Waiting has a different meaning in those cases. A deferred request describes a current capacity problem that the node will revisit. An infeasible request does not become a feasible allocation simply because the client keeps polling. The API definitions state that it will not be re-evaluated. Automation needs to preserve that distinction when reporting progress or selecting another action.
An apparent InProgress stall requires another distinction. On an older containerd, it may involve missing reporting support even after resources changed. The guide also lists delayed enactment from races with other pod updates and delays reflecting resized resources in status. A single status value can identify an unfinished observation without establishing which underlying delay caused it.
The application controls restart requirements
The container resize policy defines how resource changes interact with process restarts. The 1.27 API supports NotRequired and RestartContainer for CPU and memory. Without an explicit policy, NotRequired asks Kubernetes to try without restarting but permits a restart when necessary to actuate the change. It is not a guarantee that the process survives every resize.
RestartContainer directs Kubernetes to stop and start the container when applying the new resources. The API comments use fixed startup memory settings as an example of an application requirement. Increasing an operating-system limit cannot automatically change every application's internal sizing logic. A restart policy makes that dependency explicit.
The guide's Java startup example illustrates a different opportunity. Some applications need more CPU during initialisation than during normal operation. They can start with a larger CPU declaration and request a reduction after initialisation finishes. That proposal changes resource demand over the application's lifecycle instead of sizing the whole lifetime around its startup phase.
I find that use case more persuasive than treating live resizing as a general answer to resource management. It identifies a particular phase change that can drive a deliberate resource decision. The mechanism still needs a controller or another client to decide when that phase has ended and request the adjustment.
Alpha support includes the node configuration
Kubernetes 1.27 requires enabling InPlacePodVerticalScaling to use the feature. The May guide also says static CPU management policy is unsupported. A cluster running the correct Kubernetes minor version is therefore only one part of the required environment. The feature gate, runtime support, and node resource-management configuration all affect the experiment.
The guide describes resizing overprovisioned pods to free resources as another use case. That can matter when new pods cannot schedule even though running applications use less than their declared allocation. The mechanism allows a changed declaration for existing pods, but the distinction between intent and applied resources remains relevant throughout that adjustment. Capacity accounting needs evidence of what the node has accepted.
The runtime-reporting issue gives the alpha a precise operational boundary. A changed specification establishes the requested resources. Allocation status establishes what the node admitted, while runtime-backed status describes the resources enacted on the container. A client that preserves those meanings can report a pending resize honestly even when it cannot yet establish completion.