Kubernetes as a Dev Tool

Kubernetes standardizes interfaces around packaging and running applications, networking, storage, and ways to extend a generic control plane. This creates the perfect platform for building developer tools.

Standardized interfaces remove the need for (some) language-specific tooling. Take webpack-dev-server. It’s responsible for bundling, packaging, and running a JavaScript application. But a large part of the design of the tool should be language agnostic — a middleware system that runs an inner loop of tasks like file-watching, rebuild, redeploy, port-forwarding, and live previewing an environment. Nearly every language has one of these: Flask for Python, hot swapping built into IDEs for Java, and many more development servers. Some of them have more production/development parity than others, but in all cases, functionality is duplicated in bespoke ways across languages.

What if we had APIs that provided most of these out of the box in a language-agnostic way?

With a Kubernetes-based platform, the build step becomes packaging a container (or syncing files to an existing container and running a hot-reloading module inside the container). The deploy step becomes a declarative configuration that determines the ports that are forwarded, the commands that are run, and the volumes that are mounted. Networking, port-forwarding, and service discovery are just common API calls. Logs have a common format. Production deployments look a lot more like their development counterparts (in theory, this means fewer bugs).

At Google, I built two tools that helped move towards this goal: minikube (run Kubernetes locally on your laptop) and skaffold (a tool which used these APIs to optimize around the common APIs). Both provided a simple way to set up a reproducible developer environment with a single command (“minikube start && skaffold dev”). Development, CI, and production are the same workflows with different configurations. Start on a local cluster, and extend to hybrid resources that lived on other clusters (in the cloud).

The vision was never fully realized, but I still believe that building developer tools on top of Kubernetes is a promising path.