Skip to content

Attune

Safe, in-place Kubernetes pod resource right-sizing. VPA done right.

Attune is a Kubernetes operator that automatically right-sizes pod resource requests and limits using In-Place Pod Resize (GA in Kubernetes 1.35; beta and enabled by default in 1.33–1.34; alpha since 1.27, still feature-gated on 1.32). Attune requires Kubernetes 1.32+ for the /resize subresource path. In-place by default, optional eviction fallback for infeasible resizes, and no HPA conflicts.

The Problem

Average Kubernetes CPU utilization is about 8% (CAST AI 2026): most of the compute you request sits idle. Separately, industry projections put $44.5 billion of enterprise cloud infrastructure waste in 2025 (Harness 2025), and 70% of organizations cite overprovisioning among top cost drivers (CNCF 2023).

The existing tool for this, VPA, historically resized by evicting pods. It conflicts with HPA on the same metrics, and fewer than 1% of organizations run it in production (ScaleOps 2026, citing Datadog Container Report lineage). Newer VPA modes can attempt in-place resize where the cluster supports it; Attune is built around that path from the start, with canary, auto-revert, and SLO guardrails for unattended use. Recommendation-only tools like Goldilocks show you the numbers but leave you with hundreds of YAML edits that sit in the backlog for months.

Kubernetes 1.35 graduated In-Place Pod Resize to GA (stable). The feature was alpha from 1.27 (feature-gated through 1.32), then beta and enabled by default from 1.33. The foundation for non-disruptive right-sizing is stable. Attune is the operator built for the safe unattended loop on top of that primitive.

How It's Different

In-place apply is the shared Kubernetes primitive. Attune adds the production path: canary blast-radius control, startup boost, and SLO-backed auto-revert.

VPA Goldilocks Attune
Resize method Eviction-based Auto historically; newer modes can use in-place where supported No resize (recommend only) In-place by default (optional eviction fallback)
HPA compatible Risky on the same metric (death spirals) N/A Yes (adjusts base requests, not HPA %)
Safety Minimal guardrails N/A Auto-revert + SLO PromQL guardrails
Blast radius All targeted pods N/A Canary with observation and optional auto-promote
Cold start None N/A Startup boost, then scale back
Algorithm Backward-looking histograms VPA recommender Time-of-day-aware + burst detection + confidence
Production path <1% use in production Manual apply Observe → Recommend → Canary → Auto

Who Is This For?

  • Platform teams managing dozens of namespaces where developers set resource requests once and never look at them again.
  • FinOps teams that need concrete dollar estimates per workload and a safe path from "we know it's overprovisioned" to "it's fixed."
  • SREs running latency-sensitive services where pod restarts during peak traffic are not an option.
  • Anyone running HPA who has been told "VPA and HPA don't mix."

Key Features

  • In-place resize via the Kubernetes /resize subresource (GA in 1.35)
  • Graduated rollout: Observe, Recommend, OneShot, Canary, Auto
  • Canary rollout with observation period and optional auto-promote
  • Startup boost for cold-start / JIT CPU headroom
  • Auto-revert on OOMKill, CPU throttle, restart spikes, pod NotReady, or SLO guardrail breach
  • HPA coexistence without death spirals
  • Confidence scaling for sparse data
  • Time-of-day awareness for bursty workloads
  • Mandatory bounds (no unbounded recommendations)
  • GitOps export (versioned recommendation ConfigMaps) and optional PR automation
  • Multi-cluster fleet reporting and Grafana (multi-cluster guide)
  • Memory usage floor when decreasing limits on Kubernetes 1.35+
  • Runtime profiles for safer memory defaults by language
  • Capacity and pressure awareness with reclaimed-request signals for bin packing

Estimate your savings with the interactive calculator, or read Why Attune? for the full story.

Get Started

Metrics Sources

Attune works with multiple metrics backends. One source is configured per policy:

Backend Guide Use case
Prometheus (+ Thanos, Mimir, VictoriaMetrics) Prometheus Setup Default for most clusters; auto-discovery available
Datadog Datadog Setup Teams already using Datadog for Kubernetes monitoring
CloudWatch Container Insights CloudWatch Setup EKS clusters using AWS-native observability

Reference