I switched my local "lab" setup from minikube (which was in use for a long time) to kind recently. The main reasons were
None of us run on Linux which means we're all using VMs for our containers and we all use Docker Desktop for various things. That meant we're running extra local VMs for no good reason. With kind I can just use the one vm for all the container things.
But the real reason for the actual switch was I just kept running into things that minikube couldn't do and Kind could, as well as having things I had decided to ignore like the fact that minikube does everything on one node which is 100% unnatural for kubernetes and I had multiple cases where this setup blinded me to problems that would occur in a real cluster.
3) I've also found I prefer the configuration/customization approach of kind over minikube though admittedly that's kind of a small thing.
Ultimately I find kind is a better simulator for the purpose of prototyping future cluster changes as well as use as a local "lab" for diagnosing services in a "production like" environment 100% under your control.
kind was originally built for developing kubernetes itself, as a cheaper option for testing changes to the core components.
it wasn't really meant to compete with minikube et. al, but complement for differing usage, but you may now find it useful as a lightweight option with a slightly different feature set.
it's also the only local cluster that is fully conformant as far as I know, because conformance tests involve verifying multi-node behavior, at the time minikube did not support
- building kubernetes from a checkout and running it
- docker based nodes
- multiple nodes per cluster
These days they've gotten more similar, we're both shipping docker and podman based nodes.
I think one of the most interesting things about kind is that the entire kubernetes distro is packed into a single "node" docker image, it's very easy to work with fully offline.
I really wish you had used a regular service definition when testing KinD. The omission reduces the usefulness of your comparison. I want to choose a local k8s cluster that is as close to production as possible. And I want my local deployment configs to be as close as possible to production.
You say that "ingress in kind is a little trickier than in the above platforms" with no explanation.
For me, use Docker if you want k8s started up every time you start Docker, and easy ingress. I don't love having a cluster always running, so I'm keeping the k8s function off by default.
Use kind if you want multi-node clusters, and a production-like simulation of your environment.
Use minikube for a straightforward dev experience, where you have control over k8s version, resource allocation, and don't need meaningful configuration of the control plane.
That is pretty neat but it is nice to have a tool that had it built natively, rather than having to search through 30 different provider flags with Minikube. Hopefully there documentation has gotten better but I'd generally trust the innovation behind the Kind tool than the Minikube devs who are late to the game.
you can simulate multiple nodes for example, if you want to experiment with node selectors or test having a multi-node setup, it's quite easy with kind
I tend to recommend minikube to new comers as it provides easy addons like ingress, image registry, load balancer via minikube tunnel. You can run minikube with 2GB
Easy when only dealing with one node.
Once your familiar then I will recommend Kind when you need more than one worker node and test scenario that require multiple nodes or if you know your way to install and configure addons yourself
