Being a container-orchestration system for automating application deployment, Kubernetes is adopted and highly practised by many teams while some prefer to explore it till depths.
So it becomes important for a cluster manager or a cluster admin to split numerous cluster components or objects or resources into smaller distinct groups. It enables smooth management and effective usage of isolated resources without overlapping.
A namespace can be considered as a virtual cluster inside your Kubernetes cluster which are logically isolated from each other.
Each Kubernetes namespace provides a different scope which means that using the combination of an object name and a Namespace, each object gets an unique identity across the cluster.
It helps a lot when multiple teams are using the same cluster and there is a potential of name collision. It can be as a virtual wall between multiple clusters.
To list the namespaces in your cluster you can use the following command.
$ kubectl get namespaces
OR
$ kubectl get ns
By default, a Kubernetes cluster is created with the following three namespaces:
- default: By default all the resource are created in the default namespace. It allow applications to run with unbounded CPU and memory requests/limits.
- kube-public: its a namespace for resources that are publicly readable by all users and is generally reserved for cluster usage.
- kube-system: It is the namespace for objects created by Kubernetes systems/control plane.
You can use either the ad-hoc command or the config file to create a namespace.
//creating namespace with single command
$ kubectl create namespace dev-ns
namespace/dev-ns created
Also you can use the below example to create a namespace
apiVersion: v1
kind: Namespace
metadata:
name: prod-namespace
labels:
team: prod
We will now create a pod in the namespace we just created and for that under the metadata of a resource specify the namespace you wanna use otherwise the default namespace will be used .
apiVersion: v1
kind: Pod
metadata:
name: nginx-pod
namespace: dev-ns
labels:
app: nginx
spec:
containers:
- name: nginx-container
image: nginx
Now lets get the pods and see the output
// as namespace is not specified while getting pods
$ kubectl get pods
No resources found in default namespace.
$ kubectl get pods --namespace dev-ns
NAME READY STATUS RESTARTS AGE
nginx-pod 1/1 Running 0 2m37s
As by default the default namespace is set in the context of the cluster. To view the namespace you are currently using :
$ kubectl config get-contexts
Now to change the default namespace use following command
//changes from default to dev-ns ( created earlier)
$ kubectl config set-context --current --namespace=dev-ns
//to validate the change use this command
kubectl config view --minify | grep namespace:
Namespaces are isolated from each other, but a service in one namespace can talk to a service in another namespace. For example frontend and backend can be managed by different teams and they need to communicate wiith each other. In this case you can use the built-in DNS service discovery provided by Kubernetes and just point your app by its FQDN (fully qualified domain name).
Syntax for it :
<service-name>.<namespace>.svc.cluster.local
You must be wondering how is this possible as namespaces are supposed to provide isolation . But the fact is that namespaces don’t provide any kind of isolation of running objects.
//to delete a specific pod in a namespace
$ kubectl delete pod nginx-pod --namespace dev-ns
//to delete all resources in a namespace
$ kubectl delete all --all --namespace dev-ns
//to delete namespace (pods will be deleted automatically)
$ kubectl delete ns dev-ns
Namespaces are essential objects for dividing and managing Kubernetes clusters which allow us to logically segregate and assign resources to individual users, teams or applications.
By using Namespaces, you can increase resource efficiencies as a single cluster can now be used for a diverse set of workloads.