What are Kubernetes Namespaces?

In Kubernetes, namespaces provide a mechanism for isolating a group of related resources (e.g. Pod, Deployment) within a single cluster. Pods within the same namespace can communicate and potentially share resources.

Any resource in Kubernetes is either in the default namespace or the namespace created by the cluster operator. The default namespace is where every Kubernetes resource is created by default unless anything else is specified. The whole cluster can be considered as the default namespace.

You can create multiple namespaces within a Kubernetes cluster. This is really useful for organizing, in order to be able to better coordinate changes between different codebases. Knowing how many namespaces to create and what for really depends on the use case you have. If the project is small, with a couple of microservices, it makes sense to operate in the default namespace. But if you want to include some granularity and divide the resources for development and production you will need at least two namespaces. Maybe you want to manage multiple projects and applications on the same cluster, then you need a proper namespace strategy.

What problem do Namespaces solve?

One use case for Kubernetes Namespaces is to split a cluster into logical partitions so that it can be used by several users and teams, or a user that has numerous applications. Each user, team, or app that is operating in a namespace is completely isolated from every other Kubernetes namespace in the cluster, and they give the impression of being the only user within the cluster.

Namespaces can also be utilized to specify specialized sets of permissions, particularly those pertaining to Role-Based Access Control (RBAC). Namespaces can be managed by a Kubernetes administrator to create groups with shared permissions and roles. It's a great way to add additional layers of security to the environment.

Another use case for namespaces is good resource management. Admins can define resource usage quotas to make sure one namespace does not use all of the available CPU or memory capacity.

How to create Kubernetes Namespaces?

In order to create a Namespace in Kubernetes, use the following command:

kubectl create namespace testspace

A YAML file can also be created and applied to make a namespace:

testspace.yaml:

kind: Namespace
apiVersion: v1
metadata:
name: testspace
labels:
name: testspace
kubectl apply -f testspace.yaml

How to create resources in a Namespace?

When creating a resource, you need to explicitly tell Kubernetes in which namespace you want to create your resources, because if you don't specify the namespace the resource will be created in the default namespace.

One way to do it is to set the namespace flag when creating the resource:

kubectl apply -f pod.yaml --namespace=testspace

Or specify a Namespace in the YAML declaration:

pod.yaml:

The resource will always be generated in that namespace if you specify a namespace in the YAML file. So if you try to define another namespace for it with the command, it will fail.

apiVersion: v1
kind: Pod
metadata:
name: testpod
namespace: testspace
labels:
name: testpod
spec:
containers:
name: testpod
image: nginx

Multiple Kubernetes namespaces

It is recommended to use multiple Kubernetes namespaces when there are multiple teams or projects within a single organization, which wish to have their own virtual cluster(s) in order to isolate workloads. The resource needs of these clusters must be separated such that each team does not impact other teams’ work without proper configuration and authorization settings.

For application development, it's also a common case to use separate containerized environments for testing, staging, and production purposes. This enables separation between codebases that devs and testers are working on and the production code.

How can you create multiple namespaces in Microtica?

With Microtica, you can create Kubernetes clusters from the portal UI. Here you can actually create namespaces and treat each namespace as a separate cluster. We provide the abstraction of operating with your namespace, as you would with any Kubernetes cluster. 

When you create a Microtica Kubernetes Cluster, you’re given the ability to associate that cluster with a specific namespace. You can configure this namespace with the resource quotas you need. This means that now you’ll be able to see this Kubernetes namespace in the list of your Clusters and treat it as any normal cluster. 

This is the power of Microtica’s abstraction layer. If you have multiple team environments you would create multiple clusters in Microtica, each with the specified namespace, making sure that they are isolated and the actions taken in one cannot affect the others. Then you'll define the needed resource quotas for CPU and memory to ensure the namespace has the needed resources to run. Each of these namespaces is organized as a separate cluster in Microtica.

Summary

Namespaces are a great way to manage single Kubernetes clusters and divide them into multiple logical groups of resources. It is common practice in organizations to create multiple namespaces, each with its own virtual cluster.

Microtica abstracts the Kubernetes API and provides a simple interface for developers to manage their clusters. Start today!