chore: write dev.to article announcing Attune

[SebTardif]

Summary

Write and publish a dev.to article introducing Attune as a modern VPA alternative that leverages Kubernetes in-place pod resize.

Suggested Title

"Attune: In-Place Pod Right-Sizing for Kubernetes (A Modern VPA Alternative)"

Content Outline

1. The problem: Kubernetes resource requests are set once and drift from reality. Over-provisioning wastes money; under-provisioning causes OOMs.
2. VPA limitations: Pod restarts, HPA conflicts, short metric history, no safety rails.
3. What Attune does differently: In-place resize (no restarts), auto-revert on OOM/throttling, graduated rollout (Observe/Recommend/Auto), time-of-day scheduling, HPA compatibility, Prometheus-native.
4. Quick demo: Show a policy YAML, the operator detecting over-provisioning, and an in-place resize happening.
5. Getting started: Helm install, create an AttunePolicy, see results.
6. Comparison table: Attune vs VPA vs Goldilocks vs KRR.

Why

dev.to is a high-traffic developer platform. Multiple VPA and right-sizing articles from 2025-2026 get significant engagement. Keywords like "kubernetes right-sizing", "VPA alternative", and "in-place resize" have active search traffic. Both VPA and Prometheus Operator have multiple dev.to articles; Attune has none.

Effort

2-3 hours for writing, screenshots, and publishing.

Context

Gap analysis: VPA and Prometheus Operator have strong dev.to presence. Attune has zero articles. This is the highest-impact content marketing effort.

[SebTardif]

Draft Article (for review)

Click to expand full article

---

title: "Stop Evicting Pods to Right-Size Them: In-Place Kubernetes Resource Tuning with Attune"
published: false
description: "Kubernetes clusters average 8% CPU utilization. VPA fixes this by evicting your pods. Attune fixes this without restarts, using in-place pod resize."
tags: kubernetes, devops, opensource, cloudnative
cover_image: https://placeholder.example.com/attune-cover.png

Your Kubernetes cluster is using 8% of the CPU you're paying for.

That number comes from the CAST AI 2026 State of Kubernetes Optimization report, and it lines up with what most platform teams already suspect. Developers set resource requests to "something that works," add a generous safety margin because nobody wants a 3 AM page, and never touch it again. Multiply that across every container in every namespace, and you're paying for roughly 10x the compute you actually use.

This is not a niche problem. The CNCF 2023 FinOps microsurvey found that 70% of respondents cite overprovisioning as the number one cost driver in their cloud-native infrastructure.

The Kubernetes ecosystem has had a tool for this since 2018: the Vertical Pod Autoscaler. So why hasn't it solved the problem?

The VPA Problem

Less than 1% of organizations run VPA in fully automated mode (ScaleOps 2026). That number tells you everything. VPA has three fundamental problems that prevent production adoption.

It evicts your pods. VPA's "Auto" mode applies new resource values by evicting pods and letting the controller recreate them. In practice, this means pod restarts during traffic spikes, JVM cold-start penalties that can drop throughput by 5x, and lost progress for stateful workloads.

It fights with HPA. If you run VPA and HPA on the same workload, they create a death spiral. VPA sees low average CPU and lowers requests. HPA sees the resulting utilization spike and scales out. More replicas with smaller requests means lower average usage again. VPA lowers requests further. The official Kubernetes documentation explicitly warns against this.

It has no safety net. VPA uses backward-looking exponential histograms with no understanding of time-of-day patterns. Recommendations are unbounded by default. There is no canary rollout, no auto-revert on failure, and no per-cycle budget cap.

What Changed: In-Place Pod Resize

Kubernetes 1.32 introduced the InPlacePodVerticalScaling feature gate (alpha). Kubernetes 1.33 graduated it to beta, enabled by default. It will reach GA in Kubernetes 1.35.

This feature adds a /resize subresource to pods. The kubelet adjusts cgroup limits directly, without restarting the container. No eviction, no cold starts, no lost connections.

How Attune Works

Attune is a Kubernetes operator that automatically right-sizes pod resource requests and limits using in-place pod resize. It is open source under the Apache 2.0 license.

The operator reconciles AttunePolicy custom resources. On each cycle:

1. Metrics Collector queries Prometheus for CPU and memory usage over a configurable history window (also supports Thanos, VictoriaMetrics, Mimir).
2. Recommender Engine processes usage data through composable estimators: Percentile, Margin, Burst detection, Confidence scoring, Bounds clamping, and Change filtering.
3. Resize Engine calls UpdateResize on each pod's /resize subresource. Optional eviction fallback for infeasible resizes respects PDBs.
4. Safety Monitor watches resized pods for OOMKills, CPU throttle spikes, restart increases, and Ready condition loss. Auto-reverts on any signal.

The Graduated Rollout Model

Policies progress through graduated modes:

• Observe: Collects metrics silently. Zero footprint.
• Recommend: Surfaces recommendations and savings. Nothing applied.
• Canary: Resizes a percentage of pods first, watches them, auto-promotes only if safe.
• Auto: Resizes all eligible pods with full safety monitoring and auto-revert.

Quick Start

Install

helm install attune oci://ghcr.io/attune-io/charts/attune \
  --namespace attune-system --create-namespace

Create a Policy

apiVersion: attune.io/v1alpha1
kind: AttunePolicy
metadata:
  name: api-services
  namespace: production
spec:
  targetRef:
    kind: Deployment
    selector:
      matchLabels:
        tier: api
  metricsSource:
    prometheus:
      address: http://prometheus-server.monitoring:80
  cpu:
    percentile: 95
    overhead: "20"
    minAllowed: "1m"
    maxAllowed: "4000m"
  memory:
    percentile: 99
    overhead: "30"
    minAllowed: "4Mi"
    maxAllowed: "8Gi"
  updateStrategy:
    type: Recommend

Check Results

kubectl attune savings -n production
NAMESPACE   NAME          CPU SAVED  MEMORY SAVED  % SAVED  EST. MONTHLY
production  api-services  830m       1012Mi        34%      $72.40

How It Compares

	VPA	Goldilocks	Attune
Resize method	Evicts pods	No resize (recommend only)	In-place (no restarts)
HPA compatible	No (death spirals)	N/A	Yes (adjusts absolute base, not %)
Safety	Minimal guardrails	N/A	Graduated rollout + auto-revert
Algorithm	Backward-looking histograms	VPA recommender	Time-of-day-aware + burst detection
Production confidence	<1% use automated	N/A	Observe, Recommend, Canary, Auto

Get Started

Available on OperatorHub.io, Artifact Hub, Krew, Docker Hub, and GHCR.

Star the repo, try it in a staging cluster, file issues, or open a PR. Contributions are welcome.

[SebTardif]

Blocked by external factors: requires manual outreach, submission, or approval from third-party site/list maintainers (no API for most). Will re-evaluate and batch when higher-priority code/tech-debt items are cleared. Tracked here for visibility.

[SebTardif]

Blocked by external factors: manual outreach/submission to third-party lists or sites. Will re-batch when higher priority code items clear. Tracked for visibility.

[SebTardif]

Community/outreach chore. Currently blocked on external platform requirements or response (star thresholds, manual review queues, or form submissions). Not actionable in active engineering or multi-perspective cycles until the external dependency moves. Will re-evaluate during future backlog gates. No code change required from the Attune side at this time.

[SebTardif]

Dependency: Do not publish until kubernetes/website#55963 (K8s blog, tracked in #122) is either published or rejected. The K8s blog requires original, unpublished content. Publishing here first would disqualify the K8s blog submission.

If the K8s blog post is accepted: cross-post here with a canonical URL pointing to kubernetes.io/blog.
If rejected: publish here as the primary, then cross-post to Medium (#166).