Skip to content

Namespaces

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
  • NetworkPolicies
  • ResourceQuota and LimitRange
  • Pod Security Admission labels

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

ResourceQuota example

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

LimitRange example

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.