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:
There are many use cases for Kubernetes namespaces, including:
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:
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:
..svc.cluster.local
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
payroll.development
To access the payroll service in the production namespace you would use:
payroll.production
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.
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.
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:
newspace.yaml:
kind: Namespace
apiVersion: v1
metadata:
name: newspace
labels:
name: newspacekubectl apply -f newspace.yaml
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.
It is not standard practice to rename a Kubernetes namespace, so choose namespaces (outside of the default) carefully.
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.
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.
Streamline operations across multi-cloud infrastructure.
What tools should you choose to succeed with containers?
Once you understand what containers and Kubernetes are, the next step is to learn how the two work together.