Kubernetes for beginners — Part 2
Welcome to the second part of my blog where I discuss about Kubernetes basics. As a recap, in the first part, I talked about topics like containers and nodes and why Kubernetes is used. In this part, I shall cover some details about the components of Kubernetes and how orchestration is achieved.
If this diagram looks complex now, fear not. We shall go through the entire system part by part, and by the end, you should be able to work your way through the process on your own. Ready? Let’s get started :
Components of Kubernetes cluster
If you look at the diagram of interest, there are 2 major components for the cluster(see 2 boxes with dotted outline?) : control plane and the nodes.
The control plane’s components make global decisions about the cluster (for example, scheduling), as well as detecting and responding to cluster events (for example, starting up a new pod when a deployment’s
replicasfield is unsatisfied). Node components run on every node, maintaining running pods and providing the Kubernetes runtime environment.
If you break it down, you can see the control plane components give instructions and the nodes execute the instruction. If you look at the task Kubernetes has in hand, which is deployment, you can see it is complex, which is why the functionalities have been divided into such a structure.
Control Plane components
kube-apiserver : This server is an implementation of Kubernetes API server. As you might be knowing, API or Application Programming Interface, is a software intermediary that allows 2 applications to talk to each other. If you take your favorite WhatApp for instance, an API is does the work of receiving your messages from your phone and sending it to your friend. Now similarly, the Kubernetes API allows user to interact with Kubernetes, and the Kubernetes API server exposes the API to the users. This server acts as the front end to the entire Kubernetes control plane.
Thus, the kube-apiserver is the point of contact for outside entities with the Kubernetes control plane. An interesting thing to note here is that this kube-apiserver is designed to scale horizontally, which means you can run several instances of the server simultaneously and balance traffic between them.
etcd : (pronounced et-cee-dee which comes from Unix “/etc” folder that stores data) It is a system that stores data in the form of key-value pair. Deployment and coordination is a huge task right, so lots of data will be involved to make that happen, which is where we use etcd. This etcd stores all critical data that is needed for the functioning of Kubernetes.
kube-scheduler : It is a program(code) that performs the following function — matches a newly created pod that doesn’t have a node yet with a node that can run the pod. If you recall, a pod is a running instance of a container, and a node is a virtual machine. So in essence, the kube-scheduler finds a virtual machine for a program to run, so it “schedules”. And this matching happens based on factors like how much memory is needed by the pods, hardware specifications, and so on.
kube-controller-manager : A controller is a process that controls some activity. There are 4 kinds of controllers namely, node controller, replication controller, endpoints controller and service account & token controllers. A node controller for instance check how many nodes are down and updates accordingly. I do not want to get into the details as it is beyond the scope of this “beginners” article. A kube-contoller-manager runs all these processes. This is analogous to how a team lead will coordinate the team members and a manager coordinates the team leads.
cloud-controller-manager : This component links your cluster to the cloud service provider’s API. It also creates a division between the components that interact with the cloud and the components that do not. If you jump back to the team example, this manager will be the program manager that coordinates activity between the other managers and external clients. If you look at the diagram, the cloud-contoller-manager is the only component that is in direct contact with the cloud platform.
Node components
kubelet : It is an agent that makes sure that all containers are running safely in a pod. It is present on each of the nodes in a cluster.
kube-proxy : It maintains network rules and monitors how the pods interact with each other. A lot of machines and instances will be running, and they all communicate through the internet. So we should have some service to monitor this communication right.
Well that was a lot of information to take right. If you look at all these components overall, you will be able to see that they are all just codes, programs and machines that are helping each other out. Of course the operation of Kubernetes is quite complex, but that is because there is so much that goes behind the deployment. This system was not developed over night, it was done through many iterations by many programmers. We should be thankful for being able to use such a huge product at ease, and we should also appreciate all the backwork that is done by the different components.
