The Why and How of Kubernetes Namespaces

This article represents concepts related to Kubernetes Namespaces and how to create/delete namespaces. The following topics are discussed in this article:

• What are namespaces?
• How do you create namespaces?
• How do you work with namespaces?
• How do you delete namespaces?

What Are Namespaces?

Kubernetes namespaces can be seen as a logical entity used to represent cluster resources for usage of a particular set of users. This logical entity can also be termed as a virtual cluster. One physical cluster can be represented as a set of multiple such virtual clusters (namespaces). The namespace provides the scope for names. Names of resources within one namespace need to be unique.

By default, Kubernetes starts with the following three namespaces:

• Default: Catch-all namespace for all objects not belonging to either of the kube-public or kube-system namespaces. The default namespace is used to hold the default set of pods, services, and deployments used by the cluster.
• Kube-public: Namespace for resources that are publicly available/readable by all
• Kube-system: Namespace for objects/resources created by Kubernetes systems

The following command can be used to get a list of all namespaces:

kubectl get namespaces

The following command displays namespaces with labels:

kubectl get namespaces --show-labels

The namespaces list can be accessed in the Kubernetes dashboard as shown in the image below:

Figure 1. Kubernetes Namespaces

In real-world scenarios, you can create a namespace for your development (dev), testing (QA), and production (prod) environments. The objects in the dev/QA namespaces such as pods, services, and deployments will be available for developers/testers respectively to build and run applications. There will be lesser restrictions on modifying the resources in the dev/QA namespaces. In the production (prod) namespace, there will be greater control on who can manage the resources.

In this article, we will look into the creation/deletion of namespaces for dev/QA/prod.

How to Create Namespaces

Let’s create namespaces for 0ur development/QA/prod environments. The following would be required to be done:

• Create JSON files representing the namespaces
• Execute the kubectl command for creating namespaces

Create JSON Files Representing Namespaces

Development namespace: Save the filename as namespace-dev.json:

{
    "kind": "Namespace",
    "apiVersion": "v1",
    "metadata": {
        "name": "dev",
        "labels": {
            "name": "dev"
        }
    }
}

QA Namespace: Save the filename as namespace-qa.json:

{
    "kind": "Namespace",
    "apiVersion": "v1",
    "metadata": {
        "name": "qa",
        "labels": {
            "name": "qa"
        }
    }
}

Production Namespace: Save the filename as namespace-prod.json:

{
    "kind": "Namespace",
    "apiVersion": "v1",
    "metadata": {
        "name": "prod",
        "labels": {
            "name": "prod"
        }
    }
}

Execute the kubectl Command for Creating Namespaces

The following commands will create the namespaces for Dev/QA/Prod environments:

# Namespace for Developers
kubectl create -f namespace-dev.json
# Namespace for Testers
kubectl create -f namespace-qa.json
# Namespace for Production
kubectl create -f namespace-prod.json

Check whether the namespaces got created by executing the following command:

kubectl get namespaces --show-labels | grep name=

The following image shows the output of the above command:

Figure 2. kubectl get namespace details

One can also check the details of newly created namespaces by accessing the dashboard:

Figure 3. Kubernetes dashboard displaying newly created namespaces

How to Work With Namespaces

Once the namespaces have been created, in order to have kubectl commands work with a specific namespace, the following needs to be done:

• Assign a context to each namespace
• Switch to the appropriate context for working with that namespace

Assign a Context to Each Namespace

# Assign dev context to development namespace
kubectl config set-context dev --namespace=dev --cluster=minikube --user=minikube
# Assign qa context to QA namespace
kubectl config set-context qa --namespace=qa --cluster=minikube --user=minikube
# Assign prod context to production namespace
kubectl config set-context prod --namespace=prod --cluster=minikube --user=minikube

Switch to the Appropriate Context

Execute the following commands to switch to the specific context. Once switched to a context, any execution of kubectl command would create/update/delete objects in that namespace.

# Switch to Dev context
kubectl config use-context dev
# Switch to QA context
kubectl config use-context qa
# Switch to Prod context
kubectl config use-context prod

Just to check what the current context is, execute the following command:

kubectl config current-context

Once switched to a context, commands such as the following would give object detail for that namespace:

kubectl get pods
kubectl get deployments

How to Delete Namespaces

The commands below would delete the namespaces:

# Delete dev namespace
kubectl delete namespaces dev
# Delete qa namespace
kubectl delete namespaces qa
# Delete prod namespace
kubectl delete namespaces prod

The above commands execute in asynchronous mode. Thus, the status of the namespace would show up as terminating until the deletion is fully completed.