Deployment & Infra
Compose vs Kubernetes: multiple-choice review
Crux Multiple-choice synthesis across the Compose-vs-Kubernetes unit: orchestration scope, reconciliation, self-healing, gated rollouts, and the complexity tax weighed against real scale.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at senior altitude — in orbitSix questions that cut across the whole unit. Each one mirrors an orchestration decision you make for real — not a definition to recite, but a tradeoff to weigh against the scale you actually have.
Goal
Confirm you can connect orchestration scope, the reconciliation loop, self-healing, gated rollouts, and the complexity tax — and decide which weight a given workload earns.
Quiz
Completed
A team runs an API, Postgres, Redis, and a worker on one rented box with modest traffic. They want resilience to a crashed container and a single declarative file. Which orchestration weight fits, and why?
Heads-up This is the classic too-early mistake. A small team would own a control plane, CNI, RBAC, ingress, and YAML sprawl to self-heal across machines they don't have. Migrate when a real ceiling is in sight — not a hypothetical one.
Heads-up That loses Compose's single declarative file, named networks, dependency ordering, and one-command up/down for zero benefit. Compose is the floor for multi-container apps; dropping below it is just manual drift.
Heads-up Managed k8s removes control-plane operations but not the conceptual complexity — you still own pods, networking, RBAC, and the YAML. It is far heavier than this single-host workload needs.
Quiz
Completed
What does the Kubernetes reconciliation loop give you that Compose's restart: always fundamentally cannot?
Heads-up Speed is not the point. restart: always already handles same-host restarts; the loop's value is surviving a lost node, which Compose cannot do because it has no multi-node scheduling.
Heads-up Kubernetes YAML is famously larger, not shorter — pods, services, deployments, ingress. That sprawl is part of the complexity tax you pay for reconciliation, not a benefit.
Heads-up Reconciliation relies on readiness and liveness probes to know what healthy means — it adds health gating, it does not remove it.
Quiz
Completed
A service must roll out a new release with zero downtime and automatic rollback if the new version is unhealthy. How do Compose and a Kubernetes Deployment differ here?
Heads-up Compose has no readiness-gated rollout at all. It restarts in place with a downtime window — the health gate and automatic rollback are exactly what only the reconciliation loop provides.
Heads-up It is the reverse. Rolling updates gated on readiness are built into a Deployment; Compose restarts in place. No mesh is required for basic rolling updates.
Heads-up A Kubernetes Deployment keeps rollout history and can roll back automatically when new pods fail readiness. Compose has no such mechanism.
Quiz
Completed
What are the honest signals that a workload has genuinely outgrown Docker Compose?
Heads-up File size is not the signal. Compose handles many services on one host fine; what forces the move is needing capabilities Compose lacks — multi-node scheduling, self-healing across machines — not line count.
Heads-up Both Compose and Kubernetes run container images; that shared verb hides the real difference. Image usage is no reason to switch orchestrators.
Heads-up Observability tooling is orthogonal to orchestration weight — you can ship dashboards on a single Compose host. The move to k8s is driven by scheduling and availability needs, not dashboards.
Quiz
Completed
Surveys repeatedly rank operational complexity as the top Kubernetes pain (~70% of users), and clusters routinely sit at 30–50% utilization. What is the senior reading of these numbers?
Heads-up The complexity is intrinsic to running a distributed control plane, not a misconfiguration. Even well-run clusters carry the conceptual and operational weight; the question is whether your scale justifies it.
Heads-up 30–50% utilization is about provisioned-versus-used cluster capacity and headroom, not a runtime memory leak. It reflects over-provisioning relative to actual load.
Heads-up Managed k8s removes control-plane operations but not the conceptual complexity or the utilization economics — you still own pods, networking, and right-sizing the cluster.
Quiz
Completed
A team needs multi-node resilience and zero-downtime deploys but does not want to own a control plane or learn the full Kubernetes surface. What is the senior framing of their options?
Heads-up That false binary is exactly what drives premature k8s adoption. Swarm, Nomad, and managed PaaS give multi-node resilience and gated rollout well before self-managed Kubernetes is warranted.
Heads-up Managed k8s removes control-plane ops but keeps the full conceptual surface — pods, networking, RBAC, YAML. A managed PaaS or Swarm is often lighter for teams that just want scaling and rollout.
Heads-up Hand-rolling multi-host Compose behind a load balancer gives no self-healing, no rescheduling on node loss, and no gated rollout — you rebuild a fragile orchestrator by hand. A purpose-built middle-ground tool is the better answer.
Recap
The through-line is one decision: capability versus complexity tax, weighed against your actual scale. Orchestration scope (single host vs many nodes) and the reconciliation loop are what separate the tools; self-healing, gated rollouts, and autoscaling are what the loop buys you — at the cost of a control plane, CNI, RBAC, and YAML sprawl. You move off Compose when you hit a real single-host ceiling, a real availability need, or a real rollout/autoscaling need — and even then the answer is often a middle ground (Swarm, Nomad, managed PaaS), not self-managed Kubernetes. Buy the weight your traffic earns.