Kubernetes et Docker : différences et complémentarité
Ils ne sont pas concurrents : l'un crée les conteneurs, l'autre les orchestre. Découvrez leurs rôles respectifs et quand utiliser Kubernetes.
Sur cette page
Pour comprendre la différence, une comparaison avec le transport de marchandises aide, puisque ces outils ont emprunté leurs noms et logos à ce domaine : la baleine de Docker charge les conteneurs, l’helme de Kubernetes (en grec kubernetes signifie précisément « timonier ») les guide.
Le conteneur et le port #
Le conteneur est une boîte standard. À l’intérieur, vous mettez l’application, ses bibliothèques et la version exacte du langage dont elle a besoin. De l’extérieur, c’est toujours la même boîte, avec les mêmes attaches : celui qui la déplace n’a pas besoin de savoir ce qu’il y a dedans. Ainsi, le classique « ça marche sur ma machine » disparaît.
Contrairement à une machine virtuelle, un conteneur n’embarque pas un système d’exploitation complet : il utilise le noyau du système qui l’héberge. C’est pourquoi il démarre en une seconde et ne pèse que quelques dizaines de mégaoctets au lieu de gigaoctets. En revanche, il est moins isolé qu’une VM, et un conteneur Linux nécessite un noyau Linux.
Docker est l’atelier qui construit la boîte et la grue qui la charge sur le camion. Vous écrivez les instructions dans un Dockerfile, Docker produit une image et la fait tourner avec le Docker Engine. Vous trouverez les images prêtes sur Docker Hub, le registre public le plus utilisé.
Kubernetes est le port. Il ne construit pas de boîtes et ne les ouvre pas : il décide sur quel navire va chaque conteneur, combien de copies d’une même cargaison maintenir en circulation, quoi faire lorsqu’un navire coule et comment orienter les camions arrivant vers le bon quai. Si une boîte tombe à la mer, il en charge immédiatement une autre identique sans que personne ne s’en aperçoive.
En pratique, un cluster Kubernetes possède un control plane, qui prend les décisions, et des nœuds (les machines) qui exécutent le travail. Les conteneurs tournent dans des pods, la plus petite unité gérée par Kubernetes : généralement, un pod contient un conteneur, parfois deux ou trois qui doivent fonctionner ensemble.
Un port avec trois conteneurs est une aire de déchargement avec trois boîtes : l’organiser coûte plus cher que le problème qu’il résout. C’est pourquoi de nombreux projets se contentent très bien de Docker seul.
Ce que fait chacun #
| Docker | Kubernetes | |
|---|---|---|
| Domaine | Une machine | Plusieurs machines ensemble |
| Tâche | Construire et exécuter des conteneurs | Les distribuer, les surveiller, les remplacer |
| Problème résolu | « Fonctionne partout de la même manière » | « Reste debout et supporte la charge » |
| Difficulté | L’essentiel s’apprend en un après-midi | Des semaines, et on n’en voit jamais le bout |
| Quand l’utiliser | Dans presque tous les projets | Quand l’échelle de déploiement l’exige |
Kubernetes se justifie par cinq fonctions. Si aucune ne vous est nécessaire, alors Kubernetes ne vous sert à rien :
- Redémarrage automatique de ce qui cesse de fonctionner (self-healing).
- Scalabilité : augmente et réduit le nombre de copies en fonction de la charge.
- Distribution du trafic entre les copies actives.
- Mises à jour progressives, qui remplacent les copies une par une sans interruption, avec retour à la version précédente si quelque chose échoue.
- Configuration déclarative : vous écrivez dans un fichier YAML l’état souhaité et le système travaille pour le maintenir, au lieu d’exécuter des commandes une par une.
« Kubernetes a abandonné Docker » : ce qui s’est réellement passé #
Cette nouvelle revient de temps à autre, et elle est généralement mal expliquée.
Dans la version 1.24, sortie en mai 2022, Kubernetes a supprimé le dockershim, l’élément qui lui permettait d’utiliser le moteur Docker pour faire tourner les conteneurs. Aujourd’hui, il utilise des runtimes plus légers respectant la norme CRI, comme containerd (qui est, soit dit en passant, le même moteur que celui utilisé par Docker en interne) et CRI-O.
Les images ne sont pas concernées : celles créées avec Docker suivent la norme ouverte OCI et fonctionnent de manière identique sur Kubernetes. Pour les développeurs, rien n’a changé : vous construisez avec Docker et exécutez sur Kubernetes comme avant. La modification a seulement impacté ceux qui administrent les clusters.
Que choisir selon votre situation #
Une seule application sur un serveur. Docker suffit : une image, une commande pour la lancer et l’option --restart unless-stopped pour qu’elle redémarre toute seule. Ajouter un orchestrateur ici reviendrait à avoir un second système à maintenir pour gérer une seule chose.
Plusieurs services liés sur une machine, par exemple une application, une base de données et un cache. Ici, vous avez besoin de Docker Compose : un fichier compose.yaml décrit tous les services et la manière dont ils communiquent, et docker compose up les lance ensemble. Cela couvre l’environnement de développement de presque tous les projets et de nombreuses installations en production de taille modeste.
Plusieurs machines, une charge variable, aucune interruption autorisée. C’est là que Kubernetes commence à être rentable. Le critère : si un service doit rester opérationnel lorsqu’une machine tombe en panne, et que le nombre de copies doit s’adapter automatiquement au trafic, vous êtes au bon endroit.
Les solutions intermédiaires. k3s est un Kubernetes léger qui offre les fonctions essentielles avec beaucoup moins de complexité, adapté à deux machines ou à un Raspberry Pi. Docker Swarm, inclus dans Docker, regroupe plusieurs machines avec des commandes que vous connaissez déjà. Enfin, les services managés des grands fournisseurs, Amazon EKS, Google GKE et Azure AKS, s’occupent du control plane pour vous, même si vous devrez apprendre le modèle Kubernetes de toute façon. Sur AWS, il existe aussi ECS, qui fait tourner des conteneurs sans Kubernetes.
Les coûts cachés #
Quiconque installe Kubernetes sur un petit projet découvre rapidement que le coût n’est pas seulement technique :
- Les machines du cluster consomment même sans trafic, car les composants système tournent quoi qu’il arrive.
- Une expertise continue est requise : réseau interne, volumes persistants, gestion des identifiants, mises à jour de version. Kubernetes publie trois versions par an et chacune est supportée pendant environ quatorze mois ; on ne l’installe donc pas pour ensuite l’oublier.
- Le débogage est plus long : entre votre code et la requête de l’utilisateur, il y a davantage de couches, et apprendre à les analyser prend du temps.
- Docker Desktop est payant pour les grandes entreprises : gratuit pour un usage personnel, l’étude et les entreprises de moins de 250 employés avec un chiffre d’affaires inférieur à 10 millions de dollars ; sinon, un abonnement est nécessaire. Si vous cherchez une alternative open source, il existe Podman, Rancher Desktop et, sur Mac, OrbStack ou Colima.
Ce sont d’excellentes raisons de ne pas l’utiliser quand ce n’est pas nécessaire, et aucune d’entre elles ne justifie de l’éviter quand c’est indispensable.
Foire aux questions #
Dois-je apprendre Docker avant Kubernetes ? #
Oui, et cela vous fera gagner du temps. Kubernetes orchestre des conteneurs : si vous ne savez pas ce qu’est une image, comment elle est construite et comment elle est lancée, vous finirez par copier des configurations sans comprendre leur fonctionnement.
Kubernetes peut-il fonctionner sans Docker ? #
Oui, et c’est d’ailleurs la norme : depuis 2022, les clusters utilisent containerd ou CRI-O pour exécuter les conteneurs. Docker reste toutefois l’outil le plus pratique pour construire les images que Kubernetes exécutera ensuite.
Quelle est la différence entre un conteneur et une machine virtuelle ? #
La machine virtuelle contient un système d’exploitation complet, pèse plusieurs gigaoctets et met du temps à démarrer. Le conteneur utilise le noyau du système hôte, pèse beaucoup moins lourd et démarre en une seconde. En revanche, il est moins isolé ; pour faire fonctionner des conteneurs Linux sur Windows ou Mac, il faut tout de même passer par une petite machine virtuelle, que Docker Desktop gère automatiquement.
Kubernetes remplace-t-il Docker Compose ? #
Sur une seule machine non, et de nombreux projets restent sous Compose pour toujours. Compose décrit plusieurs services sur un seul ordinateur, ce qui est parfait pour le développement et les petites installations. Kubernetes décrit ces mêmes services répartis sur plusieurs machines, avec des règles de tolérance aux pannes.
Est-ce nécessaire pour un site ou un blog ? #
Non, dans l’immense majorité des cas. Un site statique, un blog ou une application recevant quelques centaines de visites par jour se gèrent très bien sur un serveur avec Docker, voire sans. L’orchestration commence à être rentable lorsque la montée en charge et les exigences de disponibilité l’imposent.
Quand choisir Docker Swarm plutôt que Kubernetes ? #
Lorsque vous avez peu de machines, une petite équipe et que vous voulez démarrer rapidement : Swarm s’active avec docker swarm init et utilise des fichiers similaires à ceux de Compose. Il est toutefois beaucoup moins répandu et possède un écosystème réduit. Si vous prévoyez de croître, il vaut mieux investir directement dans Kubernetes, peut-être en commençant par k3s.
Combien coûte un cluster managé ? #
Cela dépend du fournisseur et de la taille. Le principal poste de dépense concerne généralement les machines qui le composent (qui restent allumées en permanence), plus une petite tarification horaire pour le control plane sur certains services. Un environnement minimal avec redondance coûte tout de même plus cher qu’un serveur unique : faites vos calculs avant de vous lancer.
