Namespaces in Kubernetes | K8s Series By M. Sharma (On-Demand) Part 2

In this second part of K8s-Series, I’ll explain the concept of Namespaces and when to use multiple namespaces.

Prerequisites: Watch and Read “How to Build Highly Available Kubernetes Cluster on AWS”

Topics to covered in today’s article

• What is a Namespace?
• When to use multiple Namespaces?
• How to list existing Namespaces?
• How to create a new Namespace?
• How to Delete the Namespace?

So, what is a Namespace?

Before we jump into Kubernetes world. Let’s talk in general about namespace.

In a computing world, a namespace is a set of signs (names) that are used to identify and refer to objects of various kinds. A namespace ensures that all of a given set of objects have unique names so that they can be easily identified.

For example-

1. In the file systems when we assign names to the files.
2. In computer networks and distributed systems when we assign names to resources such as Printers, Computers, Websites, or even remote files.
3. In Operating System, when we partition kernel resources by namespaces so that we can support virtualization containers.

Similarly, in any hierarchical file system, we organize files inside directories, where each directory is a separate namespace so that we can contain the same files (for example sample_text.txt file) in different directories such as sample_work and past_work directory.

More insights:

In computer programming, namespaces are typically employed for the purpose of grouping symbols and identifiers around a particular functionality and to avoid name collisions between multiple identifiers that share the same name.

In networking, the Domain Name System organizes websites (and other resources) into hierarchical namespaces.

A namespace is a namespace consists of namespace identifier and a local name. The namespace name is usually applied as a prefix to the local name.

name = <namespace identifier> separator <local name>

Namespace: Kubernetes supports multiple virtual clusters backed by the same physical cluster. These virtual clusters are called namespaces.

Figure1: Displaying namespaces inside the Control Plane

Figure2: Kubectl command for displaying namespaces only

Kubernetes starts with four initial namespaces:

• default The default namespace for objects with no other namespace
• kube-system The namespace for objects created by the Kubernetes system
• kube-public This namespace is created automatically and is readable by all users (including those not authenticated). This namespace is mostly reserved for cluster usage, in case that some resources should be visible and readable publicly throughout the whole cluster. The public aspect of this namespace is only a convention, not a requirement.
• kube-node-lease This namespace for the lease objects associated with each node improves the performance of the node heartbeats as the cluster scales

When to use multiple Namespaces?

In simple answers, it depends upon the multiple teams which spread across multiple users or projects. According to K8s documentation, for clusters with a few to tens of users, you should not need to create or think about namespaces at all. Start using namespaces when you need the features they provide. Namespaces are a way to divide cluster resources between multiple users via resource quota. (https://kubernetes.io/docs/concepts/policy/resource-quotas/)

• It is not necessary to use multiple namespaces to separate slightly different resources, such as different versions of the same software: use labels to distinguish resources within the same namespace.

Detailed information about namespace

kubectl describe namespaces <name>

*Note that these details show both resource quota (if present) as well as resource limit ranges.

How to create a new Namespace?

There are two simple ways to create the namespace

1. Creating the yaml file

apiVersion: v1
kind: Namespace
metadata:
  name: <insert-namespace-name-here> 

Then run:

kubectl create -f ./my-namespace.yaml

Figure3: Creating a namespace

2. Running the Kubectl command

kubectl create namespace <insert-namespace-name-here>

Figure4: Kubectl command to create a new namespace

*Note: Avoid creating namespace with prefix kube-, since it is reserved for Kubernetes system namespaces.

How to delete a namespace?

Delete a namespace with

kubectl delete namespaces <insert-some-namespace-name>

Warning: This deletes everything under the namespace!

This delete is asynchronous, so for a time you will see the namespace in the Terminating state.

Use Case Scenario: Subdividing your cluster using Kubernetes namespaces

1. Understand the default namespace

By default, a Kubernetes cluster will instantiate a default namespace when provisioning the cluster to hold the default set of Pods, Services, and Deployments used by the cluster.

2. Create new namespaces

For this exercise, we will create two additional Kubernetes namespaces to hold our content.

In a scenario where an organization is using a shared Kubernetes cluster for development and production use cases:

Let’s create two new namespaces to hold our work.

Create the development namespace using kubectl:

kubectl create -f https://k8s.io/examples/admin/namespace-dev.json

And then let’s create the production namespace using kubectl:

kubectl create -f https://k8s.io/examples/admin/namespace-prod.json

To be sure things are right, list all of the namespaces in our cluster.

kubectl get namespaces --show-labels

Figure5: Displaying the namespaces with labels

3. Create pods in each namespace

A Kubernetes namespace provides the scope for Pods, Services, and Deployments in the cluster.

Users interacting with one namespace do not see the content in another namespace.

To demonstrate this, let’s spin up a simple Deployment and Pods in the development namespace.

Figure6: Displaying the pods for development namespace

And this is great, developers are able to do what they want, and they do not have to worry about affecting content in the production namespace.

Let’s switch to the production namespace and show how resources in one namespace are hidden from the other.

The production namespace should be empty, and the following commands should return nothing.

kubectl get deployment -n=production
kubectl get pods -n=production

Production likes to run cattle, so let’s create some cattle pods.

kubectl create deployment cattle --image=k8s.gcr.io/serve_hostname -n=production
kubectl scale deployment cattle --replicas=5 -n=production

kubectl get deployment -n=production
kubectl get pods -l app=cattle -n=production

Figure7: Displaying the pods for production namespace

At this point, it should be clear that the resources users create in one namespace are hidden from the other namespace.

As the policy support in Kubernetes evolves, we will extend this scenario to show how you can provide different authorization rules for each namespace

Hope you find this article useful. If yes, do share it with others. For the latest updates connect with me on -

LinkedIn | Twitter | GitHub |Facebook | Instagram | YouTube

👋 Join FAUN today and receive similar stories each week in your inbox! ️ Get your weekly dose of the must-read tech stories, news, and tutorials.

Follow us on Twitter 🐦 and Facebook 👥 and Instagram 📷 and join our Facebook and Linkedin Groups 💬

If this post was helpful, please click the clap 👏 button below a few times to show your support for the author! ⬇