Namespace Resource Calculator
Total up CPU and memory requests across all pods in a namespace and compare against a configured ResourceQuota.
Inputs
Total number of pods running in the namespace.
The namespace's configured requests.cpu quota.
The namespace's configured requests.memory quota.
Total Namespace CPU Request
8.00cores
Total Namespace Memory Request
10.00GiB
CPU Quota Used
50.0%
Memory Quota Used
31.3%
CPU Quota Exceeded
false
Memory Quota Exceeded
false
Step by step
Total CPU request
40 × 200m
= 8.00 cores
Total memory request
40 × 256MiB
= 10.00 GiB
CPU quota utilization
8.00 ÷ 16
= 50.0%
Memory quota utilization
10.00 ÷ 32
= 31.3%
How it works
A ResourceQuota caps the total requests and limits summed across every pod in a namespace, preventing one team from starving others sharing the cluster. This calculator multiplies per-pod requests by pod count to get namespace totals, then compares those totals against the configured CPU and memory quotas so you can see utilization before the API server starts rejecting new pod creations.
Formulas
Total CPU request
totalCPU = pods × perPodCPU
- N
- Number of pods in the namespace
- C_p
- Per-pod CPU request in millicores
- T_c
- Total namespace CPU request in millicores
Quota utilization
cpuQuotaUsed% = (totalCPU / quotaCPU) × 100
- T_c
- Total namespace CPU request
- Q_c
- Configured CPU quota
- U_c
- CPU quota utilization percentage
Frequently Asked Questions
What happens when a namespace hits its ResourceQuota?
The API server rejects any new pod (or object with a resource request) that would push the namespace total above quota, returning a 403 Forbidden with a quota-exceeded message — existing pods are not evicted.
Does ResourceQuota apply to limits, requests, or both?
You can configure quotas separately for requests.cpu/requests.memory and limits.cpu/limits.memory, plus object counts like pods, services and persistentvolumeclaims — this calculator models the requests side.
How should teams plan headroom under a shared quota?
Leave 15-20% headroom below the hard quota for rolling deployments, since a new ReplicaSet's pods briefly coexist with the old ones during a rollout and temporarily double-count requests.