Hacker News Reader

Comment by dickeytk | Hacker News Reader

what are the advantages over minikube?

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.

We use Kind. I think one of the best thing about Kind is that

- You can run it on Github actions. So, you can test in your CI pipeline.

- You can run any recent version of Kubernetes.

- Kind can start a Kubernetes cluster under a minute on a developer machine.

You can technically get Minikube running in Actions, but it's a bit annoying.

author here, some background:

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.

FWIW, I did a comparison of k8s in Docker, KinD, and minikube last week ... https://seroter.wordpress.com/2020/03/10/lets-look-at-your-o...

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.

I feel disappointed and frustrated. :(

Sure. I cheated. I specifically didn't feel like setting up extraPortMappings (https://github.com/kubernetes-sigs/kind/issues/808), and then create an ingress controller (https://kind.sigs.k8s.io/docs/user/ingress/). Not difficult, just not turnkey availability like the other two.

Read through it. Do you have a sort of TL;DR summary of pros/cons? A matrix I can use to make a decision as a new k8s user.

Good suggestion.

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.

AFAICT, minikube requires a full VM, whereas this doesn't seem to. So it should, in theory, be much more lightweight.

Minikube now has both a docker[1] and a native driver[2]. The docker driver is derived from Kind.

1. https://minikube.sigs.k8s.io/docs/reference/drivers/docker/

2. https://minikube.sigs.k8s.io/docs/reference/drivers/none/

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.

this is simply a container with a docker runtime in it, it's haeavy in that sense

actually we run containerd and I think you will find it is comparatively lightweight and fast compared to most options :-)

it's certainly heavier than _not_ using Kubernetes

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

Reply on news.ycombinator.com