Architecture of Kubernetes in Detail (Day22)

Hey Everyone!

In our previous discussion, we delve into Kubernetes. If you haven’t read it yet, you can check it out [here]. Today, we will see Architecture of Kubernetes in more detail.

Kubernetes Architecture, the open-source container orchestration engine that is revolutionizing the way we deploy and manage applications.

Kubernetes Cluster

Kubernetes follows client-server architecture where the Master Node and Worker node exist which constitutes a ‘Kubernetes Cluster’. A Kubernetes cluster consists of a group of nodes, including at least one Master (also known as the control plane) and one Worker Node. We can have multiple worker nodes and Master nodes according to the requirement.

Control Plane

The control plane components, including the API server, etcd, scheduler, and controller manager, are typically found on the master node(s) of a Kubernetes cluster. These components are responsible for managing and controlling the cluster as a whole.

Master Node

The master node is responsible for the entire Kubernetes cluster and manages all the activities inside the cluster in which master nodes communicate with the worker node to run the applications on the containers smoothly. Master Node has four primary components which help to manage all the things that we have discussed earlier:

1. API Server: In simple terms, after installing kubectl on the master node, developers run commands to create pods. These commands are sent to the API Server, which then forwards them to the appropriate components responsible for creating the pods. In other words, the API Server is the entry point for any Kubernetes task and follows a hierarchical approach to implement them. The API Server acts as the frontend of the Kubernetes cluster.
2. Etcd: is a key-value store that holds all the information about the entire cluster, including Pods’ IPs, Nodes, networking configurations, etc. It provides the cluster’s actual state information. Data from the API Server is stored in Etcd. Although Etcd is not a component of Kubernetes itself, it is crucial to the Kubernetes process. Without it, Kubernetes cannot function. Only the kube-apiserver has access to the Etcd cluster.
3. Controller Manager: The Controller Manager ensures that the actual state of the cluster matches the desired state. It retrieves the actual state information from Etcd. The Controller Manager collects data from the API Server about the desired state of the cluster, decides what actions to take, and then sends instructions back to the API Server. It ensures that the services requested in your manifest file are provided and maintained.
4. Scheduler: Once the API Server gathers information from the Controller Manager, it notifies the Scheduler to perform tasks such as increasing the number of pods. After being notified, the Scheduler takes action to allocate the required resources and schedule the work on the appropriate nodes. It is responsible for ensuring the cluster’s actual state aligns with the desired state.

Let’s understand all four components with a real-time example.

Master Node — Mall Management: In a shopping mall, there is a management office responsible for overseeing all activities and ensuring the smooth operation of the mall. Similarly, in Kubernetes, the Master Node manages and coordinates all activities in the cluster.

kube-apiserver — Front Desk: Think of the kube-apiserver as the front desk or central control desk of the mall. It’s where all requests (such as opening new stores or handling customer inquiries) are directed. In Kubernetes, the kube-apiserver communicates with all components, processing and forwarding commands.

etcd — Master Records: etcd can be compared to the master records of the mall, storing crucial information such as store locations, hours of operation, and other configurations. In Kubernetes, etcd is a key-value store that maintains configuration data and the cluster’s state.

kube-controller-manager — Task Managers: Imagine the mall has specialized task managers for different departments, such as security and maintenance. In Kubernetes, the kube-controller-manager oversees various tasks to ensure the cluster operates as expected. It continuously monitors the actual state of the cluster and works to align it with the desired state, such as ensuring the desired number of pods are running and that other cluster-level tasks are performed.

kube-scheduler — Scheduler Manager: Think of the kube-scheduler as a manager who decides which employees (pods) should work in which stores (on which worker nodes). The scheduler ensures an even distribution of tasks and efficient resource allocation within the mall, just as it does within the Kubernetes cluster. It carries out the real work of moving from the actual state to the desired state. When the kube-controller-manager identifies a need (e.g., more pods are required), it requests the kube-scheduler to allocate resources and schedule these pods to run on specific worker nodes.

To communicate with a Kubernetes cluster, you create a manifest file in YAML or JSON format. This manifest file defines the desired state of the cluster, including specifications for resources such as pods, services, deployments, and more. When you apply this manifest file using kubectl, it sends the file to the kube-apiserver. The kube-apiserver then processes the file and coordinates with other components to achieve the desired state described in the manifest.

Worker Node

The Worker Node is the mediator who manages and takes care of the containers and communicates with the Master Node which gives the instructions to assign the resources to the containers scheduled. A Kubernetes cluster can have multiple worker nodes to scale resources as needed.

The Worker Node contains four components that help to manage containers and communicate with the Master Node:

1. Kubelet: The kubelet is a primary component of a Worker Node responsible for managing and maintaining the state of pods. It communicates with the API Server on the Master Node to get details about pods and their desired state. The kubelet ensures that pods are running as expected, and if a pod fails, it may attempt to restart it or create a new pod if necessary. The IP of each pod is unique but dynamic; if a pod is stopped and restarted, it may receive a different IP address. The kubelet listens for pod creation requests and sends success or failure reports to the Master Node. It generally operates on port 10255.
2. Kube-proxy: The kube-proxy manages network configurations and provides load balancing and routing for network traffic within the cluster. It gets information about pods and services from the API Server and handles the distribution of network traffic to the appropriate pods. The kube-proxy does not assign IP addresses to pods; instead, it manages the network traffic and ensures that requests reach the correct pod.
3. Pods: A pod is the smallest deployable unit in Kubernetes and can contain one or more containers. Pods provide the environment where containers run and share resources such as networking and storage. Each pod has its own IP address, which is dynamic; if a pod is restarted, it might receive a different IP address. Although Kubernetes manages containers within pods, it primarily interacts with pods, not individual containers.
4. Container Engine: The Container Engine provides the runtime environment for containers. In Kubernetes, the container engine interacts with the container runtime, which is responsible for creating and managing containers. Popular container engines include Docker, containerd, and CRI-O. The container engine works with the kubelet to pull images, start or stop containers, and expose containers as specified in the pod manifest.

Let’s continue to understand all four components with a real-time example.

Worker Nodes — Storefronts:

Kubelet — Store Managers:

• In each store (Worker Node), you have a store manager (Kubelet) who ensures employees (Pods) are working correctly.
• Kubelet communicates with the Master Node and manages the Pods within its store.

kube-proxy — Customer Service Desk:

• kube-proxy acts like a customer service desk in each store. It handles customer inquiries (network requests) and directs them to the right employee (Pod).
• It maintains network rules for load balancing and routing.

Container Runtime — Employee Training:

• In each store, you have employees (Pods) who need training to perform their tasks.
• The container runtime (like Docker) provides the necessary training (runtime environment) for the employees (Pods) to execute their tasks.

Wrapping Up
The worker node is the backbone of your Kubernetes cluster, responsible for managing containers and executing instructions from the master node. Understanding its key components, including Kubelet, kube-proxy, pods, and the container engine, is essential as we progress in our Kubernetes journey.

In our next blog post, we’ll explore how these worker nodes interact with the master node to create a harmonious Kubernetes cluster. Stay tuned for more Kubernetes goodness!

Happy learning, Kubernetes explorers! 🚢🌐

Stay connected on LinkedIn: LinkedIn Profile

Feel free to reach out to me, if you have any other queries.

Happy Learning :)