Docker Swarm vs Kubernetes : quelles différences et quand faut-il migrer ?
Vous voici en train de comparer Docker Swarm à Kubernetes.
Soit votre cluster Docker Swarm commence à vous freiner en production. Soit votre produit entre dans une phase où vous n’allez pas pouvoir vous passer de l’orchestration.
Docker Swarm et Kubernetes répondent à des besoins différents, même, à des moments différents de la vie d’un produit. L’un privilégie la simplicité et la rapidité. L’autre apporte un cadre plus structurant pour absorber la complexité, la variabilité de la charge et les exigences d’exploitation dans la durée.
Dans cet article, nous comparons Docker Swarm et Kubernetes à l’épreuve de la production – scaling, exploitation quotidienne, gouvernance et coûts – et surtout à quel moment il faut migrer. Retour d’expérience de Semji à l’appui, un SaaS IA en forte croissance qui a franchi le pas lorsque son infrastructure est devenue un facteur limitant. Place à la magie.
Resumulus : les 3 points à retenir de l’article
- Docker Swarm et Kubernetes n’interviennent pas au même moment de vie d’un produit : Swarm est adapté pour démarrer vite, Kubernetes quand la complexité augmente.
- En production, les écarts se creusent sur quatre sujets clés : l’automatisation du scaling, la dette d’exploitation, la gouvernance et les coûts.
- L’enjeu est de peser les pour et les contres en fonction de votre produit, de vos usages et du temps réellement consacré à l’exploitation.
Docker Swarm et Kubernetes répondent au même problème de fond : faire tourner des conteneurs en production, sur plusieurs machines, sans que tout s’écroule à la première panne ou au premier pic de charge.
Dès qu’une application sort du cadre “une VM, un service”, gérer les déploiements à la main n’est pas tenable. Il faut répartir la charge, relancer ce qui tombe, déployer sans interruption, absorber les variations d’activité. C’est le rôle d’un orchestrateur.
L’orchestration de conteneurs : un standard d’infrastructure depuis 10 ans
Au début des années 2010, Docker popularise les conteneurs.
Le principe est simple : embarquer une application avec toutes ses dépendances pour la faire tourner de manière identique partout, plus vite et avec moins de gaspillage qu’une machine virtuelle classique.
Très vite, les conteneurs passent du statut d’outil “pratique” à celui destandard en production. Les applications s’appuient alors sur plusieurs composants : services, workers, traitements ponctuels, tâches planifiées, parfois répartis sur plusieurs machines. Aujourd’hui, selon la CNCF Annual Survey 2024, 91 % des organisations utilisent des conteneurs en production.
C’est pour automatiser des questions très concrètes qu’ont été inventés les orchestrateurs : sur quelles machines les conteneurs doivent tourner, combien d’instances lancer, que faire en cas de panne, comment mettre à jour sans interruption et comment gérer les variations de charge.
Docker, Docker Swarm et Kubernetes : qui fait quoi ?
Facile de confondre quand les noms se ressemblent et que les usages s’entrecroisent.
Clarifions :
- Docker est un outil de conteneurisation : il sert à construire des images et à exécuter des conteneurs sur une machine.
- Docker Swarm est un orchestrateur intégré à Docker : il permet de regrouper plusieurs machines en cluster et d’y déployer des services distribués.
- Kubernetes est un orchestrateur indépendant de Docker : il ne construit pas les images, mais s’appuie sur un moteur de conteneurs pour les exécuter, et se concentre sur leur organisation et leur supervision à grande échelle.
Attention donc à la confusion : Docker et Kubernetes ne s’opposent pas.
Il est courant d’utiliser Docker pour créer les images, puis Kubernetes pour les déployer et les opérer en production.
La vraie comparaison, ici, c’est bien Docker Swarm vs Kubernetes.
Docker Swarm : l’orchestrateur idéal pour les environnements simples
Docker Swarm a été conçu pour une chose : permettre à des équipes déjà à l’aise avec Docker de passer rapidement à l’orchestration, sans introduire un nouvel outil ni une couche de concepts complexes.
On regroupe plusieurs machines Docker en un cluster. On définit des services et un nombre d’instances attendues.
Swarm se charge du reste : placement des conteneurs, redémarrage en cas de panne, répartition du trafic.
Sur le plan fonctionnel, Docker Swarm permet de franchir un premier cap :
- une application peut tourner sur plusieurs machines
- certaines pannes sont absorbées automatiquement
- les déploiements sont déclaratifs : on définit des services et un nombre d’instances attendues et le cluster se charge de maintenir cet état dans le temps
C’est cette promesse d’orchestration simple, rapide, intégrée qui séduit dans des contextes maîtrisés : peu de services, une charge stable, et la volonté d’aller vite sans alourdir la stack.
Environ 20 % des organisations utilisent Docker Swarm pour l’orchestration de leurs conteneurs.
Source : Ambient IT, 2024
Kubernetes : au-delà de l’orchestrateur, une plateforme complète
Issu des systèmes internes de Google, notamment de leur orchestrateur maison Borg, puis confié à la Cloud Native Foundation, Kubernetes a été conçu pour orchestrer des systèmes distribués à grande échelle.
Kubernetes ne se contente pas de “lancer des conteneurs.” Il fournit une couche de pilotage entre l’application et l’infrastructure.
Tout est décrit explicitement :
- les ressources allouées
- les règles de redémarrage
- les stratégies de déploiement
- les dépendances entre composants
La plateforme peut s’exécuter sur des serveurs bare metal, des machines virtuelles, dans des Clouds publics, privés ou hybrides. Elle devient ainsi un socle commun, indépendant de l’infrastructure sous-jacente.
Mais ce qui fait réellement la différence, c’est son écosystème.
Observabilité, sécurité, déploiement automatisé, autoscaling, gouvernance : Kubernetes s’entoure de briques standardisées qui font de l’orchestrateur une véritable plateforme d’exploitation.
Plus de 60 % des entreprises utilisent Kubernetes. Un chiffre qui devrait dépasser les 90 % d’ici 2027 selon VMware.
Source : VMware, 2024.
Sur le papier, Docker Swarm et Kubernetes remplissent le même rôle. Plongeons dans les détails pour comprendre ce qui les différencie.
Scaling : Docker Swarm ou Kubernetes pour gérer les pics de trafic ?
Docker Swarm : le scaling par anticipation
Avec Docker Swarm, le scaling repose sur une logique simple : prévoir avant d’agir.
Vous définissez à l’avance un nombre de replicas pour chaque service et vous dimensionnez les machines avec une marge de sécurité pour absorber les pics. Tant que l’activité est prévisible, ce modèle fonctionne.
Le problème, c’est plutôt quand la charge ne prévient pas.
Docker Swarm sait répartir les conteneurs et redémarrer ce qui tombe, mais il ne décide pas quand scaler. Il n’existe pas de mécanisme natif capable de dire : “la file d’attente se remplit, il faut plus de capacité maintenant”.
Alors, la parade est toute trouvée : surprovisionner.
Garder des machines allumées « au cas où ».
Efficace, mais coûteux (voir le paragraphe sur les coûts).
Kubernetes : la magie de l’autoscaling
Dans l’écosystème Kubernetes, le scaling est plutôt de l’autoscaling.
Le système a la capacité d’ajuster dynamiquement les ressources en fonction de la charge réelle : CPU, mémoire, files d’attente, événements applicatifs.
Lorsque l’activité augmente, le cluster augmente ses capacités.
Lorsqu’elle retombe, la nuit, le week-end, après un pic ponctuel, les ressources sont libérées.
Automatiquement, bien évidemment.
Le scaling en situations : Docker Swarm vs Kubernetes
| Situation | Cluster Docker Swarm | Ecosystème Kubernetes |
|---|---|---|
| Un pic de trafic arrive sans prévenir | L’équipe doit intervenir ou avoir surprovisionné en amont | Le cluster détecte la charge et alloue automatiquement les ressources |
| La charge augmente progressivement | Le nombre d’instances reste celui défini à l’avance | Le nombre de pods s’ajuste automatiquement via des outils d’autoscaling |
| Les files d’attente se remplissent | La surveillance est humaine, les ajustements sont manuels | Le scaling est déclenché par métriques ou événements (ex. KEDA) |
| Les machines atteignent leurs limites | Un nouveau nœud est ajouté manuellement au cluster | De nouvelles machines sont provisionnées automatiquement (grâce à Karpenter ou Cluster autoscaler) |
| La charge retombe | Les ressources restent allouées | Les ressources sont automatiquement libérées |
| Un service spécifique a besoin de scaler | Le scaling s’applique de manière globale | Le scaling est ciblé par service ou par type de workload |
Usage quotidien : Docker Swarm ou Kubernetes pour limiter la dette d’exploitation ?
L’exploitation quotidienne avec Docker Swarm
Docker Swarm permet de démarrer vite.
Mais au quotidien, son exploitation repose souvent sur une mécanique fragile : scripts maison, procédures implicites, interventions manuelles répétées.
Le fonctionnement réel du cluster est rarement entièrement formalisé.
Comprendre pourquoi un service se comporte d’une certaine manière, comment un déploiement est censé se passer, où intervenir en cas d’incident dépend largement de l’expérience de quelques personnes clés.
Cette dette d’exploitation se manifeste par :
- des opérations répétitives
- des déploiements plus prudents, mais aussi plus lents
- une difficulté à onboarder de nouveaux profils
- une fatigue progressive des équipes.
L’exploitation quotidienne avec Kubernetes
Kubernetes est bien plus exigeant dans sa configuration.
Il se prête naturellement à une approche Infrastructure as Code : le fonctionnement du cluster, les déploiements, les ressources et les règles sont décrits en code, versionnés et reproductibles.
Cette approche ouvre souvent la voie au GitOps. En pratique, le dépôt Git devient le point de pilotage de la production : les changements passent par des commits, sont historisés, puis appliqués automatiquement au cluster, sans intervention manuelle directe.
Une pratique de plus en plus répandue dans les équipes qui cherchent à industrialiser leurs déploiements et à poser les bases d’une IDP, Internal Developer Platform.
Au-delà de ce socle, Kubernetes s’appuie sur un écosystème moderne et standardisé qui permet d’intégrer des outils dédiés à l’automatisation des déploiements (ArgoCD, Helm), à la gestion du cycle de vie applicatif (GitOps) et à l’observabilité (Grafana, Prometheus). Progressivement, vous pouvez construire une Internal Developer Platform, où les équipes déploient, testent et font évoluer leurs services sans dépendre des Ops.
L’usage quotidien en situations : Docker Swarm vs Kubernetes
| Situation | Cluster Docker Swarm | Ecosystème Kubernetes |
|---|---|---|
| Déployer une nouvelle version | Il faut lancer le déploiement manuellement ou via un script custom, puis vérifier que tout s’est bien passé | Le déploiement est automatisé et l’état attendu est appliqué en continu par le système grâce au GitOps. |
| Corriger un bug en production | Il faut intervenir directement sur le cluster, parfois en urgence | Il suffit de déclarer le changement, avec possibilité de rollback versionné |
| Redémarrer un service instable | Il faut redémarrer le service manuellement, parfois à répétition | Le service est redémarré automatiquement selon des règles définies |
| Comprendre pourquoi un service a crashé | Il faut analyser les logs et corréler les signaux disponibles, avec une visibilité qui dépend des outils externes mis en place | Il faut analyser et corréler logs, métriques et événements, avec un écosystème riche d’outils dédiés à l’observabilité |
| Ajouter une nouvelle feature infra | Il faut modifier la configuration existante avec un risque d’effet de bord | Le développeur peut lire le code d’infrastructure et les manifests pour comprendre. Il/elle est maître du déploiement de son application. |
| Onboarder un nouveau développeur | Il faut transmettre oralement les pratiques et compléter avec de la documentation | Lecture du code infra et des manifests |
| Faire évoluer l’architecture | Les changements sont faits avec prudence et souvent repoussés | Les évolutions sont progressives, maîtrisées et intégrées au cycle normal |
| Gérer un incident hors horaires | Une intervention humaine est bien souvent nécessaire | Le système réagit automatiquement dans de nombreux cas |
| Auditer ce qui a changé | Il faut reconstituer l’historique a posteriori | L’historique des changements est directement lisible dans le code (merci Git 🙏) |
Gouvernance : Docker Swarm ou Kubernetes pour passer les audits ?
La gouvernance avec Docker Swarm
Techniquement, un cluster Docker Swarm peut s’écrire as code (avec Terraform, Ansible, et Compose). Mais la gouvernance repose surtout sur l’équipe et les outils ajoutés autour du cluster.
Swarm ne fournit pas :
- un état déclaré & contrôlé nativement
- une chaîne d’audit complète
- un RBAC avancé
- ni un modèle GitOps strict
Il est alors plus difficile de garantir la conformité, la traçabilité et le contrôle des changements de façon systématique.
La gouvernance avec Kubernetes
Kubernetes apporte un modèle déclaratif, versionné et piloté via GitOps.
Chaque changement est codé, validé, historisé.
Le cluster applique uniquement ce qui est défini dans Git.
Tout est auditable :
- Configurations versionnées
- un état déclaré & contrôlé nativement
- Règles de sécurité
- un RBAC avancé
- Historique des modifications
- Contrôles d’accès
- Policies obligatoires
- Logs du control-plane
Pour des certifications comme la SOC 2 ou ISO 27001, c’est un vrai avantage : la gouvernance est intégrée dans la plateforme, pas dans les habitudes de l’équipe.
La gouvernance en situations : Docker Swarm vs Kubernetes
| Situation | Cluster Docker Swarm | Ecosystème Kubernetes |
|---|---|---|
| Définir qui a accès à quoi | Il faut définir des règles simples, souvent peu granulaires | Les rôles et permissions sont définis finement et explicitement |
| Savoir qui a modifié l’infrastructure | La traçabilité est partielle et souvent manuelle | Chaque action est tracée si vous faites du GitOps |
| Présenter des preuves de conformité | Il faut s’appuyer sur de la documentation et des explications | Les preuves sont directement visibles dans le code et l’historique Git |
| Séparer les environnements | Il n’existe pas de séparation native de type namespace. Les services sont regroupés sans réelle isolation, ni quotas, ni paramètres de configuration dédiés. | La séparation est clairement définie et contrôlée par les équipes. Il est possible de mettre en place des quotas, des règles réseau et des accès granulaires. |
| Répondre à un audit client | Le processus est long et mobilise plusieurs personnes | Le processus est structuré et rapide. Les audits sont facilités par l’écosystème. |
| Préparer une certification (SOC 2, ISO) | La préparation est complexe et peu industrialisée | La préparation est largement facilitée |
Coûts Cloud : Docker Swarm ou Kubernetes pour réduire sa facture ?
Les coûts Cloud avec Docker Swarm
Docker Swarm ne permet pas de scaler finement par application ou par type de workload. Le scaling s’applique généralement à des ensembles assez larges. Quand un service commence à tirer sur les ressources, on renforce le cluster dans son ensemble, plutôt que d’ajuster précisément le composant concerné.
Dans la pratique, cela conduit à deux effets :
- des machines partiellement utilisées pendant une grande partie du temps
- une facture cloud difficile à expliquer
On sait que ça coûte plus cher. Mais au-delà de ça, compliqué de dire quel service consomme quoi, ou ce qui justifie réellement l’ajout de nouvelles machines.
Les coûts Cloud avec Kubernetes
La capacité de Kubernetes à ajuster dynamiquement la taille du cluster réduit naturellement les coûts.
D’abord parce qu’on arrête de gaspiller : les ressources sont consommées quand elles sont utiles, pas “au cas où”.
Ensuite parce que cette élasticité peut être configurée finement.
Certains workloads nécessitent de la puissance et de la disponibilité permanente. D’autres peuvent tolérer des ressources moins chères ou intermittentes.
Cette flexibilité permet d’arbitrer en permanence entre performance, disponibilité et coût, service par service, workload par workload. Elle ouvre aussi la porte à des optimisations très concrètes du quotidien.
Les environnements de développement et de test, par exemple, n’ont pas vocation à tourner en continu. Les nuits, week-ends et jours fériés représentent près de 60 % de l’année : autant de périodes où ces environnements peuvent être mis en pause, puis relancés automatiquement quand l’activité reprend.
La facture cloud est aussi plus lisible.
On peut suivre des indicateurs concrets : coût par service, par utilisateur, par fonctionnalité.
Mais cela suppose une vraie démarche FinOps : sans lecture fine des métriques, l’élasticité seule ne suffit pas.
La gestion des coûts Cloud en situations : Docker Swarm vs Kubernetes
| Situation | Docker Swarm | Kubernetes |
|---|---|---|
| Des machines tournent à vide | Il est difficile de savoir précisément pourquoi | La consommation est directement liée à l’usage réel |
| La charge baisse (nuit, week-end) | Les ressources restent allouées | Les ressources sont automatiquement réduites |
| Un pic de trafic ponctuel survient | La facture augmente durablement | La facture augmente temporairement puis redescend |
| Évaluer le coût d’un service | La vision reste globale et peu exploitable | Le coût est identifiable par service ou workload |
| Mesurer l’impact d’un nouveau client | L’estimation reste approximative | L’impact est mesurable et traçable |
| Lancer une nouvelle feature | Le risque de surcoût est difficile à anticiper | La consommation est observable et ajustable |
| Prévoir le budget à 6–12 mois | Les projections restent larges | Les projections s’appuient sur des scénarios réels |
À ce stade, la comparaison semble clairement favorable à Kubernetes.
Mais ce serait une erreur d’en tirer une conclusion trop rapide.
À notre sens, Docker Swarm et Kubernetes ne sont pas tant deux réponses concurrentes.
Ils incarnent deux phases différentes de maturité d’un produit.
Docker Swarm est souvent un très bon choix au départ, de par sa simplicité de mise en œuvre. Kubernetes, à l’inverse, impose une discipline. Et c’est précisément ce qui le rend pertinent quand le produit change d’échelle.
C’est la trajectoire qu’a suivie Semji.
Semji est une plateforme SaaS qui aide les entreprises à gagner en visibilité sur Internet, sur Google comme sur les moteurs de recherche IA. Derrière l’interface, la réalité est exigeante : des volumes de données importants, des jobs massivement parallélisés, des files de messages qui se remplissent par vagues et une charge très variable selon les usages.
Docker Swarm a longtemps été leur socle d’infrastructure. Mais avec la croissance, le cluster demandait de plus en plus d’ajustements manuels, certaines instabilités devenaient difficiles à diagnostiquer, et l’exploitation mobilisait une part croissante de l’équipe. « Il arrivait que le cluster crashe sans qu’on ne sache vraiment pourquoi », résume Olivier Balais, CTO de Semji.
Un empilement de frictions d’infrastructure qui finissait par détourner l’énergie des équipes du produit lui-même et qui ont conduit Semji à migrer sur Kubernetes en 2023.
5 questions pour savoir s’il faut migrer de Docker Swarm à Kubernetes
1. Le scaling est-il encore gérable à la main ?
- Si vous anticipez la charge et ajustez ponctuellement → Docker Swarm
- Si la charge arrive par pics imprévisibles → Kubernetes
2. Mon infrastructure ralentit-elle le delivery produit ?
- Si les déploiements restent simples et réguliers → Docker Swarm
- Si chaque déploiement demande des vérifications, des scripts, ou mobilise toujours les mêmes personnes → Kubernetes
3. Ma facture cloud est-elle anticipable (dans une fourchette raisonnable) ?
- Si vous raisonnez surtout en capacité globale (“on a X machines”) et que la facture reste acceptable → Docker Swarm
- Si vous voulez comprendre le coût par service, par client ou par feature → Kubernetes
4. Mon cluster est-il dépendant de quelques personnes clés ?
- Si le fonctionnement est bien compris par l’équipe et reste facile à transmettre → Docker Swarm
- Si “ceux qui savent” sont toujours les mêmes et que l’onboarding devient long → Kubernetes
5. La gouvernance est-elle encore gérable ?
- Si les audits, la traçabilité ou les certifications ne sont pas encore prioritaires → Docker Swarm
- Si vous devez prouver qui fait quoi, quand et pourquoi (clients, SOC 2, ISO) → Kubernetes
Vous voulez l’avis d’un DevOps ?
Décrivez-nous votre infrastructure et nous vous répondons avec honnêteté et transparence si oui ou non, une migration est indiquée dans votre contexte.
À explorer dans le grimoire
Scaling SaaS : 5 patterns d’infrastructure qui sont des freins à la croissance
Standardiser, automatiser, éclairer : les 3 pouvoirs de Kubernetes contre la dette technique
Internal Developer Platform : faut-il être une grande boîte pour y avoir droit ?