Creating a Productive Local Development Environment with Kubernetes

Tools, practices, and configuration for creating an effective local development loop when building and deploying apps to Kubernetes

Ask any developer what their top priority is when working with a new application or new technology stack and they will point to creating an effective local development environment. This is primarily focused on installing all of the tools they need to be productive. The goal is always to get a fast development feedback loop established that is as production-like as possible.

Although the goal remains the same when working with cloud native technologies, when adopting containers and Kubernetes there are a few more tools to install and configurations to tweak.

This guide applies to a developer simply experimenting with Kubernetes and also a new engineer onboarding onto a team deploying onto Kubernetes. The quicker a developer can get their local development environment configured, the quicker they can ship code to production. The gold standard is to ship code on the first day.

From Local Dev to Remote Deployment: Avoiding Cloud Complexity

Before Kubernetes

Before cloud native architecture became the dominant approach to designing, deploying, and releasing software the local development story was much simpler. Typically a developer would install the language runtime on their machine, download the application source code, and build and run the (often monolithic) application locally via their favourite IDE.

After Kubernetes

As applications and the underlying frameworks increased in complexity, the start time of an app in development increased. This often resulted in a slow coding feedback loop. This led to many web frameworks, IDEs, or custom tools enabling “hot reloading”. This capability allows code changes to be quickly visible (and testable) via the locally running application, without the need for a redeployment or restart.

With the rise in popularity of containers and Kubernetes has introduced more layers into a typical tech stack. There are clear advantages in relation to this, such as isolation and fault tolerance, but this has also meant that the local development setup has increased in complexity.

Related Resources

Thumbnail for resource: "[Podcast] Livin’ on the Edge #13: Dave Sudia on Kubernetes Local Development, Building a PaaS, and Platform Personas"
Podcast

[Podcast] Livin’ on the Edge #13: Dave Sudia on Kubernetes Local Development, Building a PaaS, and Platform Personas

Thumbnail for resource: "[Podcast] Livin’ on the Edge #14: Katie Gamanji on Kubernetes Tooling DX, GitOps, and the Cluster API"
Podcast

[Podcast] Livin’ on the Edge #14: Katie Gamanji on Kubernetes Tooling DX, GitOps, and the Cluster API

Thumbnail for resource: "[Podcast] Livin’ on the Edge #10: Sam Newman on Microservice Ownership, Local Development, and Release Trains"
Podcast

[Podcast] Livin’ on the Edge #10: Sam Newman on Microservice Ownership, Local Development, and Release Trains

Frequently Asked Questions

Do I need to use a new IDE when developing applications for Kubernetes?

No. Many IDEs offer plugins to add extra Kubernetes support, such as VS Code and IntelliJ IDEA but there is no need to search for a new IDE.

What’s the difference between developing applications for Docker and developing applications for Kubernetes?

Building and deploying a Docker container-based application only requires a developer to have Docker installed locally. Deploying applications into Kubernetes requires access to a cluster, which can be running locally (e.g. minikube, k3s etc) or remotely (e.g. GKE, AWS EKS etc).

Docker Desktop (or Docker for Mac and Docker for Windows) now include the option to install and run a local Kubernetes cluster. Developers that don’t want to install Docker or Kubernetes locally can also develop an application locally (without building a container) and connect and integrate with a remote cluster using a tool like Telepresence.

What’s the best practice for testing Kubernetes-based applications locally?

In addition to software development best practices like unit testing and component testing, for small applications a simple end-to-end test can be conducted by deploying all of the services that make up an application in a locally running Kubernetes cluster.

When a local development machine runs out of CPU or memory to run all the services in a local cluster, using a local-to-remote development tool like Ksync, Skaffold or Telepresence can allow integration testing.

How can I develop and test my application when I can’t run all of my applications in a local Kubernetes cluster (minikube, k3s, kind etc)?

Using a local-to-remote development tool like Ksync, Skaffold or Telepresence can enable a fast development loop and integration testing.