Kubernetes Namespaces with Nirmata

Kubernetes Namespaces with Nirmata

As more and more services are built on top of Kubernetes, simple tasks can start to get more complicated. For example, without Namespaces, teams can’t create Kubernetes Services or Deployments with the same name. If you have thousands of pods, just listing them all would take some time, let alone actually administering them! And these examples are just sliver of the full scope of the potential complexity.

In this post, we will discuss how Nirmata helps manage Kubernetes for enterprise teams by automating the management of Kubernetes namespaces. A detailed introduction to Namespaces was provided in a previous post but here’s a brief summary:

Namespaces serve as a virtual cluster inside your Kubernetes cluster. You can have multiple namespaces inside a single Kubernetes cluster, and they are all logically isolated from each other. They can enhance team’s organization, security, and even performance.

Namespaces can help significantly with organizing your Kubernetes resources and can increase the velocity of your teams. You can lock down resources in a Namespace and introduce more security and isolation to your cluster!

Nirmata Environments and Namespace management

To help manage Kubernetes namespaces, Nirmata introduces the concept of an Environment. In Nirmata, an Environment is a logical grouping of applications to which you can apply policies and common configuration. A user can create a namespace with different level of namespace isolations within an environment.

Depending on the requirements, one can create the Isolation Level of Namespace per Application or Shared Namespace.

Isolation Level Options

Environments with Multiple Namespaces  

If the isolation level is Namespace per application. Each new instance of an application will run in a new namespace. Choose this level when you want to run multiple copies of the same application in an environment.

Each namespace is created before the creation of the application. If the namespace can not be created the application does not get created and an error message is received.

Similar Deployment within an Environment possible due to multiple namespaces

With this setting, the namespace exists until the application and all the corresponding resources exist. The namespace is deleted only after the deletion of the application.

Environments with a Shared Namespace:

If the user chooses the Isolation Level as Shared Namespace a single namespace is created within the environment and all applications will run under  the same namespace.

Cluster view of different applications under a Shared namespace

In case of the Shared Namespace isolation level, the namespace gets created along with the creation of Environment, and is deleted only when when the environment is deleted.

Shared Namespace View in Nirmata


Our mission at Nirmata, is to make it easy for all enterprises to adopt Kubernetes and open-source innovation. Nirmata provides simple, yet powerful abstractions, to make it easy for developers and operators to learn and manage Kubernetes at scale and in production environments.

Namespaces is an essential feature of Kubernetes, and without proper governance it is often overlooked or misused. Nirmata helps platform and operations teams easily set and manage policies for Kubernetes namespaces across the software development and delivery pipeline.  

You can explore Nirmata for free!


Kubernetes CRD for Egress IP Address Management
Spotinst and Nirmata: Providing a Simple Way to Create and Manage Your Kubernetes Infrastructure Using Excess Capacity Instances
No Comments

Sorry, the comment form is closed at this time.