Kubernetes Cluster Architecture

A Kubernetes cluster consists of a control plane plus a set of worker machines, called nodes, that run containerized applications. Every cluster needs at least one worker node in order to run Pods.

The worker node(s) host the Pods that are the components of the application workload. The control plane manages the worker nodes and the Pods in the cluster.

In production environments, the control plane usually runs across multiple computers and a cluster usually runs multiple nodes, providing fault-tolerance and high availability.

The following diagram presents an example reference architecture for a Kubernetes cluster. The architecture may vary depending on specific cluster setups and requirements.

A Kubernetes cluster has two main parts:

1. Control plane – Manages the cluster and workloads, with key components like the API Server, Scheduler, Controller Manager and etcd.

2. Data plane – Machines (nodes) that run apps in containers, managed by an agent called kubelet, which gets instructions from the control.

Control Plane or Master Components:

1. kube-apiserver: The core server that exposes the Kubernetes HTTP API. The API Server is the central management point for Kubernetes cluster.

2. etcd: A distributed key-value store that holds the cluster state. It is a consistent and highly-available store for all API server data.

3. kube-scheduler: In Kubernetes, the Scheduler decides which node should run a new pod based on resource availability and other constraints. It distributes workloads efficiently across the cluster, making sure nodes aren’t overburdened and resources are utilized optimally.

4. kube-controller-manager: Runs controllers to implement Kubernetes API behavior. The Controller Manager handles routine tasks and ensures the desired state.

5. cloud-controller-manager (optional): Integrates with underlying cloud provider(s).

   Data Plane Components:

6. Kubelet: Ensures that Pods are running, including their containers.

7. kube-proxy (optional): Maintains network rules on nodes to implement Services and routes traffic to Pods.

8. Container runtime: It is responsible for running containers.

Addons extend the functionality of Kubernetes.

• DNS: Provides cluster-wide DNS resolution for services.

• Web UI (Dashboard): A web interface for managing the Kubernetes cluster.

• Container Resource Monitoring: Collects and stores container metrics for monitoring resource usage.

• Cluster-level Logging: Saves container logs to a centralized log storage system.

Kubernetes Cluster Architecture Explained with a Hospital Analogy:

Now, I will explain Kubernetes cluster architecture using a simple hospital analogy, along with the following pictures. Think of a Kubernetes cluster as a large hospital network. The control plane acts as the headquarters, managing everything. Each node is like an individual hospital, and the pods represent the hospital departments. I will provide the most suitable examples for each component of the Kubernetes cluster using this hospital analogy to help you understand it better.

Kubernetes Objects (Hospital Departments & Services) :

\=> Namespaces (Hospital Branches): Represents different branches of the hospital network (like dev, test, prod environments). Contains pods, services, and other resources that are logically separated but part of the same cluster.

\=> Pods (Hospital Departments): Each pod represents a hospital department like ER, Surgery, etc.

\=> Services (Reception Desk): Routes traffic to appropriate departments.

\=> Replica Sets (Staffing Agency): Ensures a specific number of pod replicas are running at all times, like a staffing agency making sure there are enough nurses or doctors available in each department.

\=> Deployment (HR Department): Ensures the desired number of pods are running and replaces failing ones with proper strategies.

\=> Daemon Sets (Support Services): Ensures that a copy of a specific pod runs on all or a subset of nodes, like essential support services (e.g., cleaning staff or IT support) that operate in every hospital.

\=> Ingress (Security Services): Defines how external users access services within the cluster.

\=> Volumes (Storage Rooms): Provides storage for persistent data for pods.

\=> ConfigMap (Shared Hospital Protocols): Guidelines or SOPs used by the department.

\=> Secrets (Confidential Records): Sensitive data used by authorized departments (pods).