The Ultimate Guide to Kubernetes Architecture — A Complete CKA-Level Deep Dive

If you’re preparing for the Certified Kubernetes Administrator (CKA) exam or aiming to truly master Kubernetes, understanding the architecture is non-negotiable.
Kubernetes isn’t just a collection of containers; it’s a distributed control system — one of the most elegant and resilient designs in modern cloud computing.

This blog is your complete study reference — explaining every component, process, call flow, and real-world scenario — so you’ll never have to read another Kubernetes architecture guide again.

The Big Picture: Kubernetes Cluster Overview

A Kubernetes Cluster is made up of two planes:

1. Control Plane (Master Node): Responsible for making global decisions — scheduling, monitoring, scaling, and maintaining the desired state.
2. Worker Nodes: Where the actual applications (Pods) run.

Core Concept

Kubernetes operates on a Declarative Model — you tell it what you want, and it constantly works to make the current state match that desired state.

CONTROL PLANE COMPONENTS
Kube-API Server — The Front Door of Kubernetes

Everything in Kubernetes goes through the Kube-API Server — it’s the central communication hub for both internal and external components.

What It Does

• Exposes the Kubernetes API (via RESTful interface).
• Validates and processes incoming requests.
• Persists the cluster state in etcd.
• Acts as a message bus for all controllers and nodes.

Internal Flow: When You Run kubectl apply -f pod.yaml

Let’s trace what really happens:

1️⃣ Request Sent:

kubectl sends an HTTPS REST call to the Kube-API Server (default port 6443).

2️⃣ Authentication:

• API Server checks who you are.
• Common methods:
  • Certificates (client certs signed by cluster CA)
  • Bearer tokens (ServiceAccount tokens, OIDC, etc.)
  • Static tokens in /etc/kubernetes/pki/
• Example file for basic authentication (not recommended in production):

/etc/kubernetes/pki/users.csv

3️⃣ Authorization:

• Once authenticated, the request goes through RBAC (Role-Based Access Control) or ABAC.
• Example check: “Does this user have permission to create Pods in this namespace?”
• RBAC data is stored in Roles and ClusterRoles:

kubectl get clusterrolebinding

4️⃣ Admission Control:

• Final checkpoint before persistence.
• Admission Controllers can mutate (modify) or validate requests.
• Examples:
  • NamespaceLifecycle: Prevents use of deleted namespaces.
  • LimitRanger: Ensures Pod requests don’t exceed limits.
  • DefaultStorageClass: Assigns default storage class to PVCs.

Check which admission plugins are active:

cat /etc/kubernetes/manifests/kube-apiserver.yaml | grep admission

5️⃣ Validation and Persistence:

• API Server validates your Pod spec, then stores it in etcd.

6️⃣ Notification to Controllers/Scheduler:

• The API Server uses watchers to notify other control plane components (like Scheduler and Controller Manager) that a new Pod exists.

CKA Scenario:

If the API Server fails, the entire cluster becomes read-only — existing Pods will run, but you can’t create or delete new resources.
Check its health:

kubectl get componentstatuses

etcd — The Source of Truth

etcd is a distributed key-value store that stores all cluster data — think of it as the “brain” of Kubernetes.

What It Stores

• Everything!
• Cluster state
• Secrets, ConfigMaps
• Node and Pod objects
• RBAC policies
• CRDs (Custom Resources)

It uses the Raft consensus algorithm to ensure strong consistency across all master nodes.

Common Commands
Backup etcd before upgrades or maintenance:

ETCDCTL_API=3 etcdctl snapshot save /tmp/etcd_backup.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

Restore from snapshot:

ETCDCTL_API=3 etcdctl snapshot restore /tmp/etcd_backup.db \
  --data-dir /var/lib/etcd-from-backup

CKA Scenario:

If your cluster becomes unhealthy or components fail to start after an upgrade, restoring etcd from a snapshot is often the safest recovery path.

Kube-Controller-Manager — The Enforcer of Desired State

This component runs multiple controllers that continuously monitor and reconcile the cluster’s actual state against the desired state (stored in etcd).

Key Controllers

• Node Controller: Detects node failures.
• Replication Controller / ReplicaSet Controller: Ensures Pod count.
• Endpoint Controller: Connects Services to Pods.
• Job Controller: Manages batch job completion.
• Namespace Controller: Cleans up resources on namespace deletion .

Reconciliation Loop

1️⃣ Controller queries the API Server for the desired object state.
2️⃣ It compares it with the current state.
3️⃣ If there’s a mismatch, it acts — e.g., spawns or deletes Pods.

CKA Tip:

Understanding this loop helps in troubleshooting “CrashLoopBackOff” or “Pending” issues — it’s always a reconciliation failure somewhere.

Kube-Scheduler — The Intelligent Matchmaker

Assigns Pods to Nodes.

Process:

1️⃣ Watches the API Server for new Pods (with no Node assigned).
2️⃣ Filters nodes based on feasibility (CPU, memory, taints, affinity).
3️⃣ Scores feasible nodes based on priorities (spread, image locality, etc.).
4️⃣ Assigns the highest scoring Node to the Pod.

CKA Tip:

Check why a Pod didn’t schedule:

kubectl describe pod <pod-name>

Look for messages like:

“0/3 nodes are available: 1 node(s) had insufficient memory, 2 node(s) had taints.”

*Cloud-Controller-Manager — The Cloud Integrator
*
Handles tasks that interact with cloud providers:

• Creates load balancers for Services of type LoadBalancer.
• Attaches persistent volumes (like AWS EBS, GCP PD).
• Manages node lifecycle in cloud environments.

WORKER NODE COMPONENTS

Kubelet — The Node’s Caretaker

The Kubelet runs on every node and ensures containers are up and healthy.

Responsibilities:

• Watches API Server for Pods assigned to its Node.
• Works with the Container Runtime (e.g., containerd or CRI-O).
• Monitors containers using liveness and readiness probes.
• Reports status to the API Server.

Pod Lifecycle Example:

1️⃣ Scheduler assigns a Pod → Kubelet receives instruction.
2️⃣ Kubelet pulls images → starts containers.
3️⃣ Runs probes defined in the Pod spec.
4️⃣ Reports health & status.

Kubelet Logs Useful for troubleshooting:

journalctl -u kubelet -f

Kube-Proxy — The Network Router

Manages network rules (via iptables or IPVS) for service-to-pod and pod-to-pod communication.

Functionality:

Maintains rules to route traffic from Services to backend Pods.

Supports TCP, UDP, and SCTP.

Works closely with the Service abstraction.

CKA Scenario:
If a Service isn’t reachable, check:

kubectl get pods -o wide
kubectl get svc
sudo iptables -t nat -L -n | grep <service-name>

Container Runtime — The Executor

• Responsible for running containers.
• Supported runtimes include:
  • containerd
  • CRI-O
  • Docker (deprecated)

The Kubelet uses CRI (Container Runtime Interface) to talk to the runtime.

🔄 How a Request Flows Through the Cluster

Let’s visualize a full lifecycle:

1️⃣ You run:

kubectl apply -f pod.yam

2️⃣ API Server authenticates → authorizes → validates → stores Pod spec in etcd.
3️⃣ Scheduler assigns Pod → updates spec.nodeName.
4️⃣ Kubelet on that Node sees new assignment → pulls image → runs container.
5️⃣ Kube-Proxy updates routing for network access.
6️⃣ Controller Manager ensures Pod stays running and replicas match.

CKA-Focused Scenarios and Commands

Final Words for CKA Candidates

To truly master Kubernetes:

• Understand how components communicate.
• Know where configurations live (/etc/kubernetes/manifests/).
• Be comfortable with etcdctl, kubectl describe, and journalctl.
• Always trace the flow of a Pod — from kubectl apply to container runtime.

If you grasp this architecture deeply, every CKA troubleshooting or architecture question becomes intuitive.