Table of Contents
Engineers use Kubernetes namespaces to organize, allocate, manage, and secure Kubernetes cluster resources. A cluster can have multiple namespaces with separate logic and the ability to communicate with each other. Additionally, every resource in Kubernetes must be contained in a namespace, which can be either the system’s default namespace or a custom namespace defined by the cluster administrator.
Custom namespaces can be created as a self-service namespace; these namespaces can be created on demand without the permission of the cluster admin, providing engineers with easy and unrestricted access to your Kubernetes cluster.
This article explains self-service namespaces, how they improve productivity, and their benefits when working remotely on development projects. The article also touches on some drawbacks of giving engineers unrestricted permissions to manage namespaces in a shared cluster and how Loft features reduce those drawbacks and increase remote developers' productivity.
#What Are Self-Service Namespaces?
Self-service namespaces go one step further than typical namespaces, as engineers can create them on demand without being an admin of the cluster. Self-service namespaces are also isolated from other namespaces in the cluster. The following diagram illustrates a self-service namespace on a hypothetical shared Kubernetes cluster where users have permission to create namespaces:
In the above diagram:
Kubeis a shared Kubernetes clustermain-applicationis the main application namespacemain-application-sub1is a carbon copy of the main application namespace and its resourcesmain-application-sub2is also a carbon copy of the main application namespace and its resourcessenior-devsis the senior developers' roleoperational-devis the operational developers' roleadmin-devis the administrative developers' role
The Kube cluster houses all the namespaces listed and their resources (application and development environments). The main-application namespace contains the required environments to run the application. It’s isolated and authenticated with the senior-devs role so that only users assigned to that specific role can access that namespace and its resources.
The created main-application-sub1 and main-application-sub2 self-service namespaces are totally isolated from the main-application namespace. So, any changes made to the application or development environment cannot affect the main-application namespace or any other namespaces in the Kube cluster. Also, each self-service namespace is authenticated with specific roles so that users not binded to that role cannot access the namespace.
#How Self-Service Namespaces Improve Productivity
Giving engineers control frees up cluster administrators to concentrate on security and stability. This section highlights some ways that self-service namespaces improve cluster administrators' and engineers' efficiency.
#Custom Namespaces Creation as Required
Self-service namespaces allow your engineering teams to manage different custom namespaces within the Kubernetes cluster without needing admin permission. In this context, “manage” refers to creating, deleting, and listing namespaces.
Additionally, allowing your engineering team to create namespaces on demand provides them the autonomy, agility, and flexibility they require to test, deploy, and successfully launch new product features onto the market. It also enables engineering teams to set up and manage CI/CD pipelines, perform experiments, and set up development environments seamlessly and efficiently.
#Collaboration between Engineers and Remote Development Environments
Self-service namespaces also support stronger collaboration, allowing your engineering team to collaborate and work together from anywhere in the world through remote development environments. Engineers are able to share custom namespaces with others and gain immediate access to any shared namespaces.
As a result, your engineering teams can also complete the debugging workflow more quickly. Additionally, as everyone on your engineering teams will be able to work in the same environment, more time will be available to work on product development instead of setting up namespaces on individual machines.
The benefits of remote development environments also go beyond improved collaboration. These environments also involve a cloud-based development runtime and environment as well as shared central services that are accessible to all engineers in their respective dev environments, which has significant individual benefits.
#Creation of Short-Time Development Environments
Self-service namespaces also enable your engineering team to create and delete as many temporary namespaces as needed for experimentation and testing. This allows them to have separate product features and perform end-to-end and user acceptance testing faster and without conflicting with the namespace where the production application is located.
Additionally, since all the resources in the self-service namespaces are for a particular purpose, no one will have to spend time trying to understand the self-service namespace and its resources. This also enhances the feedback mechanism between your engineering team and other team members and stakeholders.
#Drawbacks of Self-Service Namespaces
Self-service namespaces essentially grant your engineering team unlimited permission to manage your Kubernetes cluster namespaces as needed. Unsurprisingly, this also has some disadvantages, especially when the roles are not configured properly.
#Namespace Mismanagement
Since engineering teams can create namespaces as needed, there is a very high tendency for engineering teams to create duplicate namespaces and forget to delete previously used namespaces.
#Authorization Issues
Engineering teams may accidentally run a command in the incorrect namespace if the RBAC rules are improperly specified. This can be avoided by correctly configuring the RBAC rules.
#Loft as a Solution for Self-Service Namespaces
Loft is a Kubernetes tooling company that provides open source developer tools and virtual cluster technologies for Kubernetes, as well as solutions for self-servicing namespaces. With Loft, you don’t have to worry about the drawbacks that come with self-service namespaces because of its unique features.
The following paragraphs will focus on these features and how each of them not only nullifies the drawbacks that come with self-service namespaces but also improves remote developer productivity.
#Support for GUI, Loft CLI, and kubectl Control
Loft provides a powerful graphics user interface (GUI) for namespace management as well as a command line interface (CLI) that allows you to work directly from your terminal. So, your engineering team can effectively manage their namespaces, irrespective of the interfaces they are familiar with. Additionally, engineers in your team that prefer kubectl can also use the kubectl command to manage their namespaces.
The following sections briefly explain each of the three methods supported by Loft for creating namespaces, also referred to as “spaces” in Loft. However, before you get started with any of these methods, make sure to follow these steps:
- Set up your Loft account if you don’t have one by going to the Get Started page
- Fill out the form, then click the Install via Loft CLI button
- Refer to the official documentation to get the right command to download the Loft CLI binary from GitHub, then set up Loft CLI on your local computer
After completing the requirements above, you’ll now briefly see how engineers can manage spaces using all three methods supported by Loft.
#Creating Spaces via the GUI Method
Creating a space using the GUI method is straightforward, but there are a few steps involved:
- Log in to your Loft dashboard
- Click Spaces in the sidebar
- Click the Create Space button at the top left
- Fill out the form, where the Kubernetes Name field defines the name of the space
- Finally, click the Create button at the bottom of the form
When engineers create a space using the GUI, they also need to add the newly created space as a kube-context to the kube-config file. That can be done by running the command loft use space {{space-name}}, where {{space-name}} is the value used in the Kubernetes Name field.
#Creating Spaces via the CLI Method
Creating spaces via the CLI is the fastest and easiest method, as it can be done with just one command:
loft create space {{space-name}}
Here, {{space-name}} is the name of the namespace. Also, the kube-context for the space is automatically added to the kube-config file.
#Creating Spaces via the kubectl Method
Loft also easily accommodates using kubectl to create spaces. First, add a kube-context for the cluster if you do not have one. This can be done by executing the command loft use cluster {{cluster-name}}, where {{cluster-name}} is the newly created cluster, and the new space will be created there.
Create a YAML file using the format below, where {{space-name}} is the name of the space:
apiVersion: cluster.loft.sh/v1
kind: Space
metadata:
name: {{space-name}}
Execute the command kubectl apply -f {{name_of_file.yaml}} to create the space, where {{name_of_file.yaml}} is the name of the created YAML file.
Just like with the GUI method, engineers also need to add the newly created space as a kube-context to the kube-config file by executing the command loft use space {{space-name}}.
Considering the multiple options supported by Loft to manage spaces, engineers can work freely without having any concerns about their preferred method. Additionally, engineers will be more productive since they can use any supported methods in which they are skilled.
#Ability to Share Spaces
Engineers can also share namespace access with other users or even the entire engineering team using Loft’s GUI or CLI. Also, namespace access sharing can be managed or limited by editing the roles for each user.
Engineers can also grant the Space Admin role to users in high-level or managerial positions. Additionally, this feature encourages teamwork among engineers while also reducing the authorization issues associated with sharing namespaces because each shared user will have their own appropriate role. The official documentation for Loft has more information on how to share namespaces using both the GUI and CLI methods.
#Sleep Mode and Auto-Delete
With Loft, you don’t have to worry about being charged for your inactive namespaces because its advanced inactivity detection monitors when your engineers are not working with their namespaces or virtual clusters and puts them to sleep. Loft also gives you the ability to define custom rules for automatically putting your namespaces and virtual clusters to sleep. Additionally, Loft automatically restores the state of the namespace when it notices some activities, and your engineers can keep working just like it never went to sleep.
Aside from putting inactive namespaces and virtual clusters to sleep, Loft also automatically deletes them after a certain period of inactivity. As a result, Loft helps engineers properly manage their namespaces and also helps the business minimize costs.
#Ability to Use the kubectl Command
Loft namespaces are constructed as a virtual abstraction on top of conventional namespaces. This allows them to be managed using kubectl much like conventional Kubernetes namespaces, but without the requirement to provide users access to conventional namespaces or other cluster-wide resources. As a result, engineers will be able to use their current kubectl expertise effectively.
#Conclusion
Self-service namespaces have many benefits for engineering teams and organizations as a whole. This article described how self-service namespaces improve developer productivity and some of the drawbacks associated with this approach. You also saw how Loft can be used to overcome some of these drawbacks while still reaping the benefits of self-service namespaces overall.
