Understanding kind cli with developer’s 👀

In this article, we will be taking kind to GoLand Operation Theatre and rip it apart by expert Chroot Tech 😉 to loop into inner beauty of kind’s code.

First thing first, what the heck is kind?

Kind is cli application which creates kubernetes cluster using docker container as kubernetes nodes. Since you know how easy it is to create and dispose off docker containers. It makes kind very developer friendly tool to create kubernetes clusters and test application changes on it.

so easy to create and delete clusters in kind.. kind is really kind :)

Before I start, hat’s off to the maintainers & contributors of this project for writing such an awesome tool and making developer’s life easier.

Github Repo Link: https://github.com/kubernetes-sigs/kind

Website: https://kind.sigs.k8s.io

What happens when we run command ‘kind create cluster’?

“What a dumb question? that’s a simple one, isn’t it that kind cluster gets created” 🤔

ok!! here’s another one for fun 🤭

ok.. let’s deep dive

Kind supports docker (no introduction needed) & Podman (open source tool to manage, run containers, developed by RedHat along with OpenSource contributors) to create containers which will work as kubernetes node and eventually will start kubernetes cluster within these containers.

1. kind cli detects provider type (docker or podman)

kind cli detecting provider

2. Validate provider settings and check if node container can be created

kind cli validating provider settings

3. Kind code execution then configures default values in kind config and starts cluster creation workflow which involves various actions and create node container is one of it

kind cluster create workflow then invoke provider to create container.

3.a. Provision Node Container: Provider interface will call docker or Podman based on what is installed on the host, to create a container with kindest/node image which is pre-created with all necessary files to bootstrap kubernetes services inside that container

kind/pkg/cluster/internal/providers/docker/provision.go at main · kubernetes-sigs/kind

3.b. Kubeadm-Init Action: Node container is created with specific image which is pre-created with kubeadm and all required manifests to bootstrap kubernetes cluster. Once container is running, kind cli runs below kubeadm-init command with this kubeadm config inside that container which starts etcd and api-server inside container.

Based on node configurations, nodes are tainted.

3.c. Install CNI (Container Network Interface) : Once kubeadm-init phase is completed, kubernetes cluster gets started and it is accessible but since there is no CNI installed, we can’t use it to deploy any workloads as networking is required to run any pod.

kind/pkg/cluster/internal/create/actions/installcni/cni.go at main · kubernetes-sigs/kind

3.d. Install CSI (Container Storage Interface): Once CNI is installed then we can deploy stateless applications inside it which doesn’t persist any data locally and thus doesn’t need any external volume. But, kind also deploys local-path-provisioner CSI which provisions volume in host path, which means inside docker node container which was created in step 3.a.

kind/pkg/cluster/internal/create/actions/installstorage/storage.go at main · kubernetes-sigs/kind

4. Kubeadm Join (Optional): Once CSI is installed, if there are worker-nodes defined in kind-configuration then kind will run kubeadm-join command in containers created for worker-nodes.

kind/pkg/cluster/internal/create/actions/kubeadmjoin/join.go at main · kubernetes-sigs/kind

Voila!!!! You got yourself a kubernetes cluster in few mins. Isn’t that awesome 👏🏻😇