Kubernetes Architecture in Simple Terms

Kubernetes (often shortened to K8s) is a system that runs your containerized applications across many machines and keeps them healthy. This note maps the moving parts in everyday language: what a cluster is, who makes decisions, who does the labor, and how traffic finds your app. For when, why, and where teams adopt it from a business angle, start with Kubernetes for business leaders.

In short

A cluster splits into a control plane (the brain: API, memory of state, schedulers, controllers) and worker nodes (the muscle: kubelet, runtime, networking). You declare Pods (wrappers around containers), scale them with Deployments, and expose them with Services. Everything flows through the API.

The one-sentence picture

You describe what should run (images, replicas, ports, config), store that description somewhere trusted (often Git—see GitOps), and Kubernetes reconciles: it compares the live cluster to the declaration and nudges reality until they match, within the limits of hardware and policy.

Cluster = control plane + worker nodes

A cluster is the whole system you operate as one unit. A node is a single machine (VM or bare metal) that participates in the cluster.

Control plane nodes run the components that accept requests, remember state, place work, and repair drift. In production they are usually a small, highly available set.
Worker nodes run your application containers. There are typically many of them; they report health and execute what the control plane assigns.

You do not need to memorize every binary on day one. The useful split is: decisions and bookkeeping happen on the control plane; execution happens on workers.

Control plane components (the brain)

Names vary slightly by distribution, but the ideas are stable:

kube-apiserver — The front door. kubectl, controllers, and schedulers all talk to this API. If the API is unavailable, most change stops (reads on cached data may still work in clients, but the source of truth is here).
etcd — A consistent key-value store that holds the cluster’s desired and observed state. It is not “your app database”; it is Kubernetes’ own memory.
kube-scheduler — Watches for Pods without an assigned node and picks a node based on resources, affinity rules, taints/tolerations, and other constraints.
kube-controller-manager — Runs controllers—loops that watch the API and take action. For example, the Deployment controller notices when replica counts do not match reality and creates or deletes Pods.
cloud-controller-manager (when on a cloud) — Glues the cluster to the provider: load balancers, routes, volume labels—so Kubernetes can request “a cloud load balancer” without hard-coding one vendor’s API into every binary.

Worker node components (the muscle)

kubelet — An agent on each node that registers the node with the API server and ensures containers in assigned Pods are running as declared. If kubelet is unhealthy, that node is a bad place to land new work.
Container runtime — Actually starts and stops containers (containerd, CRI-O, etc.). Kubernetes talks to the runtime through a standard interface (CRI).
kube-proxy (or data-plane replacements in some setups) — Implements part of Service networking on the node so traffic to a Service IP can reach the right Pods.

Pods, Deployments, and Services (what you usually declare)

Pod — The smallest deployable unit Kubernetes schedules. Often one main container (sometimes sidecars). Pods are ephemeral: they come and go; you design for replacement.
Deployment — Declares desired replicas and rolling updates for stateless apps. It owns ReplicaSets, which own Pods—so you rarely create Pods by hand in production.
Service — A stable virtual IP and DNS name in front of a set of Pods (via labels). Clients talk to the Service; Kubernetes load-balances to healthy Pods.

For a full walkthrough of how Pods, Deployments, Services, Endpoints, and Ingress fit together on the network, see Kubernetes networking in depth.

For stateful systems you meet StatefulSets (PostgreSQL and Redis on Kubernetes), PVs, PVCs, and StorageClasses (provisioned via CSI), and operators; the architecture above still applies—controllers just enforce stronger identity and storage rules.

Add-ons you will bump into

These are not “core” in the same sense as kube-apiserver, but real clusters depend on them:

Container Network Interface (CNI) — Gives every Pod an IP and implements network policy in many installs.
DNS (e.g. CoreDNS) — Resolves Service names inside the cluster.
Ingress controller — HTTP/HTTPS routing from outside the cluster to Services.
Metrics and logs — cAdvisor/kubelet metrics, Prometheus-style scraping, log agents—so you can see what the orchestrator cannot guess from YAML alone.

Mental model for incidents

When something breaks, a practical order of questions is: Is the API reachable? → Is etcd healthy? → Are nodes Ready? → Did the Pod get scheduled? → Did the container start (image pull, crash loop)? → Does networking reach the Pod (Service, NetworkPolicy, ingress)? The architecture tells you which logs and metrics to open next.

Blog