Serverless Orchestration : Kubernetes

Kubernetes is a software that automatically manages, scales and maintains multi-container workloads in desired states.
Modern software in increasingly run as fleets of containers, sometimes called microservices. A complete application may comprise many containers, all needing to work together in specific ways. Kubernetes is a software that turns collection of physical or virtual hosts(servers) into a platform that :
1. Hosts centralized workloads, providing them with compute, storage, and network resources and,
2. Automatically manage large scale numbers of centralized applications — keeping them healthy and available by adapting to changes and challenges.

A) How does Kubernetes work ?

1. You package your application code into a container image and push it to a container registry.
2. You create a deployment configuration file that specifies the number of replicas of your application that you want to run, and other details such as the container image to use and the resources that each replica should have.
3. You deploy your application to Kubernetes by creating a deployment object in the Kubernetes API.
4. Kubernetes schedules the replicas of your application onto the nodes in the cluster.
5. Kubernetes monitors the health of the replicas and ensures that the desired number of replicas are running at all times.
6. If a replica fails, Kubernetes automatically creates a new replica to replace it.
7. You can use Kubernetes to scale your application up or down by increasing or decreasing the number of replicas.
8. You can also use Kubernetes to roll out updates to your application by creating a new deployment with the updated container image.

B) Why use Kubernetes?

1. Scalability: Kubernetes makes it easy to scale your application up or down by increasing or decreasing the number of replicas of your application.
2. High availability: Kubernetes can ensure that your application is always available by automatically restarting failed replicas and scheduling them onto different nodes in the cluster.
3. Automated rollouts and rollbacks: Kubernetes makes it easy to deploy new versions of your application and roll back changes if necessary.
4. Environment consistency: With Kubernetes, you can define the environment that your application runs in (e.g., the container image, resource limits, etc.) and deploy that environment consistently across different environments (e.g., development, staging, production).
5. Ease of use: Kubernetes has a large and active community that has developed a wide range of tools, libraries, and integrations to make it easier to use and extend.
6. Flexibility: Kubernetes is designed to be highly modular and extensible, with a rich set of APIs that you can use to automate the deployment and management of containerized applications.

C) Kubernetes Architecture

Kubernetes Architecture

1. The API server: The API server is a key component of the Kubernetes control plane. It is the central way that all other components interact with the cluster. The API server exposes the Kubernetes API, which processes REST requests and updates the etcd store with the objects it manages.
   The API server is responsible for the following tasks:
   1. Serving the REST API that other components use to interact with the cluster.
   2. Validating and configuring the data that is stored in etcd.
   3. Persisting objects in the database.
   4. Sending events to the API clients.
   The API server is the frontend for the Kubernetes control plane and is the only component that communicates directly with the etcd database. All other components must go through the API server to access the cluster’s data.
   The API server is designed to be horizontally scalable and can be run on multiple machines to improve the performance and availability of the API. It can also be run on a single machine for development and testing purposes.
   The API server is the primary point of contact for users and other external components, such as the Kubernetes command-line interface (kubectl) and the Kubernetes dashboard.
2. etcd: etcd is a distributed key-value store that is used to store the cluster’s persistent state. It is a critical component of the Kubernetes control plane, as it stores the configuration data that is used to manage the cluster.
   etcd is designed to be highly available, meaning it can continue to function even if some of its instances fail. It uses the Raft consensus algorithm to ensure that the data stored in the cluster is consistent and to coordinate updates to the data.
   In a Kubernetes cluster, etcd is typically run as a separate set of pods, and is used by the Kubernetes API server to store and retrieve data about the cluster. This data includes information about the state of the cluster, such as the current set of nodes and the current configuration of pods and services.
3. kubelet: The kubelet is a critical component that runs on each node in the cluster. It is responsible for maintaining the desired state of the node, as defined by the control plane, and ensuring that the node’s actual state matches the desired state.
   The kubelet does this by communicating with the Kubernetes API server and receiving instructions about which pods should be running on the node. It then starts and stops pods as necessary to ensure that the desired state is achieved
   In addition to managing pods, the kubelet is also responsible for a number of other tasks related to node management. This includes reporting the node’s status to the API server, starting and stopping pods when nodes are added or removed from the cluster, and working with other node components (such as container runtime and network plugins) to ensure that pods are properly isolated and have access to the necessary resources.
4. kube-proxy: The kube-proxy is a network proxy that runs on each node in the cluster. It is responsible for implementing a portion of the Kubernetes networking model, specifically the part that deals with routing traffic to and from pods.
   The kube-proxy works by monitoring the Kubernetes API server for changes to the set of pods that are running on the node, and then updating the node’s iptables rules to reflect these changes. When a new pod is created or an existing pod is deleted, the kube-proxy will add or remove iptables rules to ensure that traffic to and from the pod is properly routed.
   The kube-proxy also plays a role in providing service discovery and load balancing for pods. When a service is created in Kubernetes, the kube-proxy will create a virtual IP (VIP) that is used to route traffic to the service. It will then use the VIP and iptables rules to load balance traffic among the pods that belong to the service.
5. Scheduler: The scheduler is a component that is responsible for assigning pods to nodes in the cluster. It is responsible for ensuring that pods are placed in a way that maximizes resource utilization and meets the availability and performance requirements of the applications that are running in the cluster.
   The scheduler works by continuously monitoring the state of the cluster and the pods that are running in it. When a new pod is created or an existing pod is deleted, the scheduler will assess the current state of the cluster and select an appropriate node for the pod to run on. It does this by considering a number of factors, including the available resources on each node, the resource requirements of the pod, and any affinity or anti-affinity rules that have been specified for the pod.
   The scheduler is a critical component of the Kubernetes architecture, as it is responsible for ensuring that pods are placed in a way that maximizes resource utilization and meets the availability and performance requirements of the applications that are running in the cluster.
6. Controller manager: The controller manager is a component that runs a set of controllers that are responsible for maintaining the desired state of the cluster. Each controller is a separate loop that monitors the cluster for a specific type of resource (such as pods or nodes) and makes changes to the resource as necessary to ensure that it matches the desired state.
   For example, the replication controller is a type of controller that is responsible for maintaining the desired number of replicas of a particular pod or set of pods. If the number of replicas falls below the desired level, the replication controller will create new pods to bring the number back up to the desired level. If the number of replicas exceeds the desired level, the replication controller will delete excess pods to bring the number down to the desired level.
   The controller manager is responsible for starting and stopping controllers as necessary, and for providing a consistent point of entry for the controllers to access the Kubernetes API server.
7. Container runtime: The container runtime is the software that is responsible for running containers on a node. It is responsible for pulling the container image from a registry, unpacking the image, and creating the container process.
   The container runtime is an essential component of the Kubernetes architecture, as it is responsible for actually executing the containers that make up the applications that are running in the cluster.
   There are several container runtime options available for use with Kubernetes, including Docker, containerd, and CRI-O. The choice of runtime can depend on a number of factors, such as the operating system being used, the requirements of the applications being run, and personal preference.

As an additional resource you can check out : What Is Kubernetes Architecture? — Components Overview

References :
1. https://www.techaheadcorp.com/blog/kubernetes-vs-docker/
2. https://www.redhat.com/en/topics/containers/kubernetes-architecture
3. https://www.geeksforgeeks.org/kubernetes-architecture/