Does a ResourceQuota limit individual Pods, or the whole namespace?

The whole namespace. Every hard limit you set is a ceiling on the sum across all objects of that type in the namespace, for example requests.cpu caps the total CPU requested by every Pod combined, not any single Pod's request.

What happens if I set requests.cpu but a Pod in the namespace doesn't specify a CPU request?

Once any compute resource quota (requests.cpu, requests.memory, limits.cpu, or limits.memory) is active in a namespace, Kubernetes requires every new Pod in that namespace to explicitly set requests/limits for that resource; Pods that don't will be rejected at admission. Consider pairing a ResourceQuota with a LimitRange to supply sane defaults automatically.

Why does this tool require a namespace, unlike some of the other generators?

A ResourceQuota is inherently namespace-scoped, it has no meaning applied cluster-wide, so the namespace field is required here rather than optional.

Can I limit other object types, like Secrets or ConfigMaps?

Kubernetes' ResourceQuota API supports many more object-count limits (secrets, configmaps, persistentvolumeclaims by storage class, and more) than this form exposes; it covers pods, services, and persistentvolumeclaims since those are the most commonly quota'd object counts, but you can add more hard limit keys manually to the generated YAML.

Kubernetes ResourceQuota Generator - Build ResourceQuota YAML

Overview

Introduction

A ResourceQuota is the tool that stops one team's namespace from quietly consuming an entire cluster's CPU, memory, or object count, but its hard-limit keys (requests.cpu, limits.memory, persistentvolumeclaims) are easy to mistype from memory.

This tool generates a ResourceQuota manifest from a straightforward form covering compute requests/limits and the three most commonly capped object counts, entirely client-side.

What Is Kubernetes ResourceQuota YAML Generator?

A Kubernetes ResourceQuota YAML generator that caps aggregate CPU/memory requests and limits, plus Pod, Service, and PersistentVolumeClaim counts, for a single namespace.

Every field is optional individually, but at least one hard limit must be set for the manifest to have any effect.

How Kubernetes ResourceQuota YAML Generator Works

Each compute field you fill in (requests.cpu, requests.memory, limits.cpu, limits.memory) becomes its own entry under spec.hard, using the exact dotted key names the ResourceQuota API expects.

The three object-count fields (pods, services, persistentvolumeclaims) are written as string-quoted whole numbers, since Kubernetes' quantity type represents plain counts as strings in the hard map.

Fields you leave blank are omitted entirely, so the generated manifest only constrains the resources you actually specified.

When To Use Kubernetes ResourceQuota YAML Generator

Use it when onboarding a new team or tenant namespace onto a shared cluster and you need to cap how much compute or how many objects it can consume.

Use it alongside a LimitRange (not covered by this generator) so individual Pods get sane default requests/limits once a compute quota makes them mandatory.

Often used alongside Kubernetes Namespace YAML Generator, Kubernetes HorizontalPodAutoscaler YAML Generator and Kubernetes Deployment YAML Generator.

Features

Advantages

Uses the exact dotted key names (requests.cpu, limits.memory, persistentvolumeclaims) the ResourceQuota API requires, which are easy to get wrong from memory.
Only includes the hard limits you actually set, keeping the generated manifest minimal and easy to review.
Runs entirely client-side; your namespace's resource planning never leaves your browser.

Limitations

Covers only cpu/memory requests and limits plus pods/services/persistentvolumeclaims counts; other quota-able resources (secrets, configmaps, storage-class-specific PVC counts, extended resources) need to be added manually.
Doesn't create a companion LimitRange, so if this quota makes CPU/memory requests mandatory, existing Pods without explicit requests will fail admission until they're updated or a LimitRange is added.
Doesn't check current usage in your namespace, so it can't warn you if existing workloads already exceed the limits you're about to set.

Examples

Capping a team namespace's compute and Pod count

Input

name: team-a-quota, namespace: team-a, requestsCpu: '4', requestsMemory: 8Gi, pods: 20

Output

apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-a-quota
  namespace: team-a
spec:
  hard:
    requests.cpu: "4"
    requests.memory: 8Gi
    pods: "20"

Only the three fields provided appear under spec.hard; limits.cpu/memory, services, and persistentvolumeclaims are simply omitted.

Best Practices & Notes

Best Practices

Pair any compute ResourceQuota with a LimitRange setting default requests/limits, so teams aren't surprised by sudden admission failures on Pods that previously had no requests set.
Set object-count limits (pods, services, persistentvolumeclaims) generously at first and tighten them once you understand a team's real usage pattern.
Review current namespace usage with `kubectl describe resourcequota` after applying, to confirm the limits you chose aren't already exceeded.

Developer Notes

Object counts are emitted as quoted string values (e.g. pods: "20") rather than bare numbers, matching how kubectl and the Kubernetes API itself represent ResourceQuota hard limits, since the underlying type is a Quantity, which serializes as a string even for plain integer counts. Compute values (cpu/memory) are passed through as typed by the user (e.g. "4", 8Gi) without reformatting, since Kubernetes' quantity suffix conventions (m, Ki, Mi, Gi) are numerous and this tool doesn't second-guess a validly-formatted quantity string.

Kubernetes ResourceQuota YAML Generator Use Cases

Capping total CPU/memory consumption for a team or tenant namespace on a shared cluster
Limiting how many Services or PersistentVolumeClaims a namespace can create, to control cloud load-balancer or storage costs
Enforcing a Pod count ceiling in a namespace to prevent runaway workload creation from exhausting cluster capacity

Common Mistakes

Applying a compute ResourceQuota to a namespace whose existing Pods have no CPU/memory requests set, which blocks all future Pod creation in that namespace until requests are added.
Forgetting the namespace field, since unlike most namespaced objects, a ResourceQuota is meaningless without an explicit target namespace.
Setting persistentvolumeclaims too low for a namespace using StatefulSets, where each replica typically claims its own PVC.

Tips

Generate the target namespace first with the Kubernetes Namespace Generator if it doesn't already exist, then apply this quota into it.

Kubernetes ResourceQuota YAML Generator