Kubernetes Development Environments: From Local to Remote

Kubernetes is a powerful open-source system for automating the deployment, scaling, and management of containerized applications. Developing applications for Kubernetes can be complex, requiring a specialized development environment optimized for working with Kubernetes.

In this article, you’ll learn about the different types of Kubernetes development environments, their pros, cons, and the factors to look out for when choosing one for your dev team.

What is a Kubernetes Development Environment (KDE)?

A Kubernetes development environment is a specialized development setup that enables developers to work effectively with Kubernetes. It encompasses the necessary tools and resources to develop, deploy, test, and debug applications running within containers on a Kubernetes cluster. It also supports installing and configuring different tools, from containers to policies and monitors, while keeping your environment updated and secure.

Importance of Kubernetes Development Environments

There are many benefits of KDEs, but here are some of my favorites:

• Kubernetes development environments provide cluster management for engineers by serving as a center for configuring, provisioning, and organizing Kubernetes resources. For instance, by running and deploying your applications to a Kubernetes cluster on your local machine, you can create a closer match to your production infrastructure, making testing more realistic and reducing potential issues.
• Run Kubernetes locally: Your own physical or virtual machine can host the Kubernetes development environment. KDEs offers a secure and separate environment that enables you to install and configure Kubernetes and any other applications, libraries, and services that may be needed.
• A Kubernetes development environment enables developers to get hands-on experience and an understanding of the concept and tools used by the operation team to sustain production tasks. This way, potential challenges can be predicted, explored, and avoided.
• KDEs are essential when starting with the Kubernetes CLI and the kubectl tool. It allows you to easily spin up and access container hosts through virtual networks, which can be useful for testing and experimenting with Kubernetes.
• Kubernetes development environment allows for efficient management of resources such as CPU and memory, which can help development teams to optimize their applications and reduce costs.

Types of Kubernetes Development Environments

The configuration of Kubernetes development environments varies, depending on the application you are building and the requirements of your development team. They can be broadly categorized into three types: Local development environment, Remote development environment, and Local-to-remote development environment. Let’s break down each of them!

Local Kubernetes Development Environment

This type of KDE can be run using your personal computer’s resources and computing power. They allow you to build containerized microservices locally on your computer without needing to access the cloud.

Examples of tools that provide local Kubernetes clusters include Minikube, K3s, Micro8s, Kind, etc. These tools can run on different operating systems and can be used to deploy multiple clusters and microservices in separate containers.

Let’s talk about some features of the local Kubernetes development environment:

• User/Developer Experience: As mentioned earlier, local KDEs are configured and tested on the developer’s computer. Mostly, the local setup is usually different for various operating systems. Setting up Kubernetes locally means developers are tasked with the responsibility of managing and maintaining the environment themselves. While it might not be an issue for senior developers, beginners may have difficulty familiarizing themselves with it. Consequently, the developer experience is poor, especially without good knowledge of Kubernetes.
• Sysadmin Experience: System Administrators do little or nothing in the setup and management of local Kubernetes clusters. Sysadmins are generally uninvolved and, therefore, have no idea whether or not the developers can work and manage their clusters. If at all, the sysadmins may provide support when developers encounter problems or have questions.
• Scalability: Local clusters quickly max out when running complex applications. This is because they only have access to the resources made available by the engineer’s computer. Furthermore, there is little room for automation during the creation of the local clusters by the engineers, as the process has to be redone by each engineer. Therefore, local clusters lack scalability.
• Flexibility: With local Kubernetes clusters, admin and developers can easily spin up and manage multiple containers, allowing them to simulate a production environment and test their applications in a controlled and isolated setting. Although local clusters are flexible in configuration, they lack certain features which make them unfit for production usage in some use cases.
• Isolation: As a developer, you have an isolated environment, i.e., an environment that is detached from other environments. This environment can even be used without internet access. This disconnection makes it impossible for all the environments to fail at once. Thereby minimizing the tendency of the local clusters to fail, enabling developers with a functioning production environment.
• Cost: Most local Kubernetes environments are open-source and quite simple to use. They only make use of computing resources that are locally available. As a result, a local Kubernetes Development Environment is literally the cheapest available solution compared to other types of KDEs.

Remote Kubernetes Development Environment

They allow developers to build, test and deploy applications in Kubernetes in a cloud-based environment, providing developers with the flexibility and scalability of the cloud, along with the powerful orchestration capabilities of Kubernetes. This allows for faster and more efficient development, and the ability to scale easily and manage applications effectively.

This is the category of the KDEs that runs in the cloud. Remote Kubernetes development environment helps engineers by providing a consistent development experience across multiple cloud providers, e.g., AWS, Azure, Google, etc.

Remote Kubernetes development environments can be created by either the sysadmin (here, the admins create the KDE and then give access to the developer) or the developer (here, the developers can create the clusters by themselves if they own an account for the cloud provider). Examples of Remote KDEs include Amazon Elastic Kubernetes Service (EKS), Google Kubernetes Engine (GKS), Azure Kubernetes Service (AKS), Red Hat OpenShift, etc.

Let’s look at some features of the Remote Kubernetes development environment:

• User/Developer Experience: For Remote KDEs, the experience depends on how the clusters were created. If the sysadmin is a gatekeeper for cluster access, the developer experience would most likely be very poor. This is because, even though sysadmins cater to cluster management, developers would have to deal with the issue of waiting for development environments to be provided to them. On the other hand, if developers have direct access to the cloud, work environments are easily and immediately created as needed. The best case scenario for developer experience is when developers have direct access to the cloud, although this can often lead to poor cluster management when there are guidelines or governing rules.
• Sysadmin Experience: Managing and distributing clusters can take up a significant amount of sysadmin time and resources. To improve this, sysadmins often implement tools and policies to deploy and control cluster usage, especially as the number of developers increases. This can help to manage clusters and improve the developer experience by making sysadmins more available to provide support and answer questions. The admin experience in a remote Kubernetes development environment can vary depending on the specific tools and resources used, but generally, it involves managing and maintaining the remote Kubernetes cluster, ensuring security and compliance, allocating resources, and providing integrations and support.
• Scalability: The fact that the individual clusters run in a cloud environment makes them infinitely scalable. Well, almost. Because when larger teams of developers are involved, individual clusters can max out their limit as admins will have to put in more effort as the team expands.
• Flexibility: Production environments for systems that are cloud-based can be completely realistic. Plus, individual environments (clusters) can be configured effortlessly to match the developer’s exact needs or are at least similar to the settings of the production environment.
• Isolation: The most secure way to isolate developers (and limit the blast radius of misbehaving applications under development) is by using cluster-level isolation. On a public cloud, the isolation of individual developers’ clusters is practically the same as that of bigger teams running production clusters. This is obviously of great importance to cloud providers.
• Cost: Most cloud KDEs use the ‘pay-as-you-run’ billing method. This means you pay for what you use. Depending on the cloud platform, you will be charged for every resource you use. The Remote Kubernetes development environment is the most expensive compared to the rest.

Local to Remote Kubernetes Development Environment

Two major challenges cloud-native development teams face today is that it’s nearly impossible to replicate a Kubernetes-based application in a local dev environment because the resources used would vary from local system to cloud system.

Secondly, with Remote KDEs, developers always have to wait for their application to be containerized, pushed to a registry, and deployed to a remote Kubernetes cluster before seeing the impact of their code changes. This can be time-consuming and frustrating and can slow down the development process.

To address the challenges of the local and remote KDEs, the local-to-remote (sometimes called “remocal”) Kubernetes Development Environment was created. This development environment allows for a more efficient and streamlined development process, as developers can quickly see the impact of their code changes without waiting for the build-push-test cycle and seamlessly test their code updates with the remote dependencies in the remote Kubernetes cluster.

Let’s look at some features of the local-to-remote Kubernetes development environment.

• User/Developer Experience: In a local-to-remote Kubernetes development environment, developers easily set up, write, and test their code on their laptops, using their preferred IDEs and debugging techniques. Then they can use the local-to-remote setup to forward requests to and from the remote Kubernetes cluster, allowing them to test their code in a production-like environment and almost immediately see the impact of your code changes. Local-to-remote environment eliminates the need for complex setup and configuration and allows developers to focus on their code and application development.
• Admin Experience: Here, the admin experience is similar to the Remote KDE admin experience. If the development team has an administrative system implemented, then admins are responsible for installing or granting permissions to developers to install things like network proxies or configuring access on the cluster. Admins are also responsible for setting up and managing the remote Kubernetes cluster and monitoring the deployment and operation of applications on the cluster. You can learn more about the administration control system of the local-to-remote KDE on the Telepresence official documentation.
• Scalability: Local-to-remote Kubernetes development environments are highly scalable. The Kubernetes cluster can be easily scaled up or down, locally or remotely, to accommodate the needs of the development team.
• Flexibility: Local-to-remote Kubernetes development environments allow developers to enjoy the benefits of working locally and remotely at the same time. It also provides developers the freedom to choose the tools and technologies they prefer to use, allowing them to work in their preferred environment and workflow.
• Isolation: With measures such as encryption in place to protect against external threats, the Local-to-remote KDE ensures that the connection between the local environment and the remote cluster is secure.

Telepresence is one of those tools that enables Kubernetes teams to adopt the local-to-remote development environment in their workflow. It allows you to quickly review the impact of your code changes and refactor it without the need to constantly redeploy your application to a remote Kubernetes cluster.

Some features of Telepresence I’ve found to be very fascinating include its ability to accelerate your inner development loop to ship features faster, the provision of a secured preview URL to share your development environment with teammates and collaborate on fixes without wasting time reproducing bugs across everyone’s machine, tripping over your teammates or impacting the production environment.

What’s the difference between the Local, Remote, and Local-to-Remote Kubernetes Development Environment?

Note: The above table is a generalization, and your mileage may vary depending on the tools and resources you use. It is important to evaluate the pros and cons of each type of development environment depending on the specific requirements of your project, team, and organization.

Conclusion

As explained in this article, the various types of Kubernetes development environments come with their pros and cons.

For instance, the Local KDEs are cheaper in cost, but developers without enough Kubernetes experience and larger teams might have to deal with several limitations.

On the other hand, Remote KDEs have unlimited flexibility but can be super expensive if not managed properly. The local-to-remote KDEs combines the advantages of local and remote Kubernetes development environments, making it easier and more convenient for developers to work with Kubernetes.

Thanks for reading this article to the end. I hope you found it helpful. Happy Building!