OpenShift Project Quota Calculator
Total ResourceQuota requests and limits across projects and read the resulting cluster overcommit ratio.
Inputs
CPU Requests Committed
150.00cores
CPU Limits Committed
600.00cores
Limit to Request Ratio
4.00:1
Memory Requests Committed
300.00GiB
Allocatable CPU Committed
156.3%
Quota Verdict
Quotas already exceed allocatable capacity — pods will sit unschedulable
Step by step
Values used
Projects with quota = 30 projects; Pods per project = 20 pods; CPU request per pod = 250 millicores; CPU limit per pod = 1,000 millicores; Memory request per pod = 512 MiB; Memory limit per pod = 1,536 MiB; Allocatable cluster vCPUs = 96 vCPU; Allocatable cluster memory = 360 GiB
OpenShift Project Quota
requests = projects × pods × request per pod (the figure the scheduler reserves); limits = the same with limits; the overcommit ratio is limit ÷ request.
CPU Requests Committed
= 150.00 cores
CPU Limits Committed
= 600.00 cores
Limit to Request Ratio
= 4.00 :1
Memory Requests Committed
= 300.00 GiB
Allocatable CPU Committed
= 156.3
Quota Verdict
= Quotas already exceed allocatable capacity — pods will sit unschedulable
How it works
ResourceQuota governs the sum of requests and limits a project may hold, and the scheduler only ever counts requests. That makes the limit-to-request ratio the real risk dial: a ratio of 1 gives Guaranteed QoS with no bursting, while a high ratio packs nodes densely and relies on workloads never bursting together. Quotas set from limits rather than requests either strand capacity or oversubscribe nodes into OOM kills, and quotas totalling more than allocatable capacity produce unschedulable pods with no obvious cause.
Formula
OpenShift Project Quota
requests = projects × pods × request per pod (the figure the scheduler reserves); limits = the same with limits; the overcommit ratio is limit ÷ request.
- request
- Guaranteed reservation the scheduler subtracts from allocatable capacity
- limit
- Runtime ceiling enforced by the cgroup, and the burst a pod may take
- overcommit ratio
- How far above its reservation the cluster lets workload burst
Frequently Asked Questions
How is OpenShift Project Quota calculated?
requests = projects × pods × request per pod (the figure the scheduler reserves); limits = the same with limits; the overcommit ratio is limit ÷ request. ResourceQuota governs the sum of requests and limits a project may hold, and the scheduler only ever counts requests. That makes the limit-to-request ratio the real risk dial: a ratio of 1 gives Guaranteed QoS with no bursting, while a high ratio packs nodes densely and relies on workloads never bursting together.
Why does OpenShift Project Quota matter?
Quotas set from limits rather than requests either strand capacity or oversubscribe nodes into OOM kills, and quotas totalling more than allocatable capacity produce unschedulable pods with no obvious cause.
What values do I need to enter?
This calculator takes 8 inputs: Projects with quota, Pods per project, CPU request per pod, CPU limit per pod, Memory request per pod, Memory limit per pod, Allocatable cluster vCPUs, Allocatable cluster memory. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.
How does a LimitRange interact with a ResourceQuota?
A ResourceQuota caps the project total but rejects pods that specify no request at all. A LimitRange supplies the per-pod defaults, so in practice you need both — the LimitRange to make unspecified pods admissible and the quota to bound the sum.
You might also need
- OpenShift Node Capacity CalculatorCommonly used together
- OpenShift Pod Density CalculatorCommonly used together
- OpenShift Registry Storage CalculatorCommonly used together
- OpenStack Keystone Resource CalculatorCommonly used together
- Hypervisor Consolidation CalculatorAlso in Virtualization & Private Cloud
- VMware VM Density CalculatorAlso in Virtualization & Private Cloud