1. Containers vs Virtual Machines
A container packages an application with everything it needs to run — code, runtime, libraries, config — but shares the host machine's OS kernel. A virtual machine virtualizes an entire hardware stack, including its own OS. This makes containers dramatically lighter and faster to start.
Figure 1 — VMs virtualize hardware and duplicate the OS per app; containers share one OS kernel via a container engine.
2. Docker Core Concepts
📄 Dockerfile
A text file with instructions to build an image — base OS, dependencies, code, and startup command.
🖼️ Image
An immutable, layered snapshot built from a Dockerfile. Stored in a registry (Docker Hub, ECR, GCR).
📦 Container
A running instance of an image — an isolated process with its own filesystem, network, and process space.
FROM node:20-alpine WORKDIR /app COPY package*.json ./ RUN npm install --production COPY . . EXPOSE 3000 CMD ["node", "server.js"]
Each instruction (FROM, COPY, RUN) creates a cached image layer — unchanged layers are reused on rebuild, which is why Dockerfiles are usually ordered from least- to most-frequently-changing steps.
3. From One Container to a Cluster
Running a single container is easy. Running hundreds of containers reliably — restarting failed ones, load-balancing traffic, scaling under demand — is where Kubernetes comes in. Kubernetes is a container orchestration platform that automates deployment, scaling, and management of containerized applications.
4. Kubernetes Architecture
Figure 2 — The Control Plane decides "what should run where"; worker nodes actually run the pods via kubelet.
| Component | Role |
|---|---|
| API Server | Front door for all cluster operations (kubectl talks to this) |
| Scheduler | Decides which node a new pod should run on |
| Controller Manager | Continuously reconciles actual state → desired state |
| etcd | Distributed key-value store holding all cluster state |
| kubelet | Agent on each node that starts/stops containers as instructed |
| kube-proxy | Handles networking rules so pods can talk to each other |
5. Key Kubernetes Objects
The smallest deployable unit — one or more tightly-coupled containers sharing storage/network. Pods are ephemeral; they get replaced, not repaired.
Declares the desired number of pod replicas and manages rolling updates. If a pod dies, the Deployment controller creates a new one automatically.
A stable network endpoint (IP + DNS name) that load-balances traffic across a set of pods, even as individual pods come and go.
Externalized configuration and sensitive values, injected into pods without baking them into the container image.
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-app
spec:
replicas: 3
selector:
matchLabels: { app: web }
template:
metadata:
labels: { app: web }
spec:
containers:
- name: web
image: myregistry/web-app:1.4.0
ports: [{ containerPort: 3000 }]
---
apiVersion: v1
kind: Service
metadata:
name: web-app-service
spec:
selector: { app: web }
ports: [{ port: 80, targetPort: 3000 }]
type: LoadBalancer
This YAML tells Kubernetes: "always keep 3 replicas of this container running, and expose them behind a single load-balanced address."
6. Self-Healing in Action
Figure 3 — When a pod dies, the Controller Manager notices the mismatch and schedules a replacement without human intervention.
7. Quick Reference
| Command | What it does |
|---|---|
docker build -t app:1.0 . | Build an image from a Dockerfile |
docker run -p 3000:3000 app:1.0 | Run a container, mapping host:container ports |
kubectl apply -f deployment.yaml | Create/update resources from a YAML manifest |
kubectl get pods | List running pods in the current namespace |
kubectl scale deployment web-app --replicas=5 | Scale a deployment up or down |
kubectl logs <pod-name> | View container logs for debugging |