Kubernetes Architecture Explained Like an Airport

Short answer: A Kubernetes cluster has two halves. The control plane is the airport control tower — it makes decisions (what runs where) but flies no planes. The worker Nodes are the runways and gates where planes (Pods) actually operate. The tower (API server, scheduler, etcd, controllers) directs; the ground crew (kubelet, kube-proxy) on each Node executes.

Part 5 of the series. Previous: What Happens When You Run kubectl apply?.

Introduction

Kubernetes architecture has a lot of named parts, and lists of components rarely stick. An airport analogy makes the roles and relationships obvious, so you can reason about failures and behavior instead of memorizing a diagram.

The problem

When something breaks, "the cluster is unhealthy" is not actionable. You need to know whether the decision-making layer is down (nothing new gets scheduled) or a specific Node is down (Pods there are affected). Without a model of who does what, every incident feels random.

Simple explanation — the airport

• Control tower (control plane): decides which plane uses which runway, tracks every flight, and reroutes when a runway closes. It does not fly planes.
• Runways and gates (Nodes): where planes actually take off, land, and park.
• Ground crew (kubelet, kube-proxy): on each runway, follows the tower's instructions — parks the plane, connects the jet bridge, directs traffic.
• Flight records (etcd): the master log of every scheduled and active flight.

If the tower goes down, planes already flying keep flying, but no new ones are scheduled. If one runway closes, the tower reroutes to others.

Official Kubernetes concept

Control plane components:

• API server: the only way in or out; all coordination flows through it.
• etcd: consistent key-value store of cluster state.
• Scheduler: assigns Pods to Nodes.
• Controller manager: runs reconcile loops (Deployments, ReplicaSets, Nodes, and more).

Node components:

• kubelet: starts and supervises containers on the Node.
• kube-proxy: programs the Node's networking so Service traffic reaches the right Pods.
• Container runtime: actually runs containers (commonly containerd).

How it works

The control plane holds desired state and decisions; Nodes do the work. The API server is the hub — kubelets report Node and Pod status to it, controllers watch it for drift, and the Scheduler watches it for unscheduled Pods. This hub-and-spoke design is why the API server's health is so important: it is the airport's tower radio.

Finance example

Your trading platform runs across 6 Nodes. At 9:30 a.m. the Scheduler (tower) places extra Trade and Risk Pods onto Nodes with spare capacity. At 11 a.m. a Node's hardware fails — its kubelet stops reporting, the Node controller marks it NotReady, and the affected Pods are rescheduled onto healthy Nodes. Customers never notice, because the tower rerouted around the closed runway. Meanwhile etcd has the authoritative record of what should be running.

C# example

Your service does not interact with these components directly, but it benefits from them. A readiness probe lets the control plane know when a Trade API Pod is ready to receive traffic:

// Readiness: only receive traffic once dependencies are reachable.
app.MapGet("/readyz", (IMarketDataClient md) =>
    md.IsConnected ? Results.Ok() : Results.StatusCode(503));

The kubelet calls this; the Service only routes to Pods that report ready.

AWS example

With EKS, AWS runs and scales the entire control plane (API server, etcd, scheduler, controllers) across availability zones for you — you never SSH into the tower. You own the worker Nodes (EC2 or Fargate) where kubelets run. This split is the main reason teams pick EKS over self-managed Kubernetes.

Architecture diagram

Production reality

How the architecture shows up when things go wrong:

• Control plane outages are silent until you try to change something. Running Pods keep serving, so users are fine, but deploys, scaling, and self-healing stall. Teams sometimes do not notice until an unrelated Node dies and nothing reschedules.
• etcd is the crown jewel. It holds all cluster state; on self-managed clusters, etcd backups and quorum are an operational must. EKS removes this burden — a major reason to use it.
• API server throttling is real at scale. Chatty controllers, operators, or `kubectl` loops can rate-limit the API server and slow the whole cluster. Watch its latency as a first-class signal.
• Cost: the EKS control plane has a flat hourly fee per cluster, which nudges teams toward fewer, multi-tenant clusters with namespace isolation rather than a cluster per service.
• Security: the API server is the single front door — locking it down (private endpoints, RBAC, audit logging) is the highest-leverage security control you have.

AI Engineering connection

When you run AI agents and MCP servers, they are workloads on the Nodes (the runways); the control plane schedules and supervises them just like any service. Understanding that the tower keeps flying even when one runway closes is exactly why agent fleets survive Node failures without manual intervention.

Interview questions

• What lives in the control plane vs on a Node? Control plane: API server, etcd, scheduler, controller manager. Node: kubelet, kube-proxy, container runtime, Pods.
• What happens if the control plane goes down? Running Pods keep running, but you cannot schedule, scale, or change anything until it recovers.
• Why is the API server so central? It is the single entry point; every component communicates through it, and it persists state to etcd.
• What does kube-proxy do? It programs Node networking so traffic to a Service reaches the correct backend Pods.
• What does EKS manage for you? The full control plane, leaving you responsible for worker Nodes and workloads.

Key takeaways

• Cluster = control plane (decides) + Nodes (execute).
• API server is the hub; etcd is the source of truth; the Scheduler places Pods; controllers reconcile.
• On Nodes, kubelet runs containers and kube-proxy handles Service networking.
• EKS manages the control plane; you manage Nodes.

Next article

Next: How Kubernetes Keeps Applications Running — self-healing, probes, and replica counts in depth. Previous: What Happens When You Run kubectl apply?.