• etcd: etcd is the log book of the ship. That is where all the details about the expected configuration exist. From a technical perspective, this is a key-value store where all the desired Kubernetes configuration is stored. The controller manager refers to the information in this database to action changes in the cluster.
  • Scheduler: The schedulers are the boatswain of the ship. They are tasked with supervising the process of loading and unloading containers on the ship. A Kubernetes scheduler schedules containers in a worker node it finds fit after considering the availability of resources to run it, the HA of your application, and other aspects.
  • kubelet: kubelets are the seamen of the ship. They carry out the actual loading and unloading of containers from a ship. From a technical perspective, the kubelet interacts with the underlying container runtime to run containers on the scheduler’s instruction. While most Kubernetes components can run as a container, the kubelet is the only component that runs as a systemd service. They usually run on worker nodes, but if you plan to run the control plane components as containers instead, the kubelet will also run on the control plane nodes.
  • kube-proxy: kube-proxy runs on each worker node and provides the components for your containers to interact with the network components inside and outside your cluster. They are vital components that facilitate Kubernetes networking.

Well, that’s a lot of moving parts, but the good news is that tools are available to set that up for you, and provisioning a Kubernetes cluster is very simple. If you are running on a public cloud, it is only a few clicks away, and you can use your cloud’s web UI or CLI to provision it very quickly. You can use kubeadm for the setup if you have an on-premises installation. The steps are well documented andunderstood and won’t be too much of a hassle.

For development and your CI/CD environments, you can use Minikube or Kubernetes in Docker (KinD) . While Minikube can run a single -node Kubernetes cluster on your development machine directly by using your machine as the node, it can also run a multi-node cluster by running Kubernetes nodes as containers. KinD, on the other hand, exclusively runs your nodes as containers on both single -node and multi-node configurations. You need a VM with the requisite resources in both cases, and you’ll be good to go.

In the next section, we’ll boot a single-node Kubernetes cluster with Minikube.

Installing Kubernetes (Minikube and KinD)

Now, let’s move on and install Kubernetes for your development environment. We will begin with Minikube to get you started quickly and then look into KinD. We will then use KinD for the rest of this chapter.

Leave a Reply

Your email address will not be published. Required fields are marked *