In Kubernetes, Kubernetes Namespaces are used to organize resources. You can have multiple Namespaces in a Cluster And these Namespaces are kind of virtual Clusters of their own.
The official definition of Namespace says "In Kubernetes, namespaces provide a mechanism for isolating groups of resources within a single cluster". Within a Kubernetes Namespace, resources must have unique names, but across different Namespaces, you can have resources with the same name.
Benefits of using Namespaces
Now Let's first discuss what is the need for Namespaces? when should you create them? And how you should use?
1. Structuring Resources in Groups
- The biggest use case of creating your own Namespaces this - imagine you have only Default Namespace which is provided by Kubernetes and you create all your resources in that Default Namespace.
- If you have a complex application that has multiple Deployments, which create replicas of many Pods and you have resources like Services and Config maps etc. very soon your Default Namespace is going to be filled with different components and it will be really difficult to have an overview of what is in happening in the project. specially, when we have multiple users creating stuff inside.
- So a better way in this case is to group resources into Namespaces. For Example, you can have a database Namespace where you deploy your database and all its required resources and you can have a Monitoring Namespace where you deploy monitoring related stuff.
2. Preventing Conflicts between Multiple Teams
- Another use case of having Namespaces is when you have multiple teams. Imagine this scenario where you have two different teams that use the same cluster. One team deploys an application which is called "my-app-deployment" and that deployment has its certain configuration.
- Now if another team had a Deployment that accidentally had the same name but a different configuration and they created that Deployment or they applied it, they would overwrite the first team's Deployment.
3. Resource Sharing
- Lets say you have one Cluster and you want to host both Staging and Development environment in the same Cluster. and the reason for that is if you're using Nginx Controller or Elastic Stack for logging, you can deploy it in one Cluster and use it for both environments.
- In that way you don't have to deploy these common resources twice in two different clusters. So now the staging can use both resources as well as the development environment.
4. Blue/Green Deployment
- Another reason for using Namespaces is when have Blue/Green Deployment for application. Which means that in the same cluster you want to have two different versions of Production - The one that is active, that is in production now and another one that is going to be the next production version.
- The versions of applications in those blue and green Production Namespaces will be different however these namespaces might need to use the same resources like Nginx Controller or Elastic Stack and this way they can both use this common shared resources without having to set up a separate Cluster.
5. Limiting Access and Resources
One more reason for using Namespaces is to limit the resources and limit the access to namespaces when we are working with multiple teams.
- Imagine two teams working in the same cluster, each with its own Namespace. By assigning access only to their respective Namespace, teams can Create, Update, and Delete resources without interfering with others. This ensures isolation and reduces the risk of accidental changes across teams.
- Additionally, resource limits can be set at the Namespace level. This guarantees fair resource allocation—preventing one team from overusing the cluster’s capacity and ensuring other applications still have the resources they need to run smoothly
Characteristics of Namespaces
There are several characteristics of a Namespaces that one should consider before deciding how to group and how to use Namespaces:
1. You can not access most of the resources from another namespace.
If you have a Config Map in Project A Namespace that references the database service, you can not use that Config Map in Project B Namespace. Instead you will have to create the same Config Map that also references the database service.
👁 Kubernetes-Namespaces-1
Each Namespace must define its own Config method even if it's the same reference. The same applies to Secret file as well. If we have credentials of a shared Service, we will have to create a Secret in each Namespace where we will need that.
2. Service can be shared across Namespaces
Service is a resource that can be shared across Namespaces. Config Map in Project B Namespace references Service that is going to be used eventually in a Pod and the way it works is that in a Config Map is the database URL in addition to its name will have Namespace at the end so using that URL you can actually access services from other namespaces.
apiVersion: v1
kind: ConfigMap
metadata:
name: my-configmap
data:
db_url: my-service.database
3. Volumes and Nodes cannot be created within a Namespace
Most of the resources can be created within the namespace but there are some components in Kubernetes that cannot be "Namespaced". That is they can only exist globally in the cluster and cannot be isolated or created within a certain Namespace. Such resources are Volumes and Node. So when you create the Volume, it will be accessible throughout the whole cluster because it's not in a Namespace.
You can get a list of components that are not bound to a namespace by using the command:
kubectl api-resources --namespaced=false
And also get the list of components that are bound to a namespace by:
kubectl api-resources --namespaced=true
