Karpenter's consolidation behaviour is counter-intuitive

Karpenter’s consolidation mechanism is designed to reduce costs by terminating nodes that are no longer needed. The observed behavior, constant available CPU despite node churn, arises when pods are redistributed rather than eliminated. This means the cluster’s total resource footprint remains unchanged, even as individual nodes are replaced. For engineers, this creates a disconnect between the expectation of reduced capacity and the reality of stable but churning resources.

The root cause lies in how Karpenter defines 'optimal' consolidation. It prioritizes bin-packing pods onto fewer nodes, but if the workload’s total resource demand is static, the consolidation process merely reshuffles pods without reducing the overall cluster size. This is not a flaw in the logic but a consequence of the algorithm’s design. Operators must recognize that consolidation does not guarantee lower resource usage, only denser packing of existing demand.

Tuning consolidation behavior is constrained by Karpenter’s limited configuration options. The `consolidationPolicy` and `consolidateAfter` parameters offer coarse control, but neither addresses the core issue of steady-state resource stability. Engineers who need predictable capacity outcomes may need to supplement Karpenter with custom tooling or adjust workload scheduling policies to align with the autoscaler’s behavior.

The counter-intuitive outcome highlights a broader challenge in autoscaling systems: the gap between theoretical efficiency and real-world observability. While Karpenter’s consolidation loop is logically sound, its effects are not always visible in aggregate metrics like total available CPU. Teams must instrument their clusters to track pod redistribution patterns, not just node lifecycle events, to fully understand the impact of consolidation.