Migrer ses applications de Docker Swarm vers Kubernetes

La migration Docker Swarm Kubernetes concerne un nombre croissant d'organisations cherchant à standardiser leur orchestration de conteneurs. Selon The Decipherist, 96% des organisations utilisent ou évaluent Kubernetes, tandis que Docker Swarm ne représente plus que 24% des déploiements. Cette tendance s'accélère avec l'adoption de l'IA : 66% des organisations hébergeant des modèles d'IA générative utilisent Kubernetes pour leurs workloads d'inférence (CNCF Annual Survey 2025).

TL;DR : Ce guide détaille les étapes clés pour migrer vos applications Docker Swarm vers Kubernetes : mapping des concepts, conversion des configurations, stratégie de migration progressive, et validation.

Pour maîtriser ces compétences, découvrez la formation LFD459 Kubernetes pour les développeurs d'applications.

Pourquoi envisager la migration Docker Swarm Kubernetes maintenant ?

Docker Swarm offre une simplicité appréciable : une seule commande docker swarm init suffit à initialiser un cluster (Portainer Blog). Cependant, plusieurs facteurs poussent les équipes vers Kubernetes.

Facteurs déclencheurs de migration :

À retenir : La migration vers Kubernetes n'est pas une question de "si" mais de "quand". Planifiez-la proactivement plutôt que sous la contrainte.

Un CTO d'entreprise témoigne dans le rapport Spectro Cloud State of Kubernetes 2025 : "Just given the capabilities that exist with Kubernetes, and the company's desire to consume more AI tools, we will use Kubernetes more in future."

Comment mapper les concepts Docker Swarm vers Kubernetes ?

La première étape d'une stratégie migration conteneurs Kubernetes réussie consiste à comprendre les équivalences entre les deux systèmes.

Tableau de correspondance des ressources

Pour approfondir les manifestes Kubernetes, consultez Manifestes YAML Kubernetes : référence rapide.

Différences architecturales fondamentales

Docker Swarm utilise un modèle déclaratif simplifié où le manager orchestre directement les workers. Kubernetes introduit plusieurs composants : etcd pour le stockage d'état, kube-scheduler pour le placement, kube-controller-manager pour la réconciliation.

# Docker Compose / Swarm
services:
  web:
    image: nginx:1.25
    deploy:
      replicas: 3
    ports:
      - "80:80"

# Kubernetes équivalent
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: nginx
        image: nginx:1.25
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  selector:
    app: web
  ports:
  - port: 80
    targetPort: 80

À retenir : Kubernetes exige plus de configuration initiale mais offre un contrôle granulaire. Chaque concept Swarm se traduit souvent en plusieurs ressources Kubernetes.

Quelle stratégie migration conteneurs Kubernetes adopter ?

Trois approches principales existent pour migrer de Docker Swarm vers Kubernetes. Le choix dépend de la criticité des applications et des contraintes de temps.

Migration progressive (recommandée)

Cette approche minimise les risques en migrant application par application :

1. Inventaire : Lister toutes les stacks Swarm et leurs dépendances
2. Classification : Prioriser par criticité et complexité
3. Pilote : Migrer une application non critique pour valider le processus
4. Itération : Appliquer les leçons apprises aux applications suivantes
5. Cutover : Basculer le trafic progressivement

# Exporter la configuration Swarm
docker stack services mon-stack --format "{{.Name}}: {{.Image}}"
docker service inspect mon-service --pretty

Migration parallèle

Faire fonctionner les deux environnements simultanément pendant une période de transition :

• Avantage : Rollback immédiat possible
• Inconvénient : Coût d'infrastructure doublé temporairement

Migration big bang

Tout migrer en une seule opération planifiée :

• Avantage : Transition rapide, pas de maintenance double
• Inconvénient : Risque élevé, nécessite une préparation exhaustive

Le hub Administration cluster Kubernetes détaille les aspects opérationnels de la gestion de cluster.

Comment convertir vos fichiers docker-compose.yml ?

Plusieurs outils automatisent partiellement la conversion des fichiers Docker Compose vers des manifestes Kubernetes.

Utiliser Kompose

# Installation
curl -L https://github.com/kubernetes/kompose/releases/latest/download/kompose-linux-amd64 -o kompose
chmod +x kompose
sudo mv kompose /usr/local/bin/

# Conversion
kompose convert -f docker-compose.yml

# Conversion avec création des ressources
kompose convert -f docker-compose.yml | kubectl apply -f -

Kompose génère des fichiers séparés pour chaque ressource. Attendez-vous à des ajustements manuels, notamment pour :

• Les volumes persistants (PVC)
• Les configurations réseau avancées
• Les health checks (probes)
• Les contraintes de ressources (requests/limits)

Conversion manuelle des secrets

# Docker Swarm
docker secret create ma-cle ./ma-cle.pem

# Kubernetes
kubectl create secret generic ma-cle --from-file=./ma-cle.pem

Pour la gestion sécurisée des secrets, consultez ConfigMaps et Secrets Kubernetes : bonnes pratiques.

Comment un ingénieur infrastructure Kubernetes valide-t-il la migration ?

La validation post-migration requiert une approche méthodique couvrant plusieurs dimensions.

Tests fonctionnels

# Vérifier le déploiement
kubectl get deployments
kubectl rollout status deployment/mon-app

# Tester les endpoints
kubectl port-forward service/mon-app 8080:80
curl localhost:8080/health

Tests de charge

# Utiliser k6 ou hey pour les tests de charge
hey -n 10000 -c 100 http://mon-app.cluster.local/api

# Surveiller les métriques
kubectl top pods -l app=mon-app

Validation du réseau

# Tester la résolution DNS interne
kubectl run test --rm -it --image=busybox -- nslookup mon-service

# Vérifier les endpoints
kubectl get endpoints mon-service

À retenir : Automatisez vos tests de validation dans un pipeline CI/CD. Une suite de tests reproductible garantit la qualité de chaque migration.

Le guide Pipeline CI/CD pour applications Kubernetes détaille l'automatisation des déploiements.

Quels pièges éviter lors de la migration Docker Swarm Kubernetes ?

L'expérience des migrations révèle des erreurs récurrentes à anticiper.

Sous-estimer la gestion des volumes

Docker Swarm simplifie le partage de volumes entre nœuds. Kubernetes nécessite une solution de stockage distribué (NFS, Ceph, cloud provider).

# PersistentVolumeClaim Kubernetes
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mon-stockage
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: standard

Ignorer les différences de réseau

Le réseau overlay Swarm fonctionne différemment des CNI Kubernetes. Testez explicitement la communication inter-services.

Négliger les health checks

Kubernetes utilise trois types de probes (liveness, readiness, startup) contre un seul mécanisme de healthcheck dans Swarm.

livenessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 30
  periodSeconds: 10
readinessProbe:
  httpGet:
    path: /ready
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 5

Pour résoudre les problèmes de déploiement, référez-vous à Résoudre les erreurs courantes de déploiement sur Kubernetes.

Oublier les contraintes de ressources

Swarm permet de déployer sans spécifier de limites. Kubernetes l'autorise aussi, mais c'est une mauvaise pratique en production.

resources:
  requests:
    memory: "128Mi"
    cpu: "100m"
  limits:
    memory: "256Mi"
    cpu: "500m"

Comment optimiser vos images pour Kubernetes ?

La migration représente une opportunité d'optimiser vos images conteneurs. Selon Cloud Native Now, les builds multi-stage réduisent la taille des images de 800 Mo à 15-30 Mo.

Utiliser des images de base légères

# Au lieu de
FROM ubuntu:22.04

# Préférer
FROM alpine:3.19
# ou
FROM gcr.io/distroless/static-debian12

Une image Alpine pèse environ 3 Mo contre 70 Mo pour Ubuntu (Medium Docker Optimization).

Builds multi-stage

# Stage de build
FROM golang:1.22 AS builder
WORKDIR /app
COPY . .
RUN CGO_ENABLED=0 go build -o main .

# Stage de production
FROM alpine:3.19
COPY --from=builder /app/main /main
CMD ["/main"]

Le guide administrateur système formation Kubernetes, les fondamentaux couvre ces bonnes pratiques.

Planifiez votre montée en compétences

À retenir : Une migration réussie repose autant sur les compétences humaines que sur les outils techniques. Formez vos équipes avant de migrer.

Le hub Développement applications Kubernetes centralise les ressources pour développeurs.

Pour l'observation post-migration, consultez Observabilité et monitoring des applications sur Kubernetes.

Passez à l'action : formations migration Kubernetes

La migration Docker Swarm vers Kubernetes nécessite une compréhension approfondie des deux écosystèmes. Les formations officielles Linux Foundation préparent efficacement vos équipes.

Formations recommandées pour l'ingénieur opérations Cloud formation LFD459 Kubernetes pour les développeurs d'applications :

• LFD459 Kubernetes pour les développeurs d'applications : 3 jours pour maîtriser le déploiement d'applications conteneurisées, idéal pour les développeurs migrant depuis Docker Swarm
• LFS458 Administration Kubernetes : 4 jours pour les ingénieurs infrastructure Kubernetes responsables des clusters de production
• Kubernetes, les fondamentaux : 1 jour de découverte pour initier les équipes aux concepts de base

Comme l'affirme Chris Aniszczyk de la CNCF : "Kubernetes is no longer experimental but foundational. Soon, it will be essential to AI as well." Positionnez vos équipes dès maintenant.