Most cloud-native cost tools are built to find and address waste reactively. Underutilized nodes, oversized requests, and idle workloads are revealed in the utilization data, the fixes are well documented, and the initial savings these tools drive are very real. But what we've seen consistently across clusters is a different category of blocker, one that quietly prevents consolidation and strands capacity your autoscaler can never reach. They don't surface in dashboards as obvious waste. They show up as a bill that stops going down despite everything looking correctly configured. Optimization blockers are distinct from waste: they're structural constraints that prevent consolidation even when capacity exists to recover. Together, they account for more than 30% of cluster capacity that sits idle while your cloud bill keeps climbing. The five blockers below are among the most common, and the least discussed. 1. Pod Disruption Budgets configured at deployment time silently block autoscaler consolidation A PDB is supposed to protect availability during voluntary disruptions. What we often see in practice is PDBs configured defensively at deployment time and never revisited, where minAvailable or maxUnavailable values effectively prohibit every consolidation attempt Karpenter tries to make. The autoscaler identifies a node drain candidate, requests eviction, and the PDB blocks it. No node gets drained. No cost is recovered. The capacity sits stranded behind a policy that was set once and forgotten. The part that makes this particularly insidious is that the PDB is doing exactly what it was configured to do. There's no misconfiguration to alert on or error to surface. A minAvailable: 1 on a single-replica workload is a textbook voluntary hard eviction block, and your autoscaler will silently respect it for as long as it’s in place. The recommended practice is to treat PDB configuration as a living artifact tied to current replica counts and actual disruption tolerances, not a one-time deployment decision. Regular audits should validate that every PDB still makes sense against the workloads it governs today, not the workloads that existed when it was written. 2. Anti-affinity rules outliving their original rationale force unnecessary node sprawl Anti-affinity rules serve a real purpose: spreading replicas across nodes or zones to avoid correlated failures. The pattern we see inflate costs is "headroom anti-affinity," where rules originally designed to enforce high availability have grown to require so many distinct nodes that the scheduler is forced to keep nodes alive that serve no other purpose. The cluster can't consolidate because the rules prohibit co-location, even when the HA rationale has long since changed. These rules are rarely documented in a way that connects them to their original intent, which means they persist long after the conditions that motivated them have changed. The team that wrote the rule is often no longer the team maintaining the cluster, and the rule lives on as received wisdom nobody questions. A good practice is to audit anti-affinity configurations against current topology requirements and replica counts, and explicitly validate whether the HA constraints they encode still reflect the reliability posture you actually need. Relaxing overly broad rules is one of the few optimization levers that unlocks consolidation opportunities no amount of rightsizing can reach. 3. Unevictable workloads anchored to consolidation candidates strand capacity your autoscaler can’t recover Some workloads are practically unevictable once scheduled. When these land on nodes that the autoscaler would otherwise drain, they anchor that node indefinitely. The autoscaler correctly identifies the node as a consolidation candidate, finds it blocked by an unevictable workload, and moves on. The node stays, and with it the ballooning cost. What makes this pattern so persistent is that nothing is broken. The workload is healthy, the node is running, the autoscaler is behaving correctly. The waste is invisible to any tool that evaluates components in isolation, because the problem only exists in the relationship between the workload's eviction behavior and its placement. A good recommendation is to identify unevictable workloads before they are scheduled and place them deliberately onto designated nodes that are excluded from consolidation candidacy. Handled proactively, this keeps the autoscaler's drain logic unobstructed. Handled reactively, it means manually untangling placement decisions that have often compounded over months. 4. Uncoordinated scheduling decisions compound into permanent node fixtures Even when individual workloads are evictable and PDBs are correctly configured, poor coordination between the scheduler and the autoscaler can lock capacity in place. The scheduler has no visibility into which nodes the autoscaler has flagged as consolidation candidates, so exactly as a node trends toward drain-ready, the scheduler lands a new pod on it because the capacity appears to be available. Instead of becoming a consolidation candidate, the node resets. The same thing can happen again on the next cycle. We have seen clusters where this scheduler-autoscaler blind spot repeats often enough, without ever being caught, that entire node groups become permanent fixtures. The waste compounds over time because every new pod scheduled onto a node is another chance for the same gap to fire again, and what starts as one missed consolidation window becomes structural debt that gets more expensive to unwind with every subsequent deploy. The ideal configuration evaluates consolidation likelihood at scheduling time, before workloads are placed, rather than trying to untangle placement decisions after the fact. Steering workloads away from nodes that are likely drain or termination candidates at the point of scheduling is the only way to prevent this pattern from taking hold in the first place. 5. Instance types chosen once and never tuned leads to persistent CPU-to-memory ratio mismatch Instance type selection is treated as a one-time infrastructure decision in most clusters we encounter. An instance family is chosen during cluster setup, often based on what was familiar or what was available at the time, and it persists unchanged through years of workload evolution. The result is a persistent mismatch between the CPU-to-memory ratios the cluster is paying for and the ratios the workloads actually consume. Memory-heavy workloads on compute-optimized instances leave CPU stranded. CPU-intensive workloads on memory-optimized instances leave memory stranded. Either way, the cluster is buying capacity it cannot use, the root cause is an instance selection that was never revisited as workload profiles changed. This is one of the more quietly expensive mismatches in Kubernetes infrastructure, because the cost doesn't announce itself. There's no failed resource request, no alert, no obvious signal that something is wrong. The cluster simply runs less efficiently than it should, at full price, indefinitely. A good practice here is to periodically analyze actual CPU-to-memory consumption ratios across your workload fleet and validate them against the instance families in use. Workload profiles drift over time, and instance selection should drift with them. How to Claw Back Your Kubernetes Spend Most Kubernetes cost optimization tools are built around the same set of signals: resource utilization metrics, node capacity ratios, and workload sizing recommendations. That scope is useful, but it's also the reason these tools reliably capture the first wave of savings and then stop. The blockers described above don't show up in utilization data. They live in the relationships between scheduling decisions, eviction policies, placement constraints, and cluster topology, and resolving them requires understanding how those layers interact, not just measuring what each workload consumes. Seeing that a node is underutilized is straightforward - understanding why it can't be drained is often the real challenge. Whether the cause is a forgotten PDB, an unevictable workload placed there six months ago, or an anti-affinity rule nobody remembers writing, is a meaningful distinction which requires full operational context across the entire cluster. Getting past the savings plateau happens when cost optimization is treated as more than a resource-sizing exercise, when it's understood to be a cluster-wide state problem that needs to be approached proactively.. —- Learn more about how Komodor’s proactive cost optimization features tackle structural blockers and architectural limitations that leave up to 30% of cluster capacity stranded. Read more.
