Rightsizing Modes¶
SLOpilot's analysis engine always applies the same suite of workload-awareness principles to every recommendation — documented canonically in Understanding Recommendations. Modes control how much headroom the engine reserves above its observations. Three modes span a spectrum from safety-leaning to cost-leaning.
Mode selection is installation-wide: one mode applies to the entire SLOpilot deployment. There is no per-workload or per-namespace override. The default mode, applied when no value is set, is conservative.
How modes relate to the analysis engine¶
Modes layer a headroom adjustment on top of the behaviours that every recommendation already incorporates. In summary:
Workload signals — the analysis engine factors in:
- Out-of-memory termination events in the workload's history
- Usage trend direction — rising, declining, or stable
- Variability — whether usage is spiky or steady-state
- Saturation — usage pressed against the current request ceiling
Detailed in Key principles.
When recommendations are withheld or deferred — during the data-collection warm-up, workloads without sufficient metric history show an informational indicator in place of a recommendation. Detailed in Confidence scoring.
Autoscaler interactions — when a Horizontal or Vertical Pod Autoscaler is detected on a workload, the engine adapts its output accordingly. Detailed in Autoscaler awareness.
The three modes¶
The three modes differ only in the size of the headroom they reserve; the principles above apply identically to all of them.
| Conservative | Default | Aggressive | |
|---|---|---|---|
| Optimisation lean | Safety-leaning | Balanced | Cost-leaning |
| Headroom above observed usage | Larger | Moderate | Tighter |
| Best-fit workload profile | Critical, variable, or spiky | General-purpose | Stable, predictable |
| Primary trade-off | Reliability priority | Balanced | Savings priority |
CPU and memory are analysed independently — the mode knob is applied within each resource type's own strategy, not as a symmetric across-the-board adjustment. See Key principles for how each resource type is treated.
Conservative¶
Conservative is the safety-leaning default. Pick this mode when the bulk of the cluster runs critical, customer-facing, or revenue-generating workloads — payment gateways, authentication services, multi-tenant APIs — or workloads whose usage is spiky, bursty, or otherwise hard to predict. Conservative reserves the largest headroom above observed usage, trading a share of potential savings for a wider margin against regressions.
Default¶
Default is the balanced mode. Pick this mode when the cluster is a mix of general-purpose microservices without an overwhelmingly critical or overwhelmingly stable character. Default reserves moderate headroom — enough to absorb normal variability while reclaiming clearly over-provisioned resources.
Aggressive¶
Aggressive is the cost-leaning mode. Pick this mode when the cluster is dominated by stable, predictable workloads — steady-state batch jobs, cron-driven workers, long-running background processors whose consumption rarely deviates from its recent baseline. Aggressive reserves the tightest headroom and surfaces the largest savings opportunities, with a correspondingly thinner margin.
Choosing a mode¶
Because the mode setting is installation-wide, ask each of the following about the bulk of your cluster's workloads, not about individual services.
- Are most workloads customer-facing or revenue-critical? — choose Conservative.
- Is the cluster a mix of general-purpose microservices without a dominant profile? — choose Default.
- Are most workloads stable, predictable, and long-running (for example, steady batch or cron-driven work)? — choose Aggressive.
- Is your top priority reliability, or cost? — reliability leans toward Conservative; cost savings leans toward Aggressive; Default sits between.
Setting the mode¶
Set the mode via Helm values. If unset, the deployment runs in conservative mode.
See Configuration for how Helm values are supplied during installation and upgrade.
Switching modes¶
Note
Mode changes take effect after a Helm upgrade or pod restart. The currently running mode is shown in the UI footer.
For the analysis principles that every mode shares, see Understanding Recommendations. For the broader Helm configuration surface, see Configuration.