Getting started with Kubernetes – Kubernetes Components

A Kubernetes cluster is made of control plane nodes and worker nodes. And the nodes are made up of a number of components with specific functionalities

Kubernetes follows a client-server architecture. It’s possible to have a multi-master setup (for high availability), but by default there is a single master server which acts as a controlling node and point of contact. The master server consists of various components including a kube-apiserver, an etcd storage, a kube-controller-manager, a cloud-controller-manager, a kube-scheduler, and a DNS server for Kubernetes services. Node components include kubelet and kube-proxy on top of a container runtime like docker.

Also checkout:

The Control plane (Master Components)

This is also the master node.

These nodes handle and manage the Kubernetes cluster. They don’t run any containers. The main components of a control plane node:

API Server
Scheduler
Controller-manager
Storage or etcd

API Server

It is the only entry point to a Kubernetes cluster that you directly interact with. User commands are sent to the API server, and we receive responses from the API server.

Kubernetes API server is the central management entity that receives all REST requests for modifications (to pods, services, replication sets/controllers and others), serving as frontend to the cluster. Also, this is the only component that communicates with the etcd cluster, making sure data is stored in etcd and is in agreement with the service details of the deployed pods.

Scheduler

The scheduler chooses which nodes(can be physical servers, VMs, cloud instances, anything) to run the user application on.

It helps schedule the pods (a co-located group of containers inside which our application processes are running) on the various nodes based on resource utilization. It reads the service’s operational requirements and schedules it on the best fit node. For example, if the application needs 1GB of memory and 2 CPU cores, then the pods for that application will be scheduled on a node with at least those resources. The scheduler runs each time there is a need to schedule pods. The scheduler must know the total resources available as well as resources allocated to existing workloads on each node.

Controller-Manager

It allows Kubernetes to integrate with cloud services, such as storage and load-balancers.

This service runs a number of distinct controller processes in the background (for example, replication controller controls number of replicas in a pod, endpoints controller populates endpoint objects like services and pods, and others) to regulate the shared state of the cluster and perform routine tasks. When a change in a service configuration occurs (for example, replacing the image from which the pods are running, or changing parameters in the configuration yaml file), the controller spots the change and starts working towards the new desired state.

Storage or etcd

It’s where the state of the cluster and all the applications are stored. Kubernetes uses etcd as its database. Because Kubernetes is a distributed system, it needs a distributed database like etcd.

etcd is a strongly consistent, distributed key-value store that provides a reliable way to store data that needs to be accessed by a distributed system or cluster of machines. It gracefully handles leader elections during network partitions and can tolerate machine failure, even in the leader node. It is a simple, distributed key value storage which is used to store the Kubernetes cluster data (such as number of pods, their state, namespace, etc), API objects and service discovery details.

Worker nodes

nodes are where user applications run. The main components of worker nodes are:

Kubelet
Kube-Proxy
Container Runtime

Kubelet

An agent that runs on each worker node of the cluster. It communicates with the control plane reporting on the status of containers and tasks.

It is the main service on a node, regularly taking in new or modified pod specifications (primarily through the kube-apiserver) and ensuring that pods and their containers are healthy and running in the desired state. This component also reports to the master on the health of the host where it is running.

Kube-proxy

Responsible for local cluster networking. It ensures each node gets its own unique IP address and implements rules to handle routing and load-balancing of traffic.

It is a proxy service that runs on each worker node to deal with individual host subnetting and expose services to the external world. It performs request forwarding to the correct pods/containers across the various isolated networks in a cluster.

Container Runtime

Container runtime is the software for running containers.