It's been a few years since I was a maintainer of minikube, but after the news that Docker Desktop will no longer be free for enterprises and some of the misconceptions of how the technology works, I thought I'd write a post.
Edit: Since this is blowing up, I wanted to say that I'm a frequent Docker Desktop user and would happily pay for it for my entire team. As someone who knows the problem space, its a piece of machinery with so many moving parts that are hard to get right.
Like I said in my 10k Hours of Programming, I'm not an expert programmer, but this might be a topic I've spent a lot of time working on. Let's start with minikube.
Minikube is the officially supported way to run Kubernetes locally on macOS, Windows, or Linux. Furthermore, it is the only tool that is a drop-in replacement for Docker Desktop.
- Minikube requires a VM. False – you can run minikube directly on Linux without a virtualization layer. Running minikube without a virtual machine is equivalent to a batteries-included version of kubeadm.
- Minikube and Docker-for-Mac are fundamentally different. False. Both use similar drivers under the hood for macOS and Windows virtualization. However, Docker's are proprietary, minikube's are open-source.
- kind, microk8s, or k3s are replacements for Docker Desktop. False. Minikube is the only drop-in replacement. The other tools require a Linux distribution, which makes them a non-starter on macOS or Windows. Running any of these in a VM misses the point – you don't want to be managing the Kubernetes lifecycle and a virtual machine lifecycle. Minikube abstracts all of this.
A deeper dive into the other tools:
k3s – a minimal distribution of Kubernetes. k3s requires Linux. Minikube works on all platforms.
Minikube's internal architecture looked like k3s long before k3s was created – a binary called localkube ran all the Kubernetes components in different goroutines. While it was quick to set up and tear down, we ran into non-conformance issues before the conformance program was designed. Since minikube vendored internal APIs, upgrading was a herculean task. Now, minikube now provisions with kubeadm. k3s is a more viable option now that the development of Kubernetes has slowed and there aren't as many breaking changes. But a few CPU cycles isn't really worth the headache of having your developer debugging why SQLite (k3s) is acting differently than etcd (minikube).
microk8s – a Snap distribution of Kubernetes. Only for Linux. Not sure why you would use it. Minikube has been far more battle-tested and is multi-platform, and doesn't require lock-in to a pseudo-package manager. you can run it in multipass, which spins up virtual machines, but it isn't as turnkey as minikube.
kind – kind runs Kubernetes inside Docker. Of course, this requires that you already have Docker on your machine. Why choose minikube over kind? You have to choose between friction with VM networking (minikube) or friction with two layers of container networking (kind). I'm biased, but I feel more comfortable with a layer of VM networking.
podman – podman is an alternative to Docker, but get mentioned as a replacement for the Docker component (not Kubernetes) of Docker Desktop. You can use podman inside of minikube.
In closing, I think that the outrage over Docker's decision is far overblown. If you're an enterprise using Docker Desktop at scale, then you should be paying for support. I'm actually really excited about the current direction of Docker and the focus the team is putting on developer tools. There are talented folks building some great features at Docker.
The most significant benefit to minikube is that you can fully customize and fork the distribution. This is great for platform teams that need to deliver a tailored experience to their end-users (developers).
More like this: