One of the past maintainers of minikube here. Minikube, while targeted towards Kubernetes developers, also provides all the features you'd want here. It also takes away most of the pain from virtual machine management w/ native hypervisors.
If you're looking for customizability (boot image, docker version, container runtime), minikube is probably your best bet. It even comes with some rudimentary file-sharing and port-forwarding primitives, but it isn't as batteries-included as Docker desktop. On the other hand, you have full ssh access to the VM to do whatever you want (+startup scripts, etc.)
Awhile back, I wrote up a comparison of all the Docker Desktop Alternatives. [1]
I use kubernetes for pushing stuff to AWS EKS, and it is great. The problem I found with minikube and other Kubernetes based "alternatives" to Docker Desktop (including podman) is that they are not compatible with Docker Compose. There are a * a lot * of "solved problems" via docker-compose.yml files, and all of my past companies have used it. I've tried some docker-compose to k8s migration tools, but the amount of crap files they generate was not feasible for me.
Nerdctl[1] (for containerd) works fine with docker-compose.yml for my purposes (which are not much). The only issue I encountered was with environment variable substitution not working the same as docker-compose, but I didn't look hard for a solution and edited my compose file
Helm charts are roughly the k8s equivalent of docker compose. Might be a few years before they’re as widespread but a lot of common things you’d want to host are largely “solved” already.
There's one big difference between Docker Desktop and minikube and the ones referenced in the docker desktop alternatives link. Docker Desktop is a desktop app (GUI and all) while all the listed alternatives are terminal apps.
For some this might not matter but for others it does.
Rancher Desktop[1] has the desktop app install experience, the GUI, and the the tools (Docker CLI/nerdctl, Kubernetes (k3s), etc), and more.
I agree, I think the GUI is important for the kinds of users who feel lost without Docker Desktop. There have been plenty of other ways for technical users to run their containers all along (really, you could just run your own VM with vagrant if nothing else) but the people who want a "point and click" turnkey experience will appreciate the GUI.
Another kind of nice thing about Rancher Desktop is it's cross platform, so even Linux users can use it. That could be nice if you have a mix of Linux and Mac devs and want to use the same tooling here. It also makes sure you don't "mess up" your real Linux system or run into any distro-specific version incompatibilities (since it's all in a disposable VM controlled by Rancher Desktop).
I've tinkered with Rancher Desktop periodically and I think it's a promising tool. For now I keep going back to running Docker directly, only because it's my existing workflow (I'm a Linux user so the Docker Desktop changes don't apply to me).
It should be noted that minikube does not work on the M1. Sadly we started switching devs over to M1 at the same time we finished up switching our local environment over to minikube.
The issue that I had with Minikube is that I couldn’t get it to work with my employer’s VPN enabled. I realize that this is more the fault of my employer’s strict no-split-tunneling configuration than Minikube’s, but sadly that is the reality I live in.
I ended up using lima vm, which has an elegant port forwarding solution to make everything running on the VM appear as if it is running on localhost.
Having made the switch, I also prefer the simplicity and transparency of know exactly how the VM is configured, and being able to make tweaks to the provisioning script if necessary. Minikube on the other hand felt a bit automagical at times.
kind (Kubernetes-in-Docker) still requires Docker, so its not a replacement for Docker Desktop (Windows/macOS). You'll need to run kind in minikube or kind in Docker Desktop.
> kind was primarily designed for testing Kubernetes itself, but may be used for local development or CI.
minikube was designed for those who want a local kubernetes environment for development. It didn't work well for testing Kubernetes itself which led to kind. They had two different, though slightly overlapping, goals.
minikube is good where you have to have a VM, which is development on Windows and OS X. Linux containers need Linux, much to the dismay of laptop buyers I guess.
I personally don't bother. I use Windows but just have a pet Linux VM where I actually do work, and then use kind (with podman; Docker seems to be turning the screws and I'm getting out ahead of that).
I prefer Minikube over Kind, because Minikube supports a lot more options and features, and has integrated the same features as Kind. Kind has not had a new release for almost a year.
If you're looking for customizability (boot image, docker version, container runtime), minikube is probably your best bet. It even comes with some rudimentary file-sharing and port-forwarding primitives, but it isn't as batteries-included as Docker desktop. On the other hand, you have full ssh access to the VM to do whatever you want (+startup scripts, etc.)
Awhile back, I wrote up a comparison of all the Docker Desktop Alternatives. [1]
[1] https://matt-rickard.com/docker-desktop-alternatives/