OpenShift Project Quota Calculator

Total ResourceQuota requests and limits across projects and read the resulting cluster overcommit ratio.

About OpenShift Project Quota Calculator

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

Worked example

With the default values below, OpenShift Project Quota Calculator returns CPU Requests Committed of 150.00. Change any input above and every figure here is recalculated in your browser.

Inputs used

Projects with quotaaccepts 1–20,000 projects: 30 projects
Pods per projectaccepts 1–5,000 pods: 20 pods
CPU request per podaccepts 1–64,000 millicores: 250 millicores
CPU limit per podaccepts 1–64,000 millicores: 1,000 millicores
Memory request per podaccepts 1–262,144 MiB: 512 MiB
Memory limit per podaccepts 1–262,144 MiB: 1,536 MiB
Allocatable cluster vCPUsaccepts 1–100,000 vCPU: 96 vCPU
Allocatable cluster memoryaccepts 1–500,000 GiB: 360 GiB

Results

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

Step by step

1Values used
2OpenShift Project Quota
3CPU Requests Committed= 150.00 cores
4CPU Limits Committed= 600.00 cores
5Limit to Request Ratio= 4.00 :1
6Memory Requests Committed= 300.00 GiB
7Allocatable CPU Committed= 156.3
8Quota Verdict= Quotas already exceed allocatable capacity — pods will sit unschedulable

Assumptions and limits

The result is derived only from the 8 inputs listed above. Anything not among them is not part of the calculation.
In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
Figures are rounded for display to 2 decimal places, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.

How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.

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.