Exploring the Existing Namespaces

Now that we know that our cluster has multiple Namespaces, let’s explore them a bit.

Getting the existing namespaces#

We can list all the Namespaces through the kubectl get namespaces command. As with the most of the other Kubernetes objects and resources, we can also use a shortcut ns instead of the full name.

The output is as follows.

We can see that three Namespaces were set up automatically when we created the cluster.

The default Namespace#

The default Namespace is the one we used all this time. If we do not specify otherwise, all the kubectl commands will operate against the objects in the default Namespace. That’s where our go-demo-2 application is running. Even though we were not aware of its existence, we now know that’s where the objects we created are placed.

There are quite a few ways to specify a Namespace. For now, we’ll use the --namespace argument. It is one of the global options that is available for all kubectl commands.

The kube-public Namespace#

The command that will retrieve all the objects from the kube-public Namespace is as follows.

The output states that No resources were found. That’s disappointing, isn’t it? Kubernetes does not use the kube-public Namespace for its system-level objects. All the objects we created are in the default Namespace.

The kube-public Namespace is readable by all users from all Namespaces.

The primary reason for kube-public's existence is to provide space where we can create objects that should be visible throughout the whole cluster.

A good example is ConfigMaps. When we create one in, let’s say, the default Namespace, it is accessible only by the other objects in the same Namespace. Those residing somewhere else would be oblivious of its existence. If we’d like such a ConfigMap to be visible to all objects no matter where they are, we’d put it into the kube-public Namespace instead. We won’t use this Namespace much (if at all).

The kube-system Namespace#

The kube-system Namespace is critical. Almost all the objects and resources Kubernetes needs are running inside kube-system Namespace.

We can check that by executing the command that follows.

We retrieved all the objects and resources running inside the kube-system Namespace. The output is as follows.

As we can see, quite a few things are running inside the kube-system Namespace.

As long as the system works as expected, there isn’t much need to do anything inside the kube-system Namespace. The real fun starts when we create new Namespaces.

Try it yourself#

A list of all the commands used in the lesson is given below.