Docker Swarm a rendu de grands services : il est simple, rapide à mettre en place et suffisant pour beaucoup de plateformes. Mais quand le nombre d'applications augmente, que plusieurs équipes partagent la même plateforme et que les exigences de sécurité se durcissent, Kubernetes devient souvent le choix logique. La migration, elle, n'a rien d'automatique. Voici les cinq erreurs que nous rencontrons le plus souvent sur le terrain.
1. Traduire les fichiers Compose ligne à ligne
Des outils comme kompose convertissent un fichier docker-compose.yml en manifestes Kubernetes. C'est un bon point de départ, jamais un point d'arrivée. Un service Swarm ne correspond pas exactement à un Deployment : il faut décider pour chaque application s'il s'agit d'un Deployment, d'un StatefulSet (base de données, file de messages) ou d'un DaemonSet (agent présent sur chaque nœud).
Les configs et secrets Swarm deviennent des ConfigMaps et des Secrets, les healthcheck deviennent des sondes. Profitez de la migration pour adopter un outil de paquetage comme Helm ou Kustomize : vous gérerez ensuite vos environnements (recette, production) sans dupliquer les fichiers.
2. Oublier le stockage persistant
Sous Swarm, beaucoup de plateformes utilisent des volumes locaux ou un partage NFS monté sur chaque nœud. Sous Kubernetes, un conteneur peut être replanifié sur n'importe quel nœud à tout moment : un volume local le suivra rarement. Il faut donc une vraie solution de stockage, exposée par une StorageClass (Longhorn, LINSTOR ou le stockage de votre baie SAN), et des PersistentVolumeClaims pour chaque application qui écrit des données.
Avant la bascule, testez la restauration des données, pas seulement leur copie. Une sauvegarde jamais restaurée n'est qu'une hypothèse.
3. Négliger le réseau et l'exposition des services
Le routing mesh de Swarm publie un port sur tous les nœuds sans configuration particulière. Kubernetes sépare les rôles : un Service donne une adresse stable à l'application à l'intérieur du cluster, un contrôleur Ingress (ou la Gateway API) l'expose à l'extérieur, avec les certificats TLS, idéalement renouvelés automatiquement par cert-manager.
Attention aussi aux noms : les applications qui s'appelaient par le nom du service Swarm doivent utiliser le nom DNS du Service Kubernetes, qui dépend de l'espace de noms (api.production.svc.cluster.local). Enfin, appliquez des NetworkPolicies : par défaut, tous les pods peuvent se parler.
4. Ne déclarer ni ressources ni sondes
Sans requests, l'ordonnanceur de Kubernetes ne sait pas où placer vos pods et peut surcharger un nœud. Sans limits sur la mémoire, une application qui fuit peut pénaliser ses voisines ; avec des limites trop basses, elle sera arrêtée en boucle (OOMKilled). Partez des consommations observées sous Swarm, puis ajustez avec les métriques de Prometheus.
Les sondes sont tout aussi importantes. La sonde readiness indique quand un pod peut recevoir du trafic, la sonde liveness quand il faut le redémarrer. Mal réglées, elles provoquent des redémarrages au démarrage des applications lentes : utilisez une sonde startup pour ces cas.
5. Tout basculer en une seule fois
La tentation est grande de migrer toutes les applications un vendredi soir. Préférez une migration par vagues : d'abord une application peu critique, puis les autres, en faisant tourner les deux plateformes en parallèle le temps de la transition.
- Abaissez la durée de vie (TTL) des enregistrements DNS quelques jours avant, pour pouvoir basculer et revenir vite.
- Écrivez le plan de retour arrière avant la bascule, pas pendant l'incident.
- Mettez en place l'observabilité (métriques, journaux, alertes) avant de migrer, pour comparer les comportements.
Et surtout : préparer l'équipe
Une plateforme Kubernetes bien construite mais que personne ne sait exploiter reste fragile. Les commandes changent (kubectl au lieu de docker service), la façon de diagnostiquer aussi. Prévoyez la montée en compétences de l'équipe d'exploitation en même temps que la migration, et non après.
C'est l'approche que nous appliquons dans nos projets : concevoir, déployer, sécuriser, puis transférer les compétences aux équipes qui exploitent la plateforme au quotidien.