Boot-Time Optimization Available in v1.30.14+
Some workloads consume significantly more CPU during container startup than during steady-state operation. Without accounting for this, a right-sized workload may experience CPU pressure at boot — causing slow starts, failed readiness probes, or stress on the node it lands on.
Boot-time optimization solves this by detecting the startup spike pattern and making three targeted adjustments: it shapes the CPU request during the boot window, intervenes immediately when a starting pod is under CPU stress, and guides Karpenter to schedule pods on nodes large enough to absorb the spike.
What It Does
When ScaleOps detects that a workload’s CPU usage during startup is significantly higher than its steady-state usage, it makes the following adjustments:
Startup-aware CPU requests CPU requests during the boot window reflect the higher startup demand rather than the steady-state recommendation. Once the boot window closes, the request is reduced back to the steady-state recommendation. This flow works alongside in-place optimization.
Immediate intervention on startup CPU stress If a pod experiences CPU pressure while booting, ScaleOps reacts immediately using the boot-time CPU recommendation — independent of the normal optimization cycle.
Karpenter node affinity guidance On Karpenter-managed clusters, ScaleOps adds a preferred node affinity to pods so they are scheduled on instance types large enough to handle the startup spike. This reduces the chance of a pod landing on a node that is correctly sized for steady state but under-provisioned for boot.
Boot-time optimization applies to CPU only and covers all workload types.
How to Enable
Built-in policies
Boot-time optimization is enabled by default in all built-in policies. No action is required.
Custom policies
Enable or disable the setting in the policy editor:
Policy edit → Automation → Boot-time optimization
GitOps / Policy CR
spec:
policyOptimize:
rightSizePolicy:
bootTimeOptimizationEnabled: true # or false to disableLimitations
- CPU only — Memory startup spikes are not acted on.
- Karpenter node affinity — The preferred node affinity is added only for workloads running on Karpenter-managed nodes. It has no effect on other node provisioners.