Introduction to Kubernetes Architecture and its Components

1. Introduction to Kubernetes Architecture & its Components The main objective of Kubernetes is to mask the complexity of managing a fleet of containers by providing REST APIs for the required functionality Kubernetes follows a client-server architecture. It is possible to have a multi-master configuration (for high availability), but by default, there is only one master server that acts as a control node and point of contact. The master server consists of various components, including a Kube-apiserver, storage etcd, a Kube-controller-manager, a cloud-controller-manager, a Kube-scheduler and a DNS server for Kubernetes services. Node components include kubelet and kube-proxy above Docker.

2. High level Kubernetes architecture showing a cluster with a master and two worker nodes Main components etcd cluster - a simple, distributed key value store that is used to store Kubernetes cluster data (such as number of pods, status, namespace, etc.), API objects, and discovery details on duty. It is only accessible from the API server for security reasons. etcd enables cluster notifications on configuration changes with the help of observers. Notifications are API requests on each etcd cluster node to trigger updating of information in the node's storage. kube-apiserver - The Kubernetes API server is the central management entity that receives all requests for REST modifications (to pods, services, replication sets / controllers and others), serving as an interface to the cluster. In addition, it is the only component that communicates with the etcd cluster, ensuring that data is stored in etcd and in accordance with the service details of the pods deployed.

3. kube-controller-manager - runs a number of separate controller processes in the background (for example, the replication controller controls the number of replicas in a pod, the endpoint controller populates the endpoint objects as services and pods, etc.) to regulate the shared state of the group and perform routine tasks. In the event of a modification of a service configuration (for example, replacement of the image from which the pods run or modification of the parameters in the yaml configuration file), the controller detects the modification and starts working towards the new desired state. cloud-control-manager - is responsible for managing controller processes with dependencies on the underlying cloud provider (if applicable). For example, when a controller has to check if a node has been stopped or configure routes, load balancers or volumes in the cloud infrastructure, all this is managed by the cloud-controller-manager. kube-scheduler - helps plan pods (a group of collocated containers inside which our application processes run) on different nodes depending on resource usage. It reads the operational requirements of the service and plans it on the most suitable node. For example, if the application needs 1 GB of memory and 2 processor cores, the pods for this application will be scheduled on a node with at least these resources. The scheduler runs whenever it is necessary to schedule modules. The planner must know the total available resources as well as the resources allocated to the existing workloads on each node. Here are the main components found on a node (worker): kubelet - the main service on a node, regularly taking into account the specifications of new or modified pods (mainly via the kube-apiserver) and ensuring that the pods and their containers are healthy and working in the desired state. This component also reports to the master on the integrity of the host on which it is running. kube-proxy - a proxy service that runs on each work node to manage individual host subnets and expose the services to the outside world. It transfers requests to the appropriate pods / containers on the various isolated networks of a cluster. The kubectl command is an online tool that interacts with kube-apiserver and sends commands to the master node. Each command is converted into an API call.