Why Kubernetes? Pods and the Control Plane
Docker gets a single container running reliably. Kubernetes (often shortened to "k8s") is what takes over once you have many containers, across many machines, that need to be scheduled, restarted when they crash, scaled up and down, and discovered by each other automatically.
The problem Kubernetes solves
Running a handful of containers by hand with docker run works fine on one machine. It falls apart once you have:
- Multiple machines (a cluster) to spread containers across.
- Containers that need to be automatically restarted if they crash or a machine dies.
- A need to scale a service from 2 replicas to 20 during a traffic spike.
- Services that need to find and talk to each other without hardcoded IP addresses.
Kubernetes is a container orchestrator: you declare the desired state ("I want 3 replicas of this container running"), and Kubernetes continuously works to make reality match that declaration.
The control plane and nodes
A cluster has two kinds of machines:
| Control plane | Worker nodes | |
|---|---|---|
| Job | Decides what should run where | Actually runs the containers |
| Key components | API server, scheduler, controller manager, etcd | kubelet, kube-proxy, container runtime |
- The API server is the front door, every
kubectlcommand and every internal component talks to Kubernetes through it. - etcd is the cluster's database, the single source of truth for the desired state.
- The scheduler decides which node a new Pod should run on (based on available resources, constraints, etc).
- The kubelet runs on every worker node and makes sure the containers the control plane assigned to that node are actually running.
Pods: the smallest deployable unit
You don't deploy a container directly in Kubernetes, you deploy a Pod, a wrapper around one or more containers that always run together on the same node and share networking/storage.
apiVersion: v1
kind: Pod
metadata:
name: hello-pod
spec:
containers:
- name: hello
image: nginx:latest
ports:
- containerPort: 80
Most Pods run exactly one container, the "multiple containers" case is for tightly-coupled helpers (like a logging sidecar) that genuinely need to share a network namespace and disk with the main container.
NOTE
You'll rarely create a bare Pod directly in a real project, almost everything is managed through a Deployment (next lesson), which creates and manages Pods for you and handles restarts, scaling, and rollouts.