Conteneur contre orchestrateur : qui fait quoi
Three words that technical meetings blur, and one idea behind them: **the image** is the frozen package (code, libraries, configuration), **the container** is that package running, an isolated process, and **the orchestrator** is the software watching a fleet of containers. The starting problem is mundane: the app runs on your machine, not on your colleague's. Docker solves it by building an image that any machine launches identically. The second problem comes with success: thousands of visitors, containers that crash, traffic to spread by hand. That is Kubernetes' job: it restarts a failed container, adds copies when load climbs and spreads traffic between them. The sentence to keep fits on one line: the question is not Docker versus Kubernetes, it is Docker then Kubernetes. The first builds and launches the boxes, the second manages their number and health. A single container on your machine (a local n8n, a test database) has no use for an orchestrator; Kubernetes only pays off once you run dozens in production. Kubernetes does not build your app either, it assumes the images already exist (its documentation says so plainly). A mental diagram (a sketch, not a screenshot): one image, then a container coming out of it, then N identical containers under an orchestrator's watch. Framing from [Instagram reel DfKNA4UPQAm](https://www.instagram.com/reel/DfKNA4UPQAm/), checked against the Docker and Kubernetes documentation.