Orchestration & Kubernetes
Orchestration derived from the problem: placement, restarts, health, rollout, discovery. Kubernetes as a control loop over desired state, its core objects and why each exists, scheduling with requests and limits, OOM kills and CPU throttling, pod autoscaling — and the mandatory lesson on when none of it is warranted.
A hundred containers across twenty machines is not a bigger version of one container on one machine. Placement, restart, health, networking, rollout and discovery each stop being decisions a human can make in time — and the thing that makes them instead is an orchestrator.
Q · Once a workload is a hundred containers spread across twenty machines, who decides what runs where — and who puts it back when it dies at 03:00?
Desired: ten API containers. Actual: eight running, two crashed. Somebody has to notice and restore the difference. Kubernetes is the answer to that question generalized into a control loop — and the loop, not the YAML, is the thing worth learning.
Q · When actual state drifts away from desired state, who notices, and what exactly do they do about it?
Desired state → control plane → scheduler and controllers → worker nodes → pods. Five boxes, one direction of flow, and everything else in Kubernetes is a detail hanging off one of them.
Q · What are the moving parts of a Kubernetes cluster, and which one is responsible when something does not run?
Ten object kinds cover almost everything. Learn them as answers to problems — "pod IPs change", "config must differ per environment", "this job must not run twice" — and the API stops being a vocabulary test.
Q · Which Kubernetes objects actually matter, and what problem does each one exist to solve?
A pod is not "a container with extra steps". It is a boundary around processes that must live and die together and share one network identity — which is a rare requirement, and the reason most pods should hold exactly one container.
Q · What is the unit Kubernetes actually schedules, and when does more than one container legitimately belong inside it?
You do not create pods. You declare a replica count and an image, and a two-level controller chain creates, replaces and gradually rolls over the pods that satisfy it.
Q · How do I go from "I want three copies of this image running" to three actual pods, and what happens when I change the image?
Desired 3, Pod B dies, the controller sees 2 and creates a replacement. That mechanism is genuinely valuable and genuinely narrow: it restores counts, and it cannot tell the difference between a dead process and a broken deployment.
Q · What exactly does an orchestrator repair on its own, and which failures does it dutifully make worse?
Pods get an IP address they did not choose and lose it on every replacement. A Service is the indirection that gives a changing set of pods one name, one address and one place to make routing decisions.
Q · If every pod's IP address changes whenever it is replaced, how does anything ever find anything?
Internet → load balancer → ingress controller → Service → pods. One external entry point, one place where host and path routing and TLS termination live, and N internal services behind it instead of N public load balancers.
Q · How does a request from the public internet reach the right pod, with TLS terminated and without one load balancer per service?
Configuration and credentials both come from outside the image, and Kubernetes offers two objects for them. The difference is smaller than the names suggest: a Secret is base64-encoded, not encrypted, and readable by anyone with namespace access.
Q · Where does environment-specific configuration come from, and does putting a credential in a Secret object actually protect it?
A stateless replica is interchangeable and disposable. A database replica has an identity, a disk, a position in a replication stream and a startup order — and running one on Kubernetes is a real decision with a real bill, usually payable in your own time.
Q · What changes when a workload owns data, and should that workload be running in the cluster at all?
A pod says it needs 500 millicores and 1 GiB. The scheduler eliminates every node that cannot satisfy that or violates a constraint, scores the survivors, and binds. When nothing survives the filter, the pod says Pending and the events say exactly why.
Q · Which machine does this pod land on, and what do I read when the answer is "none of them"?
A request is what the scheduler reserves for you. A limit is the ceiling the kernel enforces. They are not the same number, and CPU and memory behave fundamentally differently when the ceiling is reached — one throttles, the other kills.
Q · What do I actually promise when I write `requests` and `limits`, and why do CPU and memory behave so differently at the boundary?
The two ways a container hits its ceiling look nothing alike. Memory exhaustion kills the process loudly and leaves a restart count. CPU throttling leaves no restart, no error and an unremarkable CPU graph — just latency that tripled.
Q · A service got slower with no restarts and no CPU spike. What is actually happening, and how would I prove it?
Traffic rises, a metric rises, the controller computes more replicas, the scheduler places them, images pull, the application warms up. Every one of those steps takes time, which is why autoscaling never arrives during the spike that needed it.
Q · How does replica count follow demand automatically, and how late is the capacity when it finally arrives?
Two engineers, one API, one hundred requests per second. Do they need Kubernetes? No. This lesson makes that answer defensible: what a cluster actually costs, what the simpler options give you, and the small number of conditions that genuinely change the answer.
Q · This system is two engineers, one API and a hundred requests per second. Does it need Kubernetes?