Retour d'expérience : migration de Docker Swarm vers Kubernetes en entreprise

La question Kubernetes vs Docker Swarm se pose pour de nombreuses organisations ayant démarré avec Docker Swarm et envisageant une migration.

Selon The Decipherist, 96% des organisations utilisent ou évaluent Kubernetes, tandis que Docker Swarm reste à environ 24% d'adoption. Ce guide présente un scénario de migration représentatif, basé sur les patterns observés dans de nombreux projets.

TL;DR : Ce scénario type couvre une migration Docker Swarm vers Kubernetes sur 6 mois pour 40-50 microservices. Résultats typiques observés : réduction des incidents de 50-70%, amélioration du temps de déploiement de 30-50%, mais investissement initial conséquent en formation et infrastructure.

Ce type de migration est couvert dans la formation LFD459 Kubernetes pour les développeurs.

Profil type : entreprise envisageant la migration

Ce scénario représente une entreprise tech de taille moyenne (80-150 développeurs) ayant adopté Docker Swarm il y a plusieurs années. L'infrastructure type inclut :

40-50 microservices en production
3 environnements (dev, staging, prod)
10-15 nodes Docker Swarm
150-250 déploiements par mois

Limites couramment rencontrées avec Swarm :

Problème	Impact métier typique
Absence d'autoscaling natif	Surprovisionnement permanent (+20-40% coûts)
Monitoring limité	MTTR élevé (30-60 min en moyenne)
Écosystème restreint	Développements custom chronophages
Moins de talents disponibles	Difficulté de recrutement

Comme le note Portainer, Docker Swarm se configure en une commande (docker swarm init), mais Kubernetes offre une scalabilité supérieure pour des milliers de conteneurs (PhoenixNAP).

À retenir : Le choix Kubernetes vs Docker Swarm dépend de la taille : Swarm pour les architectures simples, Kubernetes pour les déploiements complexes à grande échelle.

Pour comprendre les différences techniques, consultez notre comparatif Kubernetes vs Docker Swarm, ECS et Nomad.

Phase 1 : évaluation et planification (2 mois)

Une migration réussie commence par une évaluation rigoureuse.

Audit de l'existant

# Inventaire des services Swarm
docker service ls --format "{{.Name}}\t{{.Replicas}}\t{{.Image}}"

# Analyse des ressources par service
docker stats --no-stream --format "table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}"

Résultats typiques d'un audit :

40-50 services, dont 10-15 critiques (paiement, authentification, etc.)
5-10 services stateful nécessitant des volumes persistants
10-20 jobs batch avec des dépendances complexes

Choix de la plateforme cible

Les équipes choisissent généralement une plateforme managée (GKE, EKS, AKS) pour :

Intégration native avec leur stack cloud existante
Gestion automatisée du control plane
Support entreprise 24/7

Selon le CNCF Annual Survey 2025, 82% des utilisateurs de conteneurs exécutent désormais Kubernetes en production.

Plan de formation des équipes

Un plan de formation typique pour une équipe de 20-30 ingénieurs sur 2-3 mois :

Développeurs : concepts fondamentaux + déploiement applicatif
DevOps/SRE : administration cluster + observabilité
Architectes : patterns avancés + sécurité

Comme l'affirme The Enterprisers Project : « Anybody can learn Kubernetes. With abundant documentation and development tools available online, teaching yourself Kubernetes is very much within reach. »

À retenir : La formation représente 30% du budget migration mais conditionne 80% du succès selon les retours terrain.

Notre page bonnes pratiques conteneurisation et Docker détaille les fondamentaux prérequis.

Phase 2 : migration des environnements non-critiques (2 mois)

L'approche retenue : migrer progressivement du moins critique au plus critique.

Conversion Docker Compose vers manifestes Kubernetes

# Avant : docker-compose.yml
version: '3.8'
services:
  api:
    image: mycompany/api:1.4.2
    ports:
      - "8080:8080"
    environment:
      - DB_HOST=postgres
    deploy:
      replicas: 3

# Après : deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
    spec:
      containers:
      - name: api
        image: mycompany/api:1.4.2
        ports:
        - containerPort: 8080
        env:
        - name: DB_HOST
          value: postgres-svc
        resources:
          requests:
            memory: "256Mi"
            cpu: "250m"
          limits:
            memory: "512Mi"
            cpu: "500m"

Outils de conversion utilisés

Outil	Usage	Efficacité
Kompose	Conversion automatique Compose → K8s	60% des cas
Helm	Templating des manifestes	100% des services
Kustomize	Gestion des environnements	Overlays dev/staging/prod

70% des organisations utilisent Helm selon Orca Security 2025.

Notre guide Migrer vers Kubernetes depuis Docker Compose, VMs détaille ces conversions.

Kubernetes vs Docker Swarm : défis techniques rencontrés

Défi 1 : gestion des secrets

Docker Swarm utilisait des secrets embarqués. Kubernetes offre plus d'options mais nécessite une architecture différente.

# Migration des secrets
kubectl create secret generic db-credentials \
  --from-literal=username=admin \
  --from-literal=password=<password>

Solution retenue : HashiCorp Vault avec External Secrets Operator pour centraliser la gestion.

Défi 2 : persistance des données

Les volumes Docker Swarm ne se convertissent pas directement en PersistentVolumes Kubernetes.

# PersistentVolumeClaim pour PostgreSQL
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: postgres-pvc
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: standard-rwo
  resources:
    requests:
      storage: 100Gi

Défi 3 : networking

Le passage du réseau overlay Swarm au CNI Kubernetes a nécessité une refonte des NetworkPolicies.

# NetworkPolicy pour isoler le namespace
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
spec:
  podSelector: {}
  policyTypes:
  - Ingress

À retenir : Prévoyez 2 semaines de tests réseau par environnement avant la migration de charge.

Pour le monitoring post-migration, consultez notre section Monitoring et dépannage Kubernetes.

Phase 3 : migration production (2 mois)

La migration production s'est déroulée en blue-green avec basculement progressif.

Stratégie de basculement

Semaine 1-2 : Déploiement parallèle Swarm + Kubernetes (10% trafic K8s)
Semaine 3-4 : Montée progressive (25%, 50%, 75%)
Semaine 5-6 : 100% Kubernetes, Swarm en standby
Semaine 7-8 : Décommissionnement Swarm

# Vérification santé du cluster
kubectl get nodes
kubectl get pods --all-namespaces | grep -v Running
kubectl top nodes

Incidents rencontrés

Incident	Cause	Résolution
Latence API +200ms	Limites CPU trop basses	Ajustement resources.limits
Perte de connexions DB	Mauvais probe readiness	Reconfiguration livenessProbe
OOM service paiement	Memory leak non détecté	Hotfix applicatif

La formation LFS458 Administration Kubernetes couvre ces scénarios de production.

Résultats typiques après 6 mois

Métriques opérationnelles couramment observées

Métrique	Avant (Swarm)	Après (K8s)	Évolution typique
MTTR	30-60 min	10-20 min	-50 à -70%
Incidents/mois	10-15	3-6	-50 à -70%
Temps déploiement	20-30 min	10-15 min	-30 à -50%
Disponibilité	99.5%	99.9%+	+0.3 à +0.5%

Impact financier typique

Coûts infrastructure : +10-20% (cluster Kubernetes + monitoring + formation)
Coûts opérationnels : -25 à -40% (moins d'incidents, automatisation)
ROI estimé : 12-24 mois pour amortir l'investissement initial

À retenir : Le ROI d'une migration Kubernetes se mesure sur 18-24 mois, pas sur les premiers mois post-migration.

Leçons apprises : recommandations pour votre migration

Ce qui a fonctionné

Migration progressive par criticité croissante
Formation anticipée avant le démarrage du projet
Monitoring dès le jour 1 avec Prometheus + Grafana
Runbooks de rollback testés avant chaque basculement

Ce qu'il faudrait améliorer

Sous-estimation du temps de conversion des jobs batch
Manque de tests de charge en environnement staging
Documentation insuffisante des NetworkPolicies

La formation LFS458 Administration Kubernetes prépare aux certifications validant ces compétences.

Checklist migration Kubernetes vs Docker Swarm

Avant de démarrer votre migration :

[ ] Auditer l'ensemble des services Swarm existants
[ ] Identifier les services stateful nécessitant une attention particulière
[ ] Former les équipes (minimum 2 semaines par profil)
[ ] Choisir la distribution Kubernetes (managée vs auto-hébergée)
[ ] Définir la stratégie de basculement (blue-green, canary)
[ ] Mettre en place le monitoring avant la migration
[ ] Préparer les runbooks de rollback
[ ] Tester chaque conversion en environnement non-prod

À retenir : Une migration réussie est une migration préparée : prévoyez 30% de marge sur le planning initial.

Pour approfondir les différences, consultez Kubernetes vs Docker : comprendre les différences.

Lancez votre migration avec les bonnes fondations

Le passage Kubernetes vs Docker Swarm représente un investissement stratégique. Selon Chris Aniszczyk, CTO de la CNCF : « Kubernetes is no longer experimental but foundational. Soon, it will be essential to AI as well. »

Prochaines étapes recommandées :

Évaluez votre infrastructure actuelle avec un audit technique
Formez vos équipes avant de démarrer la migration
Planifiez par phases du moins critique au plus critique

SFEIR accompagne les entreprises dans leur transformation cloud-native :

LFS458 Administration Kubernetes : maîtrisez l'administration de clusters production
LFD459 Kubernetes pour les développeurs : déployez vos applications conteneurisées
Kubernetes, les fondamentaux : découvrez les concepts essentiels en 1 jour

Demandez un conseil personnalisé pour définir votre stratégie de migration.

Points clés