Namespaces: tidy rooms

Dividing one cluster into spaces.

As a cluster hosts more apps and teams, you want a way to keep things tidy and separated — and namespaces are exactly that: a way to divide one physical cluster into virtual sections. Think of one big office building divided into rooms: everyone shares the building, but each team has its own room with its own things.

Dividing one cluster into spaces

A namespace is a named section of the cluster that scopes the objects inside it. Its most visible effect is names: two different namespaces can each have a Deployment called "web" without conflict, because the namespace is part of the identity. You use namespaces to separate environments (a dev namespace and a staging namespace in one cluster), teams (each team gets its own namespace), or applications. Most objects you have met — pods, Deployments, Services, ConfigMaps, Secrets — live in a namespace, and if you do not specify one they go into the "default" namespace. You can set a default namespace for your commands so you do not have to type it each time, and use -n to target a specific one or -A to see across all of them. Namespaces are also where quotas and access rules get applied, so they are the natural unit for giving a team its own bounded space in a shared cluster.

kubectl create namespace team-a
kubectl config set-context --current --namespace=team-a   # default for my commands
kubectl get pods                     # now shows team-a's pods
kubectl get pods -n team-b           # peek at another namespace
kubectl get pods -A                  # across ALL namespaces
 
# Reach a Service in another namespace by name:  db.team-b (svc.namespace)

What namespaces do — and do not — separate

It is important to understand the limits, because namespaces are an organizational boundary, not a security or network wall by default. Pods in different namespaces can still talk to each other over the network (you saw the cross-namespace DNS name db.team-b) unless you add a NetworkPolicy to block it, and namespaces do not isolate the underlying machines — pods from different namespaces can run on the same node. So a namespace tidies and scopes, and it is where you apply real controls (resource quotas to cap how much a team can use, access rules to control who can do what in that namespace, network policies to segment traffic), but the namespace by itself does not stop a compromised app in one namespace from reaching another. For a beginner, the useful mental model is: namespaces are rooms that keep your cluster organized and give each team or environment its own labeled space — and the actual separation (network, access, capacity) is added on top with the controls you will learn later. Used well, namespaces are how one cluster cleanly serves many apps and teams without everything piling into one crowded space.