Kubernetes Architecture
You declare the desired state; a set of controllers works continuously to make reality match. Follow one kubectl apply through the API server, etcd, controllers, scheduler and kubelet, then watch the same loop heal a crashed pod.
🎯 What you'll learn
- What Kubernetes does: declarative desired state
- Control plane vs node components
- Objects, labels, namespaces and kubectl
- RBAC/admission basics and the reconciliation loop
📚 Before you start
1What Kubernetes Does
Kubernetes (K8s) is a container orchestrator: you declare the desired state ("run 3 replicas of api:1.4.2, reachable on port 80, with 512 MiB memory each") and Kubernetes continuously works to make the actual state match — scheduling containers onto machines, restarting them when they crash, replacing them when nodes die, rolling out new versions and wiring up networking. It builds on the container concepts in devops-cloud/docker/ and is offered as a managed service by every cloud (EKS — devops-cloud/aws/16-eks, GKE, AKS).
2Cluster Components
A cluster has a control plane (the brain) and worker nodes (where your containers run).
Control plane:
| Component | Role |
|---|---|
| kube-apiserver | the front door: REST API for every read/write; authentication, authorization (RBAC), admission control; the only component that talks to etcd |
| etcd | consistent, highly available key-value store (Raft consensus) holding all cluster state |
| kube-scheduler | picks a node for each new Pod based on resource requests, affinity, taints/tolerations, topology spread |
| kube-controller-manager | runs controllers: Deployment, ReplicaSet, Node, Job, EndpointSlice, ServiceAccount… |
| cloud-controller-manager | integrates with the cloud: load balancers for Service type: LoadBalancer, node lifecycle, routes |
Every node:
| Component | Role |
|---|---|
| kubelet | agent that watches the API for Pods assigned to its node and runs them via the container runtime; reports status, runs probes |
| container runtime | containerd or CRI-O (via the Container Runtime Interface) pulls images and runs containers |
| kube-proxy | programs iptables/IPVS rules (or replaced by eBPF in Cilium) so Service virtual IPs reach Pods |
| CNI plugin | gives each Pod an IP and connects Pods across nodes (Calico, Cilium, AWS VPC CNI) |
Cluster add-ons: CoreDNS (service discovery via DNS), metrics-server, ingress controllers, CSI storage drivers.
3Objects and the API
Everything is an object with apiVersion, kind, metadata (name, namespace, labels, annotations) and usually spec (desired) and status (observed):
apiVersion: apps/v1
kind: Deployment
metadata:
name: api
namespace: petpal
labels: { app: api, team: core }
spec:
replicas: 3
selector: { matchLabels: { app: api } }
template:
metadata: { labels: { app: api } }
spec:
containers:
- name: api
image: ghcr.io/petpal/api:1.4.2
ports: [{ containerPort: 8080 }]- Namespaces partition a cluster (per team/environment) for names, RBAC, quotas and network policies.
- Labels + selectors connect objects loosely: a Service finds Pods by label, a Deployment owns Pods by label.
- Annotations hold non-identifying metadata used by tools (e.g. ingress controller settings).
- Workload objects: Pod, Deployment/ReplicaSet, StatefulSet, DaemonSet (one Pod per node — log agents), Job/CronJob.
4Working With the Cluster
kubectl get pods -n petpal -o wide # list with node and IP
kubectl describe pod api-7c9f-abcde -n petpal # events: scheduling, pulls, probe failures
kubectl logs deploy/api -n petpal --since=10m
kubectl apply -f k8s/ # declarative: create or update to match files
kubectl diff -f k8s/ # what would change
kubectl explain deployment.spec.strategy # built-in API docs
kubectl get events -n petpal --sort-by=.lastTimestampPrefer declarative kubectl apply (or GitOps — 08-production_practices_and_gitops/) of files in version control over imperative kubectl create/edit.
5Security Model in Brief
- Authentication: client certificates, OIDC tokens (cloud IAM), ServiceAccount tokens for Pods.
- Authorization: RBAC —
Role/ClusterRole(verbs on resources) bound to users/groups/ServiceAccounts withRoleBinding/ClusterRoleBinding. - Admission controllers validate/mutate objects before storage: Pod Security Admission (
restrictedprofile), ResourceQuota, LimitRanger, and policy engines (Kyverno, OPA Gatekeeper).
Under the HoodThe Reconciliation Loop▾
Nothing in Kubernetes is a one-shot command; everything is a controller watching the API server and reconciling. When you kubectl apply a Deployment: (1) the API server authenticates, authorizes and runs admission, then persists the object in etcd; (2) the Deployment controller, watching Deployments, sees no matching ReplicaSet and creates one; (3) the ReplicaSet controller sees 0 of 3 Pods and creates 3 Pod objects with no nodeName; (4) the scheduler, watching unscheduled Pods, filters nodes (enough CPU/memory requested, taints, affinity), scores them, and writes a binding; (5) the kubelet on the chosen node sees a Pod bound to it, asks containerd to pull the image and start containers, sets up networking via CNI, starts probes and reports status; (6) the EndpointSlice controller adds ready Pod IPs to the Service's endpoints, and kube-proxy on every node updates routing rules. If a node dies, the node controller marks it NotReady, its Pods are evicted, and the ReplicaSet controller creates replacements — the same loop. Watches (long-lived HTTP streams with resource versions) make this efficient: components react to changes rather than polling.
⚠️ Common Pitfalls
- Running bare Pods — nothing recreates them; use Deployments/StatefulSets/Jobs.
- Imperative changes (
kubectl edit) that drift from files in Git. - Everything in the
defaultnamespace with cluster-admin for everyone. - Treating etcd casually in self-managed clusters — no backups means no cluster.
- Ignoring events —
kubectl describeusually tells you why a Pod is Pending or crashing.
📋 Quick Reference
control plane: apiserver (only etcd client) · etcd · scheduler · controller-manager · cloud-controller-manager
node: kubelet · containerd (CRI) · kube-proxy · CNI · add-ons: CoreDNS, metrics-server, ingress, CSI
object = apiVersion, kind, metadata (labels!), spec (desired), status (observed)
workloads: Deployment · StatefulSet · DaemonSet · Job/CronJob · RBAC + admission (PSA restricted)
kubectl get/describe/logs/apply/diff/explain/events🧠 Key takeaways
- Kubernetes is a set of controllers reconciling desired state (spec) with actual state (status).
- Control plane: apiserver (only etcd client), etcd, scheduler, controller-manager; nodes run kubelet, a runtime, kube-proxy and CNI.
- Objects have apiVersion, kind, metadata (labels), spec, status; labels and selectors connect them.
- Prefer declarative kubectl apply (or GitOps) and least-privilege RBAC;
kubectl describeevents explain most problems.
🎤 Interview Q&A
Q1Describe Kubernetes' architecture.core▾
Control plane: kube-apiserver (front door, validates and stores objects), etcd (state store), scheduler (assigns pods to nodes), controller manager (reconciliation loops), cloud controller. Nodes: kubelet (runs pods), container runtime, kube-proxy (service networking).
- What talks to etcd? Only the API server.
Q2What is the reconciliation (control) loop?core▾
Controllers continuously compare desired state (specs stored in etcd) with actual state and act to converge them, e.g. the ReplicaSet controller creates pods until the replica count matches.
- Why declarative? Self-healing and idempotent: you state what you want, not steps.
Q3How does the scheduler pick a node?core▾
Filtering (resource requests fit, node selectors/affinity, taints/tolerations, volume constraints) then scoring (spread, resource balance, affinity preferences), choosing the highest-scoring node.
- Why do resource requests matter? Scheduling is based on requests, not actual usage.
Q4What happens when you kubectl apply a Deployment?senior▾
kubectl sends it to the API server (authn/authz/admission), it's stored in etcd; the Deployment controller creates a ReplicaSet, which creates Pods; the scheduler assigns them; kubelets pull images and start containers; endpoints update when pods become ready.
- What are admission controllers? Plugins that validate or mutate objects before they're stored.
Q5How is etcd protected and why does it matter?core▾
It holds all cluster state including Secrets: back it up regularly, encrypt Secrets at rest, run it with quorum (3 or 5 members), and restrict access to the API server.
- What happens if etcd loses quorum? The cluster becomes read-only/unavailable for changes.
🛠️ Practice exercises
Each exercise is a file in this topic folder. Code exercises are self-checking: run them and make the checks pass.
✅ Check yourself
Answer the questions — feedback is instant.