Kubernetes: Architecture and Components

Hi everyone 👋, I'm Hung Anh.

This is the fifth article in the Kubernetes Fundamentals series. In the previous article, we ended on a question: with containers scattered across dozens or hundreds of machines, who decides which one runs where, restarts it when it dies, or scales it up under load? That's exactly the job Kubernetes was built for.

This article is a bit different from the ones before it — instead of solving one specific problem, it's a map: what pieces actually make up a Kubernetes cluster, and what does each one do?

Let's get started.

1. The Cluster, at a Glance

A Kubernetes cluster is made of two kinds of machines working together:

• Control Plane — the brain. It makes the decisions: what should be running, where, and whether the cluster currently matches that.
• Nodes — the muscle. Each node is a machine (physical or virtual) that actually runs your containers, grouped inside Pods.

The control plane never runs your application code itself — it only ever tells nodes what to do. Everything from here is really just answering: what specifically lives inside each of those two boxes?

2. Control Plane Components

• kube-apiserver — the front door. It exposes the Kubernetes API, and literally everything else — including kubectl, every other control plane component, and every node — talks to the cluster only through it.
• etcd — a consistent, highly-available key-value store. This is where the entire state of the cluster actually lives; lose etcd, and you've lost the cluster.
• kube-scheduler — watches for newly created Pods that haven't been assigned a node yet, and picks which node they should run on.
• kube-controller-manager — runs the controllers: background loops that continuously watch the cluster's actual state and nudge it toward the state you asked for (e.g. "3 replicas of this Pod should be running" — if one dies, a controller notices and starts a new one).
• cloud-controller-manager — only present when running on a cloud provider (AWS, GCP, Azure...). It handles the cloud-specific parts, like provisioning a load balancer, so the rest of Kubernetes doesn't need to know which cloud it's running on.

3. Node Components

• kubelet — the agent running on every node. It talks to the control plane and makes sure the containers described for that node are actually running and healthy.
• kube-proxy — maintains the network rules on each node that let traffic reach the right Pod through a Kubernetes Service.
• Container runtime — the same container runtime from the previous article (containerd, CRI-O...), the piece that actually creates and runs the containers kubelet asks for.

4. Addons

Addons aren't part of the Kubernetes core, but a cluster is barely usable without them:

• DNS — gives every Service a DNS name other Pods can look up, instead of hardcoding IP addresses.
• Dashboard — a web UI for browsing and managing the cluster.
• Monitoring & Logging — collects metrics and container logs into a central place you can actually search and graph.
• Network Plugins (CNI) — has to be installed separately; it's what actually assigns Pods their IP addresses and lets them talk to each other across nodes.

5. Summary

A cluster is two kinds of machines: a control plane that decides what should run and where (kube-apiserver, etcd, kube-scheduler, kube-controller-manager, cloud-controller-manager), and nodes that actually run it (kubelet, kube-proxy, container runtime) — with addons like DNS, dashboards, monitoring, and networking filling in the rest.

That's the full map. From here, the series moves from "what is a cluster made of" to "how do I actually describe what I want it to run" — Pods, Deployments, and Services.

Happy reading! 🍵

References

1. Kubernetes Components - Kubernetes documentation
2. Kubernetes Cluster Architecture - Kubernetes documentation