What is a Namespace, and when should you use multiple namespaces?
Quick Answer
A Namespace is a way to logically partition a single Kubernetes cluster into multiple virtual clusters, scoping most object names, RBAC rules, and resource quotas within it. Use multiple namespaces to separate environments (dev/staging/prod, though many teams instead use separate clusters for this), separate teams/applications sharing one cluster, or to apply different access controls and resource limits to different parts of the same cluster.
Detailed Answer
What a Namespace actually scopes
kubectl get pods -n team-a # only pods in the "team-a" namespace
kubectl get pods -n team-b # only pods in the "team-b" namespace, even if named identically
Object names must be unique within a namespace, but the same name can be reused across different namespaces — team-a and team-b can each have a Deployment named web without conflict. Namespaces are also the scope boundary for RBAC Role bindings (see the security topic) and ResourceQuotas/LimitRanges (see the production operations topic) — a Role granted in one namespace has no effect in another unless explicitly bound there too.
What's NOT namespaced
Some objects are cluster-wide by design and don't belong to any namespace — Nodes, PersistentVolumes (though PersistentVolumeClaims are namespaced), ClusterRoles/ClusterRoleBindings, and CustomResourceDefinitions themselves. This distinction matters when writing RBAC rules or troubleshooting "why can't my namespaced Role see this object" — the object might simply be a cluster-scoped kind that a namespace-scoped Role was never going to be able to grant access to.
Common uses for multiple namespaces
- Team/application separation on a shared cluster —
team-a,team-b,payments,search, each with its own RBAC rules and ResourceQuotas, letting multiple teams safely share one cluster's underlying infrastructure without stepping on each other. - Environment separation —
dev,stagingon a shared non-production cluster (though production is very commonly kept on an entirely separate cluster, not just a separate namespace, for a stronger blast-radius boundary — see the multi-tenancy question). - Third-party/system components — many clusters keep cluster infrastructure (monitoring, ingress controllers, cert-manager) in dedicated namespaces (often prefixed
kube-system-adjacent, or a customplatformnamespace) separate from application workloads, so application-team RBAC doesn't accidentally reach infrastructure components.
The default namespace and its pitfalls
Every object created without an explicit namespace lands in default — fine for quick experimentation, but a real risk in production: it's easy to accidentally deploy to, or accidentally query, the wrong namespace when relying on an implicit default rather than always being explicit. Most teams enforce always specifying -n <namespace> (or setting a non-default namespace as the active context) as a basic operational discipline once a cluster is shared by more than one person or team.
What Namespaces don't provide
A Namespace is a logical, not a hard security, boundary — by default, Pods in different namespaces can still reach each other over the network unless NetworkPolicies explicitly restrict it (see the networking topic), and a sufficiently-privileged ServiceAccount or user can act across namespace boundaries. For workloads needing genuinely strong isolation (fully untrusted multi-tenant code, strict compliance separation), namespaces alone are usually not considered sufficient — see the multi-tenancy question for what additional mechanisms are typically layered on top.