Kubernetes Namespace Resource Governance

Kubernetes Namespace Resource Governance is the practice of bounding and defaulting resource consumption at the namespace level using ResourceQuota and LimitRange objects, giving cluster operators a way to enforce fair, predictable resource allocation across multiple teams or applications sharing a single cluster without needing to review or restrict every individual Pod manifest by hand. Where request and limit management addresses how an individual Pod declares its own resource needs, namespace governance addresses the aggregate: how much total capacity a group of workloads sharing a namespace is permitted to consume collectively, and what sensible defaults apply to workloads that do not specify their own resource declarations.

Namespace-level governance is the primary tool for multi-tenant capacity fairness in Kubernetes clusters, translating organizational boundaries (teams, applications, environments) into enforceable technical limits.

ResourceQuota

Bounding Aggregate Consumption

A ResourceQuota object sets hard ceilings on the total resource requests and limits summed across every Pod in a namespace, as well as optional limits on object counts (number of Pods, Services, PersistentVolumeClaims).

apiVersion: v1
kind: ResourceQuota
metadata:
  name: codartium-team-quota
  namespace: codartium-team
spec:
  hard:
    requests.cpu: "20"
    requests.memory: "40Gi"
    limits.cpu: "40"
    limits.memory: "80Gi"
    pods: "50"

Enforcement at Admission Time

Quota enforcement happens at the API server's admission stage — a Pod creation request that would push the namespace's aggregate consumption over any declared hard limit is rejected outright, before it is ever persisted or considered for scheduling, giving immediate, synchronous feedback to whoever submitted the manifest.

Quota Requires Every Pod to Declare Requests

Once any ResourceQuota covering CPU or memory requests exists in a namespace, every Pod created there must specify explicit requests for that resource — a Pod omitting them is rejected, since the quota system has no way to account for an undeclared consumption amount against the aggregate limit.

LimitRange

Defaulting Missing Values

A LimitRange supplies default (limit) and defaultRequest values automatically applied to any container that does not specify its own, ensuring every container ends up with meaningful, accounted-for resource declarations rather than silently landing in BestEffort QoS by omission.

apiVersion: v1
kind: LimitRange
metadata:
  name: codartium-defaults
  namespace: codartium-team
spec:
  limits:
    - default:
        cpu: "500m"
        memory: "512Mi"
      defaultRequest:
        cpu: "250m"
        memory: "256Mi"
      type: Container

Bounding Individual Container Sizes

Beyond defaulting, a LimitRange can set min and max bounds on what any single container is permitted to declare, preventing both unreasonably tiny (likely misconfigured) requests and unreasonably large ones that could single-handedly consume a disproportionate share of the namespace's quota.

limits:
  - max:
      cpu: "4"
      memory: "8Gi"
    min:
      cpu: "50m"
      memory: "64Mi"
    type: Container

maxLimitRequestRatio

LimitRange can also cap the ratio between a container's limit and its request, preventing an excessively generous burst allowance (a tiny request paired with a huge limit) that would undermine the predictability quota-based capacity planning depends on.

limits:
  - maxLimitRequestRatio:
      cpu: "4"
      memory: "2"
    type: Container

ResourceQuota and LimitRange Working Together

Complementary, Not Redundant

LimitRange ensures every individual container has sensible, bounded resource declarations; ResourceQuota ensures the aggregate sum across the whole namespace stays within an overall ceiling — the two mechanisms address different granularities and are typically deployed together, since a LimitRange alone does not prevent a namespace from accumulating many individually-reasonable Pods that collectively exceed available capacity.

Operational Practices

Setting Quotas Based on Actual Team Needs

Quota values are most effective when informed by observed historical usage and near-term growth plans for a given team or application, rather than arbitrary round numbers — quotas set without this grounding tend to either constrain legitimate workloads unexpectedly or provide no real governance value at all.

Monitoring Quota Utilization

kubectl describe resourcequota codartium-team-quota -n codartium-team

Reviewing quota utilization periodically (not just when a rejection occurs) helps teams anticipate approaching limits before they actually block a deployment, turning quota management into a proactive capacity conversation rather than a reactive troubleshooting exercise.

Example

apiVersion: v1
kind: Namespace
metadata:
  name: codartium-team
---
apiVersion: v1
kind: ResourceQuota
metadata:
  name: codartium-quota
  namespace: codartium-team
spec:
  hard:
    requests.cpu: "10"
    requests.memory: "20Gi"
---
apiVersion: v1
kind: LimitRange
metadata:
  name: codartium-limits
  namespace: codartium-team
spec:
  limits:
    - default:
        cpu: "500m"
        memory: "512Mi"
      defaultRequest:
        cpu: "250m"
        memory: "256Mi"
      type: Container