Kubernetes NameSpace: Complete Guide.

In Kubernetes, Namespaces are used to organize resources. You can have multiple Namespaces in a Cluster And these Namespaces are kind of virtual Clusters of their own. The official definition of Namespace says “In Kubernetes, namespaces provide a mechanism for isolating groups of resources within a single cluster”. Within a Kubernetes Namespace, resources must have unique names, but across different Namespaces, you can have resources with the same name.

In this article, we will learn everything about Kubernetes Namespaces – from its definition and types to a tutorial that will give you practical knowledge of the topic. But before that let’s start from the basics.

What is a Namespace?

In Kubernetes, Namespaces are used to organize resources. You can have multiple Namespaces in a Cluster And these Namespaces are kind of virtual Clusters of their own.

The official definition of Namespace says “In Kubernetes, namespaces provide a mechanism for isolating groups of resources within a single cluster”. Within a Kubernetes Namespace, resources must have unique names, but across different Namespaces, you can have resources with the same name. When you create a Kubernetes cluster, by default Kubernetes gives you 4 Namespaces out of the box:

1. default
2. kube-node-lease
3. kube-public
4. kube-system

Default Namespaces

Default Namespaces are the four Namespaces that are present by default in any Kubernetes Cluster. To see these in your Namespaces you can simply enter this command:

kubectl get namespaces

And you will see that we have 4 default namespaces:

Before learning about the 4 default Namespaces, let’s first briefly discuss kubernetes dashboard namespace, which is a Namespace that comes built-in with Minikube.

kubernetes dashboard namespace:

“kubernetes dashboard namespace” is shipped automatically in Minikube. So it is specific to Minikube installation. We will not have this namespace in a standard Cluster.

1. kube-system

kube-system is the namespace that includes objects created by the Kubernetes system. The components that are deployed in this Namespace are the system processes – they are from Master managing processes or Kubectl etc. kube-system Namespace is not meant for our (developer’s) use. so we do not have to create anything or modify anything in this namespace.

2. kube-public

kube-public contains the publicly accessible data. It has a config map that contains the Cluster information which is accessible even without authentication.

you can simply type:

kubectl cluster-info

You will get the data stored in kube-public namespace.

3. kube-node-lease

kube-node-lease Namespace is a new addition to Kubernetes. The purpose of this namespace is that it holds information about the heartbeats of Nodes. So each Node basically gets its own lease object in the Namespace. This object contains the information about that nodes availability.

4. default

default Namespace is the Namespace that we use in order to create the resources when we create a Namespace in the beginning.

Creating Namespaces

We can create a Namespace in two ways:

1. CLI Commands

Namespaces can be added to your Cluster by CLI commands. You can simply enter the following command to create a new Namespace:

kubectl create namespace my-ns

This will create a new Namespace called “my-ns”. And we can simply checkout our namespaces by the following command:

kubectl get namespaces

We can see that the “my-ns” Namespace was created.

2. Configuration file

Another better way to create a Namespace is creating a Namespaces configuration file. You can call it a better way of creating Namespaces because you have a history in your Configuration File Repository of what resources you created in the Cluster. Here is how a sample Namespace configuration file would appear to be:

apiVersion: v1
kind: Namespace
metadata:
  name: development
  labels:
    name: development

Now you can apply this configuration file using the following command:

kubectl create -f [FILE_NAME]

Benefits of using Namespaces

Now Let’s first discuss what is the need for Namespaces? when should you create them? And how you should use?

1. Structuring Resources in Groups

The biggest use case of creating your own Namespaces this – imagine you have only Default Namespace which is provided by Kubernetes and you create all your resources in that Default Namespace. If you have a complex application that has multiple Deployments, which create replicas of many Pods and you have resources like Services and Config maps etc. very soon your Default Namespace is going to be filled with different components and it will be really difficult to have an overview of what is in happening in the project. specially, when we have multiple users creating stuff inside. So a better way in this case is to group resources into Namespaces. For Example, you can have a database Namespace where you deploy your database and all its required resources and you can have a Monitoring Namespace where you deploy monitoring related stuff.

2. Preventing Conflicts between Multiple Teams

Another use case of having Namespaces is when you have multiple teams. Imagine this scenario where you have two different teams that use the same cluster. One team deploys an application which is called “my-app-deployment” and that deployment has its certain configuration. Now if another team had a Deployment that accidentally had the same name but a different configuration and they created that Deployment or they applied it, they would overwrite the first team’s Deployment. To avoid such kind of conflicts, you can use Namespaces so that each team can work in their own Namespace without disrupting the others.

3. Resource Sharing

Lets say you have one Cluster and you want to host both Staging and Development environment in the same Cluster. and the reason for that is if you’re using Nginx Controller or Elastic Stack for logging, you can deploy it in one Cluster and use it for both environments. In that way you don’t have to deploy these common resources twice in two different clusters. So now the staging can use both resources as well as the development environment.

4. Blue/Green Deployment

Another reason for using Namespaces is when have Blue/Green Deployment for application. Which means that in the same cluster you want to have two different versions of Production – The one that is active, that is in production now and another one that is going to be the next production version. The versions of applications in those blue and green Production Namespaces will be different however these namespaces might need to use the same resources like Nginx Controller or Elastic Stack and this way they can both use this common shared resources without having to set up a separate Cluster.

5. Limiting Access and Resources

One more reason for using Namespaces is to limit the resources and limit the access to namespaces when we are working with multiple teams. Imagine a scenario where we have two teams working in the same cluster and each one of them has their own Namespace so what we can do in this scenario is that we can give the teams access to only their namespace so they can only be able to Create, Update, Delete resources in their own namespace but they can not do anything in the other Namespaces. In this way we even restrict or even minimize the risk of one team accidentally interfering with another team’s work. Each one has their own secured isolated environment. Additional thing that we can do on a Namespace level is limit the resources that each Namespace consumes because if you have a cluster with limited resources you want to give each team a share of resources for their application so if one team consumes too much resources then other teams would eventually have much less and their applications may not schedule because the cluster will run out of the resources. Using Namespaces what we can do is that per Namespace we can define resource quotas that limit how much CPU, RAM, storage resources one Namespace can use.

Characteristics of Namespaces

There are several characteristics of a Namespaces that one should consider before deciding how to group and how to use Namespaces:

1. You can not access most of the resources from another namespace.

If you have a Config Map in Project A Namespace that references the database service, you can not use that Config Map in Project B Namespace. Instead you will have to create the same Config Map that also references the database service.

Each Namespace must define its own Config method even if it’s the same reference. The same applies to Secret file as well. If we have credentials of a shared Service, we will have to create a Secret in each Namespace where we will need that.

2. Service can be shared across Namespaces

Service is a resource that can be shared across Namespaces. Config Map in Project B Namespace references Service that is going to be used eventually in a Pod and the way it works is that in a Config Map is the database URL in addition to its name will have Namespace at the end so using that URL you can actually access services from other namespaces.

apiVersion: v1
kind: ConfigMap
metadata:
    name: my-configmap
data:
    db_url: my-service.database

3. Volumes and Nodes cannot be created within a Namespace

Most of the resources can be created within the namespace but there are some components in Kubernetes that cannot be “Namespaced”. That is they can only exist globally in the cluster and cannot be isolated or created within a certain Namespace. Such resources are Volumes and Node. So when you create the Volume, it will be accessible throughout the whole cluster because it’s not in a Namespace.

You can get a list of components that are not bound to a namespace by using the command:

kubectl api-resources --namespaced=false

And also get the list of components that are bound to a namespace by:

kubectl api-resources --namespaced=true

Tutorial – Creating Components in the default Namespace

By default if you do not provide a Namespace to a component, then it creates them in a default namespace. So if we apply this config map component:

apiVersion: v1
kind: ConfigMap
metadata:
    name: my-configmap
data:
    db_url: my-service.database

If we apply this Config Map file:

kubectl apply -f my-config-map.yaml

And check the namespace it belongs to by this command, actually this command will list down all the Config Maps within the Namespace default:

kubectl get configmap -n default

And we can find our my-configmap in the list.

Or you can also check it by getting details about my-configmap using the following command:

 kubectl get configmap -n default -o yaml

You will get a long output which will include these lines:

And here we can see the namespace to be default.

Tutorial – Creating Components in a new Namespace

There are two ways of creating components, we can either do it in the CLI or we configure it in the Configuration file itself:

1. Specifying Namespace in the CLI

This can be done by specifying the name of the Namespace while applying the Config Map:

kubectl apply -f my-config-map.yaml --namespace=my-

Note that we have already created my-ns in the previous sections. Otherwise it would give us an error.

2. Specifying Namespace in the Configuration file

We can simply specify which namespace we want the component to be a part of it’s configuration file. For that we can simply take our my-configuration.yaml file and edit it. We are simply adding the line “namespace: my-ns”

apiVersion: v1
kind: ConfigMap
metadata:
    name: my-configmap
    namespace: my-ns
data:
    db_url: my-service.database

Now if we apply it:

kubectl apply -f my-config-map.yaml

and if we check out our Config Map:

 kubectl get configmap -n my-ns -o yaml

We will get that same long output, but this would also include a line which says that the Namespace is now my-ns.

Changing the Active Namespace

The default namespace is our active namespace. In order to change the active namespace to any other namespace we can use kubens from kubectx. For that we will have to download kubectx by entering the following command

 sudo snap install kubectx --classic

now if we enter the command

kubens

we will get the list of namespaces present and the active namespace will be highlighted in green:

and then simply use kubens for changing the active namespace.

kubens my-ns

Now the active namespace has been changed to kubens. This means that by default if we do not specify the namespace the components will be created in the my-ns namespace.

Conclusion

Kubernetes Namespaces are a way to group resources in a Kubernetes Cluster. In this article, we discussed how Namespaces work, What are the default Namespaces present already in a Kubernetes Cluster. From need of Namespaces to it’s characteristics, we discussed everything. Do follow the tutorial and try creating resources in a Namespace by your own because that’s the best way to learn. Make sure to learn more about kubectx and its features.

We hope that this article helped you improve your understanding about Namespaces and you learned something valuable out of it.

Kubernetes Namespaces – FAQ’s

1. What is a namespace in Kubernetes?

In Kubernetes, Namespaces are a way of organizing our resources.

2. What is default Namespaces

In Kubernetes, default is a build-it namespace that is also the active namespace by default.

3. How do I create a Kubernetes namespace?

You can create a Namespace in Kubernetes by entering the following command:

kubectl create namespace [NAME]

4. What is the purpose of a namespace?

Purpose of Namespaces is to group resources of a Kubernetes Cluster in order to manage them in efficient manner.

5. How many build-in namespaces do a Kubernetes Cluster have?

We have 4 build-in namespaces in a Kubernetes Cluster – kube-system, kube-public, kube-node-lease and default.