What a container actually is
A container packages an application with everything it needs to run — code, runtime, system libraries, configuration — into one portable unit that runs identically regardless of the host machine underneath it. Unlike a virtual machine, containers share the host's OS kernel, making them far lighter and faster to start.
FROM node:20-alpine
WORKDIR /app
COPY package.json .
RUN npm install
COPY . .
CMD ["node", "server.js"]This Dockerfile describes exactly how to build one container image — every line adds a layer, and Docker caches unchanged layers between builds, which is why ordering (dependencies before source code) matters for build speed.
Why Kubernetes exists
Docker runs one container well. Running dozens or hundreds of containers reliably — restarting crashed ones, scaling up under load, rolling out updates without downtime, routing traffic to healthy instances — is a different, much harder problem. Kubernetes is the tool built specifically to manage that fleet.
Pods: the smallest deployable unit
A pod wraps one or more tightly coupled containers that always run together on the same machine, sharing network and storage. Most pods run exactly one container — the "one or more" flexibility exists for cases like a sidecar container handling logging alongside the main app.
Deployments: declaring the desired state
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-app
spec:
replicas: 3
template:
spec:
containers:
- name: web
image: myapp:1.4.0A Deployment describes what should be running — here, three replicas of this container image — and Kubernetes continuously works to make reality match that description. If a pod crashes, Kubernetes notices and starts a replacement automatically, with no human intervention required.
Services: stable networking for pods that come and go
Pods are ephemeral — they get replaced, and get new internal IP addresses each time. A Service gives a stable, unchanging address that routes to whichever healthy pods currently exist behind it, so other parts of the system never need to track individual pod addresses directly.
Kubernetes is genuinely complex — that's a real cost, not just a learning curve. For a small app with modest traffic, a simpler deployment target (a single server, a managed platform like a PaaS) is often the right call. Kubernetes earns its complexity at real scale — many services, frequent deployments, variable load — not as a default choice for every project.
The mental model that ties it together
Kubernetes is fundamentally declarative: you describe the desired end state (how many replicas, what image, what resources), and a set of controllers continuously reconciles actual state toward that description. Almost every Kubernetes concept — Deployments, Services, ConfigMaps — follows this same "describe what you want, let the system make it true" pattern.
Comments