Kubernetes vs Docker est le mauvais duel. Docker construit et fait tourner des conteneurs sur une machine ; Kubernetes est une plateforme d'orchestration qui planifie ces mêmes conteneurs sur plusieurs. La vraie question est de savoir si votre workload a grandi au-delà d'une machine, et cette comparaison y répond avec une matrice de décision, pas une liste de features.
À retenir
- Docker et Kubernetes ne sont pas concurrents. Docker empaquette une application dans une image portable ; Kubernetes la fait tourner à l'échelle.
- Kubernetes a retiré son shim runtime Docker en v1.24, mais vos images Docker y fonctionnent toujours, car les deux suivent la norme OCI.
- Docker Compose gère plusieurs conteneurs sur une machine. Un cluster extensible ne mérite sa complexité qu'à partir de la deuxième.
- Un control plane Kubernetes coûte de vraies ressources : kubeadm demande 2 CPU et 2 Go de RAM par nœud avant tout déploiement.
- Pour les petites équipes, Compose est plus rapide à opérer et moins cher que n'importe quel cluster.
Qu'est-ce que Docker ?
Docker est un outil de conteneurisation qui empaquette une application, son runtime et ses dépendances dans une seule image. Cette image tourne à l'identique partout où existe le moteur Docker : c'est l'argument de portabilité.
Trois pièces font le travail. Un Dockerfile décrit le build. L'image Docker qui en résulte est un artefact immuable et couche par couche que vous poussez vers un registry. Le démon Docker fait tourner cette image comme un processus isolé partageant le kernel de l'hôte : démarrage en environ une seconde, pas la minute qu'exige une machine virtuelle.
Docker Compose étend Docker à plusieurs conteneurs sur une même machine. Un seul fichier YAML déclare votre application, sa base de données et son cache, et docker compose up démarre les trois. Pour beaucoup de workloads de production, c'est toute l'architecture, portée par un hébergement dédié pour votre stack.
Docker embarque aussi un client, un outil de build et l'outillage d'images dans un seul paquet, raison pour laquelle les développeurs le choisissent en premier.
Qu'est-ce que Kubernetes ?
Kubernetes est une plateforme d'orchestration qui fait tourner des conteneurs sur plusieurs machines et les maintient en vie. Vous déclarez l'état souhaité en YAML, et la couche d'orchestration lit ce YAML en continu pour rapprocher la réalité de la déclaration. Cette boucle de contrôle est toute l'idée derrière Kubernetes.
Un cluster Kubernetes a deux moitiés. Le control plane Kubernetes héberge l'API server, etcd, le scheduler et le controller manager. Chaque nœud Kubernetes fait tourner un kubelet et un runtime de conteneur. Quand un nœud meurt, le scheduler déplace sa charge ailleurs sans intervention : c'est cette garantie de disponibilité que les gens achètent.
L'unité de déploiement est un pod, pas un conteneur. Un Deployment Kubernetes gère des replicas de ce pod, un Service leur donne une adresse stable, un Ingress achemine le trafic. Cette indirection rend possibles l'auto-réparation et les rolling updates, et explique que la courbe d'apprentissage de Kubernetes soit réelle.
Différences architecturales fondamentales
| Dimension | Docker | Kubernetes |
|---|---|---|
| Périmètre | Une machine | Plusieurs machines |
| Unité | Conteneur | Pod |
| Configuration | Dockerfile, fichier Compose | Manifestes YAML déclaratifs |
| Scale | Manuel | Automatique, par règles |
| Auto-réparation | Politique de restart | Re-planification sur nœuds sains |
| Réseau | Bridge par machine | Au niveau du cluster, pods routables |
| Mise en place | Minutes | Heures à jours |
L'architecture sous-jacente diffère d'un seul point : les boucles de contrôle dans l'architecture Kubernetes. Ce seul choix explique le reste. Docker exécute une commande et s'arrête. La plateforme d'orchestration fait tourner des controllers qui comparent l'état souhaité à l'état réel en permanence, puis agissent sur l'écart. C'est pour ça que le cluster se remet d'un nœud mort seul, et pourquoi la plateforme a besoin d'un datastore à quorum pour se souvenir de ce que « souhaité » veut dire.
Docker n'a pas d'architecture équivalente, parce qu'il n'a jamais été conçu pour gérer plus que la machine sur laquelle il tourne.
Quand utiliser Docker
Docker seul est le bon choix plus souvent que l'industrie l'admet.
Utilisez Docker quand vous exploitez une machine, ou une poignée administrées indépendamment : développement local, builds CI, toute application dont le trafic tient sur une boîte, là où un cluster scalable est du surdimensionnement. Un fichier Compose qu'un nouveau développeur lit en deux minutes a de la vraie valeur au quotidien.
Le test honnête : si vous ne pouvez pas nommer une panne précise que Kubernetes aurait empêchée, vous n'avez pas encore besoin de Kubernetes.
Quand utiliser Kubernetes
Kubernetes mérite sa complexité dans des conditions précises.
Vous avez besoin de capacité sur plusieurs machines et voulez que la plateforme répartisse la charge. Vous faites tourner des microservices à cycles de release indépendants, la charge exacte pour laquelle Kubernetes est né. Chaque microservice scale de son côté. Vous devez déployer sans coupure comme routine. Ou le trafic est erratique et vous confiez au scheduler l'ajout de pods à la demande.
Le multi-tenant est un autre déclencheur. Les namespaces Kubernetes, les quotas de ressources et les politiques réseau donnent à une organisation un moyen supporté d'isoler des équipes sur du matériel partagé. Docker Compose n'a pas de réponse à ça.
Cycle de vie d'un conteneur : build, ship, run
Le cycle de vie est identique des deux côtés, preuve la plus nette qu'ils ne sont pas rivaux.
Build. docker build transforme un Dockerfile en image. Kubernetes n'a aucun step de build ; il consomme les images que Docker ou un autre outil produit.
Ship. Vous poussez l'image vers un repository partagé. Les deux outils tirent du même endroit, et un tag d'image fonctionne pour l'un comme pour l'autre.
Run. Docker fait tourner le conteneur directement. Kubernetes planifie un pod sur un nœud, dont le runtime le tire et le démarre.
Seule l'étape run diffère. Toute la comparaison tient en une phrase, et elle explique pourquoi des équipes adoptent l'orchestration sans changer la façon dont Docker empaquette quoi que ce soit.
Orchestration et capacités de scalabilité
Scaler avec Docker, c'est manuel : vous démarrez plus de conteneurs et décidez où. Compose peut faire monter un service en charge sur une machine, mais rien ne rééquilibre quand elle se remplit.
Kubernetes scale sur trois axes. Le Horizontal Pod Autoscaler Kubernetes ajoute des replicas quand le CPU ou des métriques custom franchissent un seuil. Le Cluster Autoscaler ajoute des nœuds quand les pods ne trouvent plus de place. Le Vertical Pod Autoscaler ajuste requests et limits par pod. Ensemble, ils automatisent le travail de capacité que Docker vous laisse.
Le scheduler Kubernetes rend ça possible : il lit les resource requests de chaque pod et le place sur un nœud qui a de la place, en respectant affinités et taints. Mal régler les requests est la cause la plus fréquente d'un cluster Kubernetes qui paraît plein pendant que ses machines dorment, et c'est le premier défi de scalabilité que les équipes rencontrent.
Workflows de déploiement et intégration CI/CD
Une pipeline de déploiement Docker est courte. Construction de l'image, tests, push vers le registre, puis pull du nouveau tag sur la machine. Docker Compose réduit la dernière étape à une commande. Cette pipeline est simple à maintenir, et son prix est un petit blanc où l'ancien conteneur s'est arrêté et le nouveau pas encore.
La pipeline Kubernetes se termine autrement, et c'est là qu'elles divergent. Build et push sont identiques, puis la plateforme met à jour un manifeste et fait tourner les pods graduellement, en surveillant les readiness probes. Si la nouvelle version échoue à sa probe, le rollout s'arrête de lui-même. La livraison continue vers Kubernetes est plus sûre par défaut que l'équivalent Docker.
Le GitOps pousse le workflow plus loin : les manifestes vivent dans Git comme du code, et un controller réconcilie le cluster avec le dépôt. Cette intégration donne une piste d'audit et un rollback qui n'est qu'un simple revert, un vrai avantage sur un déploiement impératif.
Considérations sécurité et conformité
Les deux outils partagent une base : les conteneurs sont des processus, pas des machines virtuelles, partageant un kernel.
Avec Docker, la sécurité reste de l'hygiène de machine : n'exposez pas le socket du démon, droppez des capabilities, tournez en non-root, scannez les images avant de livrer. La surface d'attaque reste assez petite pour raisonner dessus.
Kubernetes ajoute surface et contrôles à parts égales. Le RBAC Kubernetes gouverne qui fait quoi. Les Network Policies restreignent le trafic pod à pod, ouverts par défaut jusqu'à configuration. Les Pod Security Standards Kubernetes remplacent l'ancienne admission par politiques. Les Secrets Kubernetes sont encodés en base64, pas chiffrés, sauf si vous activez le chiffrement au repos.
L'angle conformité coupe des deux côtés. L'orchestration donne une policy cohérente et auditable à travers chaque workload, appliquée uniformément. Elle donne aussi aux auditeurs beaucoup plus de composants à questionner, un coût réel pour une petite équipe.
Performance, consommation et coût
C'est ici que la comparaison devient concrète, et où la plupart des pages fournisseurs se taisent.
La performance du runtime de conteneurs est pratiquement identique. Les deux utilisent les mêmes primitives kernel, et depuis v1.24 Kubernetes parle à containerd directement, pas à travers Docker.
La différence est ce que chaque plateforme consomme elle-même. Une machine Docker fait tourner un seul démon en quelques centaines de Mo. Un control plane Kubernetes demande 2 CPU et 2 Go de RAM minimum, plus kubelet, kube-proxy et agent CNI par nœud. Sur trois machines, Kubernetes peut absorber un cinquième de votre capacité avant que vous ne déployiez quoi que ce soit.
| Configuration | Surcoût plateforme | Minimum pratique |
|---|---|---|
| Docker avec Compose | Un démon, ~300 Mo | 1 machine, 2 Go de RAM |
| k3s single node | ~600 Mo | 1 machine, 2 Go de RAM |
| Cluster complet | Control plane et agents | 3 machines, 4 Go de RAM chacune |
k3s est la voie du milieu que beaucoup d'équipes manquent : une distribution Kubernetes certifiée et légère dans un seul binaire, la même API Kubernetes sur un hardware bien moindre. Sur une machine AMD multi-cœur vous faites tenir un setup réaliste sur une seule boîte, et la gamme Rise a le compte de cœurs pour du multi-nœuds.
Choisir l'outil adapté : matrice de décision
Choisissez l'outil qui correspond à votre échelle, pas à votre ambition.
| Votre situation | Choisir |
|---|---|
| Une app, un host | Docker |
| Plusieurs services, un host | Docker Compose |
| Découvrir les conteneurs | Docker d'abord, toujours |
| Deux hosts ou plus, charge partagée | Kubernetes |
| Microservices, releases indépendantes | Kubernetes |
| Trafic erratique, scale à la demande | Kubernetes |
| Petite équipe, temps d'ops limité | Docker Compose, ou k3s |
| Isolation multi-tenant requise | Kubernetes |
FAQ
Peut-on apprendre Kubernetes en 2 jours ?
Vous pouvez apprendre le vocabulaire Kubernetes en deux jours : pods, deployments, services, ingress. Faire tourner Kubernetes en production prend des mois, car les parties dures sont le réseau, le stockage et les modes de panne, pas l'API. Commencez par un install de Kubernetes single-node k3s.
La NASA utilise-t-elle Docker ?
L'information publique sur des systèmes précis est limitée : accordez-vous peu à toute affirmation catégorique. Ce qui se vérifie, c'est que les images conteneurs OCI sont une norme transversale recherche, aérospatiale et finance. La question utile : les conteneurs sont-ils prêts pour la production ? C'est démontré.
Kubernetes devient-il obsolète ?
Non. Kubernetes est en v1.37 sur un rythme de releases trimestriel, et reste la plateforme par défaut pour les workloads conteneurs multi-machines. Ce qui change : les équipes disent désormais que c'est du surdimensionnement pour leur échelle, signe de maturité, pas de déclin.
Kubernetes remplace-t-il Docker ?
Non, même si la confusion se comprend. Kubernetes a retiré dockershim en v1.24 : le moteur Docker n'est plus le runtime à l'intérieur du cluster. Vos images Docker restent inchangées : artefacts OCI portables, exécutés nativement par containerd.
Quelle plateforme est meilleure pour les petites équipes ?
Docker Compose, dans la plupart des cas, plutôt que Kubernetes. Un fichier, une machine, aucun control plane Kubernetes à maintenir. Passez à k3s quand vous voulez l'auto-réparation, et à un cluster complet quand une machine ne suffit plus à contenir la charge.
En quoi Docker et Kubernetes diffèrent-ils en consommation de ressources ?
Au niveau du runtime de conteneurs, à peine du tout. Au niveau de la plateforme, largement : le démon Docker coûte quelques centaines de Mo, un control plane Kubernetes plus ses agents par nœud consomment des gigaoctets avant que votre application ne démarre.
Docker et Kubernetes peuvent-ils s'utiliser ensemble efficacement ?
Oui, et c'est l'arrangement normal. Construisez avec Docker en local, poussez l'image, laissez Kubernetes faire tourner le résultat. Docker et Kubernetes siègent à des étapes différentes d'un seul workflow supporté.
Conclusion
Choisissez Docker jusqu'à pouvoir nommer le problème que Kubernetes résout pour vous. La plupart des équipes qui font tourner une application sur une machine sont mieux servies par un fichier Compose qu'elles comprennent parfaitement que par un cluster qu'elles comprennent à moitié. Quand la deuxième machine arrive, ou que le déploiement doit devenir routine et zero downtime, l'orchestration rembourse son coût.
Prêt à construire votre plateforme de conteneurs ? Les serveurs dédiés Kimsufi démarrent à 11,10 $/mois, avec accès root et le support des workloads virtualisation et conteneurs.