Kubernetes Architecture Explained: Overview for DevOps Enthusiasts
Kubernetes is popular because it allows for the efficient management of containerized applications and services. It does this by automating the deployment, scaling, and management processes, ensuring that applications run smoothly and reliably. Kubernetes provides a powerful solution for modern application management that is quickly becoming the industry standard.
In this article, we’ll explore how Kubernetes works, its architecture, and the role played by its different components. We’ll start by looking at a basic overview of the Kubernetes cluster architecture and then drill down into each component.
An Overview of Kubernetes Architecture
We’ll use an analogy of a container-carrying ship to explain Kubernetes architecture.
Let's start! The purpose of Kubernetes is to host your applications in the form of containers in an automated fashion so that you can easily deploy as many instances of your application as required and easily enable communication between different services within your application.
So there are many things involved that work together to make this possible.
So let’s take a look at the Kubernetes architecture from above. We have two kinds of ships in this example, cargo ships that do the actual work of carrying containers across the sea and control ships that are responsible for monitoring and managing the cargo ships.
The Kubernetes cluster consists of a set of nodes, which may be physical or virtual, on-premise or on the cloud, that host applications in the form of containers.
In our cargo ships analogy, you can think of ships as worker nodes. But somebody needs to load the containers on the ships and not just load, plan how to load, identify the right ships, store information about the ships, monitor and track the location of containers on the ships, manage the whole loading process, etc.
This is done by the controller ships that host different offices and departments, monitoring equipment, communication equipment, cranes for moving containers between ships, etc.
In our analogy, you can think of the Kubernetes master node as the control ship. The master node is responsible for managing the Kubernetes cluster storing information regarding the different nodes, planning which containers go where, monitoring the nodes and containers on them, etc. The master node does all of these using a set of components, together known as the control plane components.
Want to learn how to set up a Kubernetes cluster on your local machine? Check out this step-by-step guide: How to Setup a Kubernetes Cluster with Minikube & Kubeadm
Kubernetes Control Plane Components
The Kubernetes control plane is essentially the brains behind the operation of a Kubernetes cluster. The control plane consists of several components, including the API server, etcd, scheduler, controllers, container runtime engine, and kubelet, which work together to ensure that the cluster functions properly and that applications are running smoothly.
Let’s now see the role of each of these components.
ETCD
Etcd is responsible for storing the configuration data of the cluster, which includes information about the nodes, pods, and services. It stores this information in a highly available key-value store.
Schedulers
The scheduler identifies the right node to place a container on based on the containers’ resource requirements, the worker nodes capacity or any other policies or constraints, such as taints and tolerations or node affinity rules that are on them. It ensures that the resources of the cluster are used efficiently and that workloads are distributed evenly across the nodes.
Controllers
Controllers in Kubernetes are components responsible for managing and maintaining a desired state of resources in the cluster. They monitor the state of resources and make necessary changes to ensure that they match the desired state. This includes creating, updating, and deleting resources and objects as needed.
The node controller takes care of nodes. They’re responsible for onboarding new nodes to the cluster and handling situations where nodes become unavailable or get destroyed. And the replication controller ensures that the desired number of containers are running at all times in your replication group.
Controllers work in conjunction with the scheduler to ensure that workloads are assigned to nodes and managed properly.
Kube API server
A Kube API server in Kubernetes is a key component that serves as the primary interface for managing the cluster. It provides a RESTful API that allows users to interact with the Kubernetes control plane and perform actions such as deploying and scaling applications, monitoring the cluster, and managing resources.
It is responsible for validating and processing incoming requests and communicating with other Kubernetes components such as the etcd datastore and the kubelet agents running on each node.
Container Runtime Engine
The container runtime engine in Kubernetes is responsible for managing the lifecycle of containers, including starting and stopping them. It is the component that actually runs the containers and provides the isolation between them. Examples of container runtime engines in Kubernetes include Docker, rocket, and Containerd.
Kubelet
A Kubelet is an agent that runs on each node in a cluster. It listens for instructions from the Kube API server and deploys or destroys containers on the nodes as required. The Kube API server periodically fetches status reports from the Kubelet to monitor the status of nodes and containers on them.
Kube-Proxy
Kube-proxy is a network proxy that runs on each node in a Kubernetes cluster. Its main function is to handle network routing for services in the cluster. It maintains network rules on the host system for forwarding traffic to the appropriate containers or services based on IP address and port number.
To learn more about Kubernetes architecture, watch this video.
Final Words
So, to summarise, we have the master and worker nodes. On the master, we have the etcd, which stores information about the cluster. We have a scheduler that is responsible for scheduling applications or containers, or nodes. We have different controllers that handle different functions like the node controller, replication controller, etc. We have a Kube API that serves as the primary interface for managing the cluster.
On the worker node, we have the Kubelet that listens for instructions from the Kube API server and manages containers. Lastly, the Kube proxy enables communication between services within the cluster. That’s a high-level overview of the various components.
Learn Kubernetes
Looking to gain or polish your Kubernetes skills? Check out the following course from KodeKloud:
You can also test your Kubernetes expertise with our FREE, fun, and challenging set of hands-on challenges.