In-place workload right-sizing

Autonomous workload optimization without restarts

Kubernetes version 1.33 or later, with the beta feature gate enabled, is required to support in-place changes.

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:

Kubernetes v1.33: In-Place Pod Resize Graduated to BetaKubernetes

Not found

Prerequisites

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

🎯 Update Kubernetes to version 1.33 or later and enable the beta InPlacePodVerticalScaling feature gate 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.

No additional configurations are needed, as PerfectScale automatically applies changes in place, delivering instant optimization.

In-place resizing limitations

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

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.

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.

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.

When PerfectScale applies in-place changes to right-size workloads, it unifies pod resources, guaranteeing consistency of the resources across the cluster.

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:

Value	Description
rollingRestart (default)	All pods will be restarted in order to update resources.
deleteRecreatePendingPod	Only pods in the PodResizePending status will be deleted to trigger rescheduling. Conditions: The number of pods in the PodResizePending state is below the 20% threshold. At least 5 pods were successfully updated If any condition fails, a rollingRestart will be applied.

CR example:

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

The Automation Strategy can be configured at the cluster, namespace, or workload level.

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):

automationStrategy: evictMutate