What is a Namespace, and when should you use multiple namespaces?
Quick Answer
A Namespace logically partitions 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), to 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 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. This lets multiple teams safely share one cluster's underlying infrastructure without stepping on each other. - Environment separation —
dev,stagingon a shared non-production cluster. 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. That way 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. That's fine for quick experimentation, but a real risk in production — it's easy to accidentally deploy to, or 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 usually aren't enough. See the multi-tenancy question for what additional mechanisms are typically layered on top.