# In-place workload right-sizing

{% hint style="info" %}
Kubernetes version **1.33 or later**, with the **beta feature gate enabled**, is required to support in-place changes.
{% endhint %}

## In-place concept

The standard pod scaling approach requires pods to restart when applying new resource requests and limits. While this can work for stateless applications, it may still introduce latency and service disruptions, making it less suitable for workloads that demand continuous uptime. In addition, this method may add operational overhead for teams to manage it effectively.

To address these challenges, **In-place Workload Right-sizing** is available. This feature is ideal for services where stability is critical, allowing you to improve performance seamlessly, reduce disruption risks due to restarts, and make the optimization process even more flexible and efficient.

With in-place changes enabled, you can:

1. **Keep infrastructure reliable** by eliminating the risks associated with restarts.
2. **Stay continuously optimized** without service disruption.
3. **Maintain operational productivity** without the overhead of time-consuming manual investigation and optimization.

You can find more details about in-place changes on the official Kubernetes website:

{% embed url="<https://kubernetes.io/blog/2025/05/16/kubernetes-v1-33-in-place-pod-resize-beta/>" %}

{% embed url="<https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/1287-in-place-update-pod-resources>" %}

## Prerequisites

To start leveraging in-place workload right-sizing, your cluster must support in-place changes.&#x20;

🎯 Update Kubernetes to **version 1.33 or later** and **enable the beta** `InPlacePodVerticalScaling` [**feature gate**](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/) for your control plane and for all nodes in your cluster. After that, PerfectScale will automatically perform in-place workload right-sizing without additional effort from your side.

{% hint style="success" %}
No additional configurations are needed, as PerfectScale automatically applies changes in place, delivering instant optimization.
{% endhint %}

## In-place resizing limitations

<table><thead><tr><th width="277.4478759765625">Limitation</th><th>Description</th></tr></thead><tbody><tr><td>Supported workload types</td><td><p><strong>Deployment</strong></p><p><strong>StatefulSet</strong></p><p><strong>DaemonSet</strong></p></td></tr><tr><td>Resizable resources</td><td><p><strong>CPU</strong></p><ul><li>request</li><li>limit</li></ul><p><strong>Memory</strong></p><ul><li>request</li><li>limit (increase only)</li></ul></td></tr><tr><td>Operating system</td><td>Windows pods do not support in-place</td></tr><tr><td>Kubernetes version</td><td><strong>1.33</strong> or later</td></tr><tr><td>Container resize policy</td><td><strong>restartPolicy: NotRequired</strong> (apply the resource change to the running container without restarting it).<br>If <strong>restartPolicy: RestartContainer</strong> - in-place changes will not apply.</td></tr><tr><td>QoS Class</td><td>The Pod's original QoS class is determined at creation and cannot be changed by a resize.</td></tr></tbody></table>

## In-place right-sizing with PerfectScale Automation

In-place pod resizing combined with PerfectScale Automation provides a complete solution for graceful and effective workload right-sizing. It eliminates manual effort associated with identifying inefficiencies and risks due to guestimated allocations, enabling continuous safe cost-reduction.

{% hint style="info" %}
If in-place resizing is not supported, PerfectScale’s safe automation algorithm will apply changes with a traditional scaling approach, ensuring your clusters remain reliable and stable.
{% endhint %}

For automated pods that support in-place changes, when an over-provisioned or under-provisioned workload is detected, PerfectScale instantly applies data-driven recommendations without pod restart, ensuring safe K8s optimization.

{% hint style="success" %}
When PerfectScale applies in-place changes to right-size workloads, **it unifies pod resources, guaranteeing consistency of the resources** across the cluster.
{% endhint %}

### PodResizePending handling

You may encounter a situation where it is impossible to apply new resources to a pod. In this case, the pod will get the **PodResizePending** status. This can happen due to:

1. The requested resize **is impossible** on the current node (for example, requesting more resources than the node can provide).
2. The requested resize **is not currently possible**, but may become possible later (for example, if another pod is removed and resources become available).

To handle such cases, you can configure the `PodResizePending` strategy in the automation configuration CR by specifying one of the following values:

<table><thead><tr><th width="230.880126953125">Value</th><th>Description</th></tr></thead><tbody><tr><td><strong><code>rollingRestart</code></strong> (default)</td><td>All pods will be restarted in order to update resources.</td></tr><tr><td><strong><code>deleteRecreatePendingPod</code></strong></td><td>Only pods in the <code>PodResizePending</code> status will be deleted to trigger rescheduling.<br><br><strong>Conditions</strong>:<br><i class="fa-circle-right">:circle-right:</i> The number of pods in the <code>PodResizePending</code> state is below the 20% threshold. <br><i class="fa-circle-right">:circle-right:</i> At least 5 pods were successfully updated<br><br>If any condition fails, a <strong><code>rollingRestart</code></strong> will be applied.</td></tr></tbody></table>

**CR example:**

```yaml
apiVersion: perfectscale.io/v1
kind: WorkloadAutomationConfig
metadata:
  name: workload-automation-config
  namespace: your-namespace
spec:
  targetRef:
    kind: Deployment
    name: pacmem-inplace-resize-burstable-qos
  automation:
    operational:
      automationMode: Enabled
      automationStrategy: inPlace
      podResizePendingStrategy: rollingRestart # configured PodResizePending strategy
```

{% hint style="success" %}
The **Automation Strategy** can be configured at the **cluster**, **namespace**, or **workload** level.
{% endhint %}

## Reverting to the evictMutate strategy

Once the agent is updated to **v1.0.26 or later**, PerfectScale **defaults to the In-Place** automation strategy. If a customer wants to opt out of In-Place automation and revert to the **evict + mutate** behavior, this must be explicitly configured in the Automation CR at the desired level (cluster, namespace, or workload):

```yaml
automationStrategy: evictMutate
```