Main Components of Kubernetes

‍

Kubernetes is a modular platform with three components groups: Master, Worker, and Addons; making Kubernetes flexible and extensible.

‍

‍

To deploy Kubernetes, you will need a cluster, and for those who might not be familiar with the term “cluster” is nothing more than a group of machines or nodes, acting as a single system.

For the Kubernetes setup, you need a cluster with at least one worker and one master. However, the minimum recommended is three workers and one master.

The exciting part of the Kubernetes cluster is the new mindset that we, as operators, must adopt. For now, let’s simplify it, thinking in terms of resources rather than machines or nodes.

What do I mean by that?

Before, we used to arrange our deployments manually on each server, but with Kubernetes, we can look at the cluster as a big pool of resources regardless of how many servers are connected.

Spoiler alert: this is how a simple Kubernetes cluster looks like. Let’s break it down in three groups: Master, Worker, and Addons.

‍

‍

The Master Components

Let’s begin with the Master components, as you probably already guessed, they run in the Master node, and they are the control plane making global decisions inside the cluster.

These components are the API server, etcd, scheduler, controller-manager, and cloud controller manager.

API server: This component exposes via API the Kubernetes control plane. This is how the Kubernetes CLI or “kubectl” interacts with the cluster.

The etcd: Etcd is a key/value store database where all the Kubernetes data gets stored and when all means like all of it.

The scheduler: The scheduler watches for pods and finds them a node with enough resources to run.

Then, the controller manager. This component is a single binary composed of four sub-processes and they are:

• The node controller: Responsible for the health of the nodes in the cluster.
• The replication controller: responsible for keeping the desired amount of pods for each replication.
• The endpoints controller: handles the Endpoints object that links services and pods.
• The service account and token controller: handles the default accounts and API access for namespaces.

The last master component is the cloud controller manager, which handles all interactions with your cloud provider. It works similar to the regular controller manager, but just for the cloud provider. As you can see, controllers are very powerful but there is more. In future episodes, we will talk about to create your own controller.

Worker Node Components.

These components are known for running on each worker node, unlike the master components, which mainly runs in one master at the time, the worker node has four very light components, make sense because you want to reserve most of the space for your pods.

‍

‍

The kubelet, which makes sure all containers are running and healthy.

The proxy allows communication to the inside network of the cluster by using network rules, mainly used for development and testing pods, it is recommended to remove it in production for security reasons.

The container runtime, which is responsible for running the containers, the most common runtimes choices are: Docker and Containerd

The add-ons.

Which provides cluster-level features by using Kubernetes resources such as DaemonSet and Deployments. These components cover areas like networking, DNS, metrics, logging, and more.

Subscribe to us or sign up for newsletter (here) for a notification when a new article comes out.

If you are interested in the video version of our post, check out our vlog (here).

Kubernetes concepts: https://kubernetes.io/docs/concepts/overview/components/

‍

‍