Kubernetes 1.35 in-place pod resize: VPA without the restart tax

The VPA Restart Tax Was the Bottleneck. It’s Gone.

Kubernetes 1.35 “Timbernetes” shipped on December 17, 2025. Among the GA features in the release was in-place pod resize — the ability to mutate a running pod’s CPU and memory requests and limits without restarting the pod. By early May 2026, GKE 1.35 has been GA for two quarters, EKS and AKS have rolled out matching support across the spring, and the Vertical Pod Autoscaler ecosystem (Cast AI, ScaleOps, StormForge, native VPA) has rebuilt around the restart-free primitive.

In-place pod resize is one of those features where the spec line item (“the resize subresource is now stable”) understates the operational change. The Vertical Pod Autoscaler — the canonical Kubernetes rightsizing primitive — has been blocked on this feature for six years. VPA had recommendations and could write right-sized requests onto a pod spec, but applying the new requests required killing the pod and waiting for the scheduler to reconcile. The kill-and-restart cycle was a hard tax that meant most platform teams either ran VPA in recommendation-only mode (ignored by application teams) or ran it on cron windows during maintenance hours (irrelevant for any workload that did not idle).

In-place pod resize removes that tax. Production teams are now reporting 20-40% rightsizing savings on overprovisioned workloads with no pod-restart blast radius. The cost-optimization story for Kubernetes in 2026 is structurally different from the 2024 / 2025 story because of that one feature.

Two additional improvements landed alongside the GA:

• Memory limit decreases are now permitted. The 1.33 beta version blocked memory-limit shrinks because the kubelet had no clean path to reclaim the memory from a running process; 1.35 GA added a graceful evict-and-retry path that handles the case safely.
• A new kubelet metrics and pod-events surface tracks every resize. Every in-place resize emits a structured event (PodResizeStarted, PodResizeCompleted, PodResizeRetried, PodResizeFailed) and updates a new kubelet metrics namespace. The metrics-and-events surface is what makes restart-free rightsizing audit-trackable.

The combined picture is the first time in Kubernetes’ history that vertical autoscaling has been operationally safe to leave on by default for production workloads.

What 2026 Rightsizing Actually Looks Like

Three workload-class patterns are emerging in the production rightsizing playbook:

• Steady-state services. Long-running services with stable utilization profiles. VPA in recommendation mode for the first two weeks builds a usage histogram; VPA in apply mode then shrinks requests to the 95th-percentile observed usage with a small safety margin. Restart-free resize means the application team never sees a pod restart; the cost surface shrinks 20-30%.
• Burst-heavy services. Services with frequent traffic spikes. Pure VPA undershrinks (the histogram is bimodal). The pattern is to size requests against the 80th-percentile usage and lean on Horizontal Pod Autoscaler (HPA) plus burst limit headroom for the spikes. Cast AI / ScaleOps / StormForge each ship a hybrid policy that reads burst patterns and applies both HPA and in-place VPA against the workload simultaneously. 30-40% savings reported on this pattern.
• Memory-pressure-sensitive workloads. Workloads where OOM kills are expensive (long warm-up, expensive context initialization, stateful in-memory caches). Pure VPA in apply mode is conservative because the memory-decrease path requires graceful eviction. The pattern is to apply VPA on CPU aggressively and on memory conservatively, with a memory-headroom multiplier that absorbs spike variance. 15-25% savings on these workloads, but the OOM-kill avoidance is the real ROI.

None of the three patterns require a specific vendor. The native VPA project plus the in-place resize primitive is enough. Cast AI / ScaleOps / StormForge add policy templates, multi-cluster scope, and prebuilt observability dashboards on top.

The Workload Tagging and Policy Surface That Makes This Work

Continuous in-place rightsizing requires the team to express, per workload, three policy primitives:

• The workload class. Steady-state, burst-heavy, or memory-pressure-sensitive. The class determines which VPA policy template applies and what the safety margins look like. Without explicit class tagging, the rightsizing loop degrades to a one-size-fits-all policy that is wrong for at least one third of the workloads.
• The pre-approved resize scope. Which workloads the autoscaler can resize without human approval. The standard pattern is: dev and staging environments are auto-resize at any percentile; production is auto-resize only against pre-approved request-bounds; production tier-0 workloads require explicit approval for any decrease.
• The audit-trail target. Where the resize events land. The kubelet metrics-and-events surface is the source; the destination is typically a centralized audit-trail store that joins resize events against the workload’s owning team, the savings delta, and the approval status. The audit trail is the artifact the FinOps team reconciles against.

Teams that codify all three primitives in version-controlled policy reach the 30-40% savings band. Teams that skip the tagging or skip the approval scope stay in the 10-15% band.

See the IAN team run on your cloud. We connect to your AWS account via a scoped read-only role, run the Observe-tier agents, and leave you with a concrete audit report — cost waste, security exposure, compliance gaps, and a labor-offset estimate. You keep the findings regardless of next steps. Get a free infrastructure audit →

The Multi-Cluster and Multi-Cloud Picture

In-place pod resize is a per-cluster primitive. The 2026 reality for any platform team running at meaningful scale is that rightsizing is a multi-cluster and increasingly multi-cloud problem. A typical mid-market engineering org now runs at least one cluster per environment per region per cloud — easily ten to thirty clusters across the footprint, often more. The 1.35 primitive unblocks the cost work, but only inside a single cluster’s boundary.

Three multi-cluster patterns are now emerging as table-stakes in 2026:

• Cross-cluster workload-class registry. The workload-class taxonomy (steady-state, burst-heavy, memory-pressure-sensitive) has to be consistent across every cluster the same workload runs in. The registry typically lives outside the cluster — in the platform team’s policy repo, in an internal developer portal, or in the active-operational-layer’s audit-trail store. Without the cross-cluster registry, the same workload gets a different policy per cluster, and the rightsizing loop drifts.
• Multi-cluster resize-event aggregation. The kubelet metrics-and-events surface is per-cluster. Aggregating resize events across the footprint requires either a centralized metrics pipeline (Prometheus federation, Mimir, Thanos) or a metadata-layer ingestion path that pulls the kubelet events into a centralized store. Without aggregation, the FinOps team cannot answer “how much did rightsizing save this month, across the whole footprint?”
• Multi-cloud policy parity. GKE 1.35, EKS, AKS, and self-managed Kubernetes each ship the in-place resize primitive on slightly different timelines and with slightly different policy surfaces. The policy framework has to abstract over the differences — the rightsizing policy expressed at the workload-class level has to compile down to whatever the underlying Kubernetes distribution actually supports. The teams that codify the abstraction reach the 30-40% savings band on every cluster; the teams that don’t reach it only on the cluster the policy was originally written for.

All three patterns sit above the per-cluster primitive. They are the work of an active operational layer that reasons across the multi-cluster footprint, not of a single in-cluster controller.

Capability Tiers Mapped to In-Place Rightsizing

The Observe / Operate / Administer capability-tier model maps cleanly to Kubernetes in-place rightsizing:

• Observe. Continuous workload-usage histogram construction, workload-class classification, resize-recommendation generation, and resize-event ingestion from the kubelet metrics-and-events surface. Auto-execute, fully audited.
• Operate. In-place resize application against pre-approved scopes (dev / staging at any percentile; production at pre-approved bounds), HPA-policy adjustments against pre-approved capacity envelopes, and pod-restart escalation when the in-place path fails. Auto-execute for reversible / scoped actions; gated when the resize crosses an organization-wide bound (tier-0 workloads, regulated workloads).
• Administer. Workload-class taxonomy changes, pre-approved-scope definition itself, tier-0 workload promotion / demotion, and any change to the rightsizing policy framework. Always requires explicit approval with separation of duties enforced.

The mapping is the difference between a platform team that ships VPA in recommendation-only mode (and recovers nothing) and one that runs continuous restart-free rightsizing on the active operational layer (and recovers 20-40%).

How IAN Helps: The Cost Agent and Resource Agent on the Active Operational Layer

IAN is the AI DevOps team for cloud infrastructure, delivered as a coordinated team of specialized agents on the active operational layer. The cost agent and the resource agent share the Kubernetes-rightsizing surface; the cost agent runs the savings-recovery loop and the resource agent runs the tagging-and-policy loop.

Workload-usage histogram construction runs continuously across every connected EKS, GKE, AKS, and self-managed Kubernetes cluster. Workload-class classification — steady-state, burst-heavy, memory-pressure-sensitive — lands in the audit trail. Reversible Operate-tier actions — in-place resize against pre-approved scopes, HPA-policy adjustment against pre-approved capacity, pod-restart escalation when the in-place path fails — execute automatically when policy permits. Irreversible or organization-wide actions (workload-class taxonomy changes, tier-0 workload promotion / demotion, rightsizing-policy framework changes) escalate to the Administer tier with separation-of-duties enforced. Every action lands in the immutable audit trail, which doubles as the FinOps reconciliation artifact and the application-team change record.

Pricing is BYOK and usage-based with a monthly minimum. Customers bring their own model keys (Claude, OpenAI, or another provider) and pay inference cost directly to their model vendor. IAN charges for the orchestration layer, per agent action, per cloud account, per operation class. Usage scales with the volume of resize actions taken, which is itself a strong signal of where the team is recovering material spend.

The unit-economics contrast with the Kubecost / OpenCost layer is structural. Kubecost / OpenCost are the cost-attribution primitive (where the dollars went). IAN’s cost agent is the cost-reduction loop on top of that primitive (what to do about it). Both layers can coexist — Kubecost / OpenCost feed the workload-attribution signal, IAN runs the rightsizing-and-policy loop.

The Three-Phase Rollout

Phase 1 — Stand up the Kubernetes-rightsizing Observe layer. Wire continuous workload-usage histogram construction, resize-event ingestion from the kubelet metrics-and-events surface, and workload-class classification across every connected cluster into the cost agent’s read path. Two-to-four weeks for a team with reasonable platform-engineering capacity.

Phase 2 — Codify the workload-class taxonomy and the pre-approved resize scopes. Tag every workload with its class. Pre-authorize the resize scopes the cost agent can act on (dev / staging at any percentile; production at pre-approved bounds; tier-0 with explicit-approval gate). Run a tabletop exercise against the team’s top ten by-spend workloads and measure recovered spend over the first 90 days. Two-to-three months of pattern tuning.

Phase 3 — Cross the cost / resource / deployment agent loop. Kubernetes rightsizing is also a resource-agent question (tag enforcement, lifecycle, quota) and a deployment-agent question (rollouts must respect the pre-approved capacity envelope). Once the cost agent’s Observe layer is live, its signals feed the resource agent’s tagging-and-quota loop and the deployment agent’s release-orchestration loop. Each agent’s outputs make the others more accurate.

The combined effect is the same the platform team would get from hiring a senior Kubernetes SRE focused on rightsizing plus a FinOps analyst dedicated to cluster cost, except the agents run continuously, never miss a workload-shape shift, and produce an immutable audit trail that satisfies internal audit and FinOps reconciliation. For most mid-market platform teams running Kubernetes at meaningful scale, that is materially better than the current state.

In-place pod resize is one of those Kubernetes primitives that unlocks a whole category of operational work that was previously gated on a feature gap. The active operational layer is built to run continuously on top of those primitives — not to wait for the next maintenance window.

Get a free infrastructure audit → | See pricing →