Cloud Native 4 min read

A Complete Visual Guide to Kubernetes Architecture

This article provides a comprehensive, step‑by‑step overview of Kubernetes architecture, detailing the control plane components (API Server, etcd, Scheduler, Controller Manager) and worker node components (kubelet, kube‑proxy, container runtimes), illustrated with diagrams and command‑line examples that show how requests flow, state is stored, pods are scheduled, and failures are handled.

Architect Chen
Architect Chen
Architect Chen
A Complete Visual Guide to Kubernetes Architecture

Kubernetes (K8s) is a core component of large‑scale architectures. Its architecture is divided into a control plane and worker nodes.

K8S overall architecture diagram
K8S overall architecture diagram

Control Plane – the “brain” of the cluster, consisting of five main components:

API Server : the single entry point for all requests; it handles authentication, validation, data processing and communication with other components.

etcd : a distributed key‑value store that persists the entire cluster state, effectively the database of Kubernetes.

Scheduler : decides on which node a pending Pod should run based on resource availability and constraints.

Controller Manager : runs various controllers (e.g., ReplicaSet, Node controller) that continuously reconcile the actual state with the desired state, acting as Kubernetes’ “autopilot”.

Other components (e.g., cloud‑controller‑manager) are omitted for brevity.

All components communicate through the API Server. A typical request flow is illustrated below:

kubectl
↓
API Server
↓
… (authentication, etc.)
↓
HTTPS
↓
… (response)

Example command: kubectl get pods etcd stores objects such as Pods, Nodes, Deployments, ConfigMaps, Secrets and Namespaces. Example of stored objects:

Pod

Node

Deployment

ConfigMap

Secret

Namespace

etcd storage diagram
etcd storage diagram

The Scheduler evaluates node metrics; for instance, it may choose Node1 with CPU 20 % and Memory 30 % over Node2 with higher utilization.

Node1
CPU: 20%
Memory: 30%

When a Pod fails, the Controller Manager recreates it to maintain the desired replica count, ensuring that the specified number of Pods (e.g., three) is always running.

Replicas = 3
Pod1
Pod2
Pod3

Worker Nodes – the machines that actually run containers. Each node includes:

kubelet : an agent that receives instructions from the API Server and ensures Pods are running correctly.

kube‑proxy : maintains network rules and load‑balances service traffic.

Container runtime (e.g., containerd, CRI‑O): pulls images and starts containers.

Worker node components diagram
Worker node components diagram

This modular design gives Kubernetes strong scalability and maintainability: control logic is centralized in the control plane, while execution logic is distributed across the nodes.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

KubernetesSchedulerEtcdControl PlaneK8s ArchitectureWorker NodesController Manager
Architect Chen
Written by

Architect Chen

Sharing over a decade of architecture experience from Baidu, Alibaba, and Tencent.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.