Making namespaces and quotas work for multi-tenant Kubernetes clusters

Kubernetes namespaces are the simplest, most familiar tool for isolating teams and applications in a shared cluster — but alone they’re not enough to prevent resource sprawl, noisy neighbors, or accidental denial of service. ResourceQuota and LimitRange give you control inside a namespace. For organizations trying to balance self-service and cluster stability, a practical pattern combines namespaces, quotas and (where useful) hierarchical namespace tooling — with a clear understanding of what each primitive actually enforces and what it doesn’t.

This article walks through the design thinking and concrete examples for governing multi-tenant clusters with namespaces and resource quotas, and highlights a recent change in the ecosystem you should know about.

Quick vocabulary refresher

• Namespace: a logical partition inside a cluster that groups resources and isolates them for RBAC, network policies, and quotas.
• ResourceQuota: a namespace-scoped Kubernetes object that limits how much of selected resources (CPU, memory, number of Pods, PersistentVolumeClaims, etc.) can be consumed inside a namespace. (kubernetes.io)
• LimitRange: a namespace-scoped object that enforces or supplies defaults for container resource requests and limits (CPU, memory). It helps make quotas meaningful by ensuring pods declare requests and limits. (kubernetes.io)
• Hierarchical namespaces / HNC: a controller that lets you create parent–child namespace relationships and propagate policies between them (useful for teams composed of several sub-namespaces). HNC was a community extension with production-ready features—but its repository was archived on April 17, 2025, so treat availability and support as a factor when planning. (kubernetes.io)

Common multi-tenant patterns and where quotas fit

1. One-namespace-per-tenant (simple)
   • Pros: easy to reason about RBAC and quotas; native Kubernetes primitives.
   • Cons: tenants who need multiple isolated environments (dev/test/prod or many microservices) often request multiple namespaces, increasing management overhead.
2. Namespace-per-application, grouped by labels (team-level governance)
   • Pros: flexible; teams own multiple namespaces and can run different apps with varying SLAs.
   • Cons: harder to enforce a team-level resource budget unless you implement a higher-level controller or aggregated accounting.
3. Hierarchical namespaces (team namespace as parent of app namespaces)
   • Pros: allows policy propagation and the idea of a team-level quota that spans child namespaces.
   • Cons: introduces extra control-plane components and operational complexity — and note that the HNC project has been archived as of April 17, 2025, which affects long-term support and adoption choices. (github.com)

For most clusters, the sweet spot is a mix of pattern 1 or 2 plus careful use of ResourceQuota and LimitRange. Cloud providers and platform teams commonly recommend creating quotas for each namespace and matching them to realistic requests for Pods, CPU and memory. This reduces overcommit and gives a clear surface for chargeback or capacity planning. (cloud.google.com)

Why LimitRange and ResourceQuota should be used together

ResourceQuota only counts what resources are requested or created; if pods don’t declare requests, quota accounting can be misleading. LimitRange helps by:

• Supplying default request/limit values for containers that don’t declare them.
• Blocking pod creation when a container explicitly violates a per-namespace limit.

Using LimitRange alongside ResourceQuota avoids the “silent oversubscription” case where teams deploy lots of pods with no resource requests and the cluster runs out of capacity. (kubernetes.io)

Practical examples

1) A basic LimitRange that sets defaults and maxima for containers:

apiVersion: v1
kind: LimitRange
metadata:
  name: team-limits
  namespace: team-alpha
spec:
  limits:
  - type: Container
    default:
      cpu: "250m"
      memory: "256Mi"
    defaultRequest:
      cpu: "100m"
      memory: "128Mi"
    max:
      cpu: "1"
      memory: "1Gi"

This ensures that any container created without explicit requests gets a sensible request and limit — making quota accounting predictable. (kubernetes.io)

2) A ResourceQuota that caps total CPU, memory and number of Pods in a namespace:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-alpha-quota
  namespace: team-alpha
spec:
  hard:
    pods: "50"
    requests.cpu: "8"
    requests.memory: "16Gi"
    limits.cpu: "12"
    limits.memory: "24Gi"

This prevents a single namespace from consuming more than its share of cluster resources and sets a clear boundary for platform teams. (kubernetes.io)

Accounting for teams that need multiple namespaces

If a team needs several namespaces (for example: team-alpha-dev, team-alpha-staging, team-alpha-prod), there are two practical ways to express a team budget:

• Centralized quotas: the platform team enforces quotas per namespace and allocates a total team budget through organizational policy or tooling that tracks sums across namespaces (external to Kubernetes).
• Hierarchical or composite quotas: some orgs evaluated the Hierarchical Namespace Controller (HNC) to create a team parent namespace and propagate quotas to children. HNC supported hierarchical resource quotas and propagation semantics — useful when you want child namespaces to inherit policy from a team root. But because the HNC project was archived on April 17, 2025, teams should treat HNC as an option that may require extra operational commitment or look into vendor-managed equivalents. (github.com)

For enterprises, cloud provider guidance often highlights starting with per-namespace quotas and using labeling/tagging plus platform automation for higher-level aggregation and chargeback. (cloud.google.com)

Operational tips and real-world gotchas

• Defaulting vs Enforcement: A LimitRange default can hide a problem (pods get defaults, quota appears healthy) — combine defaults with monitoring of actual usage to catch creeping consumption. (kubernetes.io)
• Object-count quotas: ResourceQuota can limit counts of objects (ConfigMaps, persistent volume claims, Services). This is useful for guarding API-server and etcd pressure, not just CPU/memory. (kubernetes.io)
• Quota denial behavior: When a namespace hits its ResourceQuota limit, API requests that would exceed the quota are rejected (HTTP 403). Make error messages actionable for platform users. (kubernetes.io)
• Multi-namespace tenancy: Aggregating quotas across namespaces requires external tooling or a controller; native Kubernetes doesn’t provide a built-in “team budget across namespaces” primitive without extensions. That gap is why HNC and other multi-tenancy projects emerged — but keep in mind their maintenance status. (github.com)
• Cluster limits: Even if namespace quotas are generous, cluster-wide limits (node count, pod density, etc.) still apply — quotas are a guardrail, not a capacity guarantee. Cloud provider docs remind platform teams to account for cluster-level thresholds when planning tenant density. (cloud.google.com)

When hierarchical namespaces make sense (and when they don’t)

Hierarchical namespaces help when:

• A team logically owns many namespaces and you want policy and RBAC propagated from a team root to its children.
• You need a single place to manage network policies, secrets, or resource constraints for a collection of namespaces.

They’re less useful when:

• Teams are small and a single namespace per team suffices.
• You want lightweight governance with minimal control-plane surface area.

Also, because the HNC project’s repo was archived on April 17, 2025, evaluate vendor support and long-term maintenance before building critical platform capabilities on it. Archived projects can still be valuable, but they shift operational risk onto your team. (github.com)

A pragmatic checklist for quota-driven namespace governance

• Apply a LimitRange to every tenant namespace so resource requests are always present. (kubernetes.io)
• Create ResourceQuota objects that match expected workloads and capture both compute (requests/limits) and object counts (PVCs, Services). (kubernetes.io)
• Track real usage with metrics (CPU, memory, pod counts) and alert on quota exhaustion trends rather than single rejections.
• Decide whether teams get one namespace or multiple, and be explicit about how team budgets are enforced — via per-namespace quotas plus external aggregation, or via hierarchical tooling (evaluating support and maturity first). (cloud.google.com)
• Document quota error messages and provide examples so platform users can self-diagnose quota rejections.

Closing thought

Namespaces, ResourceQuota and LimitRange are the practical building blocks to keep a shared cluster healthy — they’re simple individually but require coordinated policy and monitoring to be effective at scale. Hierarchical approaches add expressive power for complex organizations, but recent changes in the community landscape (for example, the archiving of the HNC repository on April 17, 2025) mean platform teams must weigh operational cost and support when choosing extensions. Clear quotas plus predictable defaults and good observability will keep tenants productive and minimize noisy-neighbor risk. (kubernetes.io)