Container Orchestration Basics

The plain-language idea

Compose (from earlier in this track) describes and runs a multi-container app — on one host. An orchestrator (Kubernetes, Amazon ECS, and others) solves a different, harder problem: given a fleet of machines and a set of containers that need to run, decide which machine runs which container, keep that assignment correct as machines and traffic change, and replace anything that dies — automatically, without a human running a command.

Four capabilities are what "orchestration" actually means in practice:

• Scheduling — deciding which host in the fleet has room to run a given container, based on its declared CPU/memory needs.
• Self-healing — if a container (or the host it's on) dies, the orchestrator notices and starts a replacement automatically, without a human paging in.
• Scaling — running more (or fewer) copies of a container in response to load, either manually triggered or automatically from a metric like CPU usage.
• Service discovery & load balancing — the orchestrator's version of Compose's "reach a service by its name" — except now that service might have ten replicas spread across five machines, and requests need to be distributed across all of them.

See it in a real thing: Compose's shape, orchestration's scale

Compose runs containers on one host — no view of a wider fleet.

BackNext

A Kubernetes Deployment declaring replicas: 5 for an image is doing conceptually the same job as a Compose services: entry — describing what should be running — but the scheduler deciding which of dozens of nodes actually run those 5 replicas, restarting any that fail, and load-balancing traffic across whichever are currently healthy, is work Compose never does at all. That's the actual line between "runs containers" and "orchestrates containers."

What people usually miss

Watch out

• You don't need to run Kubernetes yourself to answer orchestration interview questions well. Managed platforms (AWS ECS/Fargate, Google Cloud Run, Azure Container Apps) handle scheduling and scaling without exposing raw Kubernetes — understanding what problem orchestration solves matters more for most frontend-adjacent interviews than YAML fluency in one specific tool.
• A rolling update is how orchestrators deploy without downtime. New replicas start and pass a health check before old ones are terminated, so capacity never drops to zero mid-deploy — this is the production-scale version of the same "readiness, not just started" distinction the Compose lesson raised about depends_on.
• Health checks are what self-healing actually depends on. An orchestrator can only restart what it can detect as unhealthy — a container that's hung but still technically "running" (not crashed) needs an explicit liveness/readiness check defined, or the orchestrator has no signal to act on at all.
• Orchestration adds real operational complexity, and adopting it is a genuine tradeoff, not a strict upgrade. A small team with predictable, low-scale traffic often has a better cost-benefit running Compose (or a single managed container service) than operating a Kubernetes cluster — "we should use Kubernetes" isn't automatically correct just because it's the most capable option.

Why this matters in interviews

"What does Kubernetes actually do that Docker alone doesn't?" is a common conceptual-level question specifically because so many candidates have used docker run without ever needing to reason about multi-host scheduling — naming the four capabilities (scheduling, self-healing, scaling, service discovery) precisely is a stronger answer than "it manages containers," which doesn't actually say anything a plain docker run doesn't already do at a smaller scale.