Skip to Content
Core InfraWorkload RightsizingIn-Place Optimization

In-Place Optimization
Available in v1.17.0+

ScaleOps leverages Kubernetes’ in-place resource update feature to optimize pods without requiring a full pod restart or eviction, reducing disruption and improving efficiency.

Feature Availability

  • In Kubernetes v1.33 and above, the in-place update feature is Beta and enabled by default.
  • ScaleOps supports in-place optimizations on Kubernetes v1.33+, as long as the feature is enabled in the cluster.

Availability in Built-In Policies

Starting from Version 1.27.0

Starting from version 1.27.0, in-place optimization is enabled for ongoing automation strategy by default in all built-in policies.

Before Version 1.27.0

For ScaleOps versions prior to 1.27.0, in-place optimization can be used in two ways:

  1. Using Specific Built-In Policies: Two built-in policies are available, production-in-place and high-availability-in-place. These are essentially the same as the standard production and high-availability policies, but with in-place optimization enabled.
  2. Creating a Custom Policy: Alternatively, you can create a custom policy by duplicating an existing policy or creating a new one, and ensure that in-place optimization is enabled.

After choosing or creating a policy, associate it with the relevant workloads by either:

  • Creating a rule that targets the appropriate workloads based on labels or annotations
  • Manually selecting the workloads in the UI and assigning the policy directly

How ScaleOps Utilizes In-Place Optimization

inplacepolicy

When the RightSizing Policy is set to use in-place optimization for ongoing rollout strategy or for upon-pod-creation rollout strategy, ScaleOps will attempt to optimize pods using in-place updates.



The process is as follows:

  1. In-Place Attempt
  • ScaleOps will not perform in-place optimization if any of the following are true:
    • The current node does not have enough available resources for the new pod requirements.
    • The optimization would change the pod’s QoS (Quality of Service) class.
    • ResourceQuota constraints in the namespace do not allow the change.
    • The pod has a container with ResizePolicy.RestartPolicy="RestartContainer".
    • The optimization requires removing CPU or memory limits entirely (Kubernetes does not support removing limits via in-place updates).
  • If none of these conditions are present, ScaleOps performs the in-place update by patching the pod’s resources.

Notes:

  • Starting from version 1.25.15, workloads with a single replica and workloads that are part of a Custom Owner Grouping can be optimized using in-place updates. Additionally, RightSizing Policy constraints (such as PDB or workload availability) no longer prevent in-place optimization. For earlier versions, ScaleOps will not perform in-place optimization for such workloads or when these policy constraints apply.
  • Starting from version 1.27.10, CPU limit changes are supported in all Kubernetes versions where in-place optimization is supported, and memory limit changes are supported using Kubernetes 1.34+.
  1. Fallback to Ongoing Optimization
  • If the policy is set to use in-place for ongoing rollout strategy, and in-place optimization is not possible (due to constraints above), ScaleOps will fall back to the standard ongoing optimization process.
  • If the policy and workload constraints allow (e.g., PDB, availability requirements), ScaleOps will attempt to evict the pod or perform a zero-downtime update, depending on the policy.
  1. Fallback to Upon Pod Creation
  • If the policy is set to use in-place for upon-pod-creation rollout strategy, and in-place optimization is not possible (due to constraints above), ScaleOps will not optimize the workload, and the optimization will occur upon the next pod creation.

Observe In-Place Optimizations

The In-Place Optimizations events can be easily tracked in the Workload overview, troubleshoot and events tabs. In the screenshot below, the workload is optimized in-place, and the optimization is reflected in the Workload overview timeline events:

inplacepolicy

Notes

  • When optimization is triggered upon automation for upon-pod-creation pods, ScaleOps will initiate a rollout regardless of the in-place setting. This rollout can be disabled in the policy by disabling the Optimization upon automation option.
  • When removing automation, ScaleOps will revert the optimization without in-place update, regardless of the in-place setting in the policy.
  • In-place optimization does not guarantee zero container restarts. In rare edge cases, a container restart may still occur. This note is particularly important for workloads configured with upon-pod-creation rollout strategy, and any container restarts should be strictly avoided.
  • If ScaleOps attempts in-place optimization but the operation does not succeed within 5 minutes, ScaleOps will revert the in-place request and, if allowed by policy and not blocked by other constraints (such as PDB), will attempt to evict the pod for optimization.

Summary

  • In-place optimization provides a less disruptive way to optimize pod resources, but is subject to several Kubernetes and policy constraints.
  • ScaleOps automatically chooses the best approach based on your policy and the current cluster state, always prioritizing minimal disruption and compliance with your requirements.
Ephemeral StorageHPA and KEDA