Conteneur contre orchestrateur : qui fait quoi
Trois mots que les réunions techniques mélangent, et une seule idée derrière : **l'image** est le paquet figé (le code, les bibliothèques, la configuration), **le conteneur** est ce paquet en train de tourner, un processus isolé, et **l'orchestrateur** est le logiciel qui surveille une flotte de conteneurs. Le problème de départ est banal : l'appli tourne chez toi, pas chez ton collègue. Docker le règle en construisant une image que n'importe quelle machine lance à l'identique. Le second problème arrive avec le succès : des milliers de visiteurs, des conteneurs qui plantent, du trafic à répartir à la main. C'est le travail de Kubernetes, qui relance un conteneur en échec, ajoute des exemplaires quand la charge monte et répartit le trafic entre eux. La phrase à retenir tient en une ligne : la question n'est pas Docker contre Kubernetes, c'est Docker puis Kubernetes. Le premier fabrique et lance les boîtes, le second gère leur nombre et leur santé. Un seul conteneur sur ta machine (un n8n local, une base de test) n'a aucun besoin d'orchestrateur ; Kubernetes ne devient utile qu'au moment où tu en gères des dizaines en production. Kubernetes ne construit d'ailleurs pas ton appli, il suppose que les images existent déjà (sa documentation le dit en toutes lettres). Schéma à garder en tête (un schéma, pas une capture) : une image, puis un conteneur qui en sort, puis N conteneurs identiques sous la surveillance d'un orchestrateur. Source du cadrage : [Instagram reel DfKNA4UPQAm](https://www.instagram.com/reel/DfKNA4UPQAm/), vérifié contre les documentations de Docker et de Kubernetes.