Loading...
Kubernetes' way of dividing one cluster into named, governable territories.
Quick Definition
A Kubernetes namespace is a virtual partition within a cluster used to organize and isolate groups of resources. Namespaces support multi-tenancy, access control, and resource quotas, and they are a primary dimension for allocating Kubernetes costs to teams or environments.
A namespace is a logical partition inside a Kubernetes cluster. Workloads, configuration, and permissions live inside a namespace, so one physical cluster can host many teams or environments side by side, each in its own named space with its own rules.
Namespaces are the natural unit for governance on shared clusters. Access control is scoped per namespace, so teams administer their own space and nothing else. Resource quotas cap how much CPU and memory each namespace may claim, preventing one team from starving the rest. And because every workload belongs to exactly one namespace, they are the most reliable handle for cost allocation.
Example. A platform team gives each product team a namespace with a quota, an admin role, and a cost report. The monthly cluster bill splits cleanly by namespace, and the noisy-neighbor incidents that plagued the old free-for-all cluster stop.
A namespace-per-team or per-service convention, set early, saves enormous cleanup later. The node vs pod vs cluster explainer places namespaces in the bigger picture, and the Kubernetes Cost Management Guide covers quota and allocation design.
Per team or per service, often combined with environment, such as payments-prod. Consistency matters more than the exact scheme
They isolate logically, not at the kernel level. Strong isolation needs network policies and, for hostile tenants, separate clusters.
Indirectly and effectively: resource quotas cap the compute a namespace can claim, which caps the share of node cost it can drive.