Namespaces

TL;DR

• Namespace provides logical partitioning within a cluster; provides scope for names, RBAC, and quotas
• Default namespaces: default, kube-system, kube-public, kube-node-lease
• Namespace-scoped: Pods, Services, Deployments; Cluster-scoped: Nodes, PersistentVolumes, ClusterRoles
• Namespaces don’t provide network isolation—pods in different namespaces can talk by default; use NetworkPolicies
• ResourceQuota limits total resources per namespace; when applied, ALL pods must declare CPU/memory requests/limits
• LimitRange injects default requests/limits per container and enforces min/max boundaries
• Namespace stuck in Terminating due to finalizers on resources; edit metadata finalizers: null to force cleanup

Core Concepts

Logical Partitioning

Namespace partitions a single physical cluster into isolated logical spaces. Provides:

• Name scope: resource names must be unique within a namespace but can repeat across namespaces
• RBAC scope: RoleBindings apply to a namespace
• Quota scope: ResourceQuotas constrain resource consumption per namespace

Default Namespaces

• default: Fallback when namespace not specified
• kube-system: System components (API server, etcd, scheduler, CoreDNS, kube-proxy)
• kube-public: World-readable; cluster metadata for unauthenticated users
• kube-node-lease: Node heartbeat lease objects; optimizes performance at scale

Resource Scope

Namespace-scoped: Pods, Services, Deployments, ReplicaSets, StatefulSets, DaemonSets, Jobs, CronJobs, ConfigMaps, Secrets, PersistentVolumeClaims (PVCs), Ingresses, NetworkPolicies, RoleBindings

Cluster-scoped: Nodes, PersistentVolumes (PVs), StorageClasses, ClusterRoles, ClusterRoleBindings, CustomResourceDefinitions (CRDs), Namespaces themselves

ResourceQuota vs. LimitRange

ResourceQuota: Limits total resources (pods, CPU, memory, storage) consumed by all pods in a namespace. Enforces hard aggregate limits.

LimitRange: Injects defaults on individual containers and enforces min/max per container. Works per container, not aggregate.

Network Isolation Myth

Namespaces provide logical isolation, not network isolation. Pods in namespace A can reach pods in namespace B via DNS (e.g., service.namespace.svc.cluster.local) unless NetworkPolicies restrict traffic.

Comparison Table

Command & Configuration Reference

Namespace Management

# Create namespace
kubectl create namespace team-alpha

# Set default namespace in context
kubectl config set-context --current --namespace=team-alpha

# List resources in all namespaces
kubectl get pods -A
kubectl get deployment -A --all-namespaces

# Delete namespace (deletes all resources inside)
kubectl delete namespace team-alpha

ResourceQuota Example

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

LimitRange Example

apiVersion: v1
kind: LimitRange
metadata:
  name: team-alpha-limits
  namespace: team-alpha
spec:
  limits:
  - type: Container
    default:  # Applied if container has no limits
      cpu: 500m
      memory: 512Mi
    defaultRequest:  # Applied if container has no requests
      cpu: 100m
      memory: 256Mi
    max:  # Reject containers exceeding this
      cpu: 2
      memory: 2Gi
    min:  # Reject containers below this
      cpu: 50m
      memory: 64Mi

Quota Inspection

# Check quota usage
kubectl describe resourcequota team-alpha-quota -n team-alpha

# Describe limits
kubectl describe limits team-alpha-limits -n team-alpha

Common Pitfalls

Pitfall: ResourceQuota + Pods Without Requests/Limits Deploy pod to namespace with ResourceQuota; pod is rejected with “Forbidden” error.

• Why: When ResourceQuota exists, API server mandates every pod declare CPU/memory requests and limits (container-level).
• Fix: Add resources.requests and resources.limits to all container specs, or deploy a LimitRange to inject defaults.

Pitfall: Assuming Network Isolation Deploy pods in separate namespaces expecting network isolation; cross-namespace traffic flows freely.

• Why: Namespaces are logical only; Kubernetes network is flat by default.
• Fix: Apply NetworkPolicies to restrict ingress/egress between namespaces.

Pitfall: Namespace Deletion Hang (Finalizer Blocking) kubectl delete namespace staging hangs in Terminating forever.

• Why: A resource inside (PVC, custom resource) has a finalizer; its controller is down or unresponsive.
• Fix: Find the blocking resource: kubectl api-resources --verbs=list --namespaced=true -o name | xargs -n 1 kubectl get -n staging. Edit it: kubectl edit <resource> -n staging, set finalizers: null, save.

Interview Questions

Q — Do Namespaces provide network isolation? Can a pod in one namespace communicate with a pod in another? No. Namespaces provide logical isolation only. Network is flat; any pod can reach any other pod across namespaces via DNS (e.g., service.namespace.svc.cluster.local). To enforce network isolation, deploy NetworkPolicies to allow/deny traffic ingress/egress by namespace labels.

Q — What’s the difference between ResourceQuota and LimitRange? Which enforces aggregate limits? ResourceQuota enforces aggregate limits on all pods in a namespace (e.g., max 10 pods total, max 4 CPU total). LimitRange enforces boundaries per container (min/max CPU/memory per container) and injects defaults if not specified. When ResourceQuota exists, every pod must declare requests/limits; LimitRange can auto-inject them.

Q — A deployment in a namespaced suddenly fails with “exceeded quota”. Walk through troubleshooting. Run kubectl describe resourcequota -n <namespace> to see which limit hit (pods, CPU, memory, etc.). If cluster has capacity, update the ResourceQuota spec to increase limits. If constrained, audit pods with kubectl top pods -n <namespace> or kubectl get pods -n <namespace> -o json | jq. Delete unused deployments or reduce requests/limits on existing ones. Can also add a LimitRange to inject defaults for new pods.