Bin packing efficiency is the share of provisioned node capacity that scheduled pods actually reserve, calculated as total pod requests divided by total node allocatable capacity. A cluster offering 100 vCPU allocatable whose pods request 60 vCPU is packed at 60 percent, meaning 40 percent of node spend is idle headroom. Measure it separately for CPU and memory, because the lower ratio is the binding constraint. A practical production target is roughly 70 to 85 percent on the binding resource, with the rest reserved for spikes, daemonsets, and node failures.
Last updated: June 2026. Written by Morten Andersen and reviewed by Fredrik Filipsson, built on our See, Cut, Lock, Run method.
This explainer sits in our complete guide to Kubernetes cost optimization, the cluster pillar it links up to, and connects to the broader cloud cost optimization playbook. Packing efficiency is what the node autoscaler debate is really about, so read it alongside our Karpenter vs Cluster Autoscaler cost comparison. Measuring packing is a See step move: you cannot cut what you have not quantified.
Bin packing efficiency = total pod requests / total node allocatable capacity, computed per resource. CPU and memory separately, because clusters are rarely tight on both. Track the lower of the two; that is the resource forcing you to add nodes, and the one worth optimizing first. A second number, request waste, sits underneath it: the gap between what pods request and what they actually use.
What is bin packing efficiency in Kubernetes?
Bin packing efficiency is the percentage of allocatable node capacity that scheduled pods reserve through their resource requests. The name comes from the classic bin packing problem: fitting items of different sizes into the fewest containers. In Kubernetes the items are pods and the containers are nodes, and the scheduler's job is to place pods so that fewer, fuller nodes carry the load. High packing efficiency means most of the capacity you pay for is committed to workloads; low efficiency means you are renting nodes that sit half empty. Because cloud bills you for the node, not the pod, packing efficiency maps almost directly to wasted compute spend.
How do I measure it, step by step?
Measure packing efficiency by comparing summed pod requests to summed node allocatable capacity, per resource. Four steps:
- Sum pod requests. Add the CPU and memory requests of every scheduled pod in the cluster or namespace. Result: total reserved capacity.
- Sum node allocatable. Add allocatable CPU and memory across all nodes, which is node capacity minus what the kubelet and system reserve. Result: total sellable capacity.
- Divide per resource. Compute requests divided by allocatable for CPU and for memory separately. Result: two efficiency ratios.
- Take the binding constraint. The lower ratio is the resource forcing node count. Result: the number to drive up first.
Use allocatable, not raw capacity, because the kubelet, container runtime, and reserved system resources are not available to your pods. Per the Kubernetes resource and eviction documentation, the scheduler places pods against allocatable, so that is the honest denominator.
What is the difference between packing efficiency and utilization?
Packing efficiency measures reserved capacity against node capacity, while utilization measures actual consumption against capacity. The two diverge whenever pods request more than they use, which is the common case. A cluster can show 80 percent packing efficiency and only 30 percent CPU utilization, meaning the nodes look full to the scheduler but the workloads barely touch the capacity they hold. That gap is request waste, and you close it by right-sizing requests rather than by adding nodes. Our guide on how to right-size Kubernetes requests with VPA and Goldilocks covers that lever in detail.
Want to know how much of your cluster spend is idle headroom?
Our Kubernetes cost audit measures packing efficiency and request waste across your namespaces, finds the binding constraint, and quantifies the node spend you can reclaim. On the performance model, you pay only from realized savings. No savings, no fee.
Book a Kubernetes cost audit →How do I improve bin packing efficiency?
Improve packing efficiency by right-sizing requests, letting the scheduler and a consolidating autoscaler pack tightly, and removing constraints that strand capacity. Start with requests, because oversized requests inflate the numerator and force nodes to add up faster than real usage warrants. Then use a node autoscaler that consolidates underused nodes, so the cluster repacks as workloads shift rather than carrying half-empty nodes indefinitely. Finally, audit anti-affinity rules, topology spread, and oversized daemonsets, all of which can leave capacity that no pod is allowed to use. Packing efficiency rises when requests are honest, the scheduler is free to pack, and nothing artificially blocks placement.
The Kubernetes Cost Optimization Handbook includes the packing efficiency and request waste worksheets and the target ranges used above. It is the downloadable companion to this explainer.
Frequently asked questions
What is bin packing efficiency in Kubernetes?
Bin packing efficiency in Kubernetes is the share of provisioned node capacity that scheduled pods actually reserve, expressed as total pod requests divided by total node allocatable capacity. If your nodes offer 100 vCPU of allocatable capacity and your pods request 60 vCPU, packing efficiency is 60 percent and you are paying for 40 percent idle headroom. It is the clearest single measure of how much node spend is being wasted on unused capacity.
How do I calculate bin packing efficiency?
Sum the CPU and memory requests of all scheduled pods, sum the allocatable CPU and memory across all nodes, and divide requests by allocatable for each resource. Do CPU and memory separately, because a cluster can be packed tight on one and loose on the other. The lower of the two ratios is usually the binding constraint and the one to act on first.
What is a good bin packing efficiency target?
A practical target for steady production workloads is roughly 70 to 85 percent on the binding resource, leaving headroom for scaling spikes, daemonsets, and node failures. Pushing much above that risks pods going unschedulable during bursts; sitting far below it means you are paying for idle nodes. The right number depends on how spiky your traffic is and how fast your autoscaler adds capacity.
What is the difference between bin packing efficiency and utilization?
Bin packing efficiency compares pod requests to node capacity, while utilization compares actual usage to capacity. Packing tells you how much capacity is reserved; utilization tells you how much is consumed. The gap between requests and actual usage is request waste, which you fix by right-sizing requests; the gap between requests and node capacity is packing waste, which you fix with a better scheduler and consolidation.
The short version
Bin packing efficiency is reserved capacity over node capacity, measured per resource, and it is the fastest way to see how much Kubernetes node spend is idle. Pair it with utilization to separate packing waste from request waste, then fix each with the right lever. When you want both measured and reclaimed on your real cluster, that is what our rightsizing and waste elimination service delivers.
Cloud pricing and service behavior change frequently. Verify the specifics in this guide against the providers’ own current documentation and the FinOps Foundation: FinOps Foundation Framework ↗ and FinOps Rate Optimization capability ↗. This article also reflects Cloud Cost Room’s hands-on, vendor-neutral engagement experience.