Kubernetes 1.27 separates resource intent from allocation

Changing a resource declaration is easy to describe until the process using those resources must remain alive. A replacement pod can start with a new allocation, but resizing an existing pod requires the node to reconcile a new request with capacity already in use. The API must also distinguish the requested configuration from what the running container actually has. Without that distinction, a successful write could look like a completed resize when nothing has changed on the node.

Kubernetes 1.27, released on April 11, introduces alpha in-place resizing for CPU and memory. Its versioned release notes describe mutable container resource declarations, per-resource restart policy, and new status fields for allocation and application. These additions make resizing an observable reconciliation process.

I value Kubernetes' separation of desired and observed state. This change extends that model into a part of the pod definition that previously could not express this kind of live adjustment. The interesting question is how clearly the system reports the distance between a resource request and a running process that has received it.

The write and the allocation are different events

The release notes say container resources become mutable for the cpu and memory resource types. That scope matters. In-place resizing is a particular change to compute resource management, and it does not make the whole pod specification mutable. An operator or controller gains a way to request a different allocation for the existing pod.

The 1.27 container API definitions make the intermediate states explicit. Container status gains allocatedResources, which the kubelet sets to the requests after successful pod admission and after admission of a desired resize. Another status field, resources, reports requests and limits successfully applied to the running container. The declaration, the admitted allocation, and the applied resources therefore have separate representations.

Suppose a container requests more memory. An API write records the desired change, but the node still has to determine whether it can accept the resize. Even after accepting an allocation, it must apply the corresponding container resources. The new fields allow a reader to ask which part of that process has happened. Treating the updated specification as evidence of completion would skip both node decisions.

That distinction is useful to automation as well as to an administrator inspecting a pod. A resource controller needs some basis for deciding whether its previous request has taken effect before making another decision. The status fields provide information about allocation and application that the desired specification alone cannot supply. They also prevent a dashboard from needing to label every requested increase as immediately available capacity.

An allocation and an applied limit can legitimately differ during this process. The API comments assign each field a particular meaning, so displaying both values is informative even when they disagree. A tool that copies the requested value into its displayed running allocation would erase that information and make an unfinished operation appear complete.

Resize status describes the node's response

Pod status gains a resize field. The versioned API defines Proposed for a requested resize awaiting node evaluation and InProgress for a resize the node has accepted and is applying. It distinguishes those states from Deferred, where the node cannot resize the pod now and will retry, and Infeasible, where the request will not be re-evaluated.

Those last two states have different operational meanings. A deferred request can remain pending while the node keeps attempting it. An infeasible request is not waiting for the same retry process to succeed. A client that collapses them into one generic pending state would hide information the API deliberately exposes.

The existing pod remains the subject of these decisions. In-place resizing cannot be understood as a promise that any larger declaration can take effect immediately. The node has already admitted other work, and a new request still has to fit its allocation rules. Resource availability remains a condition of success even though creating a replacement pod is no longer the only way to express the desired change.

This also changes how completion should be described in an operational tool. Recording a request is a valid result, but it should be named as such. Completion of the API update, admission by the node, and application to the container answer different questions. The new API makes those questions separately observable instead of forcing clients to infer progress from one desired value.

In-place does not promise a restart-free process

The new container resizePolicy associates a resource name with a restart policy. The supported resource names are CPU and memory. NotRequired is the default when a policy is not specified. According to the 1.27 API comments, it asks Kubernetes to try resizing without restarting, while allowing a restart if the runtime cannot apply the change without one.

RestartContainer explicitly requires stopping and starting the container when the new resources are applied. The API comments identify applications with fixed startup memory settings as a reason for that choice. Giving the container more memory at the operating-system level does not necessarily change an application's internal memory sizing decision.

The following fragment illustrates the policy fields within a container declaration. It is a configuration fragment, not a complete pod manifest.

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

This policy permits an attempt to adjust CPU without a restart while specifying a restart for a memory change. It makes the application's requirements part of the declared resize behaviour. The resource policy belongs to each container, so the pod's existence alone does not establish that every process inside it will remain uninterrupted.

I find the explicit restart policy more useful than a broad claim of disruption-free resizing. It describes an actionable agreement between the application definition and the node. An application that needs startup-time sizing can say so, and a reader can distinguish preserving a pod from preserving every container process.

Stable seccomp defaulting still needs activation

Another 1.27 change concerns a different kind of default. The release announcement promotes SeccompDefault to stable, but explicitly requires enabling --seccomp-default on each kubelet where defaulting is wanted. Graduation describes the feature's maturity. It does not mean that installing this release silently activates the behaviour on every node.

With that setting enabled, the kubelet uses the container runtime's RuntimeDefault seccomp profile by default instead of Unconfined. The announcement says the default profiles aim to provide security restrictions while preserving workload functionality. It also warns that profiles can differ across runtimes and runtime releases.

This places part of the effective security configuration in the runtime. Two nodes can share a Kubernetes version while obtaining their default syscall restrictions from different runtime profiles. A declaration that relies on RuntimeDefault consequently names a runtime-supplied policy, not a single immutable profile defined by the Kubernetes release announcement.

The practical interpretation is precise. An operator enabling defaulting changes what happens when a workload relies on that default. The node setting and runtime implementation both matter to the resulting execution environment. Calling the feature stable is useful information for adoption, but it does not remove those configuration inputs.

Scheduling changes preserve the scheduler's role

The release also stabilises mutable scheduling directives for Jobs. The announcement limits updates to suspended Jobs that have never been unsuspended. A custom queue controller can adjust specified placement-related fields before the Job starts, while the Kubernetes scheduler still performs the actual pod-to-node assignment.

That boundary resembles the resize API's distinction between intent and application. A queue controller can decide when work should become eligible and constrain its placement without taking over every scheduler responsibility. Similarly, a resize client can express resource intent while leaving node admission and application to the components that manage those responsibilities.

Pod scheduling readiness reaches beta in the same release. Scheduling gates let a pod remain ineligible for scheduling until named criteria are satisfied. The announcement says gates can be initialised at creation and removed later, but new gates cannot be added after creation. This provides a declared waiting state instead of repeatedly presenting work to a scheduler before its prerequisites are ready.

For 1.27, the different maturity levels remain relevant. Seccomp defaulting and mutable Job scheduling directives are stable, scheduling readiness is beta, and in-place resource resizing is alpha. The release combines established controls with a new resource-management experiment. Each has its own activation and lifecycle rules, and the resource API's new status fields give that experiment a concrete way to report what the node has actually done.