01 - Kubernetes Architecture & Core Concepts

Why this matters

Everything else in Kubernetes is a variation on this control loop. Get this right and every later topic (scheduling, networking, security) slots into a mental model instead of being memorized separately.

Read this first — Definitions & Explanations

Before the quiz, make sure these ideas are clear in plain language.

Control plane vs data plane (nodes)

The control plane is the "brain": API server, etcd, scheduler, controller-manager. It decides what should happen.
The data plane (worker nodes) is where workloads actually run: kubelet, container runtime, kube-proxy. It makes things happen.

kube-apiserver

The front door of the cluster. Every kubectl call, every controller, every kubelet talk goes through the API server. Clients never talk to etcd directly. The API server validates requests, authenticates/authorizes them, then reads/writes cluster state.

etcd

A distributed key-value store that holds the source of truth for cluster state (Pods, Services, Deployments, etc.). Only the API server should access etcd. If etcd is wrong or lost, the cluster’s memory is wrong or lost.

controller-manager

Runs many controllers — small programs that continuously compare desired state (what you declared) with actual state (what is running) and act to close the gap. Example: if you want 3 replicas and only 2 exist, the replication/deployment controller creates another Pod.

Reconciliation loop

The core Kubernetes pattern: observe → diff → act → repeat forever. Controllers don’t “run once.” They keep reconciling.

scheduler

Watches for Pods that are unbound (no node assigned). It filters nodes that can’t run the Pod, scores the rest, and binds the Pod to a node. It does not start containers — kubelet does.

kubelet

The node agent. It talks to the API server, gets PodSpecs for its node, and asks the container runtime (via CRI) to start/stop containers. It also runs probes and reports Pod status.

kube-proxy

On each node, programs packet forwarding so Services reach healthy Pod endpoints (commonly via iptables or IPVS rules).

CRI (Container Runtime Interface)

The API kubelet uses to talk to runtimes like containerd or CRI-O. Kubernetes doesn’t require Docker specifically anymore — it requires a CRI-compatible runtime.

Declarative vs imperative

• Imperative: “create this now” (kubectl create, kubectl run)
• Declarative: “make the cluster match this YAML” (kubectl apply) — preferred for real systems because it’s repeatable and Git-friendly.

What Really Happens When You Run kubectl apply -f deployment.yaml?

Most Kubernetes engineers use this command every day, but behind that single line lies an entire distributed orchestration engine working to bring your application to life.

1. kubectl sends manifest to API Server: Validates schema against local cache, computes 3-way strategic merge patch, sends HTTP POST to kube-apiserver.
2. API Server validates and stores desired state in etcd: Authenticates caller, checks RBAC permissions, applies Mutating & Validating webhooks, and commits desired state to etcd via Raft consensus.
3. Deployment Controller creates a ReplicaSet: Watches API server, detects new Deployment, and creates child ReplicaSet object.
4. ReplicaSet Controller creates unbound Pods: Generates Pod definitions in Pending state with spec.nodeName: "" (no node assigned yet).
5. kube-scheduler selects the best worker node: Filters ineligible nodes (Predicates) and scores candidate nodes (Priorities), then writes a Binding object.
6. Kubelet instructs container runtime: Node kubelet detects its assigned Pod, calls containerd (CRI) to pull images and launch the pause sandbox.
7. CNI configures networking: Allocates Pod IP, creates veth pair, and connects pod network namespace to host bridge/overlay.
8. Service Ingress routes traffic: Readiness probes pass, Endpoints Controller adds Pod IP to Service Endpoints, and kube-proxy configures iptables/IPVS routing.

👉 The Core Principle: Kubernetes is a Desired State System

You don't tell Kubernetes how to run your application; you tell it what you want, and Kubernetes continuously works to make reality match that desired state. That is why Kubernetes can self-heal failed pods, automatically scale workloads, and recover from node loss.

Official docs (read for detail)

• Kubernetes Components
• Cluster Architecture
• Working with Kubernetes Objects
• kubectl Overview

Key Concepts (listen for these in the videos)

• Control plane vs data plane
• API server: the front door — everything talks to it, nothing talks directly to etcd
• etcd: the source of truth (distributed key-value store)
• controller-manager: reconciliation loops (desired state vs actual state)
• scheduler: decides which node a pod runs on
• kubelet: the node agent, talks to API server + container runtime
• kube-proxy: implements Service networking on each node
• CRI (Container Runtime Interface) — containerd/CRI-O
• Declarative vs imperative management (kubectl apply vs kubectl create)
• The reconciliation loop pattern: observe → diff → act, repeated forever

YouTube search terms

• "Kubernetes architecture explained"
• "Kubernetes control plane components deep dive"
• "kube-apiserver etcd kubelet scheduler explained"

Hands-on lab (on prod-sim)

# See all control-plane components as pods (in kubeadm-style clusters they run as pods)
kubectl get pods -n kube-system -o wide

# SSH into the control-plane node and look at the actual binaries/processes
minikube ssh -p prod-sim
  ps aux | grep -E 'kube-apiserver|etcd|kube-scheduler|kube-controller-manager|kubelet'
  sudo crictl ps            # see containers via the CRI directly
  exit

# Watch the API server directly (raw REST calls kubectl makes under the hood)
kubectl proxy --port=8080 &
curl http://localhost:8080/api/v1/nodes | jq '.items[].metadata.name'
kill %1

# Trace one `kubectl apply` end to end
kubectl apply -f https://k8s.io/examples/pods/simple-pod.yaml -v=8 2>&1 | less
# Read every log line: it's your kubectl -> apiserver -> etcd -> scheduler -> kubelet flow.

Notes

(fill in your own words after watching + labbing)