Namespace

A namespace divides a single cluster into named scopes. It is an organisational and policy boundary, not a hard security boundary.

How it works

Resource names must be unique within a namespace but not across namespaces. Each namespaced object belongs to exactly one namespace, and namespaces cannot be nested. Some objects are cluster-wide and not namespaced, including Nodes, PersistentVolumes and StorageClasses. kubectl api-resources --namespaced=true lists those that are.

A cluster starts with default, kube-system, kube-public and kube-node-lease. The documentation recommends not using default in production, and avoiding the kube- prefix for your own namespaces.

Namespaces are the attachment point for several controls: ResourceQuotas cap aggregate consumption, LimitRanges set defaults, RBAC roles can be granted per namespace, and network policies are namespaced. A Service is reachable inside its namespace by short name, and from other namespaces as <service>.<namespace>.svc.cluster.local. Since Kubernetes v1.22 each namespace carries the label kubernetes.io/metadata.name.

A practical example

kubectl create namespace team-payments
kubectl run nginx --image=nginx --namespace=team-payments
kubectl config set-context --current --namespace=team-payments

The last command makes later kubectl calls default to that namespace, which reduces accidental changes elsewhere.

Common mistakes

• Assuming namespaces isolate network traffic. Without policies, pods can still talk across namespaces.
• Creating namespaces with no quotas, so one team can consume most of the cluster.
• Using namespaces to separate versions of the same software. The documentation suggests labels for that.
• Naming namespaces after public top-level domains, which can interfere with DNS lookups.
• Granting cluster-wide roles where namespace-scoped ones would do.

When to use it and when not to

Namespaces suit clusters shared by several teams, projects or environments, where you want separate quotas and access. A small cluster with few users may not need many. Environments with strict isolation needs, such as production versus development with different compliance requirements, are often better served by separate clusters. For untrusted tenants, namespaces alone are not enough. The Kubernetes consulting page covers broader cluster design.

See also

• RBAC
• Kubernetes
• Resource Requests and Limits
• Network Policy