Categories
DevOps Orchestration

Kubernetes Namespaces Explained

You have probably heard of Kubernetes namespaces. But what are they for? What purpose do they serve? How to use them correctly? Keep reading to find out.

Table Of Contents
  1. Introduction
  2. Demo Prerequisites
  3. Kubernetes Namespaces
  4. Summary

Introduction

I assume you already know that Kuberenetes ensures the desired state of apps running inside Kubernetes cluster. It’s important to understand that the state of the apps is the state of Kubernetes API objects. There are a lot of them. For example, Pods, Services, Deployments, etc.. To see all supported API objects in your Kubernetes cluster run kubectl api-resources. That’s quite a lot. There should be ways to manage, group and modify behavior of Kubernetes objects by marking them somehow. For that purpose, Kubernetes namespaces, labels and annotations exist. We’ll have a look at Kubernetes namespaces in this post. Then, in the next posts I’ll cover labels and annotations. As always, I’ll showcase Kubernetes namespaces using a practical demo. But first, let’s go over demo prerequisites.

Demo Prerequisites

I assume you have Kubernetes cluster. If you don’t, install on your machine minikube and kubectl.

Start Kubernetes cluster using minikube start --profile custom.

Kubernetes Namespaces

To see all created resources run kubectl get all. Do you see all created resources? No, it shows only resources in default namespace. To see all created resources run kubectl get all --all-namespaces.

Why do we need Kubernetes namespaces?

Kubernetes namespaces allow to logically group resources. It’s easy to think about namespaces as virtual Kubernetes clusters where resources may have equal names. Any app comprising multiple resources will most likely have its own dedicated namespace.

Kubernetes namespaces demo

Let’s see basic namespaces CRUD commands.

To see all available namespaces run:

kubectl get ns
NAME              STATUS   AGE
default           Active   45d
kube-node-lease   Active   45d
kube-public       Active   45d
kube-system       Active   45d

So Kubernetes own resources reside in dedicated namespace kube-system. To see its resources run kubectl get all -n kube-system.

Now, let’s create new namespace kubectl create namespace test. Next, let’s create a new pod in that namespace using kubectl run hello-app --image=gcr.io/google-samples/hello-app:1.0 --namespace test.

There’s no problem to create a pod with the same name in a different namespace:

kubectl run hello-app --image=gcr.io/google-samples/hello-app:1.0 --namespace default 
pod/hello-app created

Do you want to remove all app resources? No problem. Just delete the namespace. 

#kubectl delete ns test
namespace "test" deleted

You may have noticed that removing non-empty namespaces takes time. That’s because all namespace resources are deleted along with it.

Note, that kubectl get all --all-namespaces doesn’t show all the created resources. To see the most complete resources list you’d have to use ketall.

Summary

That’s it about Kubernetes namespaces. As always, feel free to share and comment.

Bonus:

Recommended Kubernetes courses on Pluralsight:

Sign up using this link to get exclusive discounts like 50% off your first month or 15% off an annual subscription)

Recommended Kubernetes books on Amazon: