Skip to main content

Architecture of a Kubernetes cluster

Summary: a Kubernetes cluster is divided into two worlds — the control plane that decides and the data plane (worker nodes) that executes. This lesson details each of the components (API Server, etcd, Scheduler, Controller Manager, Cloud Controller Manager, kubelet, kube-proxy, container runtime), their precise role, and how they talk to each other to run thousands of Pods autonomously and resiliently.

1. Overview in one diagram​

Two fundamental rules to remember:

  1. The API Server is the mandatory central point. All communication goes through it.
  2. The control plane decides, the nodes execute. A clear separation of roles.

2. The control plane — the brain of the cluster​

The control plane is the set of components that make the decisions. In a managed cluster (EKS, GKE, AKS), the cloud fully manages the control plane for you. In an on-premise cluster, you manage it yourself.

2.1 · API Server — the mandatory gateway​

Without the API Server, nothing works. It is the most critical component of the cluster. Its high availability is the absolute priority in production.

2.2 · etcd — the memory of the cluster​

etcd comes from a play on words — it is a distributed /etc storage. Also used outside Kubernetes by projects like CoreDNS or Rook.

2.3 · Scheduler — the smart placer​

A useful analogy: the Scheduler is like a head waiter who seats the customers in a restaurant — he looks at the available tables, the group sizes, the preferences (smoking/non-smoking, terrace/indoor), and assigns the best spot.

2.4 · Controller Manager — the convergence loop​

The Controller Manager is the real engine of Kubernetes. It is the one that keeps everything in place, 24/7, without human intervention.

2.5 · Cloud Controller Manager — the gateway to the cloud​

This component exists precisely so that Kubernetes remains portable — the Kubernetes core does not know AWS or GCP; the CCM translates.

3. The worker nodes — the arms of the cluster​

A worker node is a machine (physical or virtual) that runs the Pods. This is where your actual code executes.

3.1 · kubelet — the local agent​

kubelet is the component closest to your containers. It is the one that talks to the container runtime to say "launch nginx:1.27 with these variables and this memory".

3.2 · Container Runtime — the executor​

In 2026, containerd is the default runtime on almost all clusters. Docker Engine is no longer used by Kubernetes (but remains widely used for building the images).

3.3 · kube-proxy — the network magician​

In 2026, more and more clusters replace kube-proxy with modern CNIs like Cilium (based on eBPF), which offer 10 times better performance and advanced features (observability, L7 network policies).

4. Kubernetes networking — a flat world​

Kubernetes' network model is very different from Docker's alone.

It is the CNI that makes Kubernetes portable between AWS, GCP, Azure and on-premise, despite their very different network models.

5. The complete cycle — what happens when you run kubectl apply?​

Let's follow step by step what happens when you launch a Deployment.

This complex choreography is completely invisible to you. You just see deployment/my-app created. But knowing what happens under the hood will help you enormously to diagnose incidents in production.

6. High availability — the replicated control plane​

In production, you never settle for a single control plane. You replicate at least 3.

Best practice: 3, 5 or 7 masters spread across several availability zones. The cluster tolerates the loss of an entire zone without downtime.

In a managed cluster (EKS, GKE, AKS), the cloud handles all of this for you. That is reason #1 to choose a managed cluster when starting out.

7. How much does a cluster cost in 2026?​

An important practical question — the approximate prices for a managed cluster in 2026.

Important note: these costs are frightening at first glance, but they replace an entire team of system administrators. The Kubernetes ROI is calculated in saved headcount and gained resilience, not just in cloud dollars.

Remember in 30 seconds​

  • A cluster = control plane (decides) + data plane (executes, worker nodes).
  • Control plane = API Server + etcd + Scheduler + Controller Manager + Cloud Controller Manager.
  • Worker node = kubelet + kube-proxy + container runtime (containerd).
  • The API Server is the mandatory entry point — everything goes through it.
  • etcd is the memory of the cluster — loss of etcd = loss of the cluster.
  • kubelet is the only mandatory worker-side component that talks to the API Server.
  • CNI (Container Network Interface) = makes Kubernetes portable multi-cloud.
  • HA = 3+ masters spread across several zones.

Next: YAML manifests and kubectl: the declarative workflow →