Namespaces and Resource Quotas

Analogy categoryAnalogies

Organizing a Cluster with Namespaces

A Namespace is a virtual cluster within a physical Kubernetes cluster, used to divide resources among multiple teams, projects, or environments. Namespaces scope object names, RBAC permissions, and — combined with ResourceQuotas — compute consumption, without requiring separate physical clusters.

🏏

Cricket analogy: Like the IPL running separate franchise dressing rooms within one stadium complex so Mumbai Indians and Chennai Super Kings share the ground without mixing kit bags, a Namespace divides one physical cluster into isolated virtual sections.

Creating and Using Namespaces

Every cluster ships with default, kube-system, and kube-public namespaces. Custom namespaces are created for isolating environments such as dev, staging, and production, or per-team boundaries. Objects are placed into a namespace via metadata.namespace, or by targeting it with kubectl apply -n team-payments -f deployment.yaml; cluster-scoped resources like Nodes and PersistentVolumes are not namespaced.

🏏

Cricket analogy: Like the BCCI setting up default administrative, umpiring, and public-facing wings automatically when a new stadium opens, then adding a dedicated 'Team Payments Ground' namespace for a specific franchise via kubectl apply -n team-payments.

yaml

apiVersion: v1
kind: Namespace
metadata:
  name: team-payments
  labels:
    environment: production

Limiting Aggregate Usage with ResourceQuota

A ResourceQuota constrains the total amount of CPU, memory, storage, or object count that can be consumed within a namespace, preventing one team from starving others of cluster capacity.

🏏

Cricket analogy: Like the ICC capping the total number of overseas players a league can field across all its franchises so no single team can hoard talent, a ResourceQuota caps total CPU, memory, and storage a namespace can consume.

yaml

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

Setting Per-Container Defaults with LimitRange

While ResourceQuota caps the namespace total, a LimitRange sets default, minimum, and maximum resource values for individual containers or Pods, ensuring every workload requests reasonable resources even if the developer omits them.

🏏

Cricket analogy: Like a fitness policy setting a default, minimum, and maximum training load for every player who doesn't submit their own personalized plan, a LimitRange sets default resource values for containers that omit them.

yaml

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

If a ResourceQuota specifying requests.cpu or requests.memory is active in a namespace, every Pod created there must explicitly declare resource requests/limits, or the API server will reject it — unless a LimitRange supplies defaults.

ResourceQuotas apply per namespace, not per cluster. Forgetting to set them on shared namespaces is a common cause of noisy-neighbor incidents where one misbehaving Deployment exhausts node capacity for everyone.

Namespaces provide logical isolation for names, RBAC, and quota scoping — not network isolation by default.
ResourceQuota caps aggregate CPU, memory, storage, and object counts per namespace.
LimitRange enforces default/min/max resource values at the container or Pod level.
Cluster-scoped objects (Nodes, PVs, ClusterRoles) are never namespaced.
A namespace with a requests-based ResourceQuota forces all Pods to declare requests.
kubectl get resourcequota -n <ns> shows current usage against hard limits.

Practice what you learned

1. What is the primary function of a Kubernetes Namespace?

2. Which object enforces an aggregate cap on total CPU and memory usage within a namespace?

3. What does a LimitRange primarily control?

4. If a namespace has a ResourceQuota with requests.cpu set, what happens to a Pod created without explicit CPU requests and no LimitRange present?

5. Which of the following is NOT namespaced in Kubernetes?

Was this page helpful?

Persistent Volumes and Claims

Horizontal Pod Autoscaling

Related Study Notes in DevOps

Browse all study notes

DevOps

Nginx Study Notes

DevOps · 30 topics

DevOps

Ansible Study Notes

DevOps · 30 topics

DevOps

Advanced Kubernetes Study Notes

Kubernetes · 30 topics

DevOps

Advanced Bash Scripting Study Notes

Bash · 30 topics

DevOps

Apache Kafka Study Notes

Kafka · 30 topics

DevOps

CI/CD Tools & Pipelines Study Notes

YAML · 37 topics

Topics covered

#YAML#DockerKubernetesStudyNotes#DevOps#NamespacesAndResourceQuotas#Namespaces#Resource#Quotas#Organizing#StudyNotes#SkillVeris

Organizing a Cluster with Namespaces

Creating and Using Namespaces

Limiting Aggregate Usage with ResourceQuota

Setting Per-Container Defaults with LimitRange

Practice what you learned

You May Also Like

Related Reading

Related Study Notes in DevOps

Topics covered