chore: submit guest post to CNCF blog

[SebTardif]

Summary

Submit a guest blog post to the CNCF blog about in-place pod right-sizing with Attune.

Suggested Title

"Safe In-Place Pod Right-Sizing in Kubernetes 1.33+ with Attune"

Content Angle

Focus on the Kubernetes ecosystem story rather than pure product promotion:

1. In-place pod resize graduating to beta in K8s 1.33 (and GA in 1.35) changes the right-sizing landscape
2. How operators can leverage the /resize subresource safely
3. Patterns for graduated rollout (observe, recommend, auto) with safety rails
4. How Attune implements these patterns with Prometheus metrics
5. Comparison with the VPA approach and what the ecosystem gains

Submission Process

CNCF blog accepts guest posts via their editorial process. Posts should be educational and ecosystem-focused, not purely promotional.

Why

The CNCF blog published VPA optimization guidance and a Prometheus Operator definitive guide. An Attune post would reach the CNCF's large audience of cloud-native practitioners. In-place resize is a hot topic in 2026.

Effort

3-4 hours for writing; editorial review timeline varies.

Context

Gap analysis: Both VPA and Prometheus Operator have CNCF blog posts. Attune has none. This is a high-credibility channel.

[SebTardif]

Draft CNCF Blog Post + Pitch Email (for review)

Click to expand pitch email

Subject: Guest post pitch: Safe In-Place Pod Right-Sizing in Kubernetes 1.33+

Hi,

Now that In-Place Pod Resize has graduated to beta in Kubernetes 1.33 (KEP-1287), the ecosystem has a foundation for non-disruptive vertical scaling for the first time. I'd like to contribute a guest post that walks through the patterns platform teams need for safe adoption: graduated rollout, automatic revert on safety violations, HPA coexistence, and scheduling windows. The post uses Attune, an Apache 2.0 operator built on the /resize subresource, as a concrete reference implementation, but the patterns apply to any tooling built on this API. The target audience is platform engineers and SREs evaluating how to close the right-sizing gap without the disruption VPA introduced.

Best regards,
Sebastien Tardif

Click to expand full article draft

Safe In-Place Pod Right-Sizing in Kubernetes 1.33+ with Attune

Kubernetes clusters waste resources at a staggering scale. CAST AI's 2026 State of Kubernetes Optimization report measured average CPU utilization at 8% across production clusters. The CNCF's own 2023 FinOps microsurvey found that 70% of organizations cite overprovisioning as their number-one cost driver. The tooling to fix this has existed since 2018 in the form of the Vertical Pod Autoscaler (VPA), yet fewer than 1% of organizations run VPA in fully automated mode.

The gap between knowing about overprovisioning and actually fixing it is not a knowledge problem. It is a safety problem. VPA's mechanism for applying changes (evicting pods and recreating them with new resource values) introduces the very disruption that production teams cannot tolerate. With the graduation of In-Place Pod Resize to beta in Kubernetes 1.33, that constraint no longer exists.

This post explores the patterns that make in-place right-sizing safe for production adoption and shows how one open-source operator, Attune, implements them.

The Right-Sizing Gap

Developers set resources.requests to "something that works," add a safety margin because they do not want 3 AM pages, and never revisit the values. Across every container in every deployment in every namespace, these conservative estimates compound into massive waste.

VPA was supposed to solve this. In practice, it introduced three problems that kept adoption near zero:

VPA evicts pods to apply changes. In "Auto" mode, VPA deletes a pod so the controller recreates it with new resource values. This means restarts during traffic spikes, JVM cold-start penalties, loss of in-memory state for stateful workloads, and cascading failures when VPA evicts infrastructure components.

VPA conflicts with HPA. When VPA lowers resource requests, the Horizontal Pod Autoscaler sees utilization spike and scales out. More replicas with lower requests means lower average usage, so VPA lowers requests further. This feedback loop is the well-documented "death spiral."

Recommendation-only tools do not close the loop. Tools like Goldilocks and KRR surface recommendations, but for a platform running 200 microservices, that means 200 YAML edits and 200 rollouts. In practice, the recommendations go stale before they are applied.

What In-Place Pod Resize Changes

Kubernetes 1.27 introduced In-Place Pod Vertical Scaling as an alpha feature (KEP-1287). Kubernetes 1.33 graduated it to beta, enabled by default. Kubernetes 1.35 promoted it to GA.

The feature adds a /resize subresource on pods. The kubelet applies new resource values to the running container's cgroup configuration directly. CPU changes take effect immediately. Memory limit increases take effect immediately; decreases apply when the container's working set drops below the new limit. The container is never restarted.

This is the primitive the ecosystem needed. The question shifts from "can we right-size safely?" to "what patterns should we follow?"

Patterns for Safe Adoption

Pattern 1: Graduated Rollout

A graduated rollout path lets operators build confidence incrementally:

1. Observe: Collect metrics silently. Validates that metrics pipelines work.
2. Recommend: Compute and display recommendations without acting.
3. Canary: Resize a small percentage of pods first. Watch through an observation period before touching the rest.
4. Auto: Continuously resize all eligible pods.

Most production teams follow a progression measured in weeks: Recommend for one to two weeks, Canary for a week, then Auto.

Pattern 2: Safety Rails

Any system that modifies running pod resources must have:

• Auto-revert on safety violations. OOMKill, CPU throttle spikes, restart increases, or Ready condition loss trigger immediate in-place revert.
• Exponential backoff. Each consecutive revert increases cooldown.
• Change filters. Minimum change threshold (e.g., 10%) prevents churn.
• Per-cycle budget caps. Limit aggregate CPU/memory increases per cycle.
• Resource bounds. Hard min/max values prevent nonsensical recommendations.

Pattern 3: HPA Coexistence

The solution is to separate concerns: vertical scaling adjusts the base resource request per pod, while HPA adjusts the replica count. Because in-place resize modifies cgroup limits without restarting, HPA's utilization metric reflects the new allocation immediately.

Pattern 4: Scheduling Windows

For workloads where resource adjustment feels risky during peak hours, scheduling windows restrict when resizes execute. Recommendations compute continuously; only execution is gated.

How Attune Implements These Patterns

Attune is an Apache 2.0 Kubernetes operator designed from the ground up for in-place pod right-sizing.

Graduated rollout. Five modes (Observe, Recommend, OneShot, Canary, Auto) configured via updateStrategy.type. Canary supports configurable percentage, observation period, and automatic promotion.

Multi-layer safety. When autoRevert: true (default), the safety monitor watches for OOMKills, CPU throttle ratios exceeding 50%, restart spikes, and Ready condition loss. Consecutive reverts trigger exponential backoff. After 3 of 5 resizes reverted, the policy is flagged as Degraded.

HPA coexistence. Adjusts base resource requests, not replica counts. controlledValues: RequestsOnly keeps limits stable when HPA uses CPU utilization.

Scheduling windows. Time-of-day, day-of-week, and timezone configuration. Recommendations compute continuously regardless of window.

Comparison

	VPA	Goldilocks	Attune
Resize method	Evicts pods	No resize (recommend only)	In-place (no restarts)
HPA compatible	No	N/A	Yes
Safety	Minimal	N/A	Graduated rollout + auto-revert
Production confidence	Less than 1% automated	N/A	Observe, Recommend, Canary, Auto

Getting Started

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

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

What the Ecosystem Gains

The 8% average CPU utilization statistic is a reflection of tooling limitations that In-Place Pod Resize removes. The patterns described here, graduated rollout, multi-layer safety, HPA coexistence, and scheduling windows, represent what safe vertical scaling looks like going forward.

Attune is one open-source implementation of these patterns. Contributions, issues, and feedback are welcome at github.com/attune-io/attune.

Sebastien Tardif is the maintainer of Attune.

[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]

Safe In-Place Pod Right-Sizing in Kubernetes 1.33+

By Sebastien Tardif

The $44 Billion Problem Kubernetes Still Hasn't Solved

According to CAST AI's 2025 Kubernetes cost report, clusters in their
dataset averaged roughly 8% CPU utilization. While that number reflects
their customer base rather than every cluster in existence, the
directional signal is consistent across vendors: the vast majority of
provisioned compute sits idle. CAST AI found 99.94% of clusters
overprovisioned, with 83% of container costs going to idle resources.
Industry estimates put the resulting cloud infrastructure waste at
$44.5 billion annually.

The root cause is not laziness. It is rational fear. Setting a CPU
request to 2 cores when you only use 400 millicores is the rational
choice when the alternative is getting OOM-killed at 3 AM. Developers
over-provision because under-provisioning has immediate, painful
consequences, while over-provisioning only has a slow, invisible cost.

Kubernetes has had the Vertical Pod Autoscaler (VPA) since 2018, yet
VPA in fully automated mode remains far less common than HPA in
production environments. Why?

Why VPA Never Reached Production

VPA's approach to right-sizing has three fundamental problems that have
kept it out of production for most teams:

Problem 1: Eviction-based updates. VPA changes pod resources by
evicting the pod and letting the controller recreate it with new values.
This means downtime, rescheduling, cold cache starts, and connection
interruptions. For stateful workloads, single-replica services, or
anything with a slow startup, this is unacceptable.

Problem 2: HPA conflicts. VPA and HPA fight over the same axis.
When VPA lowers CPU requests, utilization percentage jumps, triggering
HPA to scale out. More replicas lower utilization again, so VPA lowers
requests further. This feedback loop destabilizes workloads. The
official Kubernetes documentation warns against using VPA with HPA on
CPU or memory metrics.

Problem 3: Opaque recommendations. VPA relies on a histogram-based
historical usage model whose decision process can be difficult for
operators to inspect or explain. While several parameters are
configurable, understanding why VPA chose a specific value for a
specific workload requires digging into internal state that most
teams never see. When a recommendation is surprising, there is no
straightforward way to audit the reasoning.

These are not implementation bugs. They are architectural constraints
that stem from VPA being designed before in-place resize existed.

In-Place Pod Resize Changes Everything

Kubernetes 1.27 introduced in-place pod resize as an alpha feature.
In 1.33, it graduated to beta and became enabled by default. In 1.35,
it reached GA. This is one of the most significant changes to
Kubernetes resource management since the platform was created.

The /resize subresource on the Pod API lets you change a container's
CPU and memory requests and limits while the container is running.
No eviction. No rescheduling. No cold starts. The kubelet applies
the new values directly, and the container continues running without
interruption.

# Container resize policy in the pod spec
containers:
  - name: app
    resources:
      requests:
        cpu: "500m"
        memory: "256Mi"
    resizePolicy:
      - resourceName: cpu
        restartPolicy: NotRequired
      - resourceName: memory
        restartPolicy: NotRequired

CPU changes with restartPolicy: NotRequired are typically applied
in-place by adjusting cgroup limits. Memory changes are more nuanced:
while in-place memory resize is supported, the Kubernetes documentation
notes that RestartContainer is often appropriate for memory depending
on runtime constraints. Operators should choose the resize policy per
resource based on their workload's characteristics.

Either way, this is a fundamental shift. Continuous, fine-grained
resource adjustment is now practical in production without pod eviction.

But the API is just the mechanism. The hard problems are: how do you
decide what the right values are, how do you roll out changes safely,
and how do you coexist with HPA?

Patterns for Safe In-Place Right-Sizing

Building a safe right-sizing operator on top of the /resize subresource
requires solving several problems that the raw API does not address.
These patterns apply to any operator leveraging in-place resize.

Pattern 1: Graduated Rollout

The first rule of production resource changes is: do not change
everything at once. A graduated rollout model lets teams build
confidence incrementally.

A practical graduation model has five stages:

1. Observe: Collect metrics silently. No recommendations, no
   changes. This validates that the metrics pipeline is working.
2. Recommend: Compute and surface recommendations, but do not
   apply them. Teams review what would change.
3. One-shot: Apply the recommendation to one pod per cycle and
   stop. Validates the resize mechanism on a single instance.
4. Canary: Resize a percentage of pods (e.g., 10%), observe for
   a configurable window, and only promote to the full fleet if safety
   checks pass.
5. Auto: Continuously resize all eligible pods each reconciliation
   cycle.

This mirrors how organizations adopt any infrastructure change:
read-only first, then single instance, then canary, then full rollout.
Each stage can run for days or weeks before progressing.

Pattern 2: Multi-Signal Safety with Auto-Revert

In-place resize is non-disruptive going forward, but a bad resize can
still cause problems. A right-sizing operator needs to detect failures
and revert automatically, also in-place.

The critical signals to monitor after a resize:

• OOM kills: If the container is OOM-killed after a memory decrease,
  revert immediately. Check lastState.terminated.reason == "OOMKilled"
  with a timestamp after the resize.
• CPU throttling: Query rate(container_cpu_throttled_periods_total[5m]) / rate(container_cpu_cfs_periods_total[5m]). If throttling exceeds a
  threshold (e.g., 50%), the workload may be CPU-constrained and warrants
  investigation of limits, requests, and observed demand. Note that
  throttling is driven by CPU limits, not requests directly, so this
  signal must be interpreted in context. Add a grace period after resize
  because rate windows include pre-resize data.
• Restart spikes: If restartCount jumps by more than a threshold
  after resize, something went wrong.
• Pod readiness: If the pod transitions to NotReady after resize,
  revert.
• Application SLOs: Custom PromQL queries against application-level
  metrics (latency percentiles, error rates) provide the strongest
  signal. If p99 latency exceeds an SLO after resize, the resources
  are insufficient regardless of what the infrastructure metrics say.

Reverts should use the same /resize subresource, not eviction. This
means recovery is also non-disruptive. When a workload reverts
repeatedly, exponential backoff prevents the operator from retrying
every cycle.

Pattern 3: HPA Coexistence

The VPA-HPA conflict is not inherent to vertical scaling. It is
inherent to changing requests without adjusting HPA's targets.

When a right-sizing operator lowers a pod's CPU request from 500m to
300m, the CPU utilization percentage (calculated as usage/request)
jumps even though absolute usage has not changed. HPA sees 80%
utilization instead of 48% and scales out.

One strategy for preserving equivalent absolute CPU thresholds is to
recalculate HPA's utilization target proportionally after a resize:

newTarget = originalTarget * (oldRequest / newRequest)

If the original HPA target was 70% and requests dropped from 500m to
300m, the new target becomes 70% * (500/300) = 116%, capped at 100%.
This preserves the same absolute CPU threshold (350m of actual usage)
while letting HPA continue to function correctly.

This approach has caveats. The adjusted target may exceed 100% and
require capping. HPA stabilization windows add complexity. Custom
metrics HPAs do not fit this model. And progressive resizes can
introduce drift if the original target is not stored before the first
adjustment. Despite these limitations, the pattern provides a
practical starting point for percentage-based CPU utilization HPAs,
which remain the most common configuration.

Pattern 4: Confidence-Based Recommendations

A right-sizing recommendation based on 2 hours of data should be
more conservative than one based on 7 days. The recommendation
pipeline should include a confidence dimension.

A confidence score combines time coverage and data density:

timeComponent = days of data collected
dataComponent = sqrt(dataPoints / 24)
confidence = clamp(min(timeComponent, dataComponent) / 7, 0, 1)

At low confidence, apply a buffer that adds headroom. At full
confidence, the buffer shrinks to zero:

confidenceFactor = 1 + multiplier * (1 - confidence)^exponent

With the defaults of multiplier=1.0 and exponent=2.0, a workload with
minimal data gets an 80% safety buffer, while a workload with a full
week of metrics gets none. This prevents aggressive right-sizing of
newly deployed or recently changed workloads.

Pattern 5: Change Filtering to Prevent Thrashing

Without dampening, a right-sizing operator can oscillate between
values each cycle. Two filters are essential:

• Minimum change threshold: Suppress changes below a percentage
  (e.g., 10%) of the current value. If the recommendation is 460m
  and the current request is 500m, the 8% difference is noise.
• Maximum change cap: Limit each resize to a percentage of the
  current value (e.g., 50% for CPU). This forces gradual convergence
  over multiple cycles instead of a single large jump.

Directional caps add further control. You might allow 50% increases
(to recover from under-provisioning quickly) but only 30% decreases
(to avoid sudden resource drops).

Time-of-Day Awareness and Burst Detection

Workload patterns vary throughout the day. A batch processing service
might use 2 cores during nightly ETL jobs and 200 millicores during
the day. A simple percentile over the full dataset would either
over-provision for daytime or under-provision for the batch window.

Bucketing metrics into 24 hourly windows and taking the maximum
percentile across all hours ensures the recommendation covers the
peak hour without over-provisioning for the rest of the day.

Burst detection adds another layer. If the maximum observed usage
exceeds 3x the 95th percentile, the workload exhibits bursty behavior.
A logarithmic boost based on burst magnitude adds proportional
headroom:

burstFactor = 1 + sensitivity * log2(max / p95)

A 4x burst magnitude adds 20% headroom. An 8x burst adds 30%. The
logarithmic curve prevents extreme bursts from inflating recommendations
excessively.

Implementation: Attune

Attune is an open-source
Kubernetes operator (Apache 2.0) that implements all of the patterns
described above. It requires Kubernetes 1.32+ and queries Prometheus
(including Thanos, VictoriaMetrics, and Grafana Mimir), Datadog,
or Amazon CloudWatch Container Insights for usage data.

Attune uses two CRDs: AttunePolicy for per-workload configuration
and AttuneDefaults for cluster-wide defaults. A minimal policy
in recommend mode:

apiVersion: attune.io/v1alpha1
kind: AttunePolicy
metadata:
  name: api-server
spec:
  targetRef:
    kind: Deployment
    name: api-server
  metricsSource:
    prometheus:
      address: http://prometheus.monitoring:9090
  updateStrategy:
    type: Recommend

The kubectl attune plugin provides an explain command that shows
the full recommendation pipeline with intermediate values at each
stage, making the recommendation process fully transparent:

$ kubectl attune explain -n production api-server
Container: app
  Percentile (p95):     200m CPU,  800Mi memory
  + Overhead (20%/30%): 240m CPU, 1040Mi memory
  + Confidence (0.92):  253m CPU, 1097Mi memory
  + Burst (1.0x):       253m CPU, 1097Mi memory
  Bounds [1m-4000m]:    253m CPU, 1097Mi memory
  Change filter:        253m CPU, 1097Mi memory (current: 2000m/4Gi)
  Estimated savings:    $37.42/month

Attune supports all six workload types (Deployment, StatefulSet,
DaemonSet, CronJob, Job, ReplicaSet) and exposes 21 Prometheus
metrics for operational visibility, including resize counters, revert
reasons, recommendation values, confidence scores, and estimated
cost savings.

The Path Forward

In-place pod resize removes the last architectural barrier to
automated vertical scaling in Kubernetes. The patterns described
here, graduated rollout, multi-signal safety, HPA coexistence,
confidence-based recommendations, and change filtering, represent
what the community has learned from years of VPA's limitations.

The ecosystem is still early. As more operators adopt the /resize
subresource, we will collectively discover new patterns for safe
resource management. Whether you build your own controller or adopt
an existing one, the principles are the same: be conservative with
little data, use canary rollouts, monitor application-level SLOs,
and always have an automatic revert path.

The waste problem is solvable. The API is there. These patterns build
on lessons learned from VPA and early adopters of in-place resize, and
they have shown promise in early deployments. What remains is broader
adoption.

---

Sebastien Tardif is a software engineer focused on Kubernetes
infrastructure and cloud-native tooling. He is the creator of
Attune, an open-source
operator for in-place pod right-sizing.

[SebTardif]

Pivoted from CNCF blog to the Kubernetes blog (kubernetes.io/blog), which accepts community contributions via GitHub PRs without requiring CNCF membership.

Draft PR submitted: kubernetes/website#55963

The post covers reusable patterns for safe in-place right-sizing (graduated rollout, auto-revert, HPA coexistence, confidence scoring, change filtering) with Attune as an implementation example. The K8s blog team will assign an editor and writing buddy for review.

Next steps: monitor the PR for feedback from the sig-docs-blog team.

[SebTardif]

Pitched the blog post in #sig-docs-blog on Kubernetes Slack. Waiting for editor/writing buddy pairing.

Tracking:

• Draft PR: Add blog post: Safe In-Place Pod Right-Sizing in Kubernetes 1.33+ kubernetes/website#55963
• Slack pitch: posted 2026-05-30 in #sig-docs-blog