We all know how the IT sectors moving fast towards containerization, microservices, automation, etc. Most of the organizations are looking for Kubernetes professionals who have competency in containerization and orchestration tools. This blog describes the key components of Kubernetes.
What is Kubernetes?
Kubernetes is an open-source multi-container management (orchestration) tool that automates deployment, scaling, descaling, and load balancing of the containers.
Kubernetes cluster: A Kubernetes cluster is a set of nodes grouped, this way even if one node fails you have your application still accessible from the other node. There are mainly two components in a Kubernetes cluster.
- Kubernetes Master: There are one or more Master nodes in the Kubernetes cluster. The k8s master has 4 components API Server, scheduler, controller manager and etcd which are responsible for maintaining the state of the cluster.
- Worker Nodes: A node is a virtual or physical machine on which Kubernetes is installed. Container runtime, Kubelet & Kube-proxy are the major components for the worker nodes.
Kubernetes master node components:
API Server: The API server acts as the front end for Kubernetes. The users, management devices, command-line interfaces all talk to the API server to interact with the Kubernetes cluster through REST API or Kubectl.
Before performing any action i.e creating, deleting, or updating the object in etcd by API server, several plugins validate the request.
When the client is making any request to API Server, it needs to authenticate the by authentication plugins(s). Once the client gets authenticated, it passed to Authorization Plugin(s), which validates that the client has access to perform the requested action. Once the authorization is passed the request will be sent to Admission Control Plugins (ACP). An admission controller plugin intercepts the requests and initializing any missing fields or default values. Once the request passed all these checks then API Server validates the object and stores it in etcd.
Scheduler: The scheduler is responsible for distributing work or containers across multiple nodes it looks for newly created containers and assigns them to nodes.
Controller-manager: The controllers are the brain behind orchestration. They are responsible for noticing and responding when nodes, containers, or endpoints go down. in such cases, the controllers take decisions to bring up new containers. There are several different controllers available under the controller manager
- Node Controller
- Deployment Controllers
- Replication Controller
- Endpoints Controller
- StatefulSet Controllers
- Service Account and Token Controllers
- Namespace Controllers
- PersistentVolume Controllers
ETCD: ETCD is a distributed reliable key-value store used by Kubernetes to store all data used to manage the cluster. Think of it this way. When there are multiple masters and nodes in the cluster, ETCD stores all that information on all the nodes in the cluster in a distributed manner. ETCD is responsible for implementing locks within the cluster to ensure that there are no conflicts between the Masters.
Kubernetes worker node components:
Kubelet: Kubelet is the agent that runs on each node in the cluster. The worker nodes have to Kubelet agent that is responsible for interacting with a master to provide health information of the worker node and carry out actions requested by the Master on the worker nodes.
Container runtime: To run and manage a container’s lifecycle, we need a container runtime on the worker node.
Kube-proxy: Kube-proxy runs on each node of the cluster as a network proxy and a load balancer for a service on a single worker node. Kube-proxy is responsible to maintain network rules on the node. These network rules allow network communication Pods from network sessions inside or outside of your cluster.
Pod: A pod in Kubernetes is a logical group of one or more containers. These containers share the same resource like they have the same IP and shared storage. Containers within the pod can communicate to each other via localhost or 127.0.0.1 and they can also find each other by inter-process communication like SystemV, semaphores, or POSIX shared memory.
