What are Namespaces in Kubernetes and when should you use them?

Think of Namespaces like floors in an office building. Each floor houses a different department — engineering, marketing, finance. Each floor has its own conference rooms (resources) that can share the same names without conflict (Room A on floor 3 is different from Room A on floor 5). The building security (RBAC) can give each department access only to their floor. And the building manager can set limits on how much electricity (CPU) and water (memory) each floor can use.

In Kubernetes, a Namespace is a logical partition of the cluster. Resources like Pods, Services, Deployments, and ConfigMaps are 'namespaced' — they live inside a Namespace, and their names only need to be unique within that Namespace. You can have a Service called 'payments-api' in the 'staging' namespace AND a different Service called 'payments-api' in the 'production' namespace without conflict. Each Namespace is completely isolated from the other in terms of naming.

Kubernetes creates four Namespaces by default: 'default' (where resources go if you don't specify a namespace), 'kube-system' (for Kubernetes system components like CoreDNS, kube-proxy, and the metrics server), 'kube-public' (readable by all users, used for cluster discovery), and 'kube-node-lease' (holds Lease objects for node heartbeat efficiency). In production, you should never deploy your applications into 'default' or 'kube-system'.

Namespaces become powerful when combined with other Kubernetes features. ResourceQuotas let you limit the total CPU, memory, and number of objects a Namespace can consume — so one team can't monopolize the cluster. LimitRanges set default and maximum resource requests per Pod. RBAC policies can restrict users to specific Namespaces — a developer might have full access to 'staging' but read-only access to 'production'. NetworkPolicies can restrict traffic between Namespaces, creating network isolation.

A common misconception is that Namespaces provide security isolation. They don't — at least not by themselves. A Pod in one Namespace can freely communicate with a Pod in another Namespace over the network (via the full DNS name: service-name.namespace.svc.cluster.local) unless you explicitly create NetworkPolicies to block it. Namespaces are a soft boundary for organization, not a hard boundary for security. For true multi-tenant isolation, you need Namespaces plus NetworkPolicies plus RBAC plus resource quotas working together.