Migrer vers Kubernetes sans interrompre le métier

Décider si la migration est justifiée

Une application unique, déployée une fois par mois sur un serveur qui tient la charge, n’a pas besoin d’un orchestrateur. Le bénéfice apparaît quand plusieurs services doivent cohabiter, se déployer indépendamment, monter en charge séparément et survivre à la perte d’une machine.

Le coût réel n’est pas le cluster : c’est la compétence nécessaire pour l’exploiter un dimanche. Si personne dans l’équipe ne sait lire un événement de planification ou diagnostiquer un redémarrage en boucle, la migration déplace le risque au lieu de le réduire.

Commencer par l’inventaire des dépendances cachées

Ce qui casse pendant une migration n’est presque jamais le code applicatif. Ce sont les hypothèses implicites sur l’environnement : un fichier écrit sur le disque local, une tâche planifiée dans la crontab du serveur, un envoi de courrier via un relais local, une adresse IP autorisée chez un partenaire.

• Écritures sur disque local, qui disparaissent au redémarrage d’un conteneur.
• Tâches planifiées qui doivent devenir des ressources déclarées, pas dupliquées.
• Sessions stockées en mémoire, incompatibles avec plusieurs répliques.
• Adresses IP sortantes filtrées par des partenaires, qui changent avec le cluster.

Migrer par environnements, pas par services

Reconstituez d’abord un environnement complet de recette sur le nouveau socle, même imparfait. Il révèle les écarts de configuration bien mieux qu’une migration service par service, où chaque brique semble fonctionner isolément.

Traitez la configuration comme du code : une seule source de vérité, versionnée, avec une différence explicite entre environnements. Une modification appliquée à la main sur un cluster est une dette qui se paiera au prochain déploiement, quand elle sera écrasée.

Basculer le trafic progressivement

La bascule se prépare en trois leviers indépendants : le trafic, les données et les tâches planifiées. Les basculer ensemble transforme un incident mineur en panne complète ; les séparer permet de revenir en arrière sur un seul.

1. Faire coexister les deux environnements, en lecture, sur les mêmes données.
2. Basculer une part du trafic et observer les erreurs applicatives, pas seulement les codes HTTP.
3. Basculer les écritures une fois les parcours vérifiés de bout en bout.
4. Déplacer les tâches planifiées en dernier, après avoir coupé les anciennes.

Garder un chemin de retour réel

Un retour arrière n’existe que s’il a été testé et si les données restent compatibles. Une migration de schéma irréversible appliquée trop tôt supprime cette option, souvent sans que personne s’en aperçoive.

Conservez l’ancien environnement en état de fonctionner quelques semaines. Ce n’est pas un manque de confiance : c’est ce qui permet de basculer un mardi matin plutôt qu’un samedi à minuit.

Une migration réussie se mesure à ce qui n’a pas eu lieu : aucun appel client, aucune commande perdue, aucun samedi passé à remettre le système d’aplomb.