In the previous article we looked at Kubernetes from the bottom up — hardware, OS, container runtime, and cluster components. Now let's zoom into the logical architecture: how the two node types relate to each other, what each is responsible for, and one of the most common points of confusion for Kubernetes newcomers.
1. Two Node Types
Every Kubernetes cluster is composed of exactly two types of nodes:
┌─────────────────────────────────────────────────────────────┐
│ Control Plane Node │
│ │
│ kube-apiserver │
│ kube-controller-manager │
│ kube-scheduler │
│ ─────────────────── (also runs on control plane) ─────── │
│ kube-proxy │
│ kubelet │
│ etcd │
└──────────────────┬──────────────────────────────────────────┘
│ schedules + monitors
┌──────────┼──────────┐
▼ ▼ ▼
┌──────────┐ ┌──────────┐ ┌──────────┐
│ Worker │ │ Worker │ │ Worker │
│ Node │ │ Node │ │ Node │
│kube-proxy│ │kube-proxy│ │kube-proxy│
│ kubelet │ │ kubelet │ │ kubelet │
└──────────┘ └──────────┘ └──────────┘
2. Control Plane: The Brain
The control plane is responsible for cluster-wide management — it never runs your application workloads directly (by default). Its responsibilities fall into two categories:
Infrastructure-level management
- Scale the cluster up or down (add/remove/modify worker nodes)
- Monitor node health and respond to node failures
Application-level management
- Create, update, delete, and query application workload resources (Pods, Deployments, Services, etc.)
- Self-healing: detect failed Pods and reschedule them automatically
| Component | Role |
|---|---|
| kube-apiserver | Single entry point for all cluster operations; all components talk through it |
| kube-controller-manager | Runs reconciliation loops to drive cluster state toward desired state |
| kube-scheduler | Assigns unscheduled Pods to appropriate worker nodes |
| etcd | Distributed key-value store; the single source of truth for all cluster state |
3. Worker Nodes: The Muscle
Worker nodes are responsible for actually running workloads and reporting status back to the control plane.
Their two core duties:
- Execute scheduling decisions — receive Pod assignments from the control plane and start/stop containers accordingly
- Report status — continuously monitor running workloads and resource usage, reporting back to the control plane via heartbeats or events
| Component | Role |
|---|---|
| kubelet | Node agent; receives Pod specs and manages container lifecycle via the container runtime |
| kube-proxy | Maintains network routing rules; implements the Service abstraction for Pod-to-Pod and external traffic |
4. The Interesting Question: Why Does the Control Plane Run kubelet and kube-proxy?
If you look at the component list for the control plane node, you'll notice something surprising: it includes kubelet and kube-proxy — which are supposed to be worker node components.
Why?
In Kubernetes, everything runs as a workload — including the control plane components themselves.
kube-apiserver, kube-controller-manager, kube-scheduler, and etcd are all containerized applications. And in Kubernetes, running containerized applications on a node requires kubelet (to manage the containers) and kube-proxy (to handle networking).
So the control plane node needs kubelet and kube-proxy to run its own components.
Control Plane Node
├── kubelet + kube-proxy ← needed to run the control plane components
└── runs as Pods:
├── kube-apiserver Pod
├── kube-controller-manager Pod
├── kube-scheduler Pod
└── etcd Pod
5. Protecting the Control Plane: Taints
Since the control plane node runs kubelet, it is technically capable of running any workload. But allowing arbitrary application Pods to run on the control plane would risk destabilizing the cluster's management layer.
Kubernetes solves this with Taints:
# The control plane node is automatically tainted:
node-role.kubernetes.io/control-plane:NoSchedule
# This prevents the scheduler from placing regular workloads here.
# Only Pods with a matching Toleration can be scheduled on the control plane.
Control Plane Node [Tainted: NoSchedule]
↑
kube-scheduler sees this taint
→ skips control plane for regular Pod scheduling
→ only control plane system Pods (with toleration) run here ✅
This is a clean separation of concerns: the mechanism (kubelet) is the same everywhere, but policy (taints) enforces the boundary.
6. Control Plane ↔ Worker Node Communication
Worker Node Control Plane
────────────────── ──────────────────────────
kubelet → kube-apiserver (watch for Pod specs)
kubelet (heartbeat) → kube-apiserver (node status update)
kube-proxy → kube-apiserver (watch Service/Endpoint changes)
kube-apiserver → kubelet (exec, logs, port-forward)
kube-scheduler → kube-apiserver (write scheduling decisions)
kube-controller-manager → kube-apiserver (read/write desired state)
All communication flows through kube-apiserver. No component talks directly to another — everything is mediated through the API. This is what makes Kubernetes so extensible and auditable.
7. Summary
| Control Plane | Worker Node | |
|---|---|---|
| Primary role | Cluster management & scheduling | Run workloads |
| Key components | apiserver, controller-manager, scheduler, etcd | kubelet, kube-proxy |
| Also runs | kubelet + kube-proxy (to host its own components) | — |
| Workload isolation | Taint: NoSchedule (no user workloads by default) |
Accepts scheduled Pods |
| Reports to | — | Control plane (heartbeat + events) |
The key insight: Kubernetes is self-hosting. The control plane components are themselves Pods, managed by the same kubelet/kube-proxy machinery that manages every other workload in the cluster. The only thing that makes the control plane special is a policy boundary (taints), not a technical one.
Next in this series: Kubernetes Control Flow: How a Pod Goes from YAML to Running (Part 3)
Follow the series for more deep dives into Kubernetes internals.
Top comments (0)