By Alexey Baikov
CTO and Co-founder

Read More >

Everyone working with Kubernetes has seen it: the cluster utilization dashboard that stubbornly refuses to improve, despite your autoscaler being fully configured and supposedly doing its job. Nodes sit at 20–30% utilization. Scale-down events never fire. And yet the infrastructure bill keeps climbing.

The culprit is often not a misconfiguration. It’s a structural problem that most autoscalers aren’t built to handle: unevictable pods.

The stranded capacity problem no one seem to talk about enough

Unevictable pods (Jobs, CronJobs, and workloads protected by PodDisruptionBudgets) can’t be moved or terminated by an autoscaler. That’s by design: these pods represent work that needs to complete or processes that can’t tolerate interruption. But the side effect is significant.

When these pods land on a node, that node becomes effectively locked. Your autoscaler can’t drain it. It can’t consolidate it. And as the default Kubernetes scheduler continues to spread workloads across nodes for availability, you end up with unevictable pods scattered across your entire cluster, with each one pinning a node that will never be reclaimed.

The result is fragmentation at scale. Idle compute capacity is stranded across dozens of nodes, each technically “in use” but mostly empty. Research from Kubeha (2026) estimates that Kubernetes clusters waste 30–50% of compute capacity due to resource configuration drift and fragmentation. Organizations running large Kubernetes fleets can end up paying for significantly more compute than their workloads actually require, simply because their clusters can’t consolidate.

A smarter approach to Pod Placement

Zesty’s Adaptive Pod Placement feature addresses this problem at its root by changing how unevictable pods are scheduled in the first place.

Rather than letting the default Kubernetes scheduler distribute these pods freely, Adaptive Pod Placement groups unevictable pods onto the minimum number of nodes needed, while still spreading them enough to avoid single-node failure risk. This isn’t about packing every pod onto one node and hoping for the best. It’s about intentional placement that preserves availability guarantees while dramatically reducing fragmentation.

The practical effect: fewer nodes are “locked” at any given time, which means your autoscaler finally has the headroom it needs to consolidate and scale down.

No squatters: how to evict every pod

One of the valid concerns with any consolidation approach is what happens to running workloads. Aggressive eviction strategies can cause instability, incomplete job runs, or service disruptions: outcomes no engineering team wants to explain to stakeholders.

Adaptive Pod Placement takes a deliberately conservative approach. Evictions are gradual, not instantaneous. The system respects your existing PodDisruptionBudgets, and for teams that want finer control, configurable thresholds let you define how aggressively consolidation should proceed. Critically, Jobs and CronJobs are protected from eviction (the kinds of pods that represent actual work-in-progress are not candidates for displacement).

The feature also integrates with whatever autoscaler you’re already running (Cluster Autoscaler, Karpenter, or any other node autoscaler in your environment). There’s no rip-and-replace required.

What the comparison looks like

The difference between a cluster running without pod placement optimization and one with it is stark, and it compounds over time.

Without strategic placement, the default scheduler distributes unevictable pods across nodes according to general availability heuristics, which is fine for resilience but works against consolidation. Nodes fill up in ways that make them hard to drain. The autoscaler identifies scale-down candidates but can’t act on them. Fragmentation deepens.

With Adaptive Pod Placement, unevictable pods are concentrated deliberately. Under the hood, this is implemented through pod affinity and anti-affinity rules that Zesty applies automatically. Soft affinity rules pull unevictable pods towards nodes that already host unevictable pods, reducing scatter. Soft anti-affinity rules reduce the likelihood of them being on the same node with evictable pods. 

Evictable pods are then gradually moved to consolidate remaining capacity. Nodes become drainable, and your autoscaler can finally do what it was configured to do: terminate underutilized nodes and reduce your compute footprint.

The result is the same workloads running on fewer nodes: a lower infrastructure cost without any change to application behavior or availability posture.

Part of a broader optimization story

Adaptive Pod Placement works well on its own, but it fits into a larger pattern of Kubernetes cost optimization that Zesty’s platform is built around, including multi-dimensional autoscaling for pod resources and replica counts, persistent volume rightsizing, and workload cost visibility. Fragmentation is one of several layers where compute spend builds up without obvious signals; addressing it alongside the others compounds the savings.

Ready to reclaim your stranded capacity?

If your clusters are showing low utilization despite a configured autoscaler, or if you’ve noticed scale-down events that never fire, Adaptive Pod Placement is worth a closer look.

Book a demo to see it in action. The change doesn’t require migrating your infrastructure; it works within the environment you’ve already built.