98 Exploring The Existing Namespaces
98 Exploring The Existing Namespaces
In this lesson, we will explore and discuss brie y about the existing Namespaces.
Now that we know that our cluster has multiple Namespaces, let’s explore
them a bit.
kubectl get ns
We can see that three Namespaces were set up automatically when we created
the Minikube cluster.
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 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.
Almost all the objects and resources Kubernetes needs are running
inside kube-system Namespace.
We retrieved all the objects and resources running inside the kube-system
Namespace. The output is as follows.
replicaset.apps/coredns-fb8b8dccf 2 2 2 4h32m
replicaset.apps/default-http-backend-6864bbb7db 1 1 1 4h32m
replicaset.apps/kubernetes-dashboard-79dd6bfc48 1 1 1 4h32m
replicaset.apps/nginx-ingress-controller-586cdc477c 1 1 1 4h32m
As we can see, quite a few things are running inside the kube-system
Namespace. For example, we knew that there is an nginx Ingress controller,
but this is the first time we saw its objects. It consists of a Replication
Controller nginx-ingress-controller , and the Pod it created, nginx-ingress-
controller-fxrhn .
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.