Kubernetes 1.37 In-Place Pod Resize: How Scheduler Preemption Handles CPU and Memory Shortages

Kubernetes workloads do not always consume the same amount of CPU and memory throughout their lifetime.

A service may need more CPU during a traffic spike, while a batch workload may temporarily require additional memory during a processing phase. Traditionally, changing a Pod's resource requests and limits required recreating the Pod, which could interrupt the workload or complicate application management.

Kubernetes supports in-place Pod resizing, allowing the CPU and memory resources of a running Pod to be changed without restarting the Pod when the workload and resource configuration permit it.

Kubernetes 1.37 makes this capability more mature, while scheduler improvements address an important problem: what happens when a requested resize cannot fit on the current node?

The answer involves scheduler feasibility checks and preemption.

Instead of treating a resize as a completely independent operation, Kubernetes can evaluate whether the requested resources fit and, when necessary, consider whether lower-priority workloads can be preempted to make room.

This article explains how in-place Pod resizing works, how the scheduler evaluates resize requests, how preemption interacts with resizing, and what operators should consider before using it in production.

What Is In-Place Pod Resize?

In-place Pod resize allows a running Pod's resource requests and limits to be changed without recreating the Pod.

Consider a Pod initially configured with:

resources:
  requests:
    cpu: "500m"
    memory: "512Mi"
  limits:
    cpu: "1"
    memory: "1Gi"

Later, the workload requires more CPU:

CPU Request
500m
  ↓
1 CPU

With in-place resizing, Kubernetes can update the Pod's resource configuration while keeping the same Pod instance.

Conceptually:

Running Pod
    |
    v
Resize Request
    |
    v
Scheduler Evaluation
    |
    +---- Fits ----> Apply Resize
    |
    +---- Does Not Fit
                |
                v
             Preemption
                |
                v
          Apply Resize

This is particularly useful for long-running workloads where restarting a Pod is undesirable.

Why In-Place Resize Matters

Without in-place resizing, an operator or controller typically has to change a workload template and allow Kubernetes to create a replacement Pod.

For example:

Deployment
   |
   v
Update Resources
   |
   v
New ReplicaSet
   |
   v
New Pod
   |
   v
Old Pod Removed

This can be perfectly acceptable for stateless applications.

However, it is less convenient for:

• Stateful workloads

• Long-running processing jobs

• Large in-memory applications

• Applications with expensive startup

• Workloads where preserving process state matters

In-place resize provides another option:

Existing Pod
   |
   v
Resource Update
   |
   v
Same Pod Continues

The Pod identity and application process can remain intact depending on the resize mode and resource change.

CPU and Memory Behave Differently

One of the most important concepts is that CPU and memory are not equivalent from the runtime's perspective.

CPU is generally a compressible resource.

If additional CPU is available, the runtime can adjust CPU allocation without necessarily changing the application's memory layout.

Memory is different.

If a process has allocated memory, Kubernetes cannot simply assume that additional memory can always be provided without considering node capacity.

Similarly, reducing a memory limit can be dangerous if the application is already consuming more memory than the requested new limit.

Therefore, resize behavior depends on:

• Current resource usage

• Requested resources

• Limits

• Node capacity

• Container runtime behavior

• Resize policy

• Scheduler feasibility

Resource Requests vs. Limits

Before discussing scheduling, it is important to separate requests and limits.

Request

A resource request represents the amount of a resource Kubernetes uses when making scheduling decisions.

For example:

resources:
  requests:
    cpu: "500m"
    memory: "512Mi"

The scheduler uses these values to determine whether a Pod can fit on a node.

Limit

A limit defines the maximum resource amount available to a container under the applicable runtime behavior.

For example:

resources:
  limits:
    cpu: "1"
    memory: "1Gi"

During an in-place resize, changing requests can therefore affect scheduling, while changing limits can affect runtime enforcement.

Resize Policies

Kubernetes supports resize policies that determine how a container's resource changes affect the running container.

A simplified example is:

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

The policy indicates whether changing a particular resource requires the container to restart.

The exact behavior depends on the resource and container runtime support.

The important principle is:

Resize Request
     |
     v
Resize Policy
     |
     +---- Restart Required
     |
     +---- Restart Not Required

In-place resize therefore does not mean that every resource change is guaranteed to happen without a container restart.

The Scheduler's Role

A resize request can change the resource requirements of a running Pod.

That creates a scheduling question:

Does the current node have enough allocatable capacity for the new resource request?

Suppose a node has:

Allocatable CPU: 8
Current workload requests: 7.5

A running Pod currently requests:

CPU: 500m

and asks to increase its request to:

CPU: 2

The new total requirement may exceed the node's available capacity.

The scheduler therefore needs to evaluate the resize just as it would evaluate whether a newly scheduled Pod can fit.

A Resize That Fits

Consider:

Node capacity
8 CPU

Current allocation
6 CPU

Resize request
+1 CPU

Result
7 CPU

There is sufficient capacity.

The scheduler can accept the resize.

Pod
 |
 | resize +1 CPU
 v
Scheduler
 |
 | fits
 v
Resize Accepted

No preemption is necessary.

A Resize That Does Not Fit

Now consider:

Node capacity
8 CPU

Current allocation
7.5 CPU

Resize request
+1 CPU

The resulting requirement would be:

8.5 CPU

The node cannot satisfy it.

At this point, Kubernetes can evaluate preemption.

What Is Scheduler Preemption?

Preemption allows a higher-priority Pod to cause lower-priority Pods to be removed from a node when sufficient resources cannot otherwise be found.

Consider:

Node
|
+-- High Priority Pod
|     Request: 2 CPU
|
+-- Low Priority Pod
      Request: 1 CPU

If the high-priority workload cannot fit and the low-priority Pod can be removed, the scheduler may preempt the lower-priority workload.

The basic flow is:

Unschedulable Work
       |
       v
Find Candidate Nodes
       |
       v
Evaluate Preemption
       |
       v
Select Victims
       |
       v
Remove Lower-Priority Pods
       |
       v
Schedule Higher-Priority Work

With in-place resizing, a similar concept can apply to making room for a larger resource requirement.

How Resize and Preemption Interact

Imagine a running Pod:

Priority: 1000
CPU Request: 1

It requests:

CPU Request: 3

The node currently has insufficient free CPU.

Another workload on the same node has:

Priority: 100
CPU Request: 2

The scheduler can evaluate whether removing the lower-priority workload would make the resize feasible.

Conceptually:

Pod Resize
   |
   v
Does Current Node Fit?
   |
   +---- Yes ----> Resize
   |
   +---- No
         |
         v
   Can Preemption Help?
         |
         +---- Yes
         |      |
         |      v
         |  Select Victims
         |      |
         |      v
         |  Free Resources
         |      |
         |      v
         |    Resize
         |
         +---- No
                |
                v
          Resize Pending

The exact scheduler behavior depends on the resource, priority configuration, and the set of workloads running on the node.

Why Priority Matters

Preemption relies on Pod priority.

For example:

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: critical-workload
value: 100000
globalDefault: false
description: "Priority for critical workloads"

A Pod can then reference the class:

spec:
  priorityClassName: critical-workload

A lower-priority workload might have:

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: standard-workload
value: 100
globalDefault: false

This creates an ordering:

critical-workload
      100000
         |
         v
standard-workload
        100

When resources become scarce, the scheduler can use these priorities when determining which workloads are eligible for preemption.

Preemption Is Not Free

Preemption can solve a capacity problem, but it also introduces disruption.

A preempted Pod may be:

• Terminated

• Rescheduled elsewhere

• Restarted

• Delayed

• Subject to graceful termination

Therefore, increasing one Pod's resources by preempting another workload can have an operational cost.

A production system should not treat preemption as a free capacity expansion mechanism.

Pod Disruption Budgets Still Matter

Pod Disruption Budgets can influence whether workloads are suitable victims during preemption.

For example:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: payment-api
spec:
  minAvailable: 3
  selector:
    matchLabels:
      app: payment-api

If the workload must maintain three available replicas, the scheduler considers that constraint when evaluating possible preemption scenarios.

This does not mean a Pod Disruption Budget makes a workload absolutely impossible to disrupt in every situation. It is one of several factors considered by scheduling and eviction mechanisms.

Why Preemption Is a Last Resort

The scheduler first attempts to find a feasible solution without removing other workloads.

Conceptually:

Resize
 |
 v
Current Node Fits?
 |
 +---- Yes ----> Apply
 |
 +---- No
       |
       v
Other Feasible Node?
       |
       +---- Yes ----> Move / Schedule as Supported
       |
       +---- No
              |
              v
        Evaluate Preemption

This is preferable to immediately terminating workloads whenever a resource resize is requested.

In-Place Resize vs. Pod Recreation

In-place resize does not eliminate the need for scheduling.

It changes the point at which scheduling decisions occur.

Example Deployment

Consider a simple workload:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server
spec:
  replicas: 3
  selector:
    matchLabels:
      app: api-server
  template:
    metadata:
      labels:
        app: api-server
    spec:
      containers:
        - name: api
          image: example/api:1.0
          resources:
            requests:
              cpu: "500m"
              memory: "512Mi"
            limits:
              cpu: "1"
              memory: "1Gi"

During a traffic increase, the workload may need:

CPU Request
500m → 1 CPU

Instead of rebuilding the Pod, an in-place resize can update its resources.

The actual resource update can be performed through Kubernetes APIs using the supported Pod resize mechanism.

For example, an API-based update conceptually modifies:

spec:
  containers:
    - name: api
      resources:
        requests:
          cpu: "1"
          memory: "512Mi"

The scheduler then evaluates whether the new request can be accommodated.

Checking Pod Resize Status

A resize request does not necessarily mean the new resources have been immediately applied.

Operators should inspect the Pod's status.

For example:

kubectl get pod api-server-xxxxx -o yaml

Look for the resource-related fields under the Pod's status and container status.

The important operational distinction is:

Requested Resources
        ≠
Resources Successfully Applied

A resize can be pending or constrained by node capacity and runtime behavior.

Monitoring a Resize

A production controller should not assume that:

API Update Successful

means:

Resource Change Fully Applied

The system should observe the resulting Pod state.

A practical workflow is:

Request Resize
     ↓
Watch Pod Status
     ↓
Check Actual Resources
     ↓
Verify Container State
     ↓
Confirm Application Health

This is especially important when memory changes are involved.

Memory Resize Requires Extra Care

Memory is usually the more operationally sensitive resource.

Suppose a container currently consumes:

900Mi

and its memory limit is reduced to:

512Mi

That change can be unsafe because the process is already using more memory than the new limit.

Similarly, increasing memory may fail to become effective if the node cannot provide enough capacity.

Therefore:

Memory Resize
      |
      +--> Current Usage
      |
      +--> New Limit
      |
      +--> Node Capacity
      |
      +--> Runtime Support

all need to be considered.

CPU Resize Is Often More Flexible

CPU changes generally have fewer immediate safety concerns than memory changes.

For example:

500m → 1 CPU

can often be applied without restarting the process when the runtime and resize policy permit it.

However, a larger CPU request still affects scheduling feasibility.

This is why CPU resize can trigger the same capacity question:

Does the node have enough allocatable CPU?

If not, the scheduler must determine whether the request can be accommodated elsewhere or through preemption.

Scheduler Preemption and Running Pods

Traditional scheduling usually answers:

Where should this new Pod run?

In-place resize adds another question:

Can this existing Pod continue running with its new resource requirements on its current node?

That creates an interesting scheduling model:

New Pod
  |
  v
Where can it fit?

Existing Pod Resize
  |
  v
Can it continue with the new footprint?

The scheduler therefore has to reason about a resource transition rather than simply a new Pod placement.

What Happens If Preemption Cannot Solve the Problem?

Suppose a Pod asks for:

CPU: 10

but no node can provide enough capacity, even after considering preemption.

The resize cannot simply create capacity that does not exist.

The result is effectively:

Resize Request
      |
      v
No Feasible Node State
      |
      v
Resize Remains Pending

This is an important operational lesson.

In-place resizing does not create cluster capacity.

It only provides a more flexible way to modify an existing workload's resource footprint.

Cluster Capacity Still Matters

If workloads frequently request resources larger than the cluster can accommodate, the correct solution may be:

• Add nodes

• Use larger nodes

• Adjust resource requests

• Improve workload placement

• Change priority configuration

• Scale workloads horizontally

• Optimize application resource usage

Preemption should not be used as a substitute for capacity planning.

Common Mistakes

Assuming Every Resize Is Instant

Resource changes can take time to become effective.

Always inspect Pod status.

Treating CPU and Memory as Identical

They have different runtime and operational characteristics.

Ignoring Pod Priority

Preemption behavior depends heavily on priority relationships.

Overusing High Priority Classes

If everything has a very high priority, priority loses much of its usefulness.

Assuming Preemption Creates Capacity

Preemption only redistributes existing cluster resources.

Reducing Memory Limits Aggressively

Reducing memory below current usage can create instability.

Ignoring Application Health

A technically successful resize does not guarantee that the application remains healthy.

Troubleshooting a Pending Resize

If a resize does not complete as expected, investigate in this order.

Check the Pod

kubectl get pod <pod-name> -o yaml

Check Events

kubectl describe pod <pod-name>

Look for scheduling, resource, and resize-related events.

Check Node Capacity

kubectl describe node <node-name>

Review:

• Allocatable CPU

• Allocatable memory

• Existing workload requests

• Current pressure conditions

Check Pod Priority

kubectl get pod <pod-name> -o jsonpath='{.spec.priority}'

A high-priority Pod may be eligible for preemption decisions that a lower-priority Pod would not receive.

Check Cluster Capacity

If no node can satisfy the new request, preemption cannot solve the problem indefinitely.

Production Design Recommendations

Keep Resource Requests Realistic

Do not use artificially high requests simply because in-place resizing is available.

Use Priority Classes Deliberately

Reserve high priorities for workloads that genuinely need them.

Protect Critical Services

Use appropriate Pod Disruption Budgets and redundancy for important applications.

Monitor Resize Operations

A controller or automation system should observe the final Pod state instead of assuming success.

Test Memory Resizing

Memory changes deserve more testing than simple CPU adjustments.

Keep Capacity Headroom

A cluster operating permanently at 95–100% requested capacity leaves little room for safe resizing.

Prefer Horizontal Scaling Where Appropriate

Not every workload needs a larger Pod.

For stateless services, adding replicas may be safer than repeatedly increasing individual Pod resources.

Advantages of In-Place Pod Resize

Disadvantages and Risks

In-Place Resize vs. Vertical Pod Autoscaling

In-place resize is also closely related to Vertical Pod Autoscaler (VPA).

VPA traditionally analyzes workload resource usage and recommends or applies resource changes.

The important distinction is that in-place resizing provides Kubernetes with a mechanism for changing resources without necessarily recreating the Pod.

Conceptually:

VPA
 |
 | recommends resource change
 v
Pod Resize
 |
 v
Scheduler
 |
 v
Runtime

This creates an important foundation for more dynamic resource management.

However, VPA behavior, update modes, and in-place resizing capabilities should be evaluated separately. Operators should not assume that enabling in-place Pod resize automatically turns every VPA workflow into a disruption-free operation.

A Practical Resource-Scaling Strategy

For a production API, a reasonable strategy might be:

Normal Traffic
   |
   v
500m CPU / 512Mi
   |
   v
Traffic Increase
   |
   v
Resize to 1 CPU / 768Mi
   |
   v
Scheduler Feasibility Check
   |
   +---- Fits ----> Apply Resize
   |
   +---- Does Not Fit
             |
             v
       Evaluate Placement
             |
             v
       Evaluate Preemption
             |
             +---- Feasible ----> Resize
             |
             +---- Not Feasible
                        |
                        v
                  Add Capacity /
                  Keep Resize Pending

This combines application-level scaling with cluster-level scheduling rather than assuming the resize itself is sufficient.

A Production Checklist

Before adopting in-place Pod resize, verify:

[ ] Kubernetes version supports the required resize behavior
[ ] Container runtime supports the required resource changes
[ ] Resize policies are configured correctly
[ ] CPU and memory behavior have been tested separately
[ ] Pod priorities are intentionally configured
[ ] Preemption impact is understood
[ ] Critical workloads have appropriate protection
[ ] Cluster capacity has sufficient headroom
[ ] Resize status is monitored
[ ] Application health is monitored after resize
[ ] Rollback behavior is documented
[ ] VPA integration is tested if applicable

Conclusion

In-place Pod resizing gives Kubernetes workloads a more flexible way to respond to changing resource requirements without automatically recreating the Pod.

The important architectural change is that a resource update can become a scheduling problem:

Resource Change
      |
      v
Can Current Node Fit?
      |
      +---- Yes ----> Apply Resize
      |
      +---- No
             |
             v
       Evaluate Scheduling
             |
             v
       Consider Preemption
             |
       +-----+-----+
       |           |
       v           v
    Feasible    Not Feasible
       |           |
       v           v
    Resize      Pending /
                Capacity Needed

Preemption can help when a higher-priority workload needs additional resources and lower-priority workloads can safely give up capacity. But preemption is not a replacement for capacity planning, and it can introduce disruption for the workloads that are removed.

The safest approach is to combine in-place resizing with realistic resource requests, carefully designed priority classes, sufficient cluster headroom, application health monitoring, and a clear rollback strategy.

For Kubernetes operators, the major benefit is not simply the ability to change CPU or memory while a Pod is running. It is the ability to make resource allocation more dynamic while allowing the scheduler to reason about the consequences of that change.