Kubernetes vs Docker : quelle différence ? (explication simple)

Je lisais une offre d’emploi l’année dernière qui listait “Docker + Kubernetes” dans les prérequis comme si c’était un seul et même outil. Docker slash Kubernetes. Un seul bullet point. J’ai hoché la tête, supposé que c’étaient deux noms pour la même chose, et je suis passé à autre chose.

Il s’avère que c’est un peu comme dire “guitare + orchestre” comme si c’étaient des synonymes. Les deux sont liés. Ils apparaissent dans les mêmes conversations. Mais ils résolvent des problèmes complètement différents, et comprendre où l’un s’arrête et où l’autre commence vous évitera beaucoup de confusion.

Docker, c’est le conteneur

Commençons par Docker, parce qu’il est arrivé en premier et qu’il constitue la base.

Docker empaquette votre application — code, dépendances, runtime, fichiers de config, tout — dans une unité unique appelée conteneur. Ce conteneur tourne de la même façon sur votre laptop, sur un serveur de staging, sur une VM de production chez AWS. Fini le “ça marche sur ma machine” suivi de deux heures de debug sur des bibliothèques système manquantes.

Pour l’expliquer simplement : avant Docker, déployer une application signifiait configurer soigneusement l’environnement serveur, installer la bonne version de Python ou Node, et prier pour que rien n’entre en conflit avec ce qui tournait déjà. Un conteneur embarque tout ça à l’intérieur de lui-même. Il se fiche de ce à quoi ressemble l’hôte.

Voici ce que Docker fait concrètement :

• Empaquette votre appli et ses dépendances dans une image (un blueprint)
• Expédie cette image vers n’importe quelle machine avec Docker installé
• Exécute l’image en tant que conteneur — isolé, reproductible, léger
• Versionne tout, pour que vous puissiez revenir au build d’hier en quelques secondes

Si vous avez déjà écrit un Dockerfile, buildé une image et lancé docker run, vous avez utilisé Docker. C’est toute la boucle. Build, ship, run.

Pour une seule application sur un seul serveur, Docker seul suffit souvent largement. Et honnêtement ? Ça couvre plus de projets réels que les gens ne veulent bien l’admettre.

Kubernetes, c’est l’orchestre

Maintenant imaginez que vous n’avez pas un conteneur. Vous en avez quarante. Un frontend web, une API gateway, trois microservices, quelques workers de file d’attente, un cache Redis, une base PostgreSQL — chacun dans son propre conteneur. Tournant sur dix serveurs. Certains ont besoin de trois réplicas, d’autres de dix. Le trafic explose à 9h tous les matins et il faut scaler. Un serveur tombe à 3h du matin et quelqu’un doit relancer les conteneurs qui y tournaient.

Vous n’allez pas faire du SSH sur chaque serveur pour lancer docker run manuellement. Vous perdriez la raison avant jeudi.

C’est là qu’intervient Kubernetes. Kubernetes — K8s en abrégé, parce que quelqu’un a décidé que les huit lettres entre K et S méritaient une contraction — est un orchestrateur de conteneurs. Il ne construit pas de conteneurs. Il ne remplace pas Docker. Il gère les conteneurs à grande échelle.

Voici ce que Kubernetes prend en charge :

• Scaling : besoin de plus de réplicas ? K8s les lance. Le trafic baisse ? Il réduit.
• Auto-réparation : un conteneur plante, K8s le redémarre. Un noeud meurt, K8s replanifie ces conteneurs ailleurs.
• Répartition de charge : distribue le trafic entre vos réplicas automatiquement.
• Mises à jour progressives : déployez une nouvelle version sans interruption en remplaçant progressivement les anciens conteneurs par les nouveaux.
• Découverte de services : les conteneurs se trouvent par nom, pas d’IPs codées en dur.

Kubernetes se fiche de comment vos conteneurs ont été construits. Il a juste besoin d’images de conteneurs à exécuter. Docker construit les images. Kubernetes les exécute et les gère.

L’analogie qui m’a vraiment aidé

Docker est un musicien. Il sait jouer de son instrument, transporter son matériel et exécuter sa partition parfaitement.

Kubernetes est le chef d’orchestre. Il ne joue d’aucun instrument. Mais il décide qui joue quand, combien de violons sont nécessaires ce soir, ce qui se passe si le violoncelliste est malade, et comment intégrer un remplaçant sans que le public ne remarque quoi que ce soit.

On peut avoir un musicien sans chef d’orchestre. Concert solo, petite salle, ça passe. Mais on ne peut pas avoir un chef d’orchestre sans musiciens. Et dès qu’il y a trente musiciens sur scène, quelqu’un doit coordonner, sinon c’est du bruit, pas de la musique.

Comment ils fonctionnent ensemble

C’est la partie qui m’a embrouillé le plus longtemps. Docker et Kubernetes ne sont pas des concurrents. Ce sont des couches dans la même stack.

Le flux typique ressemble à ça :

1. Vous écrivez un Dockerfile qui définit l’image conteneur de votre application
2. Vous buildez l’image avec docker build
3. Vous poussez l’image vers un registre de conteneurs (Docker Hub, ECR, GCR, peu importe)
4. Vous écrivez des manifestes Kubernetes (fichiers YAML) qui décrivent combien de réplicas lancer, quelles ressources elles nécessitent, comment les exposer au réseau
5. Kubernetes tire l’image depuis le registre et la fait tourner dans votre cluster

Docker gère les étapes 1 à 3. Kubernetes gère les étapes 4 et 5. Ils se rejoignent au niveau de l’image conteneur — c’est le point de passage.

Un détail qui vaut la peine d’être mentionné : Kubernetes a abandonné le support direct de Docker dans la version 1.24 (décembre 2022). Il utilise désormais containerd ou CRI-O comme runtime de conteneurs. Mais vous construisez toujours vos images avec Docker. Les images elles-mêmes sont conformes OCI, ce qui signifie qu’elles fonctionnent partout. Rien n’a changé de votre point de vue en tant que développeur.

Quand vous n’avez PAS besoin de Kubernetes

Je sais que ça peut sembler étrange dans un article “Kubernetes vs Docker”, mais : la majorité des projets n’ont pas besoin de Kubernetes. Voilà, c’est dit.

Vous n’avez probablement pas besoin de K8s si :

• Vous faites tourner un ou deux services sur un seul serveur
• Votre trafic est prévisible et ne nécessite pas d’auto-scaling
• Votre équipe est petite (un à trois devs) et personne n’a d’expérience K8s
• Vous construisez un side project, un MVP, ou une startup en phase initiale
• Un service managé comme AWS ECS, Railway, Fly.io, ou même un simple VPS avec Docker Compose couvre vos besoins

Docker Compose est le sweet spot pour un nombre surprenant d’applications. Définissez vos services dans un docker-compose.yml, lancez docker compose up, et vous avez un setup multi-conteneurs avec réseau, volumes et variables d’environnement. Pas de gestion de cluster, pas de prolifération de YAML, pas de session de debug de trois jours parce qu’un pod n’arrive pas à joindre un service.

J’ai vu des équipes adopter Kubernetes pour une application à deux services parce que ça semblait être le choix “sérieux”. Six mois plus tard, elles avaient plus de fichiers YAML que de code applicatif et un cluster que personne ne comprenait complètement. L’infrastructure doit correspondre au problème, pas au CV.

Quand vous AVEZ besoin de Kubernetes

Cela dit, Kubernetes existe pour une raison, et quand on en a besoin, rien d’autre ne fait le poids.

Vous devriez sérieusement envisager K8s quand :

• Vous faites tourner de nombreux microservices qui doivent communiquer, scaler indépendamment et se déployer séparément
• Vous avez besoin d’auto-scaling basé sur le CPU, la mémoire ou des métriques personnalisées
• La haute disponibilité est non négociable — vous ne pouvez pas vous permettre de downtime quand un serveur tombe
• Vous déployez dans plusieurs régions ou zones
• Vous voulez des déploiements sans interruption avec des mises à jour progressives et des rollbacks faciles
• Votre équipe a grandi et vous avez besoin de patterns de déploiement standardisés que tout le monde suit

Kubernetes brille exactement au niveau de complexité où la gestion manuelle s’effondre. Si vous faites tourner quinze services sur six serveurs et que vous avez besoin qu’ils restent tous up, auto-scalent et se mettent à jour sans interruption — c’est le territoire de K8s. Essayer de faire ça avec des scripts shell et Docker Compose marchera jusqu’au moment où ça ne marchera plus, généralement à 3h du matin un jour férié.

La plupart des offres Kubernetes managées (EKS, GKE, AKS) gèrent aussi les parties difficiles du control plane. Vous n’avez pas besoin d’opérer etcd vous-même. Le fournisseur cloud s’en charge. Vous définissez ce que vous voulez faire tourner et Kubernetes s’en occupe.

L’ordre d’apprentissage (c’est important)

Si vous partez de zéro, voici ma recommandation honnête : apprenez Docker d’abord. Point final.

Kubernetes sans connaître Docker, c’est comme essayer d’apprendre l’orchestration sans savoir à quoi ressemble le son d’un instrument. Vous allez mémoriser des champs YAML sans comprendre ce qui se passe réellement dans les conteneurs que vous déployez.

Voici un parcours d’apprentissage concret :

1. Les bases de Docker — images, conteneurs, Dockerfiles, volumes, réseau. Construisez une vraie image d’application, lancez-la, cassez-la, réparez-la.
2. Docker Compose — setups multi-conteneurs. Faites tourner une appli web + base de données + cache en local.
3. Les fondamentaux des conteneurs — comprenez ce que sont les namespaces, les cgroups et les layers sous le capot. Pas obligatoire, mais ça enlève la magie.
4. Les concepts Kubernetes — pods, deployments, services, ingress. Commencez avec Minikube ou Kind sur votre laptop.
5. Kubernetes en pratique — déployez votre application Docker Compose sur un cluster K8s. Observez comment les concepts se transposent.

La plupart des gens essaient d’apprendre les deux simultanément et finissent confus sur quelle couche fait quoi. Docker d’abord, puis K8s. Chaque ingénieur expérimenté à qui j’ai posé la question dit la même chose.

Si vous construisez vos compétences cloud en partant de zéro, ce guide pour apprendre le cloud computing en tant que débutant présente la feuille de route complète — conteneurs inclus.

Et si trouver du temps au quotidien pour ça vous semble impossible, construire une habitude d’apprentissage de 15 minutes est une approche bien plus durable que les sessions marathon du week-end qu’on oublie dès lundi.

FAQ

Peut-on utiliser Kubernetes sans Docker ?

Oui, techniquement. Kubernetes fonctionne avec n’importe quel runtime de conteneurs conforme OCI — containerd et CRI-O sont les plus courants. Mais vous utiliserez toujours probablement Docker pour construire vos images, même si Kubernetes utilise un runtime différent pour les exécuter. En pratique, Docker reste l’outil standard pour créer des images de conteneurs, et ce n’est pas près de changer.

Docker Compose est-il un remplacement de Kubernetes ?

Pour des projets de petite à moyenne taille, il peut l’être. Docker Compose gère très bien l’orchestration multi-conteneurs sur un seul hôte. Là où il atteint ses limites, c’est le scaling multi-noeuds, l’auto-réparation à travers plusieurs serveurs et le load balancing de niveau production. Si votre appli vit sur un seul serveur et que vous n’avez pas besoin d’auto-scaling, Compose est plus simple et tout à fait suffisant. Une fois que vous dépassez ça, Kubernetes prend le relais.

Kubernetes est-il excessif pour mon projet ?

Probablement, si vous posez la question. Ce n’est pas une pique — c’est sincèrement vrai pour la majorité des applications. Kubernetes ajoute une complexité opérationnelle qui ne se rentabilise qu’à partir d’une certaine échelle. Si vous avez moins de cinq services et une petite équipe, commencez avec Docker Compose ou un service de conteneurs managé. Vous pourrez toujours migrer vers K8s plus tard, et vous prendrez de meilleures décisions une fois que vous aurez atteint les limites d’outils plus simples.

Combien de temps faut-il pour apprendre Kubernetes ?

Les bases de Docker : une à deux semaines de pratique ciblée. Les fondamentaux de Kubernetes (assez pour déployer et gérer une application simple) : encore deux à quatre semaines. Kubernetes en profondeur (réseau, RBAC, Helm, operators, debug de problèmes en production) : des mois de pratique concrète. L’écart entre “je peux suivre un tutoriel” et “je peux débugger un pod en échec en production” est considérable. Soyez patient.

Envie d’un parcours structuré à travers Docker, Kubernetes et l’infrastructure cloud ? Découvrez SkillRealm Learn →