Kubernetes vs Docker : Compose, Swarm ou cluster, que choisir en 2026 ?

L'essentiel en une minute

Kubernetes vs Docker est une comparaison trompeuse : Docker construit des images et lance des conteneurs, Kubernetes décide sur quelles machines ils tournent, les remplace quand ils tombent et les met à jour par étapes. La vraie question est ailleurs : Docker Compose sur un serveur suffit-il, ou faut-il un orchestrateur comme Docker Swarm, k3s ou un cluster Kubernetes géré ?

Cet article tranche avec un exemple concret : l'API de tâches de notre tutoriel Docker pour débutants, écrite une fois en compose.yaml et une fois en manifestes Kubernetes. Il s'appuie sur les documentations de Kubernetes, de Docker, de Kompose et de k3s, et sur les pages de tarifs d'AWS, de Google Cloud et d'Azure, consultées le 1er novembre 2026. Les fichiers YAML sont validés syntaxiquement, mais nous ne les avons pas exécutés sur un cluster.

Points clés

• Docker et Kubernetes ne font pas le même travail. Depuis la version 1.24, Kubernetes ne prend plus en charge Docker Engine nativement comme moteur, mais les images construites avec docker build fonctionnent toujours.
• Au 1er novembre 2026, la version courante est Kubernetes 1.37, maintenue jusqu'au 28 octobre 2027. La 1.38 est prévue le 16 décembre 2026.
• Docker Compose reste l'outil officiel pour un seul serveur. Docker Swarm et Kubernetes servent à répartir les conteneurs sur plusieurs machines.
• Kompose 1.38.0 convertit un compose.yaml en manifestes, mais ignore depends_on et place les variables d'environnement en clair : le résultat est un point de départ.
• Un plan de contrôle géré coûte 0,10 $ par heure chez AWS, soit environ 73 $ par mois selon notre calcul. Google Cloud applique le même tarif, mais un crédit mensuel couvre un cluster zonal ou Autopilot par compte de facturation. Azure propose un niveau gratuit, sans SLA.

Pourquoi « Kubernetes vs Docker » est une fausse opposition

Les deux outils travaillent à des étages différents. Docker fabrique une image à partir d'un Dockerfile, la publie dans un registre et lance des conteneurs sur une machine. Kubernetes, selon sa documentation, est une plateforme qui gère des charges de travail conteneurisées sur un cluster : il redémarre les conteneurs défaillants, tue ceux qui ne répondent pas au test de santé et ne leur envoie pas de trafic tant qu'ils ne sont pas prêts (présentation de Kubernetes, consultée le 1er novembre 2026).

La même page précise ce que Kubernetes ne fait pas : il ne compile pas votre code et ne construit pas vos images. Dans une chaîne réelle, Docker construit l'image, un registre la stocke et Kubernetes la déploie. C'est ce que fait notre tutoriel GitHub Actions, qui publie l'image de l'API sur ghcr.io à chaque modification.

L'idée que « Kubernetes a abandonné Docker » vient d'un changement réel mais étroit. Pendant des années, Kubernetes s'est appuyé sur Docker Engine par l'intermédiaire d'un adaptateur intégré appelé dockershim. Ce composant a été retiré dans la version 1.24, car Docker Engine n'implémente pas l'interface CRI que Kubernetes utilise pour parler aux moteurs de conteneurs (FAQ sur le retrait de dockershim, blog de Kubernetes, 17 février 2022).

La même FAQ répond aux deux inquiétudes habituelles :

• Vos images. Celles produites par docker build fonctionnent avec toutes les implémentations de CRI, comme containerd ou CRI-O.
• Votre poste. Si vous utilisez Docker pour développer et tester, rien ne change. Pour garder Docker Engine sur les nœuds d'un cluster, Mirantis et Docker se sont engagés à maintenir un adaptateur séparé, cri-dockerd, selon la FAQ et le dépôt de cri-dockerd.

Compose, Swarm, k3s, Kubernetes géré : le tableau comparatif

Le choix réel se fait entre quatre façons de faire tourner des conteneurs Docker en production. Le tableau résume ce que disent leurs documentations officielles, lues le 1er novembre 2026.

Sources : Compose en production, mode Swarm, spécification deploy de Compose, documentation de k3s, mise à l'échelle horizontale, versions relevées sur les pages de publication de Docker Compose, de Docker Engine et sur le canal de mise à jour de k3s.

Quelques nuances que les tableaux concurrents oublient :

• Compose est fait pour une machine. La documentation de Docker indique que Compose prend en charge la production sur un seul hôte, et que la façon la plus simple de déployer reste un seul serveur. Lancé sur un nœud Swarm, Compose prévient qu'il place tous les conteneurs sur la machine courante (déploiement d'une pile sur Swarm).
• Swarm demande un registre. Le même tutoriel montre que docker stack deploy ignore la clé build : l'image doit être poussée dans un registre accessible à tous les nœuds. La page du mode Swarm conseille d'ailleurs Compose si vous ne comptez pas déployer avec Swarm.
• k3s est un vrai Kubernetes. Sa documentation le décrit comme une distribution entièrement conforme, livrée en un binaire de moins de 100 Mo, avec containerd, CoreDNS, Traefik et un fournisseur de volumes locaux. Elle demande au minimum 2 cœurs et 2 Go de mémoire pour un serveur (prérequis de k3s).
• Metrics Server n'est pas partout. Le HorizontalPodAutoscaler lit le processeur et la mémoire des Pods via l'API de métriques, fournie en général par le module Metrics Server, qui doit être lancé séparément (mise à l'échelle horizontale). k3s le déploie d'office parmi ses composants intégrés (composants de k3s). Amazon EKS ne le déploie pas par défaut (documentation d'EKS). La documentation d'AKS indique seulement que les offres cloud peuvent le préinstaller (HPA sur AKS). Vérifiez avec kubectl get deployment metrics-server -n kube-system.

Côté usage, l'écart reste net. Dans l'enquête Stack Overflow 2026, 59,1 % des 10 889 répondants à la rubrique « Cloud development » ont travaillé avec Docker ou Docker Compose dans l'année, contre 26,0 % pour Kubernetes et 13,0 % pour Podman, soit 6 440, 2 836 et 1 415 répondants (Stack Overflow Developer Survey 2026, consulté le 1er novembre 2026).

Kubernetes vs Docker Compose : quand passer le cap

Docker Compose sur un serveur suffit tant qu'une panne de cette machine est acceptable et que la charge tient sur elle. Un orchestrateur devient utile dès que l'une de ces deux conditions tombe. Nous ne donnons pas de seuil en utilisateurs ou en requêtes par seconde : aucune des sources officielles consultées n'en fixe, et les chiffres qui circulent ne sont pas sourcés.

Restez sur Compose si :

• Une seule machine porte l'application. Une API, sa base et un Nginx reverse proxy devant tiennent dans un fichier, avec restart: unless-stopped pour relancer un conteneur arrêté.
• Une courte coupure au déploiement est tolérable. docker compose up -d recrée le service : c'est simple, mais ce n'est pas une mise à jour progressive.
• Personne n'est disponible pour exploiter un cluster. Compose se maintient avec les commandes Linux de base, Docker et un peu de supervision.

Les signaux généraux en faveur d'un orchestrateur (plusieurs nœuds, mises à jour sans coupure, charge variable, équipes multiples) sont détaillés dans la section quand Kubernetes vaut le coup de notre guide pour débutants. Le choix se joue ensuite entre trois options :

• Docker Swarm si vous voulez garder compose.yaml et la ligne de commande Docker. Swarm répartit les services sur plusieurs machines et sait revenir en arrière après une mise à jour, mais il exige un registre et nous n'avons trouvé aucune mise à l'échelle automatique dans sa documentation.
• k3s si vous avez vos propres serveurs ou quelques machines virtuelles. Vous obtenez l'API Kubernetes complète, avec Traefik, des volumes locaux et Metrics Server déjà installés, mais le plan de contrôle et ses mises à jour sont à votre charge.
• Un Kubernetes géré si la disponibilité prime et que le budget suit. Le fournisseur exploite le plan de contrôle. Par défaut, un Deployment garde au moins 75 % des Pods voulus disponibles et n'en crée pas plus de 125 % pendant une mise à jour (documentation des Deployments).

Un piège revient souvent : Kubernetes ne rend pas une application capable de monter en charge. Notre API stocke ses données dans un fichier SQLite. Deux copies qui écrivent dans le même fichier posent problème, quel que soit l'orchestrateur : il faut d'abord passer à PostgreSQL, comme le recommande notre tutoriel pour créer une API REST avec Node.js.

Verdict : dans le duel Kubernetes vs Docker Compose, le premier critère est le nombre de machines nécessaires ; le partage de l'infrastructure entre plusieurs équipes vient ensuite. Dans tous les cas, Docker reste l'outil pour construire les images et développer en local.

La même API en compose.yaml puis en manifestes Kubernetes

L'API de nos tutoriels écoute le port 3000, refuse de démarrer sans un JWT_SECRET d'au moins 32 octets, écrit sa base SQLite dans /app/data et répond {"statut":"ok"} sur /health. L'image est celle que publie le workflow GitHub Actions, ghcr.io/<compte>/api-taches.

Le compose.yaml

Ce fichier reprend les choix de nos guides Docker et Nginx : port publié sur l'adresse locale seulement, secret lu dans le .env, test de santé sur /health.

services: api: build: . image: ghcr.io/votre-compte/api-taches:main ports: - "127.0.0.1:3000:3000" environment: JWT_SECRET: ${JWT_SECRET:?definir JWT_SECRET dans .env} DB_PATH: /app/data/data.db volumes: - api-data:/app/data init: true healthcheck: test: ["CMD", "node", "-e", "fetch('http://127.0.0.1:3000/health').then(r => process.exit(r.ok ? 0 : 1)).catch(() => process.exit(1))"] interval: 30s timeout: 5s retries: 3 start_period: 10s restart: unless-stopped volumes: api-data: 

Vingt et une lignes, une commande (docker compose up -d --build), et aucun composant à installer en dehors de Docker.

Les manifestes Kubernetes

Côté Kubernetes, le secret vit dans un objet séparé. La documentation prévient que les Secrets sont stockés sans chiffrement par défaut dans etcd, la base du cluster, et que toute personne ayant accès à l'API peut les lire (documentation des Secrets). Générez d'abord une valeur de 32 octets, comme dans notre guide Nginx, puis créez le Secret en ligne de commande plutôt que de l'écrire dans un fichier versionné :

export JWT_SECRET=$(docker run --rm node:24-alpine node -e "console.log(require('node:crypto').randomBytes(32).toString('hex'))") kubectl create secret generic api-taches --from-literal=JWT_SECRET="$JWT_SECRET" 

Le fichier équivalent, à ne jamais placer dans Git avec une vraie valeur. Le texte de remplacement fait moins de 32 octets : tant qu'il n'est pas changé, l'API refuse de démarrer, ce qui est voulu.

apiVersion: v1 kind: Secret metadata: name: api-taches type: Opaque stringData: JWT_SECRET: "A-REMPLACER" 

Puis le fichier api-taches.yaml, avec le volume, le Deployment et le Service :

apiVersion: v1 kind: PersistentVolumeClaim metadata: name: api-data spec: accessModes: - ReadWriteOnce resources: requests: storage: 1Gi --- apiVersion: apps/v1 kind: Deployment metadata: name: api-taches labels: app: api-taches spec: replicas: 1 strategy: type: Recreate selector: matchLabels: app: api-taches template: metadata: labels: app: api-taches spec: shareProcessNamespace: true securityContext: fsGroup: 1000 fsGroupChangePolicy: OnRootMismatch containers: - name: api image: ghcr.io/votre-compte/api-taches:sha-1a2b3c4 ports: - containerPort: 3000 env: - name: JWT_SECRET valueFrom: secretKeyRef: name: api-taches key: JWT_SECRET - name: DB_PATH value: /app/data/data.db volumeMounts: - name: data mountPath: /app/data readinessProbe: httpGet: path: /health port: 3000 periodSeconds: 10 livenessProbe: httpGet: path: /health port: 3000 initialDelaySeconds: 10 periodSeconds: 30 volumes: - name: data persistentVolumeClaim: claimName: api-data --- apiVersion: v1 kind: Service metadata: name: api-taches spec: selector: app: api-taches ports: - port: 80 targetPort: 3000 

Appliquez-le avec kubectl apply -f api-taches.yaml, puis suivez le déploiement avec kubectl rollout status deployment/api-taches. La taille de 1 Gi est un exemple : ajustez-la. Le tag sha-1a2b3c4 remplace le commit abrégé que produit notre workflow GitHub Actions : avec un tag autre que latest, Kubernetes règle par défaut imagePullPolicy sur IfNotPresent, et un nœud qui a déjà une image main en cache ne téléchargerait pas la nouvelle (documentation des images). Un tag par commit rend chaque déploiement explicite. Si le paquet GHCR est privé, le Pod aura besoin d'un imagePullSecrets. Pour les bases de ces objets, notre guide Kubernetes pour débutants les présente un par un.

Ce qui change entre les deux

Quatre choix de ces manifestes découlent de SQLite et de la documentation :

• replicas: 1 et strategy: Recreate. Un volume en ReadWriteOnce ne peut être monté en écriture que par un seul nœud (volumes persistants). La stratégie Recreate arrête l'ancien Pod avant de lancer le nouveau : il y a donc une courte coupure, comme avec Compose. Pour une vraie mise à jour progressive, passez à PostgreSQL et à la stratégie par défaut.
• fsGroup: 1000. L'image de notre guide Docker tourne sous l'utilisateur node, d'identifiant 1000. Pour les types de volumes qui le permettent, fsGroup attribue ce groupe aux fichiers du volume pour que SQLite puisse écrire ; fsGroupChangePolicy: OnRootMismatch évite de refaire ce changement à chaque démarrage si la racine du volume est déjà correcte (contexte de sécurité).
• shareProcessNamespace: true, une alternative à init: true. Nous n'avons trouvé dans les pages consultées aucun champ de Pod qui lance un processus d'init comme le fait Compose ; avec ce réglage, les conteneurs d'un même Pod voient aussi les processus et les fichiers des autres, ce qui compte si vous ajoutez un second conteneur. Or Node.js n'est pas conçu pour tourner avec le PID 1 et ne répond alors pas à des signaux comme SIGINT (bonnes pratiques de l'image Node.js). Sans correctif, chaque arrêt du Pod attendrait la fin du délai de grâce, 30 secondes par défaut (cycle de vie des Pods). Avec un espace de processus partagé, le processus du conteneur n'a plus le PID 1 (partage de l'espace de processus). L'autre solution, que recommandent aussi les bonnes pratiques de l'image Node.js, consiste à ajouter Tini au Dockerfile : RUN apk add --no-cache tini et ENTRYPOINT ["/sbin/tini", "--"], selon le README de Tini.
• Deux sondes au lieu d'un test de santé. La sonde de disponibilité (readiness) décide si le Pod reçoit du trafic, la sonde de vie (liveness) le redémarre s'il échoue. Une sonde de vie trop sévère peut provoquer des redémarrages en cascade sous forte charge, prévient la documentation des sondes.

Comptées de la même façon, sans les lignes vides, le fichier Compose fait 21 lignes et les manifestes Kubernetes 82 avec le Secret, soit plus du triple. Dans ce match Kubernetes vs Docker Compose, ce surcoût en YAML n'est rentable que si vous avez besoin de ce qu'il apporte.

Migrer avec Kompose : ce qu'il convertit, ce qu'il laisse

Kompose, un projet officiel du groupe Kubernetes, sert à passer d'un fichier Compose à des manifestes. Son README le dit lui-même : la transformation « peut ne pas être exacte », mais elle aide beaucoup pour un premier déploiement (notre traduction, dépôt de Kompose, consulté le 1er novembre 2026).

La dernière version publiée est la 1.38.0, du 15 janvier 2026, selon la page des versions. Le README annonce un rythme de sortie toutes les trois semaines : aucune version n'est pourtant parue depuis plus de neuf mois. La commande de base est la suivante :

kompose convert -f compose.yaml 

Le tableau de conversion de Kompose et son guide d'utilisation détaillent ce qui passe et ce qui ne passe pas :

Trois limites comptent pour notre API. D'abord, le secret : environment devient une variable du Deployment, donc JWT_SECRET se retrouve en clair dans un fichier YAML. Remplacez-le par un Secret avant tout commit. Ensuite, l'ordre de démarrage : depends_on n'a pas d'équivalent, et chaque service doit savoir attendre ses dépendances.

Enfin, les sondes : le healthcheck de Compose devient une sonde de vie qui lance la même commande, mais aucune sonde de disponibilité n'est créée sans étiquettes propres à Kompose. Ajoutées au service api, celles-ci produisent une sonde de disponibilité HTTP sur /health :

 labels: kompose.service.healthcheck.readiness.http_get_path: /health kompose.service.healthcheck.readiness.http_get_port: "3000" 

La taille par défaut de 100 Mi et le passage du healthcheck en sonde de vie se lisent dans le code source de la version 1.38.0, l'étiquette kompose.volume.size permettant de changer la taille.

Verdict : utilisez Kompose pour obtenir un brouillon, puis relisez chaque fichier. Les points ci-dessus sont ceux que nos manifestes écrits à la main traitent différemment.

Coûts et charge d'exploitation

Le logiciel est gratuit, son exploitation ne l'est pas : il faut payer le plan de contrôle géré et suivre les versions.

Le rythme des versions

Le projet maintient les trois dernières versions mineures, soit 1.37, 1.36 et 1.35, avec environ un an de correctifs pour chacune, suivi de deux mois en mode maintenance (page des versions et politique des correctifs, consultées le 1er novembre 2026). La 1.37, nom de code Garhwal, est sortie le 26 août 2026 avec 67 améliorations (annonce de la 1.37).

La 1.38 est prévue le 16 décembre 2026, selon le calendrier de la version 1.38. Un cluster installé aujourd'hui devra donc être mis à jour au moins une fois par an, en passant d'une version mineure à la suivante. Dernier correctif relevé : 1.37.2, publié le 28 octobre 2026 sur GitHub.

Le prix d'un plan de contrôle géré

Les trois grands clouds facturent différemment le plan de contrôle, hors machines, stockage et réseau. Tarifs relevés le 1er novembre 2026 :

Sources : tarifs d'Amazon EKS, tarifs de GKE et tarifs d'AKS. Google précise que son crédit gratuit équivaut à un cluster zonal ou Autopilot par mois.

Notre calcul. 0,10 $ sur 730 heures donne environ 73 $ par mois pour le seul plan de contrôle chez AWS. Une version laissée en support étendu chez EKS passe à 0,60 $, soit environ 438 $ par mois. Ne pas mettre à jour son cluster a donc un prix direct.

Ce surcoût place Kubernetes géré au-dessus des offres plus simples présentées dans notre guide de l'hébergement cloud pour développeurs. Pour comparer les trois fournisseurs au-delà de Kubernetes, notre duel AWS vs Azure vs Google Cloud détaille les autres services.

Ce que nous n'avons pas pu vérifier

Cet article est une synthèse documentaire. Les points suivants restent ouverts :

• L'exécution des fichiers. Le compose.yaml et les manifestes ont été validés comme YAML, pas exécutés sur Docker ni sur un cluster. La conversion par Kompose n'a pas été lancée.
• Le prix des niveaux Standard et Premium d'AKS. La page de tarifs d'Azure n'affichait pas de montant lisible au moment de notre lecture.
• L'avenir de Docker Swarm. La documentation de Docker le présente comme intégré à Docker Engine, mais nous n'avons trouvé aucune feuille de route officielle.
• Metrics Server sur GKE et AKS. Nous n'avons trouvé aucune page officielle qui dise clairement s'il est installé d'office ; la documentation d'AKS dit seulement que les offres cloud « peuvent » le préinstaller (notre traduction).
• L'arrêt de l'API avec shareProcessNamespace. La documentation dit que le processus perd le PID 1 ; que Node.js s'arrête alors proprement sur SIGTERM est notre déduction, non testée. Tini dans l'image reste l'option la plus documentée.

Questions fréquentes

Kubernetes remplace-t-il Docker ?

Non, et c'est le cœur du débat Kubernetes vs Docker. Kubernetes a retiré dockershim dans la version 1.24 et ne prend plus en charge Docker Engine nativement sur ses nœuds, mais les images construites avec docker build fonctionnent avec tous les moteurs compatibles CRI, selon la FAQ officielle. Docker reste l'outil de construction et de développement local.

Docker Compose peut-il servir en production ?

Oui, sur une seule machine. La documentation de Docker cite les déploiements sur un seul hôte parmi les usages de Compose. Au-delà d'une machine, il faut Docker Swarm ou Kubernetes.

Comment passer de Docker Compose à Kubernetes ?

Kompose convertit un compose.yaml avec kompose convert -f compose.yaml. Relisez ensuite chaque fichier : les variables d'environnement y sont en clair, depends_on est ignoré et chaque volume devient une demande de stockage, selon le tableau de conversion.

Quelle est la version actuelle de Kubernetes ?

Au 1er novembre 2026, c'est la 1.37, sortie le 26 août 2026 et maintenue jusqu'au 28 octobre 2027, selon la page des versions. Les versions 1.36 et 1.35 sont aussi maintenues, et la 1.38 est prévue le 16 décembre 2026.

À propos de l'auteur

Abdelilah Ourti est ingénieur IA et architecte logiciel. Il conçoit et déploie des applications web et des systèmes d'IA, et publie sur NeurauTech des guides et des comparatifs destinés aux développeurs francophones. Ses autres articles sont réunis sur sa page auteur.

Méthode. Synthèse documentaire fondée exclusivement sur des sources publiques consultées le 1er novembre 2026 : documentation, blog et pages de versions de Kubernetes, documentation de Docker, de Kompose et de k3s, pages de publication sur GitHub, pages de tarifs d'AWS, de Google Cloud et d'Azure, enquête Stack Overflow 2026. Les fichiers YAML ont été validés syntaxiquement mais n'ont été exécutés ni sur Docker ni sur un cluster. Les citations issues de sources en anglais sont traduites par nos soins. Aucun lien n'est affilié et aucune relation commerciale ne lie l'auteur aux éditeurs mentionnés.

Une erreur ou un tarif périmé ? Écrivez à contact@neurautech.com : l'article sera corrigé et la date de mise à jour modifiée.

Dernière mise à jour : 1er novembre 2026.

Image d'en-tête : Tom Fisk (Pexels License). Graphiques : NeurauTech, d'après Stack Overflow et kubernetes.io.