Namespaces: dividing a cluster into virtual clusters

A single Kubernetes cluster commonly hosts multiple teams' applications, or multiple environments (staging, production) of the same application, or both. Without any separation, every object shares one flat pool of names — two teams both wanting a Deployment named api would collide directly, and there'd be no clean way to say "list only my team's Pods" without manually filtering by naming convention.

A namespace partitions object names into separate groups — two Deployments named api can coexist peacefully as long as they're in different namespaces:

Every object you've already seen (Pods, Deployments, Services, and every object this domain still covers) belongs to exactly one namespace — if you don't specify one, it goes into default, which is why simple examples often don't seem to mention namespaces at all.

Namespaces separate names and provide a scope for policies like resource quotas and access control (lesson 11 covers RBAC). They do not provide network isolation by default — a Pod in team-payments can still reach a Pod in team-search over the network unless a separate mechanism (a NetworkPolicy) explicitly restricts it. This is a common misconception worth stating precisely: namespaces are an organizational and naming boundary first, not automatically a security boundary, though they provide the scope other tools use to build one.

Without limits, one team's namespace could consume enough CPU or memory to starve every other namespace sharing the same physical cluster. A ResourceQuota caps total resource consumption per namespace:

This connects directly to Docker & Containers' resources.requests on individual Pods — a ResourceQuota is the same concept applied at the namespace level, capping the sum across every Pod in that namespace rather than one Pod's individual ceiling.

Every cluster starts with a few built-in namespaces: default (where unlabeled objects land), kube-system (the control plane's own components, like the ones lesson 1 described, running as Pods themselves in most setups), and kube-public. Recognizing kube-system objects in kubectl get pods --all-namespaces output as the cluster's own internal machinery — not something to debug as though it were your application — avoids a common early confusion.

A common, effective pattern uses namespaces to separate environments (staging, production) or teams within one cluster, letting each apply its own ResourceQuota and RBAC rules (lesson 11) while sharing the underlying physical hardware — genuinely useful cost efficiency compared to running entirely separate clusters per team or environment, at the cost of needing real discipline about namespace-scoped access control to prevent one team's mistake from affecting another's workloads.