Container Orchestration & Kubernetes
The problem
Running a handful of containers by hand is manageable; running hundreds across many machines, restarting failed ones, and distributing load between them is not — orchestration systems automate deciding which machine runs which container, and keep the desired state running despite ongoing failures.
Why now
Containers and Docker gave the packaged unit of deployment; CPU scheduling already established the general problem of assigning scarce compute resources to competing work. Kubernetes is that scheduling problem, generalized from CPU time on one machine to entire containers across a cluster of machines.
Mental model
You don't tell Kubernetes how to run your containers — you declare the desired end state ('run 3 replicas of this image') and a control loop continuously compares that desired state to reality, taking action (starting, stopping, rescheduling containers) to close the gap, forever, automatically, the same way a thermostat doesn't execute a fixed heating schedule, it just keeps checking and correcting toward a target temperature.
Requires
- Containers & DockerCloud & DevOps
Kubernetes orchestrates containers; you need to already understand what a container is and how it's built before reasoning about a system that schedules many of them across a cluster.
- CPU SchedulingOperating Systems
Kubernetes' scheduler solves the identical resource-allocation problem CPU scheduling already covered — assigning contended, limited resources to competing work — just at the scale of whole containers across many machines instead of threads on one CPU.
Used in
- Kubernetes as the dominant container orchestration platform in production use
- Self-healing deployments that automatically restart crashed containers
- Rolling updates and horizontal scaling managed declaratively rather than manually
- Service discovery, letting containers find each other without hardcoded IP addresses
Projects
- Deploy a simple application to a local Kubernetes cluster (minikube or kind), scale it to 3 replicas, and kill one pod to observe Kubernetes automatically restart it
- Write a Kubernetes deployment manifest that declares desired state (image, replica count, resource limits) and explain each field's purpose
Examples
- Declaring replicas: 3 means Kubernetes continuously ensures exactly 3 pods are running that image, restarting any that crash without manual intervention
- A rolling update replaces old pods with new ones gradually, keeping the service available throughout the deployment instead of an all-at-once cutover
Resources
Mastery checklist
- I can explain Kubernetes' declarative, reconciliation-loop model
- I can deploy a simple application and scale it using Kubernetes manifests
- I can explain how Kubernetes automatically recovers from a crashed container
- I can explain the difference between imperative container management and Kubernetes' declarative approach