Namespaces: Organizing a Shared Cluster

In one line

A Namespace is a virtual sub-division of a cluster — the standard way to separate teams, environments, or applications sharing the same physical cluster without their resources colliding or interfering.

0/4 · 0%

Think of it like this

Separate, individually-locked floors within one shared office building — everyone's in the same physical building (the cluster), but each floor (namespace) has its own space, its own access rules, and teams on different floors don't trip over each other's stuff by default.

Key ideas

01
A NAMESPACE is a virtual cluster-within-a-cluster — most resource types (pods, Deployments, Services, ConfigMaps, Secrets) belong to exactly one namespace, and by default, resources in DIFFERENT namespaces can't see each other by name (though they CAN still reach each other over the network with the right fully-qualified address, which is different from true network isolation, covered by NetworkPolicy in Phase 3).
02
Every cluster starts with a few built-in namespaces: default (where resources land if you don't specify one — fine for learning, genuinely not recommended for real organized use), kube-system (the cluster's own control-plane-related components, seen directly in Phase 0.2), and kube-public.
03
A genuinely common real convention: one namespace per ENVIRONMENT (dev, staging, production) or one namespace per TEAM/APPLICATION, letting each group manage its own resources, apply its own resource quotas, and be granted access (via RBAC, Phase 5) independently of everyone else sharing the same physical cluster.
04
A Service's SHORT DNS name (my-app-svc, from Topic 1.2) only resolves within its OWN namespace — reaching a Service in a DIFFERENT namespace requires its fully-qualified name, my-app-svc.other-namespace.svc.cluster.local — a genuinely common early confusion point when an application suddenly can't find a dependency after it's moved to a different namespace.
05
kubectl get pods (with no namespace specified) only shows resources in whatever namespace your current CONTEXT defaults to (usually default) — kubectl get pods -n <namespace> targets a specific one explicitly, and kubectl get pods -A (or --all-namespaces) shows everything across every namespace at once, genuinely useful when you're not sure where something actually landed.

Code & diagrams

namespace.yamlmarkdown

A namespace, and a resource explicitly placed inside it.

apiVersion: v1
kind: Namespace
metadata:
  name: staging
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  namespace: staging      # explicitly placed in "staging", not "default"
spec:
  replicas: 2
  selector:
    matchLabels: { app: my-app }
  template:
    metadata:
      labels: { app: my-app }
    spec:
      containers:
        - name: my-app
          image: my-registry/my-app:1.5.0

namespaces.shmarkdown

Targeting, listing across, and cross-namespace addressing.

kubectl apply -f namespace.yaml

# List every namespace in the cluster
kubectl get namespaces

# Target a specific namespace explicitly
kubectl get pods -n staging

# See EVERYTHING, across every namespace, at once
kubectl get pods -A

# Set your kubectl context's DEFAULT namespace, to avoid typing -n every time
kubectl config set-context --current --namespace=staging
kubectl get pods   # now targets "staging" automatically

# Cross-namespace addressing — from a pod in a DIFFERENT namespace than my-app-svc:
# short name (my-app-svc) does NOT resolve — must use the fully-qualified form:
# my-app-svc.staging.svc.cluster.local

Explain it without notes

Why might a Service that's reachable by its short name from one pod suddenly become unreachable by that same short name from a different pod?

Why do most real teams organize a shared cluster into multiple namespaces rather than putting everything in default?

Practice

Create a namespace and a Deployment inside it, then confirm with kubectl get pods (no namespace specified) that it does NOT show up, until you add -n <namespace> or -A.

Set your kubectl context's default namespace to something other than default, confirm it applies automatically, then switch it back.

Trade-offs

↔
Namespaces provide organizational and access-control separation, but they are NOT a strong security boundary on their own — by default, pods in different namespaces can still reach each other over the network freely, so genuine network isolation between namespaces requires explicitly configuring NetworkPolicy (Phase 3), not just placing resources in separate namespaces and assuming that alone isolates them.

Done when you can

I understand what a namespace is and why most real clusters use more than just default.
I can create resources in a specific namespace and list resources across all namespaces.
I know a Service's short name only resolves within its own namespace, and what the fully-qualified alternative looks like.