Kubernetes vs Docker : quelle différence, quel choix ?

« Kubernetes vs Docker » est l'une des comparaisons les plus mal posées du développement moderne. On imagine deux produits rivaux qu'il faudrait départager, alors qu'il s'agit de deux outils qui opèrent à des niveaux différents et se complètent très bien. Docker fabrique et lance des conteneurs sur une machine. Kubernetes pilote une flotte de conteneurs répartis sur plusieurs serveurs. Comprendre cette distinction vous évite d'installer une usine à gaz là où quelques conteneurs bien déployés suffiraient largement.

En bref : Docker et Kubernetes ne sont pas concurrents. Docker construit une image et exécute des conteneurs sur une seule machine. Kubernetes orchestre des centaines de conteneurs sur un cluster de serveurs. On les utilise souvent ensemble : Docker pour empaqueter l'application, Kubernetes pour la piloter à grande échelle. Une petite équipe n'a généralement pas besoin de Kubernetes, seulement de conteneurs déployés et maintenus en vie.

Docker, la brique de base

Docker règle un problème très concret : « ça marche sur ma machine, mais pas sur le serveur ». En empaquetant votre application avec sa version de langage, ses bibliothèques et sa configuration dans une image, Docker garantit que ce qui tourne chez vous tournera à l'identique en production. Vous décrivez cet emballage dans un Dockerfile, vous construisez une image, puis vous lancez cette image sous forme de conteneur.

Docker est un outil de conteneurisation qui empaquette une application et ses dépendances dans une image portable, puis exécute cette image comme un conteneur isolé sur un hôte unique. C'est la brique de base du monde des conteneurs : construire, lancer, arrêter, mais toujours sur une seule machine.

Le point important est là : Docker, seul, travaille sur un seul hôte. Il ne sait pas répartir votre application sur dix serveurs, redémarrer un conteneur tombé pendant la nuit sur une autre machine, ni équilibrer le trafic entre plusieurs copies. Pour comprendre les fondamentaux du format d'image et de la construction, la documentation officielle de Docker reste la meilleure référence.

Kubernetes, le chef d'orchestre

Kubernetes (souvent abrégé « K8s ») ne construit pas d'images et ne remplace pas Docker. Il part du principe que vous avez déjà des conteneurs, et son travail consiste à les faire tourner de façon fiable, en grand nombre, sur un ensemble de machines appelé cluster.

Kubernetes est un orchestrateur de conteneurs open source qui déploie, surveille et redémarre automatiquement des conteneurs répartis sur un cluster de plusieurs serveurs. Il gère l'équilibrage de charge, les mises à jour progressives et la reprise après panne, à l'échelle de centaines de conteneurs.

Concrètement, vous décrivez l'état souhaité (« je veux trois copies de cette application, joignables sur ce port »), et Kubernetes s'arrange pour que la réalité corresponde en permanence à cette description. Si un serveur tombe, il redéploie ailleurs. Si une copie plante, il la relance. Cette puissance a un prix : Kubernetes est un système complexe à installer, sécuriser et maintenir. La documentation de Kubernetes détaille bien cette philosophie de l'état déclaratif.

Kubernetes vs Docker : deux outils, deux niveaux

La meilleure façon de retenir la différence est de raisonner par niveau d'abstraction. Docker opère au niveau du conteneur individuel. Kubernetes opère au niveau du groupe de conteneurs et des machines qui les hébergent.

Dans une chaîne de production classique, les deux travaillent d'ailleurs à la suite : vous construisez une image avec Docker, vous la poussez dans un registre, puis Kubernetes récupère cette image et l'exécute sur le cluster. L'un ne va pas sans l'autre dès que vous passez à l'échelle. Poser la question en termes de « Kubernetes ou Docker » revient à demander s'il faut choisir entre un moteur et une chaîne de montage.

Il existe toutefois une nuance technique qui prête à confusion : au niveau du cluster, Kubernetes n'a pas besoin du moteur Docker complet pour lancer les conteneurs. Il lui suffit d'un runtime plus léger comme containerd ou CRI-O. Nous y revenons ci-dessous, car c'est la source d'un malentendu tenace.

La confusion Docker Swarm

Docker propose son propre orchestrateur intégré, Docker Swarm. C'est bien là que la comparaison « Kubernetes vs Docker » devient légitime, mais partielle : ce n'est pas Docker en général qui s'oppose à Kubernetes, c'est Swarm qui joue dans la même catégorie que Kubernetes.

Swarm est nettement plus simple à prendre en main et suffit pour de petits déploiements multi-serveurs. Il a cependant perdu la bataille de l'écosystème : la communauté, les outils et les offres managées se sont massivement portés vers Kubernetes. Si vous démarrez aujourd'hui et que vous avez réellement besoin d'orchestration, Kubernetes est le standard de fait. Si vous n'avez pas ce besoin, ni l'un ni l'autre n'est nécessaire.

La suppression de dockershim, souvent mal comprise

En 2021, l'annonce que Kubernetes allait « supprimer Docker » (le retrait de dockershim, effectif à partir de la version 1.24) a provoqué une petite panique. Beaucoup ont cru que leurs images Docker cesseraient de fonctionner. C'est faux, et il est utile de dissiper ce malentendu.

Ce qui a été retiré, c'est une couche d'adaptation interne (dockershim) qui permettait à Kubernetes de dialoguer avec le moteur Docker comme runtime. Kubernetes utilise désormais directement containerd ou CRI-O. En revanche, vos images restent parfaitement valides : elles suivent le standard OCI, et une image construite avec docker build tourne sans problème sur un cluster moderne. La FAQ officielle sur le retrait de dockershim confirme ce point noir sur blanc : rien à changer côté images.

Avez-vous vraiment besoin de Kubernetes ?

Voici la question qui compte vraiment, et la réponse honnête surprend souvent. La majorité des petites équipes n'ont pas besoin de Kubernetes. Ce dont elles ont besoin, c'est de conteneurs déployés, joignables en HTTPS, et maintenus en vie sans intervention nocturne.

Kubernetes devient pertinent quand vous gérez de nombreux services, un trafic très variable qui exige une mise à l'échelle fine, ou une équipe dédiée à l'infrastructure. En dessous de ce seuil, opérer un cluster vous coûte plus de temps qu'il ne vous en fait gagner : sécurité, mises à jour, réseau, stockage, observabilité, autant de chantiers permanents.

C'est exactement l'espace que couvre une plateforme en tant que service (PaaS). Pour bien situer ce modèle, notre guide qu'est-ce qu'un PaaS pose les bases. L'idée : vous poussez du code ou un Dockerfile, la plateforme construit l'image et fait tourner l'application, sans que vous ayez jamais à toucher un cluster.

Là où un PaaS entre en jeu

Sur Out Plane, vous fournissez un Dockerfile (ou un buildpack détecté automatiquement), la plateforme construit l'image et lance votre application. Le HTTPS est automatique, et chaque service obtient une URL publique de la forme {name}-{port}-{teamSlug}.outplane.app. Une base de données PostgreSQL managée peut vivre à côté, avec sauvegardes, restauration à un instant précis (PITR), réplicas de lecture, pooling et pgvector.

Soyons transparents sur le périmètre : Out Plane n'est pas un orchestrateur complet. Il n'y a pas de mise à l'échelle automatique ni de scale-to-zero. Si vous avez besoin de faire varier dynamiquement des centaines de conteneurs en fonction du trafic, un vrai cluster Kubernetes reste l'outil adapté. En revanche, des volumes persistants et un réseau privé existent bel et bien, ce qui couvre l'immense majorité des besoins d'une équipe produit.

Côté base de données, seule PostgreSQL est managée. Pour un moteur comme Redis ou MySQL, vous l'exécutez comme un conteneur classique avec un volume persistant, que vous opérez vous-même. Si vous partez d'images existantes, notre guide sur héberger vos conteneurs Docker montre le déroulé, et l'exemple de déployer n8n avec Docker illustre un cas concret d'application conteneurisée mise en ligne sans cluster. Un palier gratuit pour développeurs permet de tester tout cela sans carte bancaire.

Questions fréquentes

Kubernetes remplace-t-il Docker ?

Non. Kubernetes ne construit pas d'images et ne remplace pas Docker comme outil de conteneurisation. Il orchestre des conteneurs déjà construits sur un cluster. Vous pouvez très bien empaqueter votre application avec Docker, puis la faire tourner sur Kubernetes. Les deux occupent des niveaux différents et se complètent.

Docker et Kubernetes peuvent-ils fonctionner ensemble ?

Oui, c'est même le scénario le plus courant en production à grande échelle. Vous construisez une image avec Docker, vous la publiez dans un registre, puis Kubernetes la récupère et l'exécute sur plusieurs serveurs. Docker s'occupe de l'emballage, Kubernetes du pilotage. Ils forment une chaîne, pas une alternative.

Qu'est-ce que la suppression de dockershim a changé ?

Presque rien pour vous. Kubernetes a retiré une couche interne qui dialoguait avec le moteur Docker, au profit de containerd ou CRI-O. Vos images restent valides car elles suivent le standard OCI. Une image construite avec docker build tourne toujours sur un cluster Kubernetes récent, sans modification de votre part.

Docker Swarm est-il une alternative à Kubernetes ?

Oui, mais une alternative en perte de vitesse. Docker Swarm est l'orchestrateur intégré de Docker, plus simple à installer que Kubernetes. Il convient à de petits déploiements multi-serveurs. L'écosystème, les outils et le support communautaire se sont toutefois concentrés sur Kubernetes, devenu le standard de fait de l'orchestration.

Une petite équipe a-t-elle besoin de Kubernetes ?

Rarement. La plupart des petites équipes veulent seulement déployer des conteneurs, les exposer en HTTPS et les garder en vie. Opérer un cluster Kubernetes mobilise du temps sur la sécurité, les mises à jour et le réseau. Un PaaS fournit le même résultat sans cette charge, avec une base PostgreSQL managée en prime.

Peut-on utiliser Docker sans Kubernetes en production ?

Absolument. De nombreuses applications tournent en production dans des conteneurs Docker sans orchestrateur, sur un seul serveur ou via une plateforme managée. Kubernetes ne devient utile que lorsque vous avez besoin de mise à l'échelle automatique, de reprise après panne sur plusieurs machines, ou de gérer une grande flotte de services.

Un PaaS évite-t-il de gérer soi-même Kubernetes ?

Oui, c'est justement sa raison d'être. Vous fournissez du code ou un Dockerfile, la plateforme construit l'image et maintient l'application en ligne. Vous n'installez, ne sécurisez ni ne mettez à jour aucun cluster. En contrepartie, vous renoncez au contrôle fin qu'offre Kubernetes, ce qui convient très bien à la plupart des projets.

Kubernetes est-il gratuit ?

Kubernetes est un logiciel open source, donc gratuit à installer. Ce qui coûte, c'est de l'opérer : serveurs, temps d'ingénierie, sécurité et maintenance permanente. C'est pourquoi beaucoup passent par une offre managée. Un PaaS déplace ce coût vers un modèle à l'usage, sans facture de cluster à administrer.

Conclusion

Le débat « Kubernetes vs Docker » repose sur une fausse opposition. Docker construit et lance des conteneurs sur une machine, Kubernetes orchestre des flottes de conteneurs sur un cluster, et les deux travaillent le plus souvent ensemble. La vraie question n'est pas « lequel choisir », mais « ai-je réellement besoin d'un orchestrateur ». Pour une petite ou moyenne équipe, la réponse est généralement non : il vous faut des conteneurs déployés et maintenus, pas un cluster à administrer.

Si c'est votre cas, la voie la plus directe est de partir de vos images sans opérer d'infrastructure. Créez votre première application dans la console sur https://console.outplane.com : le palier Hobby est gratuit en permanence et un crédit d'essai de 20 $ vous attend sans carte bancaire. Consultez la page /pricing pour les détails du modèle à l'usage, et comparez les options via notre panorama des PaaS européens comparés.