How Does Kubernetes Really Work? A Deep Dive into K8s Architecture

Kubernetes (K8s) is the core of cloud‑native computing, an open‑source platform for container orchestration originally derived from Google’s Borg system and now a CNCF graduate project.

It manages the deployment, scaling, and lifecycle of containerized applications by using a declarative API combined with a control‑loop mechanism, enabling automatic deployment, horizontal scaling, self‑healing, and load balancing.

Architecture Overview

A Kubernetes cluster consists of a highly available control plane (typically three nodes) and an unlimited number of worker nodes.

Control Plane (Master)

The control plane makes global decisions (e.g., scheduling) and detects/responds to cluster events.

API Server : The cluster’s entry point; all operations go through its REST API, handling authentication, authorization, and request validation.

etcd : A distributed key‑value store that persistently holds the desired state and configuration of the cluster (the single source of truth).

Scheduler : Assigns newly created Pods to suitable Nodes based on resource requirements, affinity, taints, and other policies.

Controller Manager : Runs various controllers (e.g., Node Controller, Deployment Controller) that continuously reconcile the actual state with the desired state, implementing the declarative control loop.

Node Components (Data Plane)

kubelet : An agent running on each node that receives Pod specifications from the API server, starts containers, and reports node and Pod status.

kube-proxy : Implements the Service abstraction by handling network forwarding and load balancing for Pods.

Container Runtime : Executes container images (e.g., containerd, CRI‑O, Docker legacy).

Kubernetes Workflow

The following numbered steps illustrate how a Pod is created from a kubectl command to a running container.

1. kubectl submits a request to the API Server.
2. API Server receives the request.
3. Desired state is written to etcd.
4. Controllers detect the new Pod.
5. Scheduler selects a suitable Node.
6. The chosen Node is identified.
7. kubelet on that Node receives the task.
8. The container image is pulled and the container is created.
9. The Pod starts successfully.
10. kube-proxy sets up networking for the Pod.

This sequence demonstrates the declarative control loop: user intent → API Server → etcd → controllers → scheduler → kubelet → container runtime → running Pod.