You Don’t Need Kubernetes on Your Laptop

Jon Edvald
Jun 27, 2019 · 4 min read

A quick note: we’ve moved our blog over to garden.io, and you can also read this post there.

My least favorite part of working with Kubernetes is running it on my laptop.

It gobbles up my CPU and battery, keeps the fans running non-stop, and it’s a nuisance to maintain.

Image for post
Image for post
For added effect, a relevant stock photo.

Minikube, kind, k3s, Docker for Desktop, microk8s, etc. are all good efforts designed to make that as pleasant as possible, and kudos to all of them. Seriously. But no matter how you slice it, Kubernetes isn’t designed to run on my laptop. Nor is my laptop designed to run a cluster of containers in layers of VMs. The poor thing will try its best, but it won’t like it, and will show its dissatisfaction by making its fans scream, and scalding my thighs if I’m not careful.

Let laptops be laptops, we say.

Garden is a tool for developers, in the same area as Skaffold and Draft, that makes developing and testing Kubernetes applications faster and easier.

Since we started working on Garden, about eighteen months ago, we knew that developing distributed systems locally was a stop-gap solution, so we designed Garden with a lot of flexibility in mind and laid some solid foundations.

Now we’re ready to support both local and remote Kubernetes environments, and it’s better than ever: you can now run all your builds, deployments, and tests in a remote cluster.

In short:

With Garden v0.10 you can completely get rid of your local Kubernetes cluster, and still enjoy rapid feedback while you write your code. All free and open source.

Image for post
Image for post
Enjoy the same developer experience with remote and local environments.

Okay, you have my attention.

Sharing development clusters has broader implications, especially for teams working together, and for CI pipelines.

“How so?”

First off, the in-cluster builder — either a standard Docker daemon or Kaniko — and the bundled in-cluster registry are shared cluster-wide. Meaning, your team can share a development cluster, and all the build caches and images are shared across all developers. Because Garden tags your images based on hashes of your source files, the tags and layers are consistent between users.

This means that once any developer has built a version of an image, your whole team has as well. Day in and day out, developers download the same base images and build the exact same things on separate computers. I wonder how much bandwidth and electricity has been wasted on that…

And the same goes for tests: test results are stored cluster-wide and are available for your whole team, in much the same way. Once one developer has tested a version of your code, no-one has to repeat the exact same test.

So it’s not just about not having to run minikube. This leap opens up a lot of optimizations for your team — no more redundant builds and test runs!

What was that about CI?

You can run the same exact commands in CI as when you develop, and use the same environment, caches and test results.

Your CI basically becomes a bot developer working in the same environment as you.

Image for post
Image for post
All the moving parts, through development and testing.

You can drastically simplify your CI pipeline configs. Just run Garden from CI to do the builds, tests, and deploys — and because you and CI use the same environment, you’re much less likely to find yourself debugging CI issues.

All that poking at thousands of lines of configs and scripts, then pushing, waiting, hoping, rinsing, and repeating ad nauseam… None of that. You just develop. No extra steps.

And just to make it crystal clear: When you or anybody on your team has built or tested something with Garden, so has your CI. If you don’t change anything after running tests yourself, your CI doesn’t need to test it again, or even build it. Garden just checks the box and goes straight to your other workflows, like spinning up a preview environment, pushing artifacts, and so on.

Sounds good! How do I try it out?

Join us at the #garden on Kubernetes Slack if you have any questions, problems, or just want to chat. We’re eager to help and get feedback from you.

Thanks again for all your help with the post, Ellen Körbes. ❤

Garden

Kubernetes and cloud native testing platform

Jon Edvald

Written by

CEO, founder @ garden.io

Garden

Garden

Garden is a Kubernetes and cloud native testing platform for every step of the development process. With Garden, spin up on-demand, production-like testing environments for integration tests, QA, and development.

Jon Edvald

Written by

CEO, founder @ garden.io

Garden

Garden

Garden is a Kubernetes and cloud native testing platform for every step of the development process. With Garden, spin up on-demand, production-like testing environments for integration tests, QA, and development.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store