Acing the CKAD

Kubernetes Architecture Explained

Yay! We are already 3 articles into the CKAD Tips series. As always, these articles are geared towards helping you excel when you take the CKAD examination. In today’s article, I’ll explain one of the most important things you need to know when working with Kubernetes — the Kubernetes Architecture.

It is very unlikely that you will be asked about the Kubernetes architecture during the CKAD exam because the CKAD is more of a practical, hands-on exam than a theoretical exam. However, understanding the Kubernetes Architecture gives you the proper foundation for grasping the practical bit of Kubernetes and how it works.

Kubernetes (K8s) is a container orchestrator that helps you automate, deploy, scale, and manage your containerized applications. An example of this is if a containerized application stops working, Kubernetes can restart it for you, and if a container isn’t responding to your user-defined health check, Kubernetes kills it and doesn’t advertise it to clients until it is ready to serve traffic.

For containerized applications to be deployed into Kubernetes, they are placed in pods; the pods are then scheduled to be hosted on available nodes. In the world of Kubernetes, nodes can either be physical or virtual machines with a given role, and a collection of these nodes using a shared network to communicate with each other is called a cluster.

The components of this cluster make up the Kubernetes architecture, and that’s what I’ll be demystifying further in this article. 👇

Understanding the Kubernetes Architecture

As mentioned earlier, a Kubernetes cluster consists of nodes that run containerized applications. Of these nodes are the master nodes, also collectively known as the control plane, which is responsible for managing the cluster, and the worker nodes, collectively known as the data plane, which runs the cluster’s workload (containerized applications).

Consider an army of soldiers reporting to a commander. The commander acts as the brain of the operation and gives the soldiers instructions for them to follow. Once the soldiers follow the commander’s instructions and complete them, the mission they set out to achieve has been completed. If anything goes wrong, they report back to the commander and await further instructions.

In the world of Kubernetes, the army commander is the Control plane, while the soldiers are the worker nodes.

Here’s a quick overview of how it works; When you want to deploy a containerized application into a Kubernetes cluster, you have to make an API call to the server using a custom client or local client like kubectl.

This API call is made to the control plane’s kube-apiserver component, which then communicates to another control plane component called the kube-scheduler to schedule the containerized application on an available node in the Kubernetes cluster. Then, a worker node component called kubelet receives the spec information of the containerized application, implements the request that was made, and reports back to the control plane (just like the soldier reports back to the commander).

Let’s talk about the components of the master and worker nodes in detail. 👇

The Components of the Kubernetes Control Plane

The control plane in a Kubernetes cluster consists of these five components:

kube-apiserver

The kube-apiserver component is the entrance to the Kubernetes control plane. It is responsible for processing and validating requests.

Kubernetes exposes an API via the kube-apiserver and allows us to communicate with the API using a custom client or a local client called kubectl. All calls, both internal and external traffic, are handled via the kube-apiserver.

etcd

Orchestrating involves control loops that coordinate and confirm the different tasks done and that the operations taken produce the desired effect. In order to do this, there has to be a source of truth that will be used for these verification purposes.

The etcd is a key-value pair store used to hold and manage the state of the cluster, critical information, and networking metadata that distributed systems need to keep running. It serves as that source of truth in a Kubernetes cluster!

The kube-apiserver is the only Kubernetes control plane component connected to the etcd — meaning all requests made to discover the state of the cluster or Kubernetes object passes through the kube-apiserver (and that’s why the kube-apiserver is also responsible for validating requests).

kube-scheduler

Assigning containers to a certain node is known as scheduling. This is what the kube-schedulercomponent is in charge of.

After an API request has been made to the kube-apiserver to deploy a container into a Kubernetes cluster, the kube-scheduler finds a suitable node to run that container on as a Pod.

The kube-scheduler reviews the worker nodes (aka data plane), their computing power, and availability and then schedule the containerized application unto the node.

kube-controller-manager

In Kubernetes, there are different controllers that watch the shared state of the cluster through the kube-apiserver and makes changes attempting to move the current state towards the desired state. For instance, the Node controller is responsible for noticing and responding when nodes go down.

The kube-controller-manager component is a compilation of all these different individual controllers into a single controller manager.

cloud-controller-manager

The cloud-controller-manager component lets you link your cluster into your cloud provider’s API like AWS, GCP, etc., and separates the components that interact with that cloud provider from components that only interact with your cluster.

The cloud-controller-manager only runs controllers that are specific to a cloud provider. If you run Kubernetes on your computer using tools like minikube or kind, that cluster will not have the cloud-controller-manager component.

The Components of the Kubernetes Data Plane

Compared to the Control plane, the worker nodes have a lesser number of components. Let’s break them down:

kubelet

Remember how we talked about the relationship between the control plane (the army commander) and the data plane (the soldiers)? The control plane passes instructions to the data plane which is then expected to implement the instructions and report back to the control plane on the state of the cluster.

The component in the data plane responsible for implementing these instructions is the kubelet. It acts as a moderator between the control plane and each of the nodes in a cluster, receives spec information for container configuration, downloads and manages any necessary resources, and works with the container engine on the local node to ensure the container runs or is restarted upon failure.

kube-proxy

This component is a network proxy that runs on each node and maintains network rules on them. These network rules allow network communication to your Pods from network sessions inside or outside your cluster.

Container Runtime

Remember we said containerized applications are wrapped in a pod and placed on a node in a Kubernetes cluster. These nodes must have a container runtime like Docker or cri-o to work as intended. And since Kubernetes is an orchestration tool for containerized applications, it supports container runtimes.

Previously, Kubernetes supported only the Docker container runtime, but as the project grew, it began to add support for other container runtimes.

The Kubernetes community then decided to move to a more structured, standardized Container Runtime Interface (CRI) instead of directly integrating third-party solutions like Docker into the core code. Learn more about the dockershim removal and deprecation from Kubernetes in this article by Matt Campbell.

Summary

The control plane and data plane work together, each performing the operations and tasks that make Kubernetes the powerhouse it is.

Understanding the inner workings of the Kubernetes architecture is very important, not just for the CKAD, but also as a Kubernetes Engineer. I hope you found this article useful. If you have any questions, share them in the comment section below.

Ace the CKAD with me!

This article is part of the CKAD Tips weekly series, where I write articles that will enable anyone studying for the CKAD to excel during the examinations. Stay up to date on the latest additions to this series by following us on Medium and Twitter.

The CKAD series, so far:

• Frequently Asked Questions About the CKAD Exam, Answered
• 6 Reasons You Should Take the CKAD
• How to create & connect to a Google Cloud VM using SSH on Mac/Linux
• Kubernetes Architecture Explained
• Kubernetes Object Management Techniques — why you should know them before taking the CKAD exam
• CKAD/CKA Exam Tips from 10 People Who Passed the Exam
• How to Use the Vim Editor
• Debugging and Fixing Kubernetes Apps during the CKAD Exam