Kubernetes Namespaces

Kubernetes is well-known for its massive scalability; a single cluster can contain multiple nodes and containers. This means that multiple groups and projects can share the cluster, a practice known as "cluster multi-tenancy." However, when several teams and projects are running within the same cluster, things can become confusing, and people can step on each other's toes if order is not maintained.

Fortunately, this is where namespaces come in handy. Namespaces provides a mechanism for isolating groups of resources within a single cluster. They make it simple to split clusters into sub-clusters that can still communicate with one another. A team's infrastructure is better protected against outages and malicious threats by remaining isolated within a namespace.

In this blog let's discuss some of its capabilities and limitations.

When Should You Use Multiple Namespaces?

Namespaces are designed to be used in environments with a large number of users spread across multiple teams or projects. It defines the scope of names. For example, you can create namespaces called Dev, QA, Production, R&D and so on. Resource names must be unique within a namespace but not across namespaces.

Namespaces cannot be nested within each other, and each Kubernetes resource can only exist in one namespace. Namespaces are a method of allocating cluster resources to multiple users (via resource quota).

Why should you use a Namespace?

Different teams may want to use the same resource names for different projects. Because the components of one namespace are not directly linked to those of another, an object can be named in multiple namespaces without issue. Furthermore, item manipulation in one namespace has no effect on similar items in another. This has the potential to reduce damage.

Namespaces are also useful for defining specialized permission sets, particularly those related to Role-Based Access Control (RBAC). It's an efficient way to increase security in your environment.

Namespaces can also be used for smart resource management. It can help improve performance across your clusters. Separating namespaces can improve search performance in the Kubernetes API. This lowers latency and increases application speed for each containerized app on the cluster.

Namespace Creation | Default vs. Manual

There are two types of namespaces: default namespaces and manually generated namespaces. Kubernetes creates a default namespace that includes all system resources. Let's learn more about the default and manual namespaces in the following sections.

Working with Namespaces -

When the cluster setup is performed, Kubernetes creates a few namespaces.

Run the following command to see the namespaces -

kubectl get namespace

NAME              STATUS   AGE
default           Active   1d
kube-node-lease   Active   1d
kube-public       Active   1d
kube-system       Active   1d

Kubernetes create four namespaces -

1. default - The default namespace for objects that have no other namespace.

2. kube-system - The namespace for objects created by the Kubernetes system.

3. kube-public - This namespace is generated automatically and can be accessed by all users (including those not authenticated). This namespace is mostly reserved for cluster use, in case some resources need to be publicly visible and readable across the entire cluster. This namespace's public aspect is merely a convention, not a requirement.

4. kube-node-lease - This namespace contains Lease objects that are associated with each node. The kubelet can detect node failure by sending heartbeats to the control plane via node leases.

Create new namespaces

Let's create a new namespaces. We will use below YAML file for creating a new namespace.

{
  "apiVersion": "v1",
  "kind": "Namespace",
  "metadata": {
    "name": "rnd",
    "labels": {
      "name": "rnd"
    }
  }
}

To create the namespace, type the below command.

kubectl create -f namespace-definition.yaml

To verify, let's list all of the namespaces in our cluster by running below command

kubectl get namespaces --show-labels

NAME          STATUS    AGE       LABELS
default       Active    52m       <none>
rnd			  Active    21s       name=rnd

Create pods in namespace

A Kubernetes namespace defines the scope of the cluster's Pods, Services, and Deployments. Users who interact with one namespace do not see the content in another. Let's start by making a new pod in the production namespace.

apiVersion: v1
kind: Pod
metadata:
  labels:
    app: rnd-pod
  name: rnd-pod
  namespace: rnd
spec:
  containers:
  - image: nginx
    name: nginx

If you look closely, you will notice that the namespace field has now been added under the metadata section.

To create this pod run the below command

kubectl create -f pod-definition.yaml

Use the below command to see if the pod is created -

kubectl get pods -n rnd 

We can also use the command below to list all pods in all namespaces -

kubectl get pods --all-namespaces

Deleting Namespaces -

The below command can be used to delete everything under the namespace.

kubectl delete namespaces rnd 

How Many Namespaces Should You Use?

Consider a scenario in which you would use multiple namespaces. These namespaces serve as repositories for your critical resources, which have their own names. However as the saying goes, too much of anything is bad. Namespaces are not immune in this regard. While it is beneficial to isolate and organize, excessive division and declaration can lead to confusion. The trick is to get the most out of your namespaces while not overburdening your management capabilities.

All these features makes Namespaces a powerful tools for defining the security, performance, and hierarchy of your Kubernetes system.

I hope you found this information useful.

Thank you for taking the time to read it.

*** Explore | Share | Grow ***