Deployment & Infra
Compose vs Kubernetes: free-recall review
Retrieval beats re-reading. For each prompt, say or write a full answer from memory before you open the model answer — the effort of recall is what makes the orchestration decision tree stick.
Reconstruct the unit’s spine — orchestration scope, the reconciliation loop, self-healing, gated rollouts, the complexity tax, and the middle ground — without looking back at the lesson.
- 01Both Docker Compose and Kubernetes 'run containers.' What is the fundamental difference in what they orchestrate?
- 02What is the reconciliation loop, and why is it the single mechanism that separates Kubernetes from Compose?
- 03How does a zero-downtime rolling update with automatic rollback work in Kubernetes, and what does Compose do instead?
- 04What is the 'complexity tax' of Kubernetes, and what concrete numbers describe it?
- 05What concrete signals tell you a workload has genuinely outgrown Docker Compose?
- 06Why is the Compose-versus-Kubernetes choice not binary, and what sits in the middle?
If you could reconstruct each answer from memory, you hold the unit’s spine: orchestration scope separates a single-host process manager from a distributed control plane; the reconciliation loop is the mechanism that buys self-healing, gated rollouts, and autoscaling; the complexity tax (control plane, CNI, RBAC, YAML sprawl, ~70% naming it the top pain, 30–50% utilization, five-figure bills) is the price; the signals to leave Compose are a real single-host ceiling, a real availability need, or a real rollout/autoscaling need; and the choice is never binary — Swarm, Nomad, and managed PaaS sit in between. Buy the weight your scale earns.