Architecture and Components

An overview of Kubernetes' architecture and components

Terminology

Cluster

• Multiple Nodes form a Cluster

Node

• A compute instance (physical or virtual server)

Pod

• Consists of one or more Containers

Container

• A lightweight, portable OS (e.g., Linux) generally containing an application with all required components

Container Runtime Engine

• Software that manages and runs containers on the Node e.g., Docker, containerd, cri-o, gVisor, etc.

---

Control Plane Components

• The Control Plane consists of the core components needed to manage a Kubernetes cluster

• These sit on the Master Node (which is abstracted from you in a cloud-managed service like AWS EKS)

kube-apiserver

• The kube-apiserver is the primary management component of Kubernetes

• This exposes an API that we can authenticate to and perform tasks like monitoring the state of the cluster and components, deploying Pods, grabbing information, and more

• All components of the cluster will go through this API

etcd

• A key/value store used for storing all Kubernetes cluster data

• The data is immutable, anytime it needs to be updated, the whole structure is re-generated with the new data

• The key/value store always preserves the previous values so this data will grow indefinitely unless it's configured to remove old versions

kube-scheduler

• Assigns newly created Pods to suitable Nodes in the Cluster based on things like resource requirements, constraints, and policies

kube-controller-manager

• Moniters the state of the cluster through the api-server and makes changes attempting to move the current state towards the desired state

• Many controllers can exist on a Cluster e.g., replication controller, deployment controller, etc.

---

Data Plane Components

kubelet

• An agent running on each Node (also including Master Node) responsible for ensuring Pods are healthy and running

• Receives instructions from the kube-scheduler to create/delete Pods

kube-proxy

• A network proxy which maintains network rules on the Nodes e.g., when a new Service is deployed the kube-proxy ensures a rule maps it to the correct Pods running the service

• This can be replaced with Container Network Interface (CNI) Network plugins such as Cilium, Flannel, Calico, and others