Kubernetes NameSpace

• You can think of a Namespace as a virtual cluster inside your Kubernetes cluster.
• Kubernetes namespace allows you logically organize your resources into groups.
• You can have multiple namespaces inside a single Kubernetes cluster, and they are all logically isolated from each other.
• The objects part of this namespace will be part of no other namespaces.

Why do you need namespaces?

• When we have a large set of Kubernetes resources running on our cluster Kubernetes namespaces helps in organizing them and allows you to group them together based on the nature of the project.
• By doing so you have more control over them and can effectively manage them by using unit filters.
• This will also allow the teams or projects to exist in their own virtual clusters without fear of impacting each other’s work
• For example, you can have separate namespaces created for different environments such as development, staging, production, etc. for a project or an application.

4 different default NameSpace

• When you provision a Kubernetes cluster it will create a different namespace to hold the default set of Pods, Services, and Deployments used by the cluster.
• By default, Kubernetes provides four namespaces.

kube-system:

• kube-system is the namespace for objects created by the Kubernetes system.
• We should avoid putting anything personal in that namespace.
• It would contain pods like kube-dns, kube-proxy, kube-API, and others controllers.
• We can check resources under the kube-system namespace.

kube-public:

• Used for public resources and readable by all users (including those not authenticated).
• This namespace is mostly reserved for cluster usage not recommended for other Kubernetes users.
• It contains the configmap that has cluster information.
• We can check the configmap by running the following command.

kube-node-lease:

• This namespace holds the heartbeats of nodes and each node is associated to lease object in the namespace.
• Node leases allow the kubelet to send heartbeats so that the control plane can detect node failure.
• It determines node availability.

default:

• The default namespace is the namespace where your resources are created in the beginning if you do not specify any namespace while creating your cluster.
• The objects part of this namespace will be part of no other namespaces.

Scenario, when to use namespace?

Team NameSpace

• Namespaces are to assign different teams with their own namespace.
• This lets each team manage their own application without interfering with the work of other teams.
• Team A can't access any resource for Team B, Team C, and this will avoid conflict or override between the resources.
• Cluster admin can limit the authority of the Team A user only to access the Team-A-namespace, Team-B user to Team-B-namespace only, and Team-C user to Team-C namespace only.

Different Environment

• Another scenario would be that you want to create a different environment for your application, development, staging, and production env.
• we may do coding, testing, and deployment in dev env and this will not impact stable env such as staging and prod.

Logically breakdown the application

• If you have all your resources in the default namespace, it will very difficult to manage all the different versions of the different components.
• It is better to logically group the resource into different namespaces.
• We can logically group different components into different namespace as the database contain all the resources related to databases, Redis rabbitMQ, etc.
• monitoring will contain all the resources like Prometheus, grafana, etc, application-service will contain the different services, etc.

Also, check

Kubernetes Tutorials