A Kubernetes cluster gets more efficient when the node capacity you pay for moves closer to what the workloads need, and the lever is resource requests, not measured usage. The scheduler places pods by their requests, and node autoscalers add and remove nodes by requests. When pods ask for more than they use, the cluster occupies more nodes than the load requires. The work has three steps in a fixed order: bring requests in line with usage, pack pods more densely, remove surplus nodes. Splitting the cost across teams is covered in Kubernetes cost allocation, the prices of control plane and nodes in containers and Kubernetes.
How it works
A pod lands only on a node where the sum of requests stays below capacity, even when actual usage there is low. What counts is allocatable capacity, what is left for pods after the reservations for system daemons, and the scheduler does not over-subscribe it. A container may use more than it requested while the node has room, and where only a limit is set, Kubernetes copies it as the request. Paid capacity that does no work builds up on four layers:
| Layer | What is paid for without doing work | Lever | Owner |
|---|---|---|---|
| Requests above usage | requested but unused CPU and memory | lower requests from measurements, Vertical Pod Autoscaler | workload team |
| Replicas above load | peak-load replicas around the clock | Horizontal Pod Autoscaler, a lower minimum | workload team |
| Unrequested node capacity | allocatable minus the sum of requests, the idle cost | bin packing, consolidation, better-fitting node types | cluster operator |
| System overhead | reservations for system daemons, DaemonSets on every node | number of DaemonSets, node size | cluster operator |
Pod autoscalers
The Horizontal Pod Autoscaler is part of core Kubernetes and adjusts the number of replicas. It computes target utilisation as a percentage of the request; without a request, a pod's CPU utilisation is undefined and nothing happens for that metric. The Vertical Pod Autoscaler is a separately installed add-on that computes requests from past usage. In Off mode its recommendations stay in the object's status, Initial applies them only when a pod is created, Recreate evicts pods whose requests differ significantly, and InPlaceOrRecreate changes them in the running pod where possible. Off delivers the numbers without touching a pod. Microsoft advises against combining VPA and HPA on the same CPU and memory metrics on AKS; GKE offers its own routes for that.
Node autoscalers
Kubernetes SIG Autoscaling sponsors two node autoscalers, Cluster Autoscaler and Karpenter. Both add nodes for unschedulable pods, consolidate poorly utilised nodes, and decide by requests, not usage, so requests set too high can keep a node from being consolidated.
Cluster Autoscaler grows and shrinks predefined node groups. It treats a node as unneeded when the sum of CPU requests and the sum of memory requests are below 50% of its allocatable capacity (configurable) and every pod fits elsewhere; after ten minutes in that state it removes the node. Pods with a restrictive PodDisruptionBudget, without a controller or with local storage, kube-system pods without a PodDisruptionBudget and the annotation cluster-autoscaler.kubernetes.io/safe-to-evict: "false" prevent that. Karpenter picks individual virtual machines to fit the pending pods instead of scaling groups. Its consolidation deletes a node whose pods fit on free capacity elsewhere, or replaces it with a cheaper one; consolidationPolicy sets which nodes qualify: only empty ones (WhenEmpty), those where the saving outweighs the disruption to running pods (Balanced), or, by default, any node that can be removed or replaced more cheaply (WhenEmptyOrUnderutilized).
AWS
With Amazon EKS Auto Mode, AWS operates Karpenter-based node scaling itself: unschedulable pods get new nodes, and nodes no longer needed are consolidated away. Without Auto Mode, Karpenter is open-source software the customer installs, configures and runs; Cluster Autoscaler on EKS works through Auto Scaling groups.
Azure
The AKS cluster autoscaler uses defaults of 0.5 for scale-down-utilization-threshold and ten minutes for scale-down-unneeded-time; both can be changed in the autoscaler profile. Node auto-provisioning runs Karpenter for the cluster and picks VM sizes from the requests of pending pods; it comes preconfigured in AKS Automatic and is switched on in AKS Standard.
Google Cloud
In GKE Standard, Cluster Autoscaler also decides by requests, resizing the managed instance group behind the node pool. balanced, the default, holds spare capacity so that new pods start sooner; optimize-utilization gives up that reserve for utilisation, scales down earlier and harder and steers pods towards nodes with high allocation. GKE can also create node pools for pending pods. Autopilot bills general-purpose workloads by their pod requests, not by node (containers and Kubernetes covers the model). Where requests are missing, Autopilot sets 0.5 vCPU and 2 GiB in the general-purpose compute class; values below the minimum or outside the allowed CPU to memory ratio are raised.
What it means for your cost
On clusters billed by node, the bill falls only when a node goes away. Smaller requests alone only grow the idle share; consolidation is what saves instance hours. With pod-based billing, as in GKE Autopilot, there is no node to consolidate, and the request itself is the lever. The FinOps Foundation places this work in its Usage Optimization capability. A diagnosis runs in this order:
- Report idle per cluster as its own line instead of spreading it over the teams (Kubernetes cluster cost visibility).
- Compare requests with usage per workload, for example with a VPA in
Offmode, and decide with the team, as with rightsizing instances. - Check that a node autoscaler runs and why nodes stay; Karpenter reports the reason as a node event.
- Only then turn to node types, the spot share and commitments.
Nodes are ordinary virtual machines, and a commitment sized on the cluster before optimisation is partly unused afterwards (commitment coverage and utilisation). Spot nodes suit workloads that tolerate interruption (spot capacity); Karpenter replaces one spot node with another only once the SpotToSpotConsolidation feature flag is on, and then only with at least 15 candidate instance types. The saving is proven only when the nodes' instance hours or the billed pod resources fall in the billing data (from estimated to realised savings).
Where it goes wrong
- Requests lowered, bill unchanged. Symptom: VPA recommendations are applied, node instance hours stay the same. Cause: no node autoscaler consolidates, or the node pool's minimum size keeps the nodes.
- A node stays despite low allocation. Symptom: nodes with few requests keep running for weeks. Cause: one of the pod types listed under node autoscalers blocks the scale-down.
- The HPA does not scale. Symptom: the replica count stays flat while load changes. Cause: a container has no CPU request, so utilisation is undefined.
- VPA and HPA working against each other. Symptom: the VPA lowers requests and the HPA starts more replicas at the same load. Cause: both react to the same CPU and memory metrics, and the HPA measures utilisation against the request.
- Autopilot dearer than expected. Symptom: pods are billed for more resources than the manifest states. Cause: missing requests get defaults, small ones are raised to the minimum or the allowed ratio.
- A spot pool blocks scaling. Symptom: after evictions the AKS cluster fails to scale out or upgrade. Cause: with the
Deallocateeviction policy, stopped spot nodes keep counting against the compute quota.
Sources
Read on 2026-10-16. Kubernetes resource management for pods and containers, reserve compute resources for system daemons, horizontal pod autoscaling, vertical pod autoscaling, node autoscaling, Cluster Autoscaler FAQ and Karpenter disruption; FinOps Foundation Usage Optimization (CC BY 4.0); AWS scale cluster compute with Karpenter and Cluster Autoscaler and EKS Auto Mode; Microsoft cluster autoscaler in AKS, node auto-provisioning, Vertical Pod Autoscaler in AKS and spot node pools; Google Cloud GKE cluster autoscaler, node pool auto-creation, resource requests in Autopilot, vertical Pod autoscaling and GKE pricing.