The definitive breakdown of how Kubernetes clusters work — Control Plane (brain), Worker Nodes (muscle), and the communication flows between them. Critical for the ~25% “Cluster Architecture” CKA domain.
The Two Halves of a Cluster
Half
Role
Analogy
Control Plane
Makes global decisions, detects & responds to cluster events
On-prem clusters often lack this. Managed clusters (EKS, GKE, AKS) rely on it heavily.
Worker Node Components (The Muscle)
1. kubelet
Attribute
Detail
Role
Node agent — registers the node, reports status, ensures pods are running
What It Does
Receives PodSpecs from API Server, instructs Container Runtime to create/maintain/destroy containers
Health
If kubelet stops → node becomes NotReady; existing pods keep running but no new ones scheduled
CKA Exam Relevance
Debugging NotReady nodes often starts with checking kubelet: systemctl status kubelet, journalctl -u kubelet
2. kube-proxy
Attribute
Detail
Role
Network proxy — maintains network rules for Service-to-Pod communication
Implementation
iptables mode (default) or IPVS mode (better performance at scale)
What It Does
Routes traffic hitting a Service IP to one of the healthy backend pods
CKA Exam Relevance
If Services aren’t routing → check kube-proxy logs and iptables/IPVS rules.
3. Container Runtime
Attribute
Detail
Role
Actually creates and runs containers
CRI Standard
Kubernetes speaks to runtimes via the Container Runtime Interface
Common Runtimes
containerd (default in modern clusters), CRI-O (Red Hat), Docker (deprecated as direct runtime)
CKA Exam Relevance
Use crictl to inspect containers when docker CLI doesn’t work. crictl ps, crictl logs, crictl exec.
Communication Flows
Creating a New Pod (User Request)
1. User runs: kubectl apply -f pod.yaml
│
▼
2. kubectl sends YAML to kube-apiserver
│
▼
3. API Server validates, writes PodSpec to etcd
│
▼
4. kube-scheduler watches etcd, sees unscheduled pod
│
▼
5. Scheduler selects best node, writes node assignment back to etcd
│
▼
6. API Server notifies kubelet on selected node
│
▼
7. kubelet instructs Container Runtime to pull image and create container
│
▼
8. Container Runtime reports status back to kubelet → API Server → etcd
│
▼
9. kube-proxy updates iptables rules so Service can route to new pod
Self-Healing When a Pod Dies
1. kubelet detects container exited (via runtime health checks)
│
▼
2. kubelet reports pod status to API Server → etcd
│
▼
3. kube-controller-manager (Replication Controller) sees mismatch:
desired replicas = 3, actual running = 2
│
▼
4. Controller creates replacement pod spec, writes to etcd
│
▼
5. Scheduler assigns new pod to available node
│
▼
6. kubelet creates replacement container
│
▼
7. kube-proxy updates iptables rules so Service routes to new pod
│
▼
8. Cluster returns to desired state (3 replicas running)
Service Routing Note: When the replacement Pod gets a new IP, the Endpoints controller automatically updates the Service’s backend list. kube-proxy then programs new iptables rules so traffic to the Service IP is forwarded to the new Pod. Clients using the Service never notice the change. Source: CKA Day 9
Default Namespaces and Component Placement
Kubernetes automatically creates four Namespaces on cluster bootstrap. The Control Plane components themselves run as Pods (in most modern installations) inside the kube-system Namespace:
Component
Namespace
Notes
kube-apiserver
kube-system
Static Pod or DaemonSet on control plane nodes
etcd
kube-system
Either stacked (Pod) or external to cluster
kube-scheduler
kube-system
Static Pod on control plane nodes
kube-controller-manager
kube-system
Static Pod on control plane nodes
kube-proxy
kube-system
DaemonSet running on every node
CoreDNS
kube-system
Deployment providing cluster DNS
Exam Trap: When asked to “list all pods in the cluster,” remember that kubectl get pods only shows the default Namespace. Use kubectl get pods -A or kubectl get pods --all-namespaces to see system components in kube-system. Source: CKA Day 10
Pods vs. Containers
Aspect
Docker Container
Kubernetes Pod
Unit of Deployment
Single container
One or more containers
Networking
Isolated (by default)
Shared IP, shared port space; containers talk via localhost
Storage
Isolated volumes
Shared volumes between containers
Lifecycle
Managed by Docker daemon
Managed by kubelet + controllers
Scaling
Manual
Managed by ReplicaSet/Deployment
Key Insight: You almost never create bare Pods in production. You create Deployments that manage ReplicaSets that manage Pods.
High Availability (HA) Control Plane
For production clusters, the Control Plane must survive node failures:
Component
HA Strategy
kube-apiserver
Multiple instances behind a load balancer
etcd
3+ nodes in a Raft cluster (tolerates (n-1)/2 failures)
kube-scheduler
Multiple instances, only one active leader at a time (leader election)
kube-controller-manager
Multiple instances, only one active leader
CKA Tip: The exam typically uses a single control plane node, but you must understand HA concepts for real-world operations.