Why Container Orchestration

From Run Commands to Declared Intent

Ten containers on one host is a scripting problem. Two hundred across five hosts is an operations problem: something must decide where each starts, restart what dies, and roll changes without downtime.

Docker alone gives you docker run and restart policies on a single node. It knows nothing about the other nodes, cannot spread replicas for fault tolerance, and has no concept of advancing an image change across a fleet safely.

Orchestration flips the unit of thinking. You declare the outcome — three replicas of v2, each needing 250m CPU — and a control loop keeps pushing reality toward it. Nodes fail; you edit one field instead of touching every host.

kubectl scale deploy/web --replicas=5

The declaration lives in the API, not in a runbook, so it survives people and machines.

What the Orchestrator Takes Over

Four day-2 jobs dominate, and each maps to a Kubernetes object:

• Placement — the scheduler fits pods onto nodes using requests and taints.
• Health and healing — probes mark containers ready; a dead pod is replaced by its controller.
• Scaling — the HPA adjusts replicas from load, or you change it directly.
• Rollouts — Deployments create a new ReplicaSet and bound the swap with maxSurge and maxUnavailable.

strategy:
  type: RollingUpdate
  rollingUpdate: { maxSurge: 1, maxUnavailable: 0 }

None of it requires application changes: any process that listens on a port and exits on SIGTERM participates.

When Not to Orchestrate

Pitfall 1 — orchestrating a single box. One node of Kubernetes still means etcd, a control plane, and YAML maintenance. For a solo server, systemd or compose is simpler; orchestration pays when you need multiple nodes, real rollouts, or self-healing you refuse to script.

Pitfall 2 — ignoring requests. The scheduler trusts resources.requests for placement. Omit them and pods land anywhere until one noisy neighbor triggers node pressure evictions.

Interview-ready: name the failure you prevent (node loss, bad release), the field that prevents it (replicas, readiness probe, rollingUpdate), and the proof — delete a pod and watch kubectl get pods -w replace it.