- 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.
