Kubernetes Architecture at a Glance

The Big Picture

A Kubernetes cluster is a set of machines called nodes. Every node plays one of two roles: it’s either part of the Control Plane or it’s a Worker Node (also called a data plane node).

┌─────────────────────── Kubernetes Cluster ──────────────────────────┐
│                                                                      │
│  ┌──────────────────── Control Plane ───────────────────────┐        │
│  │  kube-apiserver  │  kube-scheduler  │  controller-manager │       │
│  │               etcd (distributed state store)              │       │
│  └───────────────────────────────────────────────────────────┘       │
│                              │                                        │
│          ┌───────────────────┼───────────────────┐                   │
│          ▼                   ▼                   ▼                   │
│   ┌────────────┐    ┌────────────┐    ┌────────────┐                 │
│   │  Worker 1  │    │  Worker 2  │    │  Worker 3  │                 │
│   │  kubelet   │    │  kubelet   │    │  kubelet   │                 │
│   │ kube-proxy │    │ kube-proxy │    │ kube-proxy │                 │
│   │  Pod  Pod  │    │  Pod  Pod  │    │  Pod  Pod  │                 │
│   └────────────┘    └────────────┘    └────────────┘                 │
└──────────────────────────────────────────────────────────────────────┘

The Control Plane is the brain — it makes decisions about the cluster. The Worker Nodes are the muscle — they run your application containers.

The Control Plane

kube-apiserver — The Front Door

The API Server is the single entry point to Kubernetes. Every operation — deploying an app, listing pods, updating a config — goes through the API Server.

# All these commands talk to kube-apiserver
kubectl get pods
kubectl apply -f deployment.yaml
kubectl delete service my-app

Key characteristics:

• Exposes the Kubernetes REST API
• Validates and processes every request
• The only component that reads from and writes to etcd
• Stateless and horizontally scalable — run 3+ replicas for HA

etcd — The Source of Truth

etcd is a distributed, strongly-consistent key-value store. It holds the entire desired and observed state of your cluster.

Every object you create in Kubernetes — Pods, Deployments, Services, Secrets — is ultimately stored as a key-value pair in etcd.

/registry/pods/default/my-pod       → Pod spec + status
/registry/deployments/default/api  → Deployment spec
/registry/secrets/default/db-pass  → Encrypted secret

Key characteristics:

• Uses the Raft consensus algorithm for distributed consistency
• Only the API Server communicates with etcd directly
• Back up etcd regularly — it contains your entire cluster state
• Run on 3 or 5 nodes for HA (odd numbers prevent split-brain scenarios)

kube-scheduler — The Placement Engine

The Scheduler watches for newly created Pods that don’t yet have a node assigned. For each such Pod, it selects the optimal node using a two-phase process:

Phase 1 — Filtering: Remove nodes that cannot run the Pod (insufficient CPU/memory, taint mismatches, etc.)

Phase 2 — Scoring: Rank remaining nodes (prefer nodes with the most available resources, respect affinity rules, etc.)

The highest-scoring node wins; the scheduler writes the node assignment to etcd via the API Server.

kube-controller-manager — The Reconciliation Engine

The Controller Manager runs a collection of controllers — control loops that continuously watch the cluster state and work to make the actual state match the desired state you declared.

Observe current state
    ↓
Compare with desired state
    ↓
Take corrective action (if needed)
    ↓
Repeat forever

Key built-in controllers:

• Node Controller — notices when nodes become unreachable and marks their pods for rescheduling
• ReplicaSet Controller — ensures the right number of pod replicas are always running
• Deployment Controller — manages rolling updates and rollbacks
• Job Controller — creates Pods for batch jobs and cleans up when they finish
• EndpointSlice Controller — keeps Service endpoints up to date

cloud-controller-manager

In cloud environments (AWS, GCP, Azure), this component interfaces with cloud provider APIs to manage cloud-specific resources like load balancers, node lifecycle, and cloud storage volumes.

Worker Nodes

Worker nodes are where your application Pods actually run. Each node runs three components:

kubelet — The Node Agent

The kubelet is an agent running on every worker node. It watches the API Server for Pods assigned to its node and ensures those containers are running and healthy.

Responsibilities:

• Pulls container images from registries
• Starts and stops containers via the container runtime (containerd, CRI-O)
• Runs liveness and readiness health checks
• Reports node capacity and Pod status back to the API Server

kube-proxy — The Network Rules Engine

kube-proxy maintains iptables/ipvs rules on each node that implement Kubernetes Services. When you send traffic to a Service IP, kube-proxy’s rules route it to one of the live Pods backing that Service.

Container Runtime

The software that actually executes containers. Kubernetes supports any runtime implementing the Container Runtime Interface (CRI):

Runtime	Notes
containerd	Most common; default in EKS, GKE, AKS
CRI-O	Lightweight; used by OpenShift
Docker	Via cri-dockerd shim (legacy path)

How a Pod Gets Scheduled: The Full Flow

Let’s trace exactly what happens when you run kubectl apply -f deployment.yaml:

1. kubectl  ──────►  kube-apiserver   (HTTP POST /apis/apps/v1/deployments)
                           │
2.                    Validates + stores Deployment in etcd
                           │
3.                    Deployment Controller notices new Deployment
                      Creates ReplicaSet → Creates Pod objects (unscheduled)
                           │
4.                    kube-scheduler notices unbound Pods
                      Filters + scores nodes → binds Pod to best node
                      Writes node binding to etcd via API Server
                           │
5.                    kubelet on target node notices Pod assigned to it
                      Pulls container image → Starts container
                           │
6.                    kubelet reports Pod status: Running
                      API Server updates etcd

This entire flow completes in 1–3 seconds for most workloads.

Key Concepts to Know

Node

A physical or virtual machine participating in the cluster. Can be a Control Plane node (runs cluster management components) or a Worker Node (runs your application Pods).

Cluster

The complete set of Control Plane and Worker nodes managed together by Kubernetes.

Namespace

A logical partition of cluster resources. Think of it as a folder that groups related objects.

kubectl get pods -n production   # Only pods in 'production' namespace
kubectl get pods -n staging      # Only pods in 'staging' namespace
kubectl get pods -A              # All pods in all namespaces

Use namespaces to separate: environments (dev/staging/prod), teams, or multi-tenant applications sharing a single cluster.

Pod

The smallest deployable unit in Kubernetes. A Pod wraps one or more containers that share a network namespace and storage. We’ll cover Pods in depth in Module 4.

Key Takeaways

• Every K8s cluster has a Control Plane (brain) and Worker Nodes (where apps run)
• Control Plane: API Server (front door), etcd (state store), Scheduler (placement), Controller Manager (reconciliation loops)
• Worker Nodes: kubelet (agent), kube-proxy (network rules), container runtime (runs containers)
• The universal K8s loop: observe current state → compare with desired → take action → repeat
• Full scheduling flow: kubectl → API Server → etcd → Controller Manager → Scheduler → kubelet
• Namespaces provide logical partitioning within a single cluster

You now have a solid mental model of Kubernetes architecture. Take the quiz to test your understanding, then we’ll dive deep into each component.