What Kubernetes Is & Why It Exists

This course builds directly on this site's own docker1/docker2 courses — container knowledge is assumed throughout. docker2-8 deliberately gave only an "orientation" toward Kubernetes without teaching it. This chapter is that promised deeper dive, starting from the actual problem Kubernetes exists to solve.

The Problem: Containers at Scale

A single container is easy to manage by hand — docker run, or Docker Compose for a handful running together on one host. But what happens with hundreds or thousands of containers spread across many physical machines? Which host runs which container? What happens when a host dies? How do containers find each other across hosts? How do you roll out an update without downtime? How do you scale up or down automatically? None of this is solved by Docker alone — Docker manages containers on a single host.

What "Container Orchestration" Actually Means

Container orchestration is automating the deployment, scaling, networking, and lifecycle management of containers across a cluster of machines, not just one. An orchestrator makes scheduling decisions (which node runs which workload), handles failures automatically (self-healing), and provides a consistent way to describe "what should be running" — a declarative desired-state model this course returns to repeatedly, starting with Chapter 5.

A Brief History — From Borg to Kubernetes

Google's internal Borg system ran containers at massive internal scale for over a decade before Kubernetes existed. Kubernetes, released in 2014, was Google's open-sourced, redesigned answer — donated to the Cloud Native Computing Foundation (CNCF). The name is Greek for "helmsman" or "pilot," explaining both the ship's-wheel logo and the common abbreviation "K8s" (K, 8 letters, s).

Why Docker Alone Isn't Enough at Scale

Directly closing the loop on docker2-8's deferral: Docker Compose handles multiple containers on one host well. It has no concept of multiple physical machines, no automatic failover if a host dies, no built-in rolling-update mechanism across a fleet, and no cluster-aware scheduling at all. These gaps are exactly what Kubernetes exists to close.

What Kubernetes Actually Adds

• Scheduling workloads across many nodes (Chapter 2).
• Automatically restarting or replacing failed containers (Chapters 5, 11).
• Built-in service discovery and load balancing (Chapter 6).
• Declarative rollouts and rollbacks (Chapter 5).
• Horizontal scaling, covered fully in Course 2.
• Secret and configuration management (Chapter 7).
• Storage orchestration across a cluster (Chapter 8).

Kubernetes vs. Docker — Clearing Up a Common Confusion

Kubernetes and Docker are not competitors. Kubernetes orchestrates containers; Docker (or another container runtime) actually runs them. Historically Kubernetes used Docker directly as its runtime; modern Kubernetes uses the Container Runtime Interface (CRI) and commonly runs containerd directly instead. Container images built in docker1/docker2 remain fully compatible and reusable regardless — they follow the OCI (Open Container Initiative) image standard, independent of which runtime actually executes them.

Where Kubernetes Fits in the Cloud & DevOps Landscape

cloud1-2's terminology map already named the managed Kubernetes services — EKS, AKS, GKE. This course stays deliberately provider-agnostic and conceptual first, matching cloud1's own cross-provider framing, before any provider-specific managed-service detail. Worth distinguishing from cloud1-3's VM-level auto-scaling groups too: that's scaling whole virtual machines; Kubernetes orchestrates containers within a cluster of machines — related, but a genuinely different layer.

When You Don't Need Kubernetes

An honest counterpoint, matching this site's own recurring convention: a small application running on a single server, or even Docker Compose on one host, doesn't need Kubernetes' complexity. Kubernetes solves problems that only really appear at a certain scale — adopting it prematurely adds real operational overhead without a corresponding benefit. Worth naming plainly rather than treating Kubernetes as something every project automatically needs.

Hands-On Exercises