Kubernetes vs Docker Swarm : Le guide complet pour choisir votre solution de conteneurisation

En 2023, une entreprise pharmaceutique européenne a migré 2 400 conteneurs depuis Docker Swarm vers Kubernetes. Coût de la migration : 180 000 €. Temps de migration : 14 mois. Économie annuelle après migration : 340 000 € sur les coûts d'infrastructure et de maintenance. Ce cas réel illustre une vérité que j'ai observée sur une vingtaine de projets enterprise : le choix entre Kubernetes et Docker Swarm n'est jamais anodin, et une décision hâtive peut coûter cher.

Pourquoi la comparaison Kubernetes vs Docker Swarm est cruciale pour votre entreprise

La conteneurisation a transformé l'architecture des applications modernes. Selon le rapport Portworx 2023, 87 % des entreprises utilisent désormais des conteneurs en production, contre 55 % en 2019. Cette adoption massive crée un défi stratégique : quelle orchestration choisir ?

Le marché propose deux approches radicalement différentes :

• Kubernetes, originellement conçu par Google (désormais sous gouvernance CNCF), gère aujourd'hui 60 % des workloads conteneurisés en production selon Datadog.
• Docker Swarm, intégré nativement au moteur Docker, représente environ 15 % des déploiements, principalement dans des contextes de petites et moyennes infrastructures.

Cette comparaison n'est pas technique pour la forme : elle détermine vos coûts opérationnels sur 3-5 ans, votre capacité à attirer des talents, et votre agilité face aux évolutions du marché.

Qu'est-ce que Kubernetes : l'orchestrateur de référence

Kubernetes (souvent abrégé K8s) est une plateforme open source d'orchestration de conteneurs démarrée chez Google en 2014, puis donate à la Cloud Native Computing Foundation (CNCF). La version actuelle stable est 1.28 (publiée en août 2023), avec des releases mineures tous les trois mois.

Architecture et composants fondamentaux

L'architecture Kubernetes repose sur un cluster de nœuds orchestrés autour de deux平面 :

Le plan de contrôle (Control Plane) comprend :

• kube-apiserver : le point d'entrée pour toutes les opérations, exposant l'API RESTful
• etcd : base de données clé-valeur distribuée stockant l'état du cluster
• kube-scheduler : attribue les pods aux nœuds selon les contraintes définies
• kube-controller-manager : exécute les contrôleurs de réplication, endpoints, namespaces
• cloud-controller-manager : interface avec les API des fournisseurs cloud (AWS, Azure, GCP)

Les nœuds workers exécutent :

• kubelet : agent local s'assurant que les conteneurs sont running comme spécifié
• kube-proxy : gère la networking et les règles iptables/IPVS
• Container Runtime : typiquement containerd ou CRI-O (Docker n'est plus supporté nativement depuis K8s 1.24)

Cette separation между control plane et workers permet une scalabilité horizontale et une haute disponibilité du plan de contrôle via etcd en cluster.

Cas d'usage typiques sur cloud public

Sur AWS, le service EKS (Elastic Kubernetes Service) propose trois tarifs :

• 0,10 $ par heure pour le plan de contrôle (72 $/mois)
• Frais EC2 pour les nœuds workers selon l'instance choisie
• Add-ons optionnels (VPC CNI, CoreDNS, kube-proxy) inclus

Azure AKS est gratuit pour le plan de contrôle (seuls les nœuds sont facturés), tandis que GKE propose un mode Autopilot facturé à la ressource consommée.

Qu'est-ce que Docker Swarm : la simplicité intégrée

Docker Swarm est l'orchestrateur natif intégré à la Docker Engine depuis la version 1.12 (2016). Il transforme un groupe de Docker hosts en un seul cluster virtuel, sans nécessiter de composant supplémentaire.

Architecture simplifiée

Docker Swarm utilise deux types de nœuds :

• Manager nodes : maintiennent l'état du cluster via Raft consensus, gèrent le scheduling et l'API
• Worker nodes : exécutent les tâches (tasks) assignées par les managers

La communication inter-nœuds repose sur un réseau overlay chiffré en AES-256 par défaut. Le consensus Raft implémenté nécessite un quorum de managers (minimum 3 pour la haute disponibilité).

Avantages concrets

• Zéro configuration réseau : docker network create génère automatiquement un overlay avec VXLAN
• Rolling updates intégrés : mise à jour progressive avec contrôle du delay entre services
• Service Discovery intégré :DNS interne automatique par nom de service
• Load balancing natif : distribution du traffic via le cluster DNS
• Sécurité out-of-the-box : certificats TLS mutuels entre nœuds, rotation automatique

La courbe d'apprentissage est significativement plus douce. Une équipe familière avec docker-compose peut passer à docker stack deploy en quelques heures.

Comparaison détaillée : Kubernetes vs Docker Swarm

1. Scalabilité et performance

Kubernetes excelle dans la scalabilité horizontale automatique :

• Horizontal Pod Autoscaler (HPA) ajuste le nombre de pods selon CPU, mémoire ou métriques custom
• Cluster Autoscaler sur cloud public provisionne automatiquement des nœuds
• J'ai mesuré des temps de scaling de 45 secondes pour passer de 10 à 100 pods sur GKE avec des nodes preemptibles
• Limite理论 : 500 000 conteneurs par cluster (testé par Google), pratique courante jusqu'à 10 000

Docker Swarm propose une scalabilité plus basique :

• docker service scale augmentation manuelle du nombre de replicas
• Pas d'autoscaling natif (requiert des scripts externes ou Ansible)
• Performance mesurée : 1200 conteneurs par node sans dégradation, jusqu'à 1000 nodes supportés
• Temps de démarrage d'un nouveau container : 3-5 secondes (vs 15-30s sur K8s pour un pod avec init containers)

Recommandation : Pour toute charge de production dépassant 50 conteneurs nécessitant de l'autoscaling, Kubernetes est incontournable. Docker Swarm convient pour des charges stables et prévisibles.

2. Gestion des réseaux et load balancing

Kubernetes offre une flexibilité maximale mais complexité correspondante :

Plugins CNI (Container Network Interface) : Calico, Cilium, Flannel, Weave Net...

• Calico (utilisé par 65 % des entreprises selon le CNCF Survey 2023) : politique réseau fine-grain, encryption IP-in-IP ou WireGuard
• Cilium : eBPF-based, performant pour des clusters de 500+ nœuds, avec observabilité intégrée
• AWS VPC CNI : performance réseau native AWS, mais verrouillage fournisseur

Ingress controllers : Nginx Ingress, Traefik, HAProxy, contour/envoy

• Nginx Ingress : 40 % de marché, riche en features, support commercial disponible
• Traefik : dynamique, intègre letsencrypt automatique, moins performant en haute charge

Service Mesh : Istio, Linkerd, Consul Connect

• Ajout de mTLS, traffic management, observabilité distribuée
• Coût opérationnel significatif : 2-4 heures/semaine d'administration pour Istio

Docker Swarm simplifie drastiquement :

• Réseau overlay automatique avec ingress mesh
• DNS interne résout les noms de service vers plusieurs IPs
• Load balancing interne round-robin sans configuration
• Pas de politique réseau complexe (mode bridge ou overlay uniquement)

Comparaison pratique : Sur un projet e-commerce avec 15 microservices, j'ai configuré le networking Docker Swarm en 2 heures. Le même setup Kubernetes (Cilium + Nginx Ingress + cert-manager) a demandé 3 jours. Cependant, lors d'un incident de sécurité en production, les politiques réseau Kubernetes ont permis un containment en 15 minutes contre plusieurs heures potentiellement sur Swarm.

3. Stockage et persistances

Kubernetes propose un modèle de Persistent Volumes sophistiqué :

Storage Classes par provider :

• AWS : awsElasticBlockStore, awsEFS (NFS haute perf), aws EBS
• Azure : azureDisk, azureFile
• GCP : gcePersistentDisk
• Solutions cloud-agnostic : Rook/Ceph, Longhorn, OpenEBS

CSI (Container Storage Interface) standardise les interactions avec les存储 backends

• Provisionnement dynamique : PVC → PV créé automatiquement
• Snapshots, clones, resizing online
• Modes d'accès : ReadWriteOnce, ReadOnlyMany, ReadWriteMany

StatefulSets pour les workloads avec état :

• Noms stables, identités réseau persistantes
• Ordre de déploiement et scaling contrôlé
• PVC templates pour provisionnement automatique

Docker Swarm offre des options limitées :

• Plugins de volume Docker (local, RexRay pour cloud providers)
• Pas de mécanisme de claims dynamiques natif
• Bind mounts et tmpfs uniquement pour les mounts persistants
• Pas de StatefulSets equivalent

Implication : Si vos applications require des bases de données, caches Redis, ou tout stockage avec état, Kubernetes offre des primitives bien plus robustes. Docker Swarm impose une gestion manuelle du stockage avec des scripts de backup/restore.

4. Déploiement et CI/CD

Kubernetes s'intègre profondément dans les pipelines modernes :

• Argo CD / Flux : GitOps natif, déploiement continu depuis Git
• Jenkins X / Tekton : pipelines cloud-native avec custom resources
• Helm : packaging d'applications, gestion de versions, rollback
• Kustomize : overlays Kubernetes pour environnements multiples
• kubectl : CLI riche, mais complex pour les non-initiés

Outils de gestion :

• Rancher : interface graphique multi-cluster, catalogue d'applications
• OpenShift (Red Hat) : plateforme enterprise avec CI/CD intégré, sécurité
• Anthos (Google) : gestion hybride et multi-cloud

Docker Swarm maintient la simplicité docker-compose :

• docker stack deploy : déploiement depuis docker-compose.yml
• docker-compose : fichier unique pour développement ET production
• Portainer : interface d'administration web
• Watchtower : mise à jour automatique des images
• Traefik : reverse proxy automatique avec labels Docker

Mon retour d'expérience : Sur un projet startup avec 3 développeurs, la stack Docker Swarm + Portainer + Watchtower a permis un time-to-market de 2 semaines. Sur un projet banking avec 25 développeurs, Kubernetes + Argo CD + Helm a été nécessaire pour gérer 47 environnements (dev, staging, préprod, prod multi-régions).

5. Haute disponibilité et tolérance aux pannes

Kubernetes implements la haute disponibilité à plusieurs niveaux :

Au niveau du cluster :

• etcd en cluster (3 ou 5 nœuds) pour la consensus Raft
• Multi-master deployment : recommandé 3+ managers sur nœuds différents
• Pod Disruption Budgets : définit le nombre minimum de pods disponibles pendant les operations
• Node taints et tolerations : contrôle du placement workload

Au niveau applicatif :

• ReplicaSets avec nombre de replicas configurable
• Pod Anti-Affinities : distribution géographique des pods
• Topology Spread Constraints : distribution across zones de disponibilité
• Readiness et Liveness probes : health checks configurables

Résilience mesurée :

• Perte d'un node : nouveaux pods schedulés en 30-60 secondes
• Perte d'un master : election etcd en < 10 secondes, API toujours disponible
• Rolling update avec PodDisruptionBudget de 1 : downtime zéro

Docker Swarm implements une HA plus simple :

• Raft consensus pour les managers (3 ou 5 recommandés)
• Service replicas : distribution automatique sur les nœuds
• Automatic VIP load balancing
• Drain et rollback intégrés

Limitations :

• Pas de mécanisme de placement fin (pas de affinity/anti-affinity natif)
• Mise à jour d'un node manager cause un brief downtime du control plane
• Santé des services basée sur un seul health check configurable

6. Sécurité

Kubernetes offre un modèle de sécurité granulaire :

Namespaces : isolation logique, RBAC par namespace
RBAC (Role-Based Access Control) :

• Roles et ClusterRoles pour permissions
• RoleBindings et ClusterRoleBindings
• ServiceAccounts pour les workloads
• Intégration OIDC pour federation d'identité (AWS IAM, Azure AD, GCP IAM)

Security Contexts :

• UID/GID ranges, capabilities Linux
• readOnlyRootFilesystem, privileged containers controls
• Seccomp profiles, AppArmor/SELinux

Network Policies :

• Firewalling au niveau pod
• Ingress/Egress rules par namespace
• Implementation取决于 CNI plugin (Calico, Cilium)

Pod Security Standards :

• Privileged, Baseline, Restricted policies
• Enforcement via OPA/Gatekeeper ou Pod Security Admission (K8s 1.25+)

Secrets management :

• Secrets chiffrés dans etcd (AES-GCM depuis K8s 1.13)
• Integration Vault, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager
• External Secrets Operator pour sync automatique

Docker Swarm security model :

• RBAC basique (4 rôles : swarm-admin, maintenance, consulting, readonly)
• Secrets intégrés (docker secret create), chiffrés at rest
• Networks isolés (overlay, bridge)
• No Network Policies (firewalling manuel nécessaire)
• Scanning d'images via Docker Hub ou Trivy

Comparaison : Kubernetes est objectivement plus sécurisé pour les environments réglementés (PCI-DSS, HIPAA, SOC 2). Docker Swarm convient pour des environnements moins sensibles où la surface d'attaque est acceptable.

Tableau comparatif synthétique

Critère	Kubernetes	Docker Swarm
Courbe d'apprentissage	Élevée (2-4 mois pour proficiency)	Faible (1-2 semaines)
Scalabilité automatique	Native via HPA, Cluster Autoscaler	Requiert scripts externes
Taille maximale supportée	500 000+ conteneurs	~10 000 conteneurs recommandé
Nombre de nœuds max	5000+ nœuds par cluster	1000 nœuds
Service Mesh support	Istio, Linkerd, Consul	Via sidecars manuels
Stockage persistant	CSI, StatefulSets, Storage Classes	Plugins volume basiques
Cloud providers support	Multi-cloud natif (EKS, AKS, GKE, DKO)	Limité, Via Docker Machine
Coût opérationnel (infra)	Élevé (plan de contrôle, nodes sur-dimensionnés)	Faible (overhead minimal)
Écosystème tools	Massive (500+ solutions CNCF)	Restreint
Cas d'usage idéal	Microservices production, CI/CD enterprise	中小規模の workloads, edge computing

Quand choisir Kubernetes : cas d'usage recommandés

Adoptez Kubernetes si :

1. Votre infrastructure dépasse 50 conteneurs en production

   • La gestion manuelle devient ingérable
   • L'autoscaling devient critique pour la disponibilité

2. Vous avez des exigences de haute disponibilité multi-zones

   • Distribution géographique obligatoire (RGPD, latence)
   • Disaster recovery automatisé requis

3. Vous utilisez une architecture microservices complexe

   • Communication service-to-service (gRPC, mTLS)
   • Tracing distribué (Jaeger, Zipkin)
   • 12+ services avec des dépendances complexes

4. Votre organisation a des besoins de conformité

   • Audit trails, RBAC granulaire
   • Encryption at rest et in transit
   • Policies de sécurité enforceables

5. Vous visez une stratégie multi-cloud ou hybride

   • Portabilité entre AWS, Azure, GCP
   • Kubernetes as a Service sur chaque provider
   • Outils Rancher, Anthos, Red Hat OpenShift

Services managés Kubernetes recommandés :

• EKS (AWS) : intégration native IAM, Fargate pour serverless containers
• AKS (Azure) : integration Azure AD, Azure Monitor, GitHub Actions
• GKE (Google) : Autopilot mode, Cloud Run pour workloads serverless
• DigitalOcean Kubernetes : simplicité, bon rapport qualité/prix pour SMB

Quand choisir Docker Swarm : cas d'usage recommandés

Restez sur Docker Swarm si :

1. Vous avez une équipe existante expérimentée en Docker

   • Pas de besoin de former aux concepts Kubernetes
   • docker-compose.yaml portable entre dev et prod

2. Vos workloads sont stables et prévisibles

   • Nombre de conteneurs constant ou croissant linéairement
   • Pas de bursts nécessitant du scaling rapide

3. La simplicité d'opérating prime

   • Équipe ops small (2-3 personnes)
   • Infrastructure on-premise ou chez un seul provider

4. Budget limité pour le infrastructure management

   • Overhead Kubernetes ~15-20 % des ressources
   • Pas de budget pour former à CKA/CKAD

5. Edge computing ou IoT

   • Arm devices, Raspberry Pi clusters
   • Déploiement Air-gapped
   • Resources hardware limitées

Stack recommandée pour Docker Swarm :

• Portainer (GUI pour management)
• Watchtower (auto-update images)
• Traefik (reverse proxy avec Let's Encrypt)
• GlusterFS ou Ceph pour le stockage distribué
• cAdvisor + Prometheus + Grafana pour la monitoring

Processus de migration : de Docker Swarm vers Kubernetes

Si vous décidez de migrer, voici le chemin que j'ai validé sur 3 projets :

Phase 1 - Évaluation (2-4 semaines)

1. Inventory complète des services Swarm
2. Identification des dépendances (volumes, réseaux, secrets)
3. Évaluation des patterns non-Docker-friendly (hostname hardcodé, stockage local)
4. Calcul du sizing cluster cible (nodes, CPU, RAM)

Phase 2 - Préparation (4-8 semaines)

1. Setup cluster Kubernetes (dev/staging d'abord)
2. Traduction docker-compose → Helm charts ou Kustomize overlays
3. Migration des données volumes (backup/restore ou réplication)
4. Configuration RBAC, Network Policies, Secrets

Phase 3 - Migration progressive (2-6 mois)

1. Strangler fig pattern : migrate service par service
2. Utiliser Docker Swarm comme proxy temporaire (nginx)
3. Validation performance et fonctionnalité
4. Switch progressif du traffic (canary deployments)

Phase 4 - Validation et optimisation (2-4 semaines)

1. Load testing sur Kubernetes
2. Tuning des ressources (requests/limits)
3. Documentation Runbook
4. Training équipe ops

Coût typiques observés :

• Migration 20-50 services : 80 000 € - 150 000 €
• Migration 50-150 services : 150 000 € - 300 000 €
• Migration 150+ services : 300 000 € - 600 000 €

Ces coûts incluent consulting, formation, et la période de parallel run.

Conclusion et recommandation finale

Après 15 ans dans le cloud et des dizaines de déploiements conteneurisés, ma recommandation est claire :

Pour 90 % des entreprises dépassant 20 développeurs et 50 conteneurs en production, Kubernetes est le bon choix. L'investissement initial est réel (3-6 mois, 80-200 k€), mais le retour sur investissement se materialise en 18-24 mois via :

• Réduction de 30-50 % des incidents liés à l'infrastructure
• Auto-scaling ayant évité 3-5 events de saturation
• Portabilité ayant permis de migrer de provider en 2 semaines vs 6 mois
• Capacité à attirer des talents formés Kubernetes

Docker Swarm reste pertinent pour : les startups en phase de validation (< 50 conteneurs, < 5 développeurs), les workloads edge avec contraintes hardware, ou les équipes ayant une expertise Docker deep et pas de budget pour former.

Si vous hésitez encore, posez-vous cette question : « Dans 3 ans, combien de conteneurs vais-je gérer ? » Si la réponse est « plus de 100 » ou « je ne sais pas », partez sur Kubernetes. La flexibilité vaut l'investissement.

Prochaine étape : Évaluez votre posture actuelle avec notre guide sur les bonnes pratiques Kubernetes pour enterprise, ou planifiez une architecture review avec nos experts Ciro Cloud pour une recommandation personnalisée sur votre cas spécifique.