Comparing Apples and Oranges
Bin packing optimizes for efficiency, but in a multi-tenant cluster shared by multiple teams, efficiency alone is not enough. You also need fairness. The challenge is that different workloads have fundamentally different resource profiles, making a simple 50/50 split meaningless.
Imagine two teams sharing a cluster with 100 CPUs and 100GB of RAM:
* Team A runs CPU-intensive video transcoding jobs. Each job needs 8 CPUs and 2GB RAM.
* Team B runs memory-intensive in-memory databases. Each job needs 1 CPU and 16GB RAM.
If you give each team 50 CPUs and 50GB RAM, Team A can run 6 jobs (limited by CPU) while Team B can run only 3 jobs (limited by memory). That doesn't feel fair — Team A is getting more work done from the same "share."
The Dominant Share
Kubernetes (influenced by the academic work behind systems like Apache Mesos) addresses this with Dominant Resource Fairness (DRF), an economic fairness theory.
The key insight: identify each user's dominant resource — the resource type they consume the most of, expressed as a percentage of total cluster capacity.
Example with a 10-CPU, 10GB cluster:
| Team | CPU Request | Memory Request | CPU % of Cluster | Memory % of Cluster | Dominant Share |
|---|---|---|---|---|---|
| A | 6 CPUs | 1 GB | 60% | 10% | 60% (CPU) |
| B | 2 CPUs | 5 GB | 20% | 50% | 50% (Memory) |
DRF's goal is to equalize the dominant shares across all users. The scheduler allocates resources so that no user's dominant share exceeds another's by more than necessary. This prevents a team from monopolizing one resource type while barely using another.
In Kubernetes, DRF principles are implemented through ResourceQuotas at the namespace level combined with the scheduler's scoring logic. Each namespace gets a quota — hard ceilings on total requested and limited CPU and memory across every Pod in that namespace — and the scheduler respects those boundaries when placing Pods.