Namespaces

The Problem Namespaces Solve

A Kubernetes cluster is usually shared by more than one team. Development, QA, and production workloads — plus supporting services like logging, monitoring, and ingress — all end up running on the same physical infrastructure. Without any structure, every Deployment, Service, and Pod lands in the same flat space:

Kubernetes Cluster
├── Frontend (dev)
├── Frontend (qa)
├── Frontend (prod)
├── Backend
├── Redis
├── MySQL
└── ...everything mixed together

With dozens of engineers deploying into that same space, two problems show up immediately:

• No isolation. It's impossible to tell at a glance which Pods belong to dev, which belong to QA, and which are serving production traffic.
• Naming collisions. Kubernetes objects of the same kind must have unique names within the space they live in. If the dev team and the QA team both create a Deployment named frontend, one of them fails.

Namespaces solve this by letting you partition a single cluster into multiple virtual environments.

What Is a Namespace?

A namespace is a logical partition inside a Kubernetes cluster. It doesn't add new physical infrastructure — the same nodes, the same control plane, the same networking fabric are all still shared underneath — but object names, resource quotas, and access controls are scoped to it.

A useful analogy is an apartment building: every resident shares the same building, water, and electricity, but each family lives independently on their own floor. A Kubernetes cluster is the building; each namespace is a floor.

Kubernetes Cluster
│
├── Namespace: development
│     ├── frontend
│     └── backend
│
├── Namespace: qa
│     ├── frontend
│     └── backend
│
└── Namespace: production
      ├── frontend
      └── backend

Everything still runs in the same cluster — it's only logically separated.

Why Namespaces Matter

The clearest illustration is the naming-collision problem from above. Without namespaces, the development team and the QA team can't both have a Deployment called frontend — Kubernetes rejects the second one as a conflict. With namespaces, each team's frontend Deployment lives in its own scope:

development/frontend
qa/frontend
production/frontend

Same name, different namespace, no conflict. This is the core value namespaces provide:

• Organize resources by team or environment
• Avoid naming conflicts between otherwise-identical resources
• Separate environments (dev, QA, staging, production)
• Enable per-namespace resource quotas and access controls (RBAC)

The Default Namespace

Every cluster ships with a namespace called default. Any object you create without specifying a namespace — including everything in the previous lessons of this module — lands there.

kubectl get namespaces

NAME              STATUS   AGE
default           Active   12d
kube-system       Active   12d
kube-public       Active   12d
kube-node-lease   Active   12d

kubectl get ns is the shorthand for the same command.

System Namespaces

Alongside default, every cluster provisions a handful of namespaces reserved for Kubernetes itself:

You can inspect what's actually running in kube-system — it's the same set of control-plane pieces covered in the Kubernetes overview lesson, just visible as ordinary pods:

kubectl get pods -n kube-system

NAME                         READY   STATUS    RESTARTS   AGE
coredns-...                  1/1     Running   0          12d
etcd-...                     1/1     Running   0          12d
kube-apiserver-...           1/1     Running   0          12d
kube-controller-manager-...  1/1     Running   0          12d
kube-proxy-...               1/1     Running   0          12d
kube-scheduler-...           1/1     Running   0          12d

Creating a Namespace

kubectl create namespace development

namespace/development created

kubectl get namespaces
# development now appears in the list

Deploying Into a Namespace

By default, kubectl apply targets whatever namespace your current context is pointed at — normally default:

kubectl apply -f deployment.yaml
# creates the Deployment in "default"

To target a different namespace, pass -n:

kubectl apply -f deployment.yaml -n development

Verify it landed where you expect:

kubectl get deployments -n development   # shows the Deployment
kubectl get deployments                  # empty — it's not in "default"

Same cluster, different namespace — the object simply doesn't exist from the point of view of a namespace it wasn't created in.

Setting the Namespace in YAML

Instead of remembering -n development on every command, you can bake the namespace into the manifest itself:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  namespace: development
spec:
  # ...

Now a plain kubectl apply -f deployment.yaml creates the object inside development automatically, regardless of which namespace your shell context defaults to.

Viewing Resources in a Namespace

The same pattern — append -n <namespace> — works for any kubectl get:

kubectl get pods -n development
kubectl get svc -n development
kubectl get all -n development

Deleting a Namespace

kubectl delete namespace development

This deletes every object inside development — Deployments, ReplicaSets, Pods, Services, ConfigMaps, everything — in one shot. It's a convenient way to tear down an entire environment, but there's no undo: treat kubectl delete namespace with the same caution as rm -rf.

Namespace Isolation

Namespaces isolate object names, not just visually group things. Two identically-named Deployments and Services in different namespaces coexist without any conflict:

development
  Deployment: frontend
  Service:    frontend-service

qa
  Deployment: frontend
  Service:    frontend-service

Kubernetes treats these as entirely separate objects because their fully-qualified identity includes the namespace. kubectl get deployment frontend run against the development namespace has no knowledge of the frontend Deployment sitting in qa.

Communication Across Namespaces

Namespace isolation applies to naming and (optionally) network policy — it does not mean pods in different namespaces are unable to talk to each other. By default, a pod in development can still reach a Service in production, using Kubernetes' built-in Service DNS:

<service-name>.<namespace>.svc.cluster.local

For example, a frontend pod in development reaching a backend Service in production would use:

backend.production.svc.cluster.local

Within the same namespace, the short form (backend) resolves correctly on its own, because CoreDNS searches the pod's own namespace first. Once you're crossing namespace boundaries, the namespace-qualified name is required. Service networking and CoreDNS resolution are covered in full in the next module — for now, the important takeaway is that namespaces are a logical and administrative boundary, not a network wall by default.

Best Practices

• Use namespaces to separate environments (development, QA, staging, production) or teams, and for cross-cutting concerns like monitoring, logging, and ingress.
• Don't create a namespace per application — that fragments the cluster without adding real isolation and makes cross-namespace DNS the common case instead of the exception.
• As a rule of thumb: one namespace per environment or per team, not one per service.

Summary

Kubernetes Cluster
│
├── Namespace: development   → Deployment → ReplicaSet → Pods → Service
└── Namespace: production    → Deployment → ReplicaSet → Pods → Service

Cluster, namespace, deployment, and pods map neatly onto the apartment analogy from earlier: the cluster is the building, a namespace is a floor, a Deployment is a house on that floor, and the Pods are the people living in it. Everyone shares the same building, but each floor operates independently — right up until someone needs to walk to a different floor, which is exactly what namespace-qualified Service DNS is for.

With workloads now organized into namespaces, the next question is how to expose several of them to the outside world through a single entry point — which is what Ingress is for.