In‑Place Pod Vertical Scaling: Mutable Resource Requests and Limits in Kubernetes
This proposal introduces in‑place vertical scaling for Pods by making PodSpec resources mutable, extending PodStatus with ResourcesAllocated, adding ResizePolicy and Resize fields, and updating the CRI UpdateContainerResources and ContainerStatus APIs to support live CPU and memory adjustments without restarting containers.
The proposal enables on‑the‑fly updates of a Pod's resource requests and limits without recreating the Pod or restarting its containers by making the PodSpec resources mutable and extending PodStatus with a new ResourcesAllocated field that reflects the actual resources assigned by the node.
It also enhances the Container Runtime Interface (CRI) with an updated UpdateContainerResources API that accepts a platform‑agnostic ContainerResources message, allowing the API to work on Windows and future non‑Linux runtimes, and expands ContainerStatus to expose the current CPU and memory limits.
New fields such as ResizePolicy (with values RestartNotRequired and Restart ) are added to PodSpec.Containers to give fine‑grained control over whether a resize can happen without a restart. The Pod.Status.Resize field records the lifecycle of a resize request with possible values Proposed , InProgress , Deferred , and Infeasible .
API changes include making Pod.Spec.Containers[i].Resources a declarative desired state, adding Pod.Status.ContainerStatuses[i].ResourcesAllocated (type v1.ResourceList ) and Pod.Status.ContainerStatuses[i].Resources (type v1.ResourceRequirements ), and introducing Pod.Status.Resize (type map[string]string ) to track resize actions.
The design details describe how the Kubelet interacts with the API server and the CRI to accept, validate, and apply resize requests, how it updates cgroup limits in the correct order, and how it handles failures, conflicts, and node‑level resource accounting.
Risks include backward compatibility concerns, potential issues with decreasing memory limits, and older clients that do not understand the new fields. Implementation notes mention the long‑standing KEP history, the large PR that introduced the changes, and example usage with a test Pod showing how to patch resource requests and observe the resulting resize status transitions.
// ContainerResource saves the container's resource configuration
message ContainerResources {
// Linux‑specific resource configuration
LinuxContainerResources linux = 1;
// Windows‑specific resource configuration
WindowsContainerResources windows = 2;
} message UpdateContainerResourcesRequest {
// ID of the container to update.
string container_id = 1;
// Resource configuration specific to Linux container.
LinuxContainerResources linux = 2;
// Resource configuration for the container.
ContainerResources resources = 3;
} --- a/staging/src/k8s.io/cri-api/pkg/apis/services.go
+++ b/staging/src/k8s.io/cri-api/pkg/apis/services.go
@@
- // UpdateContainerResources updates the cgroup resources for the container.
- UpdateContainerResources(containerID string, resources *runtimeapi.LinuxContainerResources) error
+ // UpdateContainerResources updates resource configuration for the container.
+ UpdateContainerResources(containerID string, resources *runtimeapi.ContainerResources) errorDevOps Cloud Academy
Exploring industry DevOps practices and technical expertise.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.