Skip to content

Namespaces

Assumes: you know what Pods, Deployments and Services are - see Pods and Deployments and Services.

Namespaces provide logical partitioning inside a single cluster.

They are useful for separating teams, environments, and policy boundaries without creating separate clusters for everything.

Built-in Namespaces

Namespace Purpose
default Fallback namespace if none is specified
kube-system Control-plane and system workloads
kube-public Publicly readable metadata use cases
kube-node-lease Lease objects that nodes update each heartbeat cycle; the node controller uses them to detect node failure faster without adding load to etcd

Namespaced vs Cluster-Scoped Resources

Namespaced resources:

  • Pods
  • Deployments
  • Services
  • ConfigMaps
  • Secrets

Cluster-scoped resources:

  • Nodes
  • StorageClasses
  • PersistentVolumes
  • ClusterRoles and ClusterRoleBindings

Check scope quickly:

kubectl api-resources --namespaced=true
kubectl api-resources --namespaced=false

Isolation Boundaries

Namespaces isolate object names and many policies, but they are not a complete security boundary by themselves.

For real multi-tenant separation, combine:

  • Namespaces
  • RBAC (Role-Based Access Control - the system that decides which users and workloads may read or change which objects)
  • NetworkPolicies (rules that restrict which pods may talk to which)
  • ResourceQuota and LimitRange (caps and defaults on CPU, memory and object counts)
  • Pod Security Admission labels (per-namespace limits on what a pod is allowed to do)

Each of those four controls has its own page later in your track - for now you only need to know that a namespace alone does not enforce isolation.

DNS and Cross-Namespace Access

Service discovery works at three levels of specificity:

  • same namespace: http://my-service
  • cross namespace: http://my-service.other-namespace
  • fully qualified: http://my-service.other-namespace.svc.cluster.local

The bare name (my-service) resolves to the pod's own namespace because the pod's DNS search path tries <own-namespace>.svc.cluster.local first. The two-part form (service.namespace) works cross-namespace because the search path also includes svc.cluster.local. Use the fully qualified name in configuration that moves between clusters - it removes any dependency on search-path behavior. DNS and Service Discovery covers the full resolution mechanics.

Cross-namespace traffic is allowed by default unless restricted by NetworkPolicy. Namespaces partition names, not the network.

Resource Governance

Two objects do the enforcement, and both are namespace-scoped: ResourceQuota caps the total a namespace may consume, and LimitRange supplies per-container defaults and ceilings. You will meet both properly in Quotas and LimitRanges; the shapes are here for reference.

Governance objects you will meet later

ResourceQuota - a hard cap on the whole namespace:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-a-quota
  namespace: team-a
spec:
  hard:
    pods: "50"
    requests.cpu: "20"
    requests.memory: 40Gi

LimitRange - defaults applied to every container that does not set its own:

apiVersion: v1
kind: LimitRange
metadata:
  name: default-container-limits
  namespace: team-a
spec:
  limits:
    - type: Container
      default:
        cpu: "500m"
        memory: "512Mi"
      defaultRequest:
        cpu: "100m"
        memory: "128Mi"

Operational Practices

  • Use explicit namespaces in CI/CD (-n or fully-qualified manifests).
  • Use naming conventions (team-a-dev, team-a-prod).
  • Avoid placing application workloads in kube-system.
  • Audit namespace ownership and RBAC regularly.

Namespace deletion is not instant

Deleting a namespace deletes everything in it - and the deletion can hang. A namespace stuck in Terminating almost always means some resource inside it has a finalizer that cannot complete (commonly a custom resource whose operator was already uninstalled). Check with:

kubectl get namespace <name> -o jsonpath='{.status.conditions}'

The conditions name the resource types still blocking deletion. Fix the underlying finalizer rather than force-editing the namespace object.

Certification notes

  • Know how to set the namespace for your kubectl context: kubectl config set-context --current --namespace=<ns>. In timed exams, forgetting -n is a classic way to lose points on otherwise correct answers.
  • kubectl api-resources --namespaced=false answers "is this resource namespaced?" faster than memorizing the list.

Summary

Namespaces are foundational for cluster organization, but policy controls are what make isolation enforceable in production. They partition names and policy scope - not the network, and not the nodes.

Check Yourself

A pod in namespace team-a curls http://api and gets a response from a Service in team-a. What would it get if the only api Service lived in team-b?

An NXDOMAIN. The bare name resolves through the pod's DNS search path, which tries the pod's own namespace first and never reaches team-b. Use api.team-b or the fully qualified api.team-b.svc.cluster.local.

You put dev and prod in separate namespaces. Can a compromised dev pod open a TCP connection to a prod pod?

Yes, by default. Namespaces partition names and policy scope, not the network. Cross-namespace traffic is allowed unless a NetworkPolicy restricts it, and a namespace on its own is not a security boundary.

Why can a namespace sit in Terminating for hours, and what is the correct fix?

Something inside it has a finalizer that cannot complete - classically a custom resource whose operator has already been uninstalled, so nothing is left to run the cleanup. kubectl get namespace <name> -o jsonpath='{.status.conditions}' names the blocking resource types. Fix the finalizer or reinstall the controller; force-editing the namespace object leaves orphaned resources behind.

You ran kubectl get pods and see nothing, but a colleague says the app is running. What is the most likely explanation?

You are looking at a different namespace - almost certainly default, because your context has no namespace set. Add -n <namespace>, or set it once with kubectl config set-context --current --namespace=<ns>.

Next Steps

Beginner track - step 7 of 12. Next: ConfigMaps and Secrets. Back to the track overview.