Creating a Productive Kubernetes Local Development Environment
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 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.
Start Your Learning Journey
Skill level
Kubernetes Beginner
Time to complete
18 minutes • 4 lessons
What you'll learn
- How to create and configure a local dev environment to work with services deployed in Kubernetes
- Understand Kubernetes basics and cloud-native development concepts
- How to use Kubernetes for basic app development:
- Deploy a service from source code to a Kubernetes cluster
- Route traffic from the cluster’s edge to the app
What you need
Nothing! We’ll walk through learning the concepts and installing the tools you’ll need as we go.
Your journey begins here
Enter your email below to get started.
Ready to build your own productive local development environment?
This learning journey walks you through the primary concepts and hands-on activities required to create an effective local development environment with Kubernetes, which includes everything from the containerization of code to real-time local testing of distributed services.
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 favorite IDE.
Start Your Learning Journey
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.
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.
Supercharging Your Local Kubernetes Development Environment
Being able to effectively configure a local development environment for services deployed in Kubernetes is not dependent on a single tool or technique. A combination of approaches is required:
--> Container Build Tools
The ability to quickly and repeatedly build containers locally is vital when changing code and configuration. Many teams want to adopt industry-approved container build standards or don’t want the hassle of assembling their own containers, and here the use of build packs is popular.
--> Hot Reload
Developers want to quickly see the results of their code changes without having to redeploy or restart all of their services.
--> K8s-Aware Command Line
When deploying applications via the CLI to multiple K8s environments, both local and remote, it is essential to rapidly understand which context and namespace is being used. Being able to quickly and easily change context and namespaces is also valuable.
--> Kubernetes Dashboard
Not every developer wants to be at the command line the entire time they are working. Pointing and clicking around a high-level overview of an application’s deployment can support rapid learning and help identify problems such as high CPU or memory consumption.
--> Collaborative Remote Testing
When building distributed (microservice-based) systems, it is often the case that issues can only be recreated in certain environments. Being able to share access to these environments with both fellow developers and stakeholders enables a quicker find-fix-release dev loop.