VOL. VII · CH. 7.7 · SOFTWARE ENGINEERING

Kubernetes & Orchestration

What manages hundreds of containers when Docker alone only knows how to run one.

DivisionDevOps / Infrastructure

DifficultyAdvanced

Prerequisites7.6 5.15

Related7.8

2 min read · 335 words

7.7.1Definition

Kubernetes is a container orchestration platform that automates deploying, scaling, healing, and networking containers (7.6) across a cluster of machines. Where Docker packages and runs a single container, Kubernetes manages the fleet — deciding which machine runs which container, restarting failed ones, and scaling their count up or down with demand.

7.7.2Why It Exists

Running a handful of containers manually is straightforward; running hundreds across many machines, with some failing, demand fluctuating (5.15), and new versions rolling out continuously, is not something a human operator can track by hand. Kubernetes exists to automate that entire operational layer — self-healing, scaling, and networking — for containerized systems too complex to manage manually.

7.7.3Core Concepts

Pod — the smallest deployable unit, typically one or a few tightly-coupled containers.
Deployment — a declaration of how many replicas of a pod should run and how updates should roll out.
Service — a stable network endpoint routing traffic to the current set of healthy pods, regardless of which specific pods are running.
Self-healing — Kubernetes automatically restarts or reschedules failed pods to maintain the declared desired state.

7.7.4Common Mistakes

Adopting Kubernetes for a workload a single server or a simpler platform (7.8) would run fine, taking on substantial operational complexity for no corresponding need.
No resource limits set on pods, allowing one misbehaving container to consume an entire node's resources and starve neighboring workloads.
No readiness/liveness probes configured, so Kubernetes cannot distinguish a genuinely healthy pod from one that's silently stuck.

7.7.5Best Practices

Reach for Kubernetes only once genuine operational complexity — many services, variable scale, multi-environment orchestration — justifies it.
Set explicit CPU/memory resource requests and limits on every workload.
Configure meaningful readiness and liveness probes so self-healing actually reflects true application health.

Real-World ExampleKubernetes originated at Google as the successor to their internal Borg system, built specifically to orchestrate a scale of containerized workloads — tens of thousands of services — that manual operation could never have sustained.

← Back to Part VII — Software Engineering Practice