What is a Kubernetes namespace for?

A namespace is a virtual cluster that isolates resources for a team, environment, or application. Names only need to be unique within a namespace, and you can attach quotas, network policies, and RBAC rules per namespace for multi-tenancy.

What does a ResourceQuota enforce?

A ResourceQuota caps the aggregate resource consumption of a namespace — total CPU and memory requests and limits, and counts of objects like pods. Once the quota is hit, new pods that would exceed it are rejected at admission time.

Why do I also need a LimitRange?

A ResourceQuota that caps total limits requires every pod to declare requests and limits, or admission fails. A LimitRange supplies default requests and limits to containers that omit them, and enforces per-container min and max, so the quota works smoothly.

What happens when a quota is exceeded?

The Kubernetes admission controller rejects the create or update request with a quota-exceeded error. Existing workloads keep running, but you cannot schedule more until usage drops or the quota is raised.

Can I change quotas later?

Yes. Edit and re-apply the ResourceQuota or LimitRange at any time. Lowering a quota below current usage does not evict running pods, but it blocks new ones until consumption falls under the new limit.

What is the Kubernetes Namespace & ResourceQuota Builder?

Build a Kubernetes Namespace with a matching ResourceQuota (CPU, memory, pod caps) and a LimitRange of per-container defaults — the standard primitives for safe multi-tenant clusters. It runs free in your browser on Gera Tools, with nothing uploaded.

Kubernetes Namespace & ResourceQuota Builder

Name: Kubernetes Namespace & ResourceQuota Builder
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

Get one useful tool a week

Like this tool? Enter your email and we'll send you one genuinely useful Gera tool a week — plus a link to come back to this one. No spam, one-click unsubscribe any time.

Stand up a safe multi-tenant namespace

When several teams share a cluster, an unbounded namespace can starve everyone else by scheduling too many pods or oversized containers. This builder generates the three objects that fence off a namespace: the Namespace itself, a ResourceQuota capping aggregate usage, and a LimitRange providing sensible per-container defaults.

How it works

The ResourceQuota sets hard ceilings on the sum of requests.cpu, requests.memory, limits.cpu, limits.memory, and the pod count across the whole namespace. Kubernetes enforces these at admission time — any request that would push the namespace over a cap is rejected.

A quota that limits limits.cpu/limits.memory forces every container to declare those values. The LimitRange fills the gap: it injects default and defaultRequest values into containers that omit them, and sets per-container max ceilings. Together they guarantee that every workload is accounted for and the quota math always has the numbers it needs.

The three generated objects and why you need all three

Namespace is the isolation boundary. Resources in one namespace cannot directly reference resources in another without explicit configuration. The namespace also carries labels for RBAC, network policies, and cost attribution.

ResourceQuota enforces aggregate limits across the whole namespace. Without it, a single team can schedule unlimited pods and consume all cluster resources, degrading every other tenant. The quota is the namespace’s budget.

LimitRange enforces per-container limits and provides defaults. Without it, any container that omits resource declarations will trigger a quota admission error once the quota is enforced — because Kubernetes has no number to add to the quota total. The LimitRange supplies those defaults silently, so developers who forget to set resources still get sensible values and admission succeeds.

Choosing quota values

There is no universal right answer for quota sizes, but a few starting heuristics:

Namespace type	Suggested CPU quota	Suggested memory quota
Small dev team (2–5 devs)	4 cores total	8Gi total
Medium product team (5–15 devs)	16 cores total	32Gi total
Production workload	Sized to peak load + 30% headroom	—
Staging / test	Half of production quota	—

The pod count limit prevents runaway deployments or job floods. A typical team namespace might cap at 50–100 pods; a large production namespace may not need a pod count limit if the resource quota is tight enough.

Tips for applying

Keep defaultRequest modest — it is the floor each container reserves and counts against the quota even when idle.
Set the LimitRange max to your largest sane container so a single workload cannot consume the entire namespace quota by itself.
Add a team label to the namespace for cost attribution and to target it with network policies or RBAC bindings.
Apply all three documents together in one command; the LimitRange should exist before any workloads are deployed so defaults take effect from the first pod.

kubectl apply -f namespace-with-quota.yaml
kubectl describe resourcequota -n <namespace>