Kubernetes Architecture Explained | Day 30 of 90 Days of DevOps

Hello everyone and welcome to Day 30 of 90 Days of DevOps.

In this blog, I will explain the architecture of Kubernetes, one of the most popular tools for container orchestration and management.

Kubernetes is an open-source, cloud-native platform that allows you to deploy, scale, and manage your applications across multiple nodes and clusters.

Kubernetes Overview

Before diving into the architecture of Kubernetes, let’s first understand what Kubernetes is and why we call it k8s. Kubernetes is a Greek word that means “helmsman” or “pilot”. It is also the origin of the word “cybernetic”, which means “the science of control and communication in animals and machines”. Kubernetes is a fitting name for a tool that helps you control and communicate with your containers and machines.

Kubernetes is also abbreviated as k8s, where the number 8 represents the number of letters between the first and the last letter of Kubernetes. This is a common way of shortening long names in the tech industry, such as i18n for internationalization and a11y for accessibility.

Benefits of using Kubernetes

Kubernetes provides many benefits for developers and operators who want to run their applications in containers. Some of the benefits are:

• High availability: Kubernetes ensures that your applications are always up and running by automatically restarting failed containers, rescheduling them to different nodes, or scaling them to meet demand.
• Load balancing: Kubernetes distributes the traffic among your containers by exposing them as services with their own IP addresses and DNS names. It also supports service discovery and routing mechanisms to connect your services with each other.
• Scalability: Kubernetes allows you to easily scale your applications up or down by changing the number of replicas or using horizontal pod autoscaling. You can also scale your cluster by adding or removing nodes as needed.
• Portability: Kubernetes enables you to run your applications on any platform that supports Kubernetes, such as public clouds, private clouds, hybrid clouds, or bare metal servers. You can also migrate your applications across different environments without changing your code or configuration.
• Automation: Kubernetes automates many tasks that are otherwise tedious or error-prone, such as deployment, rollback, configuration management, secret management, service discovery, resource allocation, health monitoring, etc.
• Extensibility: Kubernetes is designed to be modular and pluggable, so you can customize it to suit your needs. You can use various tools and plugins that integrate with Kubernetes, such as Helm, Istio, Prometheus, etc. You can also extend Kubernetes by adding your own custom resources and controllers.

Architecture of Kubernetes

Kubernetes follows a client-server architecture that consists of two main components: the control plane and the data plane. The control plane is responsible for managing the state and configuration of the cluster, while the data plane is responsible for running the workloads and services on the cluster.

The control plane consists of several components that communicate with each other through the API server. The API server is the central hub that exposes the Kubernetes API and processes all requests from clients and other components. The etcd is a distributed key-value store that stores the cluster data in a consistent and reliable way. The scheduler is responsible for assigning pods to nodes based on various factors such as resource requirements, affinity rules, etc. The controller manager runs various controllers that handle different aspects of the cluster such as node lifecycle, replication, service endpoints, etc. The cloud controller manager interacts with the underlying cloud provider to manage cloud-specific resources such as load balancers, storage volumes, etc.

The data plane consists of several components that run on each node in the cluster. The node is a physical or virtual machine that hosts one or more pods. A pod is a group of one or more containers that share the same network namespace and storage volumes. A container is a lightweight and isolated environment that runs an application process. The kubelet is an agent that runs on each node and communicates with the API server to register the node, report its status, and execute pod operations. The kube-proxy is a network proxy that maintains network rules on each node and enables service abstraction by forwarding requests to backend pods. The container runtime is software that runs and manages containers on each node. Kubernetes supports various container runtimes such as Docker, containerd, CRI-O, etc.

The following diagram illustrates the architecture of Kubernetes:

Kubernetes Architecture

Control plane

The control plane is the component of Kubernetes that controls and manages the state and configuration of the cluster. It consists of several components that communicate with each other through the API server. The control plane components are:

• API server: The central hub that exposes the Kubernetes API and processes all requests from clients and other components.
• etcd: A distributed key-value store that stores the cluster data in a consistent and reliable way.
• scheduler: Responsible for assigning pods to nodes based on various factors such as resource requirements, affinity rules, etc.
• controller manager: Runs various controllers that handle different aspects of the cluster such as node lifecycle, replication, service endpoints, etc.
• cloud controller manager: Interacts with the underlying cloud provider to manage cloud-specific resources such as load balancers, storage volumes, etc.

The control plane components can run on a single node or multiple nodes for high availability and fault tolerance. The control plane node is also called the master node.

Difference between kubectl and kubelet

kubectl and kubelet are two different tools that are used to interact with Kubernetes. The main difference between them are:

• kubectl is a command-line interface (CLI) tool that allows you to communicate with the API server and perform various operations on the cluster, such as creating, updating, deleting, or inspecting resources. You can use kubectl on any machine that can access the API server, such as your local machine or a remote server.
• kubelet is an agent that runs on each node in the cluster and communicates with the API server to register the node, report its status, and execute pod operations. You can use kubelet to manage the pods and containers on a specific node, such as starting, stopping, or restarting them.

Role of the API server

The API server is the central hub of the Kubernetes control plane that exposes the Kubernetes API and processes all requests from clients and other components. The API server performs the following roles:

• It validates and configures the data for the API objects, such as pods, services, deployments, etc.
• It updates the etcd store with the latest state of the API objects.
• It provides a RESTful interface for clients to access and manipulate the API objects.
• It handles the authentication and authorization of clients and enforces admission control policies on requests.
• It supports various features such as versioning, discovery, aggregation, webhooks, etc.

The API server is designed to be scalable and extensible. You can run multiple instances of the API server and balance the traffic between them. You can also extend the API server by adding custom resources and controllers.

Conclusion

In this blog, I have explained the architecture of Kubernetes and its main components. I hope you found this blog useful and learned something new.

If you have any questions or feedback, please feel free to leave a comment below or contact me on GitHub or LinkedIn.

Thank you for reading and happy learning!