KCNA — Worker Node Components
Worker Node Components
Worker nodes are where your applications actually run. Each worker node has three essential components: kubelet, kube-proxy, and a container runtime.
Worker Node Architecture
┌──────────────────── Worker Node ────────────────────┐
│ │
│ ┌──────────┐ │
│ │ kubelet │◄──── Communicates with API Server │
│ │ (Agent) │ │
│ └─────┬────┘ │
│ │ Manages pod lifecycle │
│ ▼ │
│ ┌──────────────────┐ │
│ │ Container Runtime │ containerd / CRI-O │
│ │ (Runs Containers) │ │
│ └─────┬────────────┘ │
│ │ │
│ ┌─────▼─────────────────────────────────┐ │
│ │ Pod Pod Pod │ │
│ │ ┌───────────┐ ┌──────────┐ ┌──────┐ │ │
│ │ │Container A│ │Container B│ │Cont C│ │ │
│ │ └───────────┘ └──────────┘ └──────┘ │ │
│ └───────────────────────────────────────┘ │
│ │
│ ┌────────────┐ │
│ │ kube-proxy │ Manages network rules │
│ │ (Network) │ │
│ └────────────┘ │
│ │
└──────────────────────────────────────────────────────┘
The Three Worker Node Components
1. kubelet
The kubelet is the primary agent on every worker node. It ensures containers are running in pods.
| Aspect | Details |
|---|---|
| What it does | Receives pod specifications from the API server and ensures those pods are running and healthy |
| Where it runs | On every worker node (and sometimes control plane nodes too) |
| Key behavior | Communicates only with the API server — never with etcd directly |
| Health checks | Runs liveness and readiness probes on containers |
| Reporting | Reports node status and pod status back to the API server |
What kubelet does, step by step:
- Watches the API server for pod assignments to its node
- Pulls the container image (via the container runtime)
- Starts the container
- Monitors the container’s health (probes)
- Reports status back to the API server
- Restarts containers if they crash
What kubelet does NOT do:
- Does NOT manage containers that weren’t created by Kubernetes
- Does NOT decide which pods to run (that’s the scheduler’s job)
- Does NOT network across pods (that’s kube-proxy)
2. kube-proxy
kube-proxy maintains network rules on each node that allow pods to communicate with each other and with the outside world.
| Aspect | Details |
|---|---|
| What it does | Maintains network rules (iptables or IPVS) for Service-to-Pod routing |
| Where it runs | On every node in the cluster |
| Key behavior | When traffic arrives for a Service, kube-proxy routes it to the correct pod |
| Implementation | Can use iptables (default) or IPVS mode |
How kube-proxy works:
External request → Service (ClusterIP) → kube-proxy → Pod
│
├── Routes to Pod A (node 1)
├── Routes to Pod B (node 2)
└── Routes to Pod C (node 3)
Key distinction: kube-proxy handles Service-to-Pod routing. It does NOT handle Pod-to-Pod networking — that’s the job of the CNI plugin (Calico, Cilium, Flannel, etc.).
3. Container Runtime
The container runtime is the software that actually runs containers on the node.
| Aspect | Details |
|---|---|
| What it does | Pulls images, creates containers, starts/stops them |
| Interface | Must implement the Container Runtime Interface (CRI) |
| Common runtimes | containerd (most common), CRI-O |
| Key change | Docker was removed as a runtime in Kubernetes v1.24. containerd is now the default. |
| Runtime | Description | Used By |
|---|---|---|
| containerd | Industry-standard container runtime, CNCF Graduated | Most K8s distributions, EKS, GKE |
| CRI-O | Lightweight runtime designed specifically for Kubernetes | OpenShift, some CKA lab environments |
Exam note: Docker itself is no longer a supported Kubernetes runtime. However, Docker images (OCI images) still work perfectly — it’s just the Docker daemon (dockerd) that was removed.
Control Plane vs Worker Node Comparison
| Aspect | Control Plane | Worker Node |
|---|---|---|
| Purpose | Makes decisions | Runs workloads |
| Runs user apps? | No (usually) | Yes |
| Key components | API server, etcd, scheduler, controller manager | kubelet, kube-proxy, container runtime |
| Failure impact | Can’t schedule new pods or make changes | Pods on that node become unavailable |
| Typical count | 1-3 (odd number for etcd quorum) | 1 to thousands |
How Worker Nodes Register
When a new worker node joins the cluster:
| Step | What Happens |
|---|---|
| 1 | kubelet starts on the new node |
| 2 | kubelet registers itself with the API server |
| 3 | API server adds the node to the cluster |
| 4 | Scheduler can now assign pods to this node |
| 5 | kubelet starts watching for assigned pods |
Node Health Monitoring
The control plane continuously monitors node health:
| Status | Meaning | What Happens |
|---|---|---|
| Ready | Node is healthy and accepting pods | Normal scheduling |
| NotReady | Node is unhealthy | No new pods scheduled; existing pods may be rescheduled |
| Unknown | Node controller hasn’t heard from kubelet | After timeout, treated as NotReady |
If a node becomes NotReady:
- The node controller waits (default: 5 minutes)
- If the node doesn’t recover, pods are marked for eviction
- ReplicaSets detect missing pods and create replacements on healthy nodes
Key Takeaways for the Exam
- Every worker node runs three components: kubelet, kube-proxy, and a container runtime
- kubelet is the agent that ensures pods are running — it communicates with the API server, not etcd
- kube-proxy handles Service-to-Pod routing using iptables or IPVS
- Container runtime (containerd or CRI-O) actually runs the containers
- Docker daemon was removed in K8s v1.24 — containerd is the standard
- kubelet runs health probes (liveness, readiness) on containers
- If a node fails, the node controller eventually evicts pods and they get rescheduled
What’s Next?
Let’s understand how all these components communicate — through the Kubernetes API.
