Table of Contents
Since the release of Docker almost a decade ago, the use of containers has been becoming increasingly popular, especially with the growth of hardened container security and container orchestration. After competing with other container orchestration tools like Docker Swarm, Kubernetes saw a massive adoption wave in 2019. All the major cloud platforms were offering hybrid-cloud solutions, such as AWS Outposts, Azure Arc, and Google Anthos, with Kubernetes at the center.
Since then, Kubernetes has become an enabler for developers, testers, data engineers, analytics engineers, and so on. Unfortunately, in most companies, Kubernetes is still out of reach for most of those roles. Only DevOps, infrastructure, and platform teams typically have access to Kubernetes. They act as facilitators for other teams.
To some extent, this goes against the grain of Kubernetes. One of the core ideas behind containers is to democratize access to infrastructure.
Access to a Kubernetes cluster removes a lot of barriers for engineers. We’ll get into the details of how and what and why shortly, but they all boil down to a key result: being able to access infrastructure empowers engineers to concentrate on solving the business problem at hand.
Why Should Every Engineer Have Access to Kubernetes Clusters?
A Kubernetes cluster is an abstraction of the underlying infrastructure that your organization uses for development. With Kubernetes, you can use these available resources to spin up isolated dev and test environments quickly without impacting anyone else on your team.
Usually, there's a DevOps team that grants an engineer access to a cluster. If we consider removing that layer of approval and giving engineers direct access to Kubernetes clusters, engineers could be more responsible for the amount of resources they use. They could own their cost of infrastructure.
Let's look at some of the main reasons why direct access to Kubernetes is a good thing.
Improves Development Speed
In many other areas of engineering, like business intelligence, self-service platforms have reduced engineers' friction, wait time, and frustration. Acquiring infrastructure before you can start your work tends to add unnecessary cognitive load on an engineer. As a business, you can’t afford to mentally fatigue your engineers with tangential tasks; you want them to concentrate on their core work.
The self-service capability of Kubernetes can increase the speed of development by removing unnecessary hurdles. For instance, when a developer needs to run through and test code changes, a self-service platform lets them quickly spin up a container and destroy it when they’re done testing their code. You can easily see this impact with small experiments, like A/B testing.
Puts Less Burden on DevOps
DevOps and infrastructure teams often take flak for being slow to approve infrastructure requests, modify identity-related permissions, and fix security issues. Consider that they're slow because they're overloaded with requests that you could easily offload to a self-service setup.
Moving to a self-service setup impacts DevOps engineers just as positively as developers who need to consume Kubernetes resources for their work. With their workload reduced, DevOps teams can concentrate on automating more processes and building platforms that can help multiple teams across the entire organization.
Engineers Learn More Skills
The evolution of cloud infrastructure has made it easy for engineers to spin up their work. Regardless of an engineer's specialty, they all deal with infrastructure one way or another. With a self-service setup, they can use Kubernetes to manage their containers while learning more about infrastructure, how to access logs, and how to debug issues.
An engineer who owns the cost and operations of their own infrastructure is an engineer with a deeper understanding of the problems they’re working on and the tools they're using to solve them. And of course, more knowledge leads to more career doors getting opened for, say, frontend engineers, backend engineers, or data engineers.
How to Give Engineers Direct Access to Kubernetes Clusters
Let’s say I’ve persuaded you. You’ve agreed on the point that engineers should have direct access to Kubernetes clusters. How, then, do you grant them this direct access?
There are a few fundamental principles and general directions that you need to follow when giving engineers direct access to your Kubernetes clusters. Let’s talk about them.
Don’t Give Them Unrestricted Access
Unrestricted access to Kubernetes can be disastrous. Kubernetes runs on top of actual physical servers on-premises and in the cloud. This means that there's a limited capacity for spinning up containers. With unrestricted access, engineers can spin up more containers than they need, impacting the availability of cluster resources for other engineers.
Unrestricted access to Kubernetes clusters also poses a security threat to your business. Many of your tasks, even in dev and test environments, might involve critical data. You don't want everyone to have access to every bit of data that’s used by your Kubernetes cluster.
In other words, restrictions should apply to what an engineer can do with a cluster. You can use one or more of the many established methods of controlling access, such as role-based access control (RBAC), policy-based access control (PBAC), and so on.
Use Namespaces or Multi-cluster Abstractions
Like namespaces in programming languages or databases, Kubernetes namespaces give you a way to logically abstract and group your Kubernetes resources. This way, you can take separate action on different groups.
Namespaces come in handy when you’re working with different environments, such as dev and test. They’re also useful when you want to separate resources according to teams, projects, or workgroups. With Kubernetes's RBAC capabilities, you can create cluster-wide roles to enforce the use of existing roles and prevent duplicate ones.
Multiple Kubernetes clusters give you more concrete isolation between your workloads. With the right tooling, a multi-cluster setup might work, but beware that it can significantly complicate things, too. But it is easily manageable with the right tools and control planes.
Enable Self-service Capabilities
Whether you use namespaces or a multi-cluster setup, the important thing is that your Kubernetes infrastructure should be available to developers with a self-service platform. This self-service abstraction layer is a huge step toward reducing operations workload from the DevOps teams and speeding up development and testing.
Loft Labs provides a solution for giving engineers direct access to Kubernetes clusters. Loft's virtual Kubernetes clusters run within a namepsace, so engineers can rest assured that their development, testing, and debugging efforts won't break anything for other engineers sharing the same underlying infrastructure resources.
Loft takes a shift-left approach for putting engineers in charge of the development process. Put up strict security and resource limit guardrails with Loft templates, and let your engineering teams spin up Kubernetes namespaces whenever they want, safely and efficiently.
Conclusion
The rise in popularity of Kubernetes has given it a strong place in today’s development landscape. Making your engineers jump through hoops to use it is only going to slow down your organization. Instead, consider giving them direct access to Kubernetes clusters via self-service platforms, so you can keep your engineering processes efficient.
Of course, it’s important to offer access intelligently and safely. Keep in mind a few key principles when giving your engineers direct access to Kubernetes clusters, like avoiding unrestricted access and using namespaces.
Loft Labs takes the self-service approach to infrastructure. Save your engineers a whole lot of time by giving them fine-grained control over resources, enabling a deeper GitOps integration, and working with continuous delivery tools. Give Loft a shot if you want to enable engineers across your organization to have more control over the development process!
