Kind: Question: comparison with kubeadm-dind-cluster?

Created on 8 Nov 2018  路  5Comments  路  Source: kubernetes-sigs/kind

Most helpful comment

NOTE: this may not be 100% accurate and is only current as of this comment's writing.
Additionally, kubeadm-dind-cluster is a cool project and I've probably missed many features here.
There are others you should consider including:

With kind we're aiming to build something very maintainable and "hermetic" (minimal dependency on external resources, pre-pulled images etc) for the k8s project and some associated projects.

It is pretty similar to kubeadm-dind-cluster, but I'd say they make slightly different tradeoffs. EG kubeadm-dind-cluster patches in a hyperkube binary everywhere to try to optimize the Kubernetes build -> cluster loop as much as possible, whereas kind builds all of the artifacts you'd consume from a release, and does not patch any existing images etc..


| | kind | kubeadm-dind-cluster |
|-------------|-----|------------------------|
| primary implementation language | go | bash |
|multi-node | not yet 鈩笍 | yes |
| Kubernetes binaries / images | release build, pre-pulled into a "node" docker image | hyperkube patched into to replace all existing binaries |
| configuration | flags, Kubernetes style yaml config, full access to patch generated kubeadm config | environment variables |
| supported versions | Kubernetes v1.11+ (Currently) | Kubernetes 1.9+ |
| Kubernetes build support | make/bash/docker, bazel, released packages (apt) | make/bash/docker + supports remote docker |
| OS support | Linux, macOS, Windows (needs some more love, but functions without installing anything but kind and docker) | Linux, macOS |
| IPV6 | not yet :tm: | yes |
| CNI | weave currently, open to changing that if anyone needs to... | flannel, weave, calico, kube-router, ... |
| CI | full conformance tests for every supported branch / Kubernetes release | basic cluster up / smoke tests |
| CLI | fully featured cobra based command line binary | bash scripts |


Also from the kubeadm-dind-cluster README:

Important note: you need to do ./dind-cluster....sh clean when you switch between Kubernetes versions (but no need to do this between rebuilds if you use BUILD_HYPERKUBE=y like described below).

You do not need to do this with kind.

Generally kind has fairly default networking at the moment, we've not expanded on that yet, but it _should_ be very stable and we aim to have fast booting, reliable and conformant Kubernetes at arbitrary versions. we ship prebuilt images for releases, and will soon ship pre-built kind command line binaries.

I've also aimed to very explicitly note every single "hack" necessary to make this work at the very least in extensive code comments, and cited upstream documentation / articles as much as possible. In doing so I've ruthlessly eliminated unnecessary cargo-culted logic / hacks / work-arounds.

I hope kind will be relatively easy to understand for the average go / docker user. Unlike kubeadm-dind-cluster, kind is not a fork of any previous hacks, it is a clean rewrite from the ground up.

All 5 comments

one would be, dind-cluster is written in bash, while kind is written in go. :)

We should probably document some kind of comparison, I kinda loathe these things because it's hard to write a fair, objective one that brings up all useful points... there are tradeoffs with any Kubernetes setup.

/assign

NOTE: this may not be 100% accurate and is only current as of this comment's writing.
Additionally, kubeadm-dind-cluster is a cool project and I've probably missed many features here.
There are others you should consider including:

With kind we're aiming to build something very maintainable and "hermetic" (minimal dependency on external resources, pre-pulled images etc) for the k8s project and some associated projects.

It is pretty similar to kubeadm-dind-cluster, but I'd say they make slightly different tradeoffs. EG kubeadm-dind-cluster patches in a hyperkube binary everywhere to try to optimize the Kubernetes build -> cluster loop as much as possible, whereas kind builds all of the artifacts you'd consume from a release, and does not patch any existing images etc..


| | kind | kubeadm-dind-cluster |
|-------------|-----|------------------------|
| primary implementation language | go | bash |
|multi-node | not yet 鈩笍 | yes |
| Kubernetes binaries / images | release build, pre-pulled into a "node" docker image | hyperkube patched into to replace all existing binaries |
| configuration | flags, Kubernetes style yaml config, full access to patch generated kubeadm config | environment variables |
| supported versions | Kubernetes v1.11+ (Currently) | Kubernetes 1.9+ |
| Kubernetes build support | make/bash/docker, bazel, released packages (apt) | make/bash/docker + supports remote docker |
| OS support | Linux, macOS, Windows (needs some more love, but functions without installing anything but kind and docker) | Linux, macOS |
| IPV6 | not yet :tm: | yes |
| CNI | weave currently, open to changing that if anyone needs to... | flannel, weave, calico, kube-router, ... |
| CI | full conformance tests for every supported branch / Kubernetes release | basic cluster up / smoke tests |
| CLI | fully featured cobra based command line binary | bash scripts |


Also from the kubeadm-dind-cluster README:

Important note: you need to do ./dind-cluster....sh clean when you switch between Kubernetes versions (but no need to do this between rebuilds if you use BUILD_HYPERKUBE=y like described below).

You do not need to do this with kind.

Generally kind has fairly default networking at the moment, we've not expanded on that yet, but it _should_ be very stable and we aim to have fast booting, reliable and conformant Kubernetes at arbitrary versions. we ship prebuilt images for releases, and will soon ship pre-built kind command line binaries.

I've also aimed to very explicitly note every single "hack" necessary to make this work at the very least in extensive code comments, and cited upstream documentation / articles as much as possible. In doing so I've ruthlessly eliminated unnecessary cargo-culted logic / hacks / work-arounds.

I hope kind will be relatively easy to understand for the average go / docker user. Unlike kubeadm-dind-cluster, kind is not a fork of any previous hacks, it is a clean rewrite from the ground up.

Please re-open or file another issue if you have further questions. I'm going to hold off documenting anything further until kind has a proper support & release model in place, discussing this more today with @munnerz.

Thanks!

Was this page helpful?
0 / 5 - 0 ratings