Kubernetes namespaces are a central part of how we structure, deploy, and manage containers today. However, namespaces are not a new concept; in fact, Linux namespaces were introduced in 2002 and designed to separate and group individual processes and capabilities. So how did the idea grow to be used in the robust fashion it is used today? This blog will review;

  • What is a Namespace?
  • What makes Kubernetes Namespace different?
  • Kubernetes Namespace Best Practices

What is a Namespace?

Namespaces are a feature of the Linux kernel. Namespaces partition kernel resources so that defined processes can view and interact with a limited set of resources. This separation is useful when evaluating the different resources that are available to the kernel. Some processes will require the ability to view and edit network capabilities; others will require filesystem access. The qualifications for these two example processes should be different.

Namespaces allow the kernel to assign group attributes to a single or multiple processes. The feature works by having a single namespace for a set of resources and processes, each referring to different resources. There are currently eight types of supported Linux kernel namespaces:

During each process initialization, a symbolic link in the /proc/<$pid>/ns directory is created. The symbolic link will define the process capabilities during runtime with each process will contain defined capabilities of all eight classes. The Linux documentation has an example output of what can be found in a processes /proc/<$pid>/ns directory:

$ ls -l /proc/$$/ns | awk '{print $1, $9, $10, $11}'
total 0
lrwxrwxrwx. cgroup -> cgroup:[4026531835]
lrwxrwxrwx. ipc -> ipc:[4026531839]
lrwxrwxrwx. mnt -> mnt:[4026531840]
lrwxrwxrwx. net -> net:[4026531969]
lrwxrwxrwx. pid -> pid:[4026531836]
lrwxrwxrwx. pid_for_children -> pid:[4026531834]
lrwxrwxrwx. time -> time:[4026531834]
lrwxrwxrwx. time_for_children -> time:[4026531834]
lrwxrwxrwx. user -> user:[4026531837]
lrwxrwxrwx. uts -> uts:[4026531838]

Each process contains the details for what system capabilities and child processes it is allowed. When creating a new Linux namespace, a namespace API allows for the creation, deletion, and modification of any namespaces. The API will enable programs to interact with the namespaces in a stable and scalable way.

How are Kubernetes Namespaces Different?

When creating a new Kubernetes namespace, a request is sent using the namespace API using the defined syscalls, and since Kubernetes has admin privileges, a new namespace will be created. The new namespace will contain specifications for the capabilities of a new process assigned under its domain.

Kubernetes (and any admin) can alter the specifications of several capabilities, such as the Mount or Network capabilities. Those capabilities are typically changed by applying Kubernetes objects, such as services, with all of the processes linked to the created namespace, allowing a one-stop clean-up of all processes in the event of a namespace deletion.

Kubernetes namespaces are comparable to Linux namespaces. However, Kubernetes manages namespaces in a declarative style. The simple clean-up process is central to managing operations at scale and the cluster management add-ons such as role-based access control (RBAC), making namespaces even more powerful.

Kubernetes Namespace Best Practices

It is worth examining a few management problems that occur when configuring your Kubernetes namespace and some best practices to follow.

1. Create a management structure

Since many Kubernetes management capabilities are built around the namespace functionality, an effective management structure must be defined. Without proper management, storage, memory, CPU, and other resources, will be requested and utilized chaotically. Group silos also arise from the lack of management, mostly because teams do not want to get in each other’s way. Development is also slowed due to a lack of shared knowledge and collaboration. The outcome is uncoordinated resources and high costs due to the underutilization of resources. The lack of direction creates a culture where teams develop without the benefit of shared knowledge and collaboration.

2. Avoid using excessive namespaces

Namespaces should not be created at will by anyone in the organization. Allowing individuals to create namespaces without management will lead to many additional environments.

Namespaces should be tied to the application or function they are created for, such as a backend or frontend namespace. Providing other users the ability to identify the workloads associated with the namespace quickly.

3. Don’t overload namespaces

Users should create namespaces for a specific application or microservice and all of the application requirements. This specificity is for multiple reasons;

  • Simplified recreation of the entire application
  • Fine-grained network management
  • Greater scalability
  • Greater observability

Do not overload namespaces with multiple workloads that perform unrelated tasks. Keep your namespaces precise and straightforward.

4. Use a scalable naming structure

If you have multiple customers or applications that need to be separated, make sure you develop a scalable naming structure. As your company grows, you want to ensure that your namespaces can be easily discernible.

5. Know when to use cluster vs. namespace separation

Sometimes the namespace separation of resources is not enough. As regional considerations begin to pop up, separating workloads by cluster and region may be a necessity. Do not be afraid to separate applications/groups between clusters, as this may be a more scalable solution. As long as you create precise, declarative Kubernetes objects, your resources will be portable and scalable.

6. Label everything

Labels are identifying metadata that you can add to your namespaces to give them extra context. Creating or attaching Kubernetes labels to your namespaces is necessary as they will help monitor, log, and debug applications later on. As your applications grow, the amount of log and metric data they produce and the ability to quickly identify and sort through this data will be vital.

You can hold labeling audits between teams to ensure current workloads are accurately labeled to create naming cohesion. This may seem cumbersome, but the overall observability of your system will thank you for it.

Conclusion

Since all organizations are different, it is up to you to figure out how best to implement and manage Kubernetes Namespaces. In general, aim to:

  • Create an effective Kubernetes Namespace structure
  • Keep namespaces simple and application-specific
  • Label everything
  • Use cluster separation when necessary
  • Be consistent
  • Re-evaluate constantly

The last and most important part is to secure your clusters! Namespaces alone will not secure your workloads!

There is so much more that we at Red Hat want to help you with. You can find out more HERE.