By Alwyn Botha, Alibaba Cloud Tech Share Author. Tech Share is Alibaba Cloud’s incentive program to encourage the sharing of technical knowledge and best practices within the cloud community.

Kubernetes namespaces are used to keep the work of different teams or projects separate. For example if you work in a company with 50+ other developers in 5 different teams, you do not want to see all the Kubernetes resources created by all those people all the time.

You want to see only the resources in your team — much shorter list of Pods, Deployments, and around 25 other Kubernetes resources. By the same logic you may want to set up your own mini environment where you see only the Kubernetes resources you work with. All the above can be done using Kubernetes namespaces.

Namespaces are easy to define, and once you switch to such a namespace all your work is automatically kept in that separate namespace — not visible to others on the same development server.

Minor note: The official documentation inconsistently refers to namespaces with upper or lower case first letter. I did the same throughout this tutorial; globally replacing it with lowercase will give your yaml syntax errors.

Default Kubernetes Namespaces

Get a list of current namespaces:

These three Namespaces are all automatically created during a new Kubernetes install.

Create Two Namespaces

We are now going to create two new namespaces so that we can create Kubernetes objects in it — to see how the separation works.

Create and read YAML file below to see how we create a development Namespace.

Create and read YAML file below to see how we create a tutorials Namespace.

Run kubectl create to create those two Namespaces.

Get detail about just created Namespaces.

Our 2 new objects are listed and ready for use.

Set-Context to Switch between Namespaces

In order to easily switch between Namespaces we use the concept of switching context.

Switching between Namespaces directly would have been quite straightforward to understand, but as it is Kubernetes decided to implement switching Namespaces only via switching contexts .

Let’s investigate our current context:

Only one context available: minikube.

To see the current context we are working in, use:

Let’s create contexts for our 2 Namespaces : development and tutorials.

To keep it simple the name of the context is equal to the Namespace name.

Let’s view config again:

Easily readable we can see our contexts pointing to the correct Namespaces.

To get the current context, use:

minikube is the default context. If you are not following these tutorials on a minikube installation your default context will probably have a different name.

Not a problem; the context your are in now is your default context.

Let’s create a Pod in this context to see how it is kept separate / hidden from other contexts.

IMPORTANT : Note that nowhere in that YAML spec do we specify a Namespace to create this Pod in.

Kubernetes objects are automatically created in the current context.

Create the Pod.

List all available / visible Pods:

Create Pod in Development Namespace

Let’s switch context to development and create a Pod there.

Create YAML file for the Pod.

Create the Pod.

List all available / visible Pods:

Only this one Pod that I created in this Namespace is listed.

my-minikube-pod in default minikube Namespace / context not visible and not listed.

Create Pod in Tutorials Namespace

For experience let us create one Pod in our last context : tutorials .

Let’s switch context to tutorials and create a Pod there.

YAML source spec for our Pod.

Create the Pod.

List all available / visible Pods:

Only this one Pod that I created in this Namespace is listed.

my-minikube-pod and my-development-pod in other 2 Namespaces / contexts not visible and not listed.

Using Namespaces

To separate your Kubernetes resources just switch context and do your work there. Objects automatically created in your current context.

Let’s quickly investigate the resources visible in our Namespaces.

Each context only shows its single Pod.

Kubectl api-resources in Namespaces

Not all Kubernetes resources are in a Namespace.

Get a list of Kubernetes API resources in a Namespace:

Expected output :

Get a list of Kubernetes API resources not in a Namespace:

Expected output :

Quick comments about some resources NOT in a Namespace :

  • nodes / servers running Kubernetes — must be visible in all Namespaces
  • Namespaces itself must be visible in all Namespaces — otherwise switching would be impossible
  • PersistentVolumes must be visible everywhere
  • same for the full list of other resources NOT in a Namespaces

We have seen throughout this tutorial that Pods ARE created in Namespaces.

Switch between the Namespaces and you will see the 2 commands below show the full list of nodes and Namespaces.

Namespaces Are Not a Secure Feature

As you have just seen I can easily create contexts and use it to switch Namespaces.

Also, Namespaces names are by default visible to everyone.

There is built-in functionality to show all resources while in ANY Namespace:

It is called adding the — all-namespaces=true flag.

That list is a bit messy, let us exclude kube-system Pods.

All Pods created in this tutorial show — across 3 Namespaces.

Out of the box Namespaces are a convenience feature.

You have to use the Kubernetes Authorization Plugin to properly secure each Namespaces in isolation.

Kubernetes Authorization Plugins controls not just Namespaces. It also enables fine-grained-access control for specific containers, other Kubernetes objects and general Kubernetes administrator operations.

Clean Up

Our previous command showed we have 3 Pods running.

Let us now delete it.

Note each delete command will take 30 seconds since I did not force delete it immediately using — force — grace-period=0 on the delete command.

Important : switch to default context: minikube

Otherwise you will delete the context you are currently switched to:


Follow me to keep abreast with the latest technology news, industry insights, and developer trends.