Docker ou Kubernetes : qui fait quoi ?

La réponse courte

Ce n’est pas un ou-exclusif. Docker (ou BuildKit, ou n’importe quel OCI builder) fabrique le colis. Kubernetes fait tenir le colis en nombre, sur un cluster : où il s’exécute, combien d’exemplaires, comment on les joint, comment on les remplace.

Dockerfile  →  image  →  registre
                          ↓
              Deployment (je veux 3)
                          ↓
                   Pods + Service

Docker sait lancer un conteneur, un petit graphe avec Compose, un réseau bridge, un volume. Il ne sait pas : élire un nœud, rescheduler après une panne machine, faire un rolling update avec budget, exposer un Service stable pendant que les Pods naissent et meurent, appliquer des quotas multi-équipes.

Kubernetes ne sait pas, à lui seul, comment votre jar a été compilé. Il référence une image. Si l’image est grasse, root, et taguée latest, le cluster exécute exactement ça, très bien, en trois réplicas.

Ce que l’intervieweur vérifie

Que vous cessez de répondre « on a mis Kubernetes donc on n’a plus besoin de Docker ». Beaucoup de clusters n’utilisent plus Docker Engine comme runtime (containerd, CRI-O) ; ils utilisent encore des images OCI, souvent construites par Docker ou BuildKit. La compétence Dockerfile ne disparaît pas. Elle devient le contrat d’entrée du cluster.

Il vérifie aussi que vous ne transformez pas la question en cours Kubernetes. Pod, Deployment, Service : trois mots suffisent à situer. Le ConfigMap n’est pas « l’ENV de Docker en plus compliqué » : c’est le réglage hors de l’image, ce que l’image seule ne doit plus contenir.

Le fil du code jusqu’au navigateur est déroulé dans Docker et Kubernetes : qui fait quoi.

La relance probable

« On peut faire de la prod avec Docker seuls ? »

Oui, à petite échelle : une ou deux VM, Compose ou des units systemd, des backups de volumes, une discipline de tags. Le jour où vous avez besoin de plusieurs nœuds et d’une réparation automatique, vous n’ajoutez pas « plus de Docker ». Vous changez de couche.

« Docker Swarm alors ? »

Une réponse honnête : c’est un orchestrateur, il existe, ce n’est plus là que se créent les postes. En entretien 2026, Kubernetes est l’horizon ; Swarm est une note de bas de page, pas le sujet.