How to set up a Kubernetes development environment. Compare local clusters like kind and minikube, live-reload tools like Tilt and Skaffold, remote and cloud-based development, and request-level isolation that lets you develop against real dependencies without rebuilds.
A Kubernetes development environment is where developers write, run, and test their services against the Kubernetes platform and its real dependencies, rather than against a stripped-down local stand-in. The challenge is that a modern application can span dozens of microservices, so the “just run it all locally” model that worked for a monolith breaks down. This guide covers the main ways to develop on Kubernetes, from local clusters and live-reload tools to remote and cloud-based environments and request-level isolation, and how to choose between them. For the decision-framework version, see our hub guide to local development on Kubernetes.
I saw a post on Reddit recently that was labeled a ‘n00b question’ that felt like it revealed a much more basic question with Kubernetes: how do you define a local dev environment?
What is the best way to have my frameworks (back-end and front-end) working, with the ability to edit files on them in realtime, without having to rebuild images, restart pods, etc.
The question really stems from a starting place that this is really easy to do with a single containerized workload, e.g. with Docker.
With docker-compose, it’s all real simple, e.g. if I work on a django project, I will just create a couple of compose files with a few containers (python, postgres, nodejs, nginx, etc.) with different targets for dev and production, use a bind mount (projectdir/django_app/ -> /django_app inside the container), edit the code, then use CI/CD tools to build images, push to a private repo, etc.
When trying to answer the user’s question, I thought of kind: kind is a tool for running local Kubernetes clusters using Docker container “nodes”. kind was primarily designed for testing Kubernetes itself, but may be used for local development or CI. The Signadot team uses kind to test whether something will work on multiple versions of Kubernetes. However in my experience kind is not a tool for doing the live reloads that this user, and others, are hoping to use.
At least two tools are specifically targeted at this use case.
Tilt is an ephemeral environment tool intended for small teams. Tilt is a tool to automate build and deploy processes for microservices. Technically, it can handle so much more than just a simple controller, but it serves this purpose well.
Gergely Brautigam has a nice writeup on using Tilt for local testing.
Skaffold is a command line tool that facilitates continuous development for container based & Kubernetes applications. Skaffold handles the workflow for building, pushing, and deploying your application, and provides building blocks for creating CI/CD pipelines.
One potential solution for scaling local development is to use a cloud-based Kubernetes environment, such as AWS EKS or GKE. This allows for larger clusters with more resources, and can provide a more production-like environment for testing and development. However, this approach may not be feasible for smaller teams or those with limited budgets. You’re also going to be dealing with longer build and push times to test small code changes. Further, as your team grows will be that a cloud-based testing environment will end up getting ‘fought over’ as everyone wants to test their changes at the same time.
While these are all great tools, they’re not all going to scale to very large engineering teams or super-large clusters. One redditor with a 5 node dev cluster sees it quickly use all available storage. Further, as discussed in my recent writeup on large teams testing on Kubernetes, while these tools will prevent you having to re-build your containers with each local code change, over time the daily process of updating all the other containers in the cluster and building the whole thing will start to impact developer velocity.
Instead of squeezing a cluster onto a laptop, many teams move the development environment into the cloud. A remote Kubernetes development environment runs your code on a real cluster while you keep editing locally, which removes the resource ceiling of a laptop and gives you a more production-like target. Tools that sync your local files into a running pod, or proxy traffic between your machine and the cluster, make this practical. Approaches range from a full per-developer namespace or cluster to lighter, shared models.
The tradeoff is the one the Reddit thread hinted at: dedicated remote or cloud environments per developer get expensive and slow to provision, and a single shared cluster gets “fought over” as everyone tries to test at the same time. The real question becomes how to give every developer a high-fidelity, isolated place to work without duplicating the whole stack.
The most resource-efficient answer is to run only the one service you are changing, locally or in a sandbox, and connect it to a shared, production-like baseline cluster for everything else. Signadot’s local development workflow does exactly this: a lightweight tool routes specific requests from the shared cluster to the service running on your machine, while all other dependencies resolve to the live baseline services. You get instant feedback on local code changes, with no rebuilds and no need to replicate dozens of services.
Because isolation happens at the request level rather than by duplicating infrastructure, many developers can work against the same baseline cluster at once without interfering with each other. This is the same model behind ephemeral environments in Kubernetes and request-level isolation, applied to the inner development loop.
Signadot connects the service you are working on to a shared, production-like Kubernetes cluster, so you get instant feedback without replicating the whole stack. The free tier is open to every developer.
Start freeFor most teams running real microservices, the practical answer is a combination: a local cluster for quick iteration on isolated pieces, and a shared baseline with request-level isolation for high-fidelity integration work. For the testing side of this, see the complete guide to microservices testing.
Developing on Kubernetes does not have to mean fighting your laptop or queuing for a shared environment. Local clusters and live-reload tools solve the inner loop for small pieces, while remote and request-level approaches let you work against real dependencies at scale. The right choice depends on how many services you run and how production-like your feedback needs to be.
Run only the service you are changing and share the rest of your cluster. High-fidelity development against real dependencies, at a fraction of the cost of duplicating environments.
Start free
Get the latest updates from Signadot
