Namespaces are a way to organize clusters into virtual sub-clusters — they can be helpful when different teams or projects share a Kubernetes cluster. Any number of namespaces are supported within a cluster, each logically separated from others but with the ability to communicate with each other. Namespaces cannot be nested within each other.
Any resource that exists within Kubernetes exists either in the default namespace or a namespace that is created by the cluster operator. Only nodes and persistent storage volumes exist outside of the namespace; these low-level resources are always visible to every namespace in the cluster.
Kubernetes comes with three namespaces out-of-the-box. They are:
- default: As its name implies, this is the namespace that is referenced by default for every Kubernetes command, and where every Kubernetes resource is located by default. Until new namespaces are created, the entire cluster resides in ‘default’.
- kube-system: Used for Kubernetes components and should be avoided.
- kube-public: Used for public resources. Not recommended for use by users.
There are many use cases for Kubernetes namespaces, including:
- Allowing teams or projects to exist in their own virtual clusters without fear of impacting each other’s work.
- Enhancing role-based access controls (RBAC) by limiting users and processes to certain namespaces.
- Enabling the dividing of a cluster’s resources between multiple teams and users via resource quotas.
- Providing an easy method of separating development, testing, and deployment of containerized applications enabling the entire lifecycle to take place on the same cluster.
Small teams or smaller organizations may be perfectly content using the default namespace. This is particularly relevant if there is no need to isolate developers or users from each other. However, there are many useful benefits to having multiple namespaces, including:
- Isolation. Large or growing teams can use namespaces to isolate their projects and microservices from each other. Teams can re-use the same resource names in different workspaces without a problem. Also, taking an action on items in one workspace never affects other workspaces.
- Organization. Organizations that use a single cluster for development, testing, and production can use namespaces to sandbox dev and test environments. This ensures production code is not affected by changes that developers or testers make in their own namespaces throughout the application lifecycle.
- Permissions. Namespaces enable the use of Kubernetes RBAC, so teams can define roles that group lists of permissions or abilities under a single name. This can ensure that only authorized users have access to resources in a given namespace.
- Resource Control. Policy-driven resource limits can be set on namespaces by defining resource quotas for CPU or memory utilization. This can ensure that every project or namespace has the resources it needs to run, and that no one namespace is hogging all available resources.
- Performance. Using namespaces can help improve performance of a given cluster. If a cluster is separated into multiple namespaces for different projects, the Kubernetes API will have fewer items to search when performing operations. This can reduce latency and speed overall application performance for each application running on the cluster.
How can pods communicate across Kubernetes namespaces?
Although namespaces are separate from each other, they can easily communicate with each other. Kubernetes DNS service directory can easily locate any service by its name by using the expanded form of DNS addressing:
Simply adding the namespace name to the service name provides access to services in any namespace on the cluster. For example, to access the payroll service in the development namespace you would use the address
To access the payroll service in the production namespace you would use:
Note that network policies can optionally be utilized to control access between namespaces. For example, a network policy can allow or deny all traffic from other namespaces. Network polices apply only to connections and are not a substitute for firewalls that perform packet inspection.
What is the command to find current Kubernetes namespaces?
All namespaces in the cluster can be displayed with the command:
kubectl get namespace
This will return a list of all namespaces in the cluster, including the default namespaces, along with their status and age.
What is the command to create a new Kubernetes namespace?
Namespaces are created simply with the command:
kubectl create namespace
As with any other Kubernetes resource, a YAML file can also be created and applied to create a namespace:
name: newspacekubectl apply -f newspace.yaml
How do you switch between Kubernetes namespaces?
To address namespaces once they are created, actions must include the –namepsace= option in the command. Since this can get cumbersome, the default namespace can be changed by using the kubectl config command to set the namespace in the cluster context.
For example, to change from the default namespace to one named ‘testing’ you would enter:
kubectl config set-context --current --namespace=testing
This will set the default namespace to ‘testing’ for all future kubectl commands.
How do you rename a Kubernetes namespace?
It is not standard practice to rename a Kubernetes namespace, so choose namespaces (outside of the default) carefully.
How do you delete a Kubernetes namespace?
Namespaces are deleted with the command:
kubectl delete namespaces
Since the deletion is an asynchronous activity, the namespace will show as ‘terminating’ until the namespace is deleted.
A warning about deleting Kubernetes namespaces
Deleting a namespace is a final act. Everything in the namespace including all services, running pods, and artifacts will be deleted. Garbage collection will run on anything that had existed in that namespace. Be certain everything in the namespace should be deleted before taking this action.