Kubernetes Architecture

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. Source: CKA Day 25

The Two Halves of a Cluster

Half	Role	Analogy
Control Plane	Makes global decisions, detects & responds to cluster events	The brain
Worker Nodes	Runs the actual application containers	The muscle

┌─────────────────────────────────────────────────────────────┐
│                    Control Plane (Brain)                     │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────────────┐   │
│  │ kube-       │  │   etcd      │  │ kube-controller-    │   │
│  │ apiserver   │  │ (Data Store)│  │ manager             │   │
│  │ (Front Door)│  │             │  │ (State Reconciler)  │   │
│  └──────┬──────┘  └──────┬──────┘  └─────────────────────┘   │
│         │                │                                   │
│         │         ┌──────┴──────┐                            │
│         │         │ kube-       │                            │
│         │         │ scheduler   │                            │
│         │         │ (Assigner)  │                            │
│         │         └─────────────┘                            │
│         │                                                     │
│         │    ┌─────────────────────────────┐                 │
│         │    │ cloud-controller-manager    │                 │
│         │    │ (Cloud Provider Bridge)     │                 │
│         │    └─────────────────────────────┘                 │
└─────────┼───────────────────────────────────────────────────┘
          │
          │ REST API + etcd watch streams
          │
┌─────────┼───────────────────────────────────────────────────┐
│         │              Worker Nodes (Muscle)                 │
│  ┌──────▼──────┐  ┌─────────────┐  ┌─────────────────────┐  │
│  │   kubelet   │  │  kube-proxy │  │ Container Runtime   │  │
│  │  (Node Agent)│  │ (Network)   │  │ (containerd/CRI-O)  │  │
│  └─────────────┘  └─────────────┘  └─────────────────────┘  │
│                                                               │
│  ┌─────────────────────────────────────────────────────────┐  │
│  │                    Pods (Workloads)                      │  │
│  │  ┌─────────┐  ┌─────────┐  ┌─────────┐                 │  │
│  │  │Container│  │Container│  │Container│  ...             │  │
│  │  │   1     │  │   2     │  │   3     │                 │  │
│  │  └─────────┘  └─────────┘  └─────────┘                 │  │
│  └─────────────────────────────────────────────────────────┘  │
└───────────────────────────────────────────────────────────────┘

---

Control Plane Components (The Brain)

1. kube-apiserver (API Server)

Attribute	Detail
Role	Front door and gatekeeper of the cluster
What It Does	Validates all requests (auth, authz, admission), serves the REST API, is the only component that writes to etcd
Scaling	Can be horizontally scaled behind a load balancer for HA
CKA Exam Relevance	If API Server is down → cluster is frozen. You must know how to check its status and certificates.

Authentication & Authorization: Every request to the API server passes through TLS termination → Authentication → Authorization → Admission Control before reaching the resource. The API server supports multiple authentication plugins (X.509 client certificates, bearer tokens, OIDC, webhook) and authorization modules (Node, ABAC, RBAC, Webhook). See Kubernetes Authentication & Authorization for the full request pipeline. Source: CKA Day 22

Direct REST API Access: The API server is a standard HTTPS REST endpoint. Any client — kubectl, curl, or a custom SDK — can call it directly using a valid client certificate for mutual TLS. For example:

curl https://<control-plane-ip>:6443/api/v1/namespaces/default/pods \
  --cacert ca.crt --cert client.crt --key client.key

This returns the same JSON that kubectl get pods -o json produces, proving that kubectl is a thin wrapper over the REST API. Source: CKA Day 23

Key Exam Commands:

kubectl get componentstatuses  # Check control plane health
kubectl get --raw /healthz     # API Server health endpoint

2. etcd

Attribute	Detail
Role	Distributed, consistent key-value store for all cluster data
What It Stores	All Kubernetes objects (pods, nodes, ConfigMaps, Secrets, RBAC, events)
Security	etcd peers and etcd clients communicate over mutual TLS (see TLS Fundamentals)
Consistency	Raft consensus algorithm — requires majority (quorum) for writes
CKA Exam Relevance	Backup (etcdctl snapshot save) and restore (etcdctl snapshot restore) are guaranteed exam tasks. Detailed commands and DR patterns are in Kubernetes ETCD Backup and Restore.

Key Exam Commands:

ETCDCTL_API=3 etcdctl snapshot save snapshot.db \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key

3. kube-scheduler

Attribute	Detail
Role	Watches for unscheduled pods and assigns them to the best node
Scheduling Factors	Resource requests/limits, taints/tolerations, node affinity/anti-affinity, node conditions, data locality
Extensibility	Custom schedulers can be written and specified per-pod via schedulerName
CKA Exam Relevance	You may need to configure PriorityClass, PodTopologySpread, or debug why a pod is stuck Pending.

The scheduler uses resource requests as part of node fitting. If a Pod requests more memory or CPU than any node has available, the Pod remains Pending and kubectl describe pod reports insufficient resources. Resource limits are enforced later at runtime by kubelet/container runtime; exceeding a memory limit produces OOMKilled. Source: CKA Day 16

4. kube-controller-manager

Attribute	Detail
Role	Runs continuous controller loops that reconcile actual state with desired state
Key Controllers	Node Lifecycle, Replication, Endpoints, Service Account & Token, Deployment, StatefulSet, PersistentVolume
What It Does	If a pod dies → creates replacement. If a node fails → marks NotReady and reschedules pods. The Service Account & Token controller ensures every Namespace has a default ServiceAccount and manages token Secret lifecycle.
CKA Exam Relevance	Understand that controllers are the “automation” behind Kubernetes self-healing.

5. cloud-controller-manager

Attribute	Detail
Role	Bridges Kubernetes with cloud-provider APIs (AWS, GCP, Azure)
What It Manages	Cloud load balancers, storage volumes (EBS, GCE PD), node routes, node lifecycle in cloud
CKA Exam Relevance	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 Source: CKA Day 12
CoreDNS	kube-system	Deployment providing cluster DNS Source: CKA Day 31

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

---

Static Pods and Control Plane Bootstrapping

Static Pods are Pods managed directly by the kubelet on a node, without any API server involvement. This is the mechanism that bootstraps the control plane itself. On a kubeadm cluster, the files in /etc/kubernetes/manifests on the control plane node define the kube-apiserver, kube-scheduler, and kube-controller-manager as Static Pods. The kubelet reads these manifest files and creates the containers before the API server is even online. Source: CKA Day 27

Key Insight: Because Static Pods are node-local, you cannot delete them with kubectl delete — the kubelet will recreate them instantly. To remove a Static Pod, you must delete its manifest file from the node filesystem. Source: CKA Day 13

Aspect	Static Pod	Regular Pod
Managed by	kubelet (node-local)	API server + scheduler
Manifest location	Node filesystem (/etc/kubernetes/manifests)	etcd (via API server)
Scheduler involved	❌ No	✅ Yes
kubectl delete	❌ Recreates immediately	✅ Deletes permanently
Use case	Control plane components	Application workloads

---

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.

---

Sources

• CKA Day 5: Kubernetes Architecture Explained

Practical Practice

Exam-style hands-on tasks for this topic. Complete each task before reviewing the solution. Time yourself — CKA tasks average 5–7 minutes.

Task 1: List Control Plane Components and Ports List all control plane components and their ports. Requirements: Include kube-apiserver, etcd, scheduler, controller-manager. Verification: kubectl get pods -n kube-system or node-local crictl ps Solution:

# Control plane components and default ports
# kube-apiserver: 6443
# etcd: 2379 (client), 2380 (peer)
# kube-scheduler: 10259
# kube-controller-manager: 10257
# kubelet: 10250
# kube-proxy: 10256
kubectl get pods -n kube-system
# OR on control plane node:
crictl ps | grep -E "apiserver|etcd|scheduler|controller"
netstat -tlnp | grep -E "6443|2379|2380|10259|10257"

Task 2: Identify the Scheduler Identify which component is responsible for scheduling and verify it’s running. Requirements: Use kubectl and node-local tools. Verification: kubectl get pods -n kube-system -l component=kube-scheduler Solution:

kubectl get pods -n kube-system -l component=kube-scheduler
# OR
crictl ps | grep scheduler
kubectl logs -n kube-system -l component=kube-scheduler

Task 3: Trace a Request Flow Draw the request flow: kubectl → API server → etcd → scheduler → kubelet. Requirements: Describe each hop and which component writes to etcd. Verification: Conceptual / verbal explanation. Solution:

# 1. kubectl apply -f pod.yaml
# 2. API server validates auth/authz/admission, writes PodSpec to etcd
# 3. kube-scheduler watches etcd, sees unscheduled Pod, selects node, writes node assignment to etcd
# 4. API server notifies kubelet on selected node
# 5. kubelet instructs container runtime to create the container
# 6. kubelet reports status back to API server → etcd
# 7. kube-proxy updates iptables rules for Service routing

Related Pages

• Why Kubernetes?
• CKA Certification
• CKA Study Roadmap
• Deployment, ReplicaSet & Replication Controller — The workload controllers that implement self-healing
• Kubernetes Services — How kube-proxy routes traffic to Pods
• Kubernetes Namespaces — Default namespaces and system component isolation
• Multi-Container Pods — How kubelet orchestrates multiple containers within a Pod
• Kubernetes DaemonSet — kube-proxy and CNI plugins run as DaemonSets
• Kubernetes Static Pods — Control plane bootstrapping and node-local Pod management
• Kubernetes Manual Scheduling — Bypassing the scheduler with nodeName and nodeSelector
• Kubernetes Taints and Tolerations — Node taints and Pod tolerations for negative scheduling
• Kubernetes Node Affinity — Advanced positive scheduling with rich operators and soft/hard constraints
• Kubernetes Resource Requests and Limits — scheduler resource fitting, Metrics Server, and OOMKilled behaviour
• Kubernetes Autoscaling — HPA controller runs inside kube-controller-manager; Metrics Server feeds it data
• Horizontal Pod Autoscaler (HPA) — controller loop that scales workloads via the API server
• Kubernetes Labels and Selectors — Metadata system that connects Services to Pods
• Kubernetes Health Probes — kubelet executes liveness, readiness, and startup probes on each node
• Kubernetes ConfigMaps and Secrets — Stored in etcd; served by API Server; consumed by kubelet
• CoreDNS — Cluster DNS Deployment running in kube-system
• Kubernetes CNI — CNI plugins interface with kubelet and container runtime for Pod networking
• Kubernetes Ingress — Layer 7 routing atop kube-proxy and CNI for HTTP/HTTPS traffic
• TLS Fundamentals — Control plane mTLS, kubeadm PKI, and CertificateSigningRequests
• Kubernetes Authentication & Authorization — API server request pipeline through authn/authz
• Kubernetes RBAC — Role-based permissions enforced by the API server
• Kubernetes Service Account — In-cluster identity and token management handled by the controller manager
• Kubernetes Storage — PV controller, dynamic provisioning, and cluster-scoped storage resources
• CKA Day 24 — Kubernetes RBAC Continued: ClusterRole and ClusterRoleBinding
• Kubernetes Cluster Upgrade — How Static Pod manifests enable kubeadm upgrade apply to re-create control-plane containers
• Kubernetes ETCD Backup and Restore — Snapshot and restore mechanics for the cluster’s consistent data store
• Kubernetes Disaster Recovery — DR hierarchy and cluster reconstruction when ETCD or control plane is lost
• Kubernetes Versioning & Version Skew — Component version compatibility and upgrade path rules
• Kubernetes Kubeconfig — Client-side credentials for API server access
• Docker Fundamentals
• Kubernetes Control Plane Troubleshooting — Day 38: systematic diagnosis of kube-apiserver, etcd, scheduler, and controller-manager failures
• Kubernetes Worker Node Troubleshooting — Day 39: kubelet, container runtime, CNI, kube-proxy, and resource pressure eviction
• Kubernetes Logging and Monitoring — control plane and node component log locations, kubectl logs, and journalctl
• Kubernetes Application Troubleshooting — control plane events, kubelet failures, and the layered failure model
• Kubernetes Concepts Index

---

Tags: kubernetes k8s-architecture control-plane worker-nodes cka devops etcd kubelet kube-apiserver