Docker Swarm a longtemps séduit par sa simplicité : quelques commandes, une orchestration minimale, et une intégration native avec Docker. Mais à mesure qu’une application grandit, cette simplicité devient une limite : autoscaling rudimentaire, écosystème restreint, observabilité limitée et communauté en perte de vitesse. La migration vers Kubernetes, via des services managés comme EKS (AWS) ou AKS (Azure), s’impose alors comme la voie de la maturité : orchestration riche, écosystème immense et modèle de production éprouvé à grande échelle.
Pourquoi quitter Docker Swarm pour Kubernetes ?
La motivation principale est la maturité opérationnelle. Kubernetes offre des capacités que Swarm ne propose pas nativement ou de façon aboutie : autoscaling horizontal des pods (HPA), déploiements progressifs avec rollback automatique, gestion déclarative de l’état souhaité, maillage de services (Istio, Linkerd), et un écosystème d’outils (Helm, Argo CD, Prometheus) devenu le standard de l’industrie. Swarm, en mode maintenance, ne bénéficie plus d’innovations majeures, et recruter des ingénieurs compétents sur Kubernetes est bien plus facile que sur Swarm.
Le revers de la médaille est la complexité : Kubernetes introduit une courbe d’apprentissage réelle et de nombreux concepts (Pods, Deployments, Services, Ingress, ConfigMaps, Secrets, RBAC, namespaces). Une migration bien menée transforme cette complexité en levier ; une migration bâclée la transforme en dette technique.
Docker Swarm vs Kubernetes : les correspondances à maîtriser
La traduction d’un fichier Swarm vers des objets Kubernetes n’est pas linéaire, mais les correspondances suivantes donnent le cap :
| Concept Docker Swarm | Équivalent Kubernetes | Remarques |
|---|---|---|
| Service | Deployment + Service | Séparation du déploiement et de l’exposition |
| docker-compose.yml | Manifests YAML + Helm | Découpage par ressource, templating Helm |
| Overlay network | CNI (Calico, Cilium) + NetworkPolicy | Modèle réseau différent, politiques riches |
| Published ports | Service (ClusterIP/NodePort) + Ingress | Routage par hôte/virtualhost |
| Configs / Secrets | ConfigMap / Secret | Encodage base64 pour les secrets |
| Replica count | ReplicaSet + HPA | Autoscaling sur métriques |
| Swarm mode manager | Control plane managé (EKS/AKS) | Plus de nœuds managers à gérer soi-même |
| Healthcheck | Probes (liveness/readiness/startup) | Plus fin et plus puissant |
Cette table est le point de départ d’un travail de refonte des workloads : chaque service Swarm doit être redéfini en Deployment Kubernetes avec ses probes, ses limites de ressources et ses politiques réseau.
Les étapes d’une migration Swarm vers Kubernetes
- Audit des services Swarm : lister les services, leurs images, variables d’environnement, secrets, réseaux, volumes et dépendances inter-services.
- Choix de la cible : EKS sur AWS ou AKS sur Azure selon votre cloud, avec une réflexion sur la taille du cluster, les node groups et le réseau (VPC, sous-réseaux).
- Écriture des manifests : convertir chaque service en Deployment, définir les Services, ConfigMaps et Secrets, puis packager le tout en charts Helm pour la reproductibilité.
- Mise en place de l’ingress : déployer un contrôleur d’entrée (NGINX Ingress, Traefik) et router le trafic HTTP/HTTPS vers les bons services, avec gestion des certificats TLS.
- Sécurisation : activer le RBAC, définir des NetworkPolicies, scanner les images (Trivy, Snyk), et gérer les secrets via un coffre (Secrets Manager, Vault, ou CSI driver).
- Observabilité : déployer Prometheus + Grafana pour les métriques, l’agrégation de logs (Loki, CloudWatch, Azure Monitor) et des traces si nécessaire.
- Bascule progressive : déployer en parallèle, tester en environnement de pré-production, puis basculer le trafic (DNS ou ingress) avec un plan de rollback vers Swarm.
- Formation et fermeture : former les équipes aux commandes kubectl et aux runbooks, puis décommissionner le cluster Swarm.
Les pièges qui guettent les équipes
Le premier piège est la gestion des secrets : en Swarm, ils sont souvent stockés en clair ou via des mécanismes simples ; en Kubernetes, il faut une vraie stratégie (chiffrement au repos, coffre externe, rotation). Le deuxième est le réseau : les politiques réseau Kubernetes étant plus strictes par défaut, une application qui communiquait librement entre services peut se retrouver coupée ; il faut cartographier les flux avant de durcir. Le troisième piège est l’état des données : les volumes Docker et les bases embarquées dans les conteneurs posent problème ; les données persistantes doivent migrer vers des volumes managés (EBS, Azure Disk, EFS) ou des bases managées.
Enfin, la limite des ressources : Kubernetes impose de déclarer requests et limits, ce qui révèle brutalement les services qui consommaient trop en Swarm. C’est une bonne chose, mais cela exige un travail de calibrage.
Stratégie de bascule sans interruption
La bascule d’un cluster Swarm vers Kubernetes doit être progressive et réversible. La méthode éprouvée consiste à faire cohabiter les deux orchestrateurs pendant une période de transition : le nouveau cluster Kubernetes est déployé en parallèle, les services migrent par vagues, et un même point d’entrée (load balancer ou DNS) répartit le trafic. On commence par les services les moins critiques, on observe les métriques, puis on progresse vers les services cœur.
Le rollback consiste simplement à rediriger le trafic vers Swarm en cas de problème. Cette capacité de repli, testée en conditions réelles, est la garantie que la migration ne se transforme jamais en incident de production.
Gouvernance, CI/CD et conduite du changement
Kubernetes invite à repenser le CI/CD : GitOps avec Argo CD ou Flux, déploiements canary ou blue/green, promotion d’images. C’est l’occasion de moderniser la chaîne de livraison en même temps que l’orchestration. La conduite du changement est essentielle : les développeurs comme les ops doivent apprendre les concepts Kubernetes, les commandes kubectl et les nouveaux outils. Sans accompagnement, le cluster devient rapidement ingouvernable.
Volumes, données persistantes et workloads stateful
La migration des workloads stateless vers Kubernetes est la partie la plus simple ; la difficulté se concentre sur les données persistantes. En Swarm, un volume Docker attaché à un service suffisait ; en Kubernetes, il faut des PersistentVolumeClaims (PVC) adossés à des StorageClasses adaptées au cloud cible — EBS sur AWS, Azure Disk sur Azure, ou EFS/Azure Files pour les volumes partagés entre plusieurs pods.
Les bases de données embarquées dans des conteneurs sont le point le plus risqué. La meilleure pratique consiste à les externaliser vers un service managé (Amazon RDS, Azure Database) avant la bascule, ce qui simplifie la sauvegarde, la haute disponibilité et le scaling. Pour les bases qui doivent rester dans le cluster, utilisez des StatefulSets avec un volume par réplica, et validez la stratégie de sauvegarde et de restauration sur le nouvel orchestrateur.
Prévoyez aussi la migration des données elles-mêmes : selon les volumes et la tolérance à l’interruption, privilégiez la réplication logique, un dump/restore pendant une fenêtre de maintenance, ou un transfert via des outils de synchronisation. La règle d’or est de ne jamais supprimer les volumes Swarm tant que les données n’ont pas été vérifiées sur le cluster Kubernetes, avec un contrôle d’intégrité (nombre de lignes, checksums) avant le décommissionnement.
Pourquoi se faire accompagner par Performances Digital ?
Migrer de Docker Swarm vers Kubernetes est un saut de maturité qui se prépare. Chez Performances Digital, nous accompagnons cette transition de bout en bout : audit des services Swarm, conception de l’architecture Kubernetes (EKS ou AKS), écriture des manifests et des charts Helm, sécurisation (RBAC, NetworkPolicies, secrets) et mise en place de l’observabilité. Notre approche par bascule progressive garantit la continuité de service, et nous formons vos équipes pour qu’elles deviennent autonomes sur leur nouvel orchestrateur.
Passer à Kubernetes, c’est sécuriser et industrialiser l’orchestration de vos conteneurs pour la prochaine décennie. Demandez votre devis gratuit : nous évaluerons votre cluster Swarm et vous proposerons une trajectoire de migration chiffrée, avec un plan de bascule sans interruption.
