Use expander strategy
The expander determines how Cluster Autoscaler chooses which node group to scale up when multiple options can fit pending pods — the wrong strategy leads to consistently picking expensive or oversized instances.
Expander | Behavior | Best For |
|---|---|---|
| Chooses group that will have least idle CPU/memory after scheduling | Cost optimization (recommended) |
| Chooses group that can schedule the most pending pods | Batch processing |
| Uses user-defined priority list | Graviton-first, then x86 fallback |
| Random selection (default in some versions) | Not recommended for cost optimization |
For the deployment manifest with least-waste expander and a priority-based ConfigMap for Graviton-first strategy expander-strategy.yaml
Check expander
Verify which expander is active and confirm scale-up decisions match your priority configuration. For the verification commands, see the verify-expander-strategy.sh
For the complete scripts and manifests, see the 4-karpenter-cost-optimization
Actions
Switch from the default random expander to least-waste for general cost optimization, or priority if you have mixed Spot/On-Demand/Graviton node groups and want explicit control over which scales first. Never use random in production — it ignores cost entirely.
Key takeaway: The expander strategy is a one-line change that determines whether every scale-up event picks the cheapest option or an arbitrary one. least-waste alone can reduce per-scale-up cost by 20–30% by avoiding oversized instances.
