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.
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.. 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.
- kind cli detects provider type (docker or podman)
2. Validate provider settings and check if node container can be created
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
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.
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.
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.
Voila!!!! You got yourself a kubernetes cluster in few mins. Isn’t that awesome 👏🏻😇