Comment migrer vos workloads Kubernetes en production en 7 etapes

Bryan

Expert delivery et équipes offshore · 6 juillet 2026 · 10 min de lecture

Migrer des workloads Kubernetes en production est l'une des operations les plus delicates en DevOps. Que ce soit pour changer de provider cloud, upgrader vers une version majeure, ou consolider plusieurs clusters, la migration implique des risques reels : perte de donnees, interruption de service, degradation de performances. Ce guide en 7 etapes, base sur des migrations reelles effectuees pour des entreprises a Paris, Lyon, Nantes et Toulouse, vous donne une methodologie eprouvee pour migrer vos workloads sans stress et sans downtime.

Etape 1 : Auditer l'existant

Avant de toucher a quoi que ce soit, vous devez avoir une vision claire et exhaustive de ce qui tourne sur votre cluster actuel. Un audit incomplet est la premiere cause d'echec des migrations Kubernetes. On l'a vu chez un client a Paris : une migration planifiee sur 3 jours a pris 3 semaines parce que personne n'avait documente les CronJobs et les ConfigMaps specifiques a l'environnement.

Commencez par lister tous les namespaces actifs avec kubectl get ns --no-headers | wc -l. Pour chaque namespace, exportez l'inventaire complet des ressources : Deployments, StatefulSets, DaemonSets, Services, Ingress, ConfigMaps, Secrets, PersistentVolumeClaims, CronJobs, HPA, PDB, et NetworkPolicies. L'outil kubectl get all --all-namespaces -o yaml > cluster-export.yaml est un bon point de depart, mais attention : « all » ne couvre pas vraiment tout (il omet les ConfigMaps, Secrets, PVC, etc.).

Utilisez plutot un outil dedie comme Velero pour creer un snapshot complet de votre cluster. Velero exporte toutes les ressources Kubernetes, y compris les CRDs (Custom Resource Definitions) et les ressources custom installees par vos operateurs. C'est aussi votre filet de securite : en cas de probleme, vous pouvez restaurer l'etat complet du cluster source.

Documentez egalement les dependances externes : quels services communiquent avec des bases de donnees managees (RDS, Cloud SQL), des files d'attente (SQS, Pub/Sub), des caches externes (ElastiCache, Memorystore) ? Ces dependances conditionnent la strategie de migration. Si votre cluster a Lyon depend d'une base RDS dans la meme region AWS, migrer vers OVHcloud implique aussi de migrer la base de donnees, ce qui double la complexite.

Etape 2 : Choisir le bon provider manage

Le choix du provider Kubernetes manage depend de quatre criteres : la souverainete des donnees (ou sont stockees les donnees), la maturite de la plateforme (versions K8s supportees, features disponibles), le cout (prix du control plane + workers), et la proximite geographique (latence pour vos utilisateurs). Voici un comparatif des principaux providers pertinents pour les equipes francaises :

Pour les entreprises soumises a des contraintes reglementaires (sante, finance, administration publique), OVHcloud avec la qualification SecNumCloud est generalement le choix par defaut. Pour les startups qui cherchent le meilleur rapport prix/performance, Scaleway Kapsule offre des tarifs tres competitifs avec un service fiable. GKE reste le choix le plus mature pour les equipes qui ont besoin de fonctionnalites avancees (Autopilot, Anthos, fleet management).

Etape 3 : Preparer le cluster cible

La preparation du cluster cible est une etape critique qui conditionne le succes de toute la migration. Vous devez reproduire fidlement la configuration de votre cluster source, tout en profitant de l'occasion pour corriger les problemes connus et appliquer les bonnes pratiques actuelles.

Commencez par provisionner le cluster via Infrastructure as Code. Si vous n'utilisez pas encore Terraform ou Pulumi, c'est le moment. Ne provisionnez jamais un cluster de production via la console web du provider : c'est non reproductible, non auditable, et ca garantit des differences entre vos environnements.

Installez les composants systeme essentiels dans l'ordre suivant : ingress controller (Nginx, Traefik ou Istio selon votre stack), cert-manager pour les certificats TLS, external-dns pour la gestion automatique des enregistrements DNS, et metrics-server pour l'autoscaling. Utilisez Helm ou Kustomize pour deployer ces composants de maniere declarative.

Reproduisez les RBAC (Role-Based Access Control) du cluster source. Exportez les ClusterRoles, ClusterRoleBindings, Roles et RoleBindings avec Velero ou un script kubectl. Verifiez que les ServiceAccounts utilises par vos workloads existent sur le nouveau cluster et ont les memes permissions. C'est un point souvent oublie qui cause des erreurs 403 en cascade au moment de la migration.

Etape 4 : Migrer les workloads stateless

Les workloads stateless (API REST, frontends, workers de traitement) sont les plus simples a migrer. Le principe : deployer les memes manifests sur le nouveau cluster, verifier qu'ils fonctionnent, puis rediriger le trafic.

Si vos manifests Kubernetes sont versionnes dans Git (et ils devraient l'etre), la migration se resume a pointer votre pipeline CI/CD vers le nouveau cluster. Avec ArgoCD, c'est aussi simple que de creer une nouvelle Application pointant vers le meme repo Git mais avec le kubeconfig du nouveau cluster. Avec un pipeline classique (GitHub Actions, GitLab CI), mettez a jour le secret contenant le kubeconfig.

Deployez d'abord dans un namespace de test sur le nouveau cluster. Executez vos suites de tests d'integration et de smoke tests. Verifiez les logs, les metriques de latence, et les taux d'erreur. Comparez les performances avec le cluster source : si la latence P99 augmente de plus de 20%, investigez (difference de specs CPU, overhead reseau, location des dependances externes).

Une fois valides, deployez les workloads dans les namespaces de production du nouveau cluster. Ne redirigez pas encore le trafic : ils tourneront en parallele du cluster source pendant les etapes suivantes. Cette approche blue-green vous permet de valider chaque workload individuellement avant la bascule globale.

Etape 5 : Migrer les workloads stateful

C'est l'etape la plus delicate. Les workloads stateful (PostgreSQL, MySQL, MongoDB, Redis, Elasticsearch) transportent des donnees qui ne doivent pas etre perdues ni corrompues. La strategie depend du type de workload et de la tolerance au downtime.

Pour les bases de donnees relationnelles (PostgreSQL, MySQL), la methode la plus fiable est la replication logique. Configurez le nouveau cluster comme replica du cluster source. Pour PostgreSQL, utilisez la streaming replication ou pg_logical. Pour MySQL, utilisez la replication GTID. La replication assure que les donnees sont synchronisees en continu entre les deux clusters. Au moment de la bascule, vous promouvez la replica en primary.

Pour les caches (Redis, Memcached), deux options. Si votre application tolere un cache froid, il suffit de deployer une nouvelle instance sur le nouveau cluster et de laisser le cache se rechauffer naturellement. Si vous avez besoin d'un cache chaud des la bascule (cas typique : sessions utilisateurs stockees dans Redis), utilisez la replication Redis entre les deux clusters. Commande cle : REPLICAOF <source-host> <port>.

Pour les systemes de fichiers (PersistentVolumes utilises pour du stockage de fichiers), Velero avec le plugin restic est la solution standard. Velero sauvegarde le contenu des PV, les transfere vers un stockage objet (S3, GCS, Swift), puis les restaure sur le nouveau cluster. Le processus est transparent pour l'application, mais peut prendre du temps pour les gros volumes (comptez environ 100 Go/heure sur un lien 1 Gbps).

Etape 6 : Bascule DNS et validation

C'est le moment de verite. La bascule DNS consiste a rediriger le trafic de production du cluster source vers le cluster cible. Avant de toucher au DNS, verifiez une derniere fois que tous les workloads sont operationnels sur le nouveau cluster avec une checklist exhaustive.

Checklist pre-bascule : tous les pods sont en Running/Ready, les health checks (liveness et readiness probes) passent, les metriques de latence sont comparables au cluster source, les logs ne montrent pas d'erreurs anormales, les certificats TLS sont valides et renouveles via cert-manager, les replicas de bases de donnees sont synchronisees (lag de replication < 1 seconde), et les CronJobs ont ete testes au moins une fois.

Pour la bascule elle-meme, deux approches. La methode DNS : modifiez les enregistrements A/CNAME de votre domaine pour pointer vers les IP du nouveau cluster. Le TTL (Time to Live) de vos enregistrements DNS determine le temps de propagation. Reduisez le TTL a 60 secondes au moins 24 heures avant la bascule pour minimiser le temps de transition. Apres la bascule, certains clients garderont l'ancien cache DNS pendant le temps du TTL precedent.

La methode load balancer : si vous utilisez un load balancer externe (AWS ALB, Cloudflare, un HAProxy on-premise), ajoutez le nouveau cluster comme backend, puis retirez progressivement le cluster source. Cette methode est plus fine car elle permet un basculement progressif (10% du trafic, puis 50%, puis 100%) et un rollback instantane.

Apres la bascule, surveillez activement les metriques pendant au moins 4 heures. Les indicateurs cles : taux d'erreur HTTP (5xx), latence P50/P95/P99, nombre de connexions actives, et consommation CPU/memoire des pods. Utilisez Grafana avec des dashboards compares (ancien cluster vs nouveau) pour detecter les anomalies.

Etape 7 : Plan de rollback et decommission

Ne decommissionnez jamais l'ancien cluster immediatement apres la bascule. Gardez-le en etat de fonctionnement pendant au moins 7 jours apres la migration. C'est votre filet de securite : si un probleme critique apparait sur le nouveau cluster (bug applicatif non detecte en staging, probleme de performance sous charge reelle, incompatibilite avec une dependance externe), vous pouvez rebasculer le trafic vers l'ancien cluster en quelques minutes.

Documentez la procedure de rollback avant la migration. Elle doit etre executable en moins de 5 minutes par n'importe quel membre de l'equipe. Concretement : un script ou une commande qui remet les enregistrements DNS ou la configuration du load balancer a l'etat precedent. Testez cette procedure sur un environnement de staging avant le jour J.

Apres 7 jours sans incident, vous pouvez commencer la decommission de l'ancien cluster. D'abord, arretez les workloads (scale a 0 replicas). Attendez 24 heures pour confirmer qu'aucun service ne depend encore de l'ancien cluster. Puis sauvegardez une derniere fois les donnees avec Velero. Enfin, detruisez les ressources via Terraform ou la console du provider.

N'oubliez pas de mettre a jour votre documentation : diagrammes d'architecture, runbooks de deploiement, procedures de disaster recovery, et contacts des providers. C'est le moment ideal pour creer ou mettre a jour vos ADR (Architecture Decision Records) pour documenter pourquoi vous avez migre et quels tradeoffs vous avez faits.

Les erreurs les plus frequentes (et comment les eviter)

Apres avoir accompagne des dizaines de migrations Kubernetes pour des equipes a Paris, Lyon, Nantes et Toulouse, voici les erreurs recurrentes que nous observons :

Erreur 1 : ignorer les NetworkPolicies. Si votre cluster source a des NetworkPolicies (et il devrait en avoir), elles ne sont pas toujours exportees par les outils automatiques. Resultat : les pods communiquent librement sur le nouveau cluster, ce qui masque des problemes de connectivite qui apparaitront quand vous appliquerez les policies.

Erreur 2 : oublier les differences de StorageClass. Chaque provider a ses propres noms de StorageClass. Un PVC qui reference « gp3 » chez AWS ne fonctionnera pas chez OVHcloud qui utilise « csi-cinder-high-speed ». Utilisez des StorageClass abstraction layers ou mettez a jour vos manifests avant la migration.

Erreur 3 : ne pas tester les DNS internes. Les Services Kubernetes resolvent via CoreDNS a l'interieur du cluster. Si vos applications utilisent des noms de service hardcodes (type my-service.my-namespace.svc.cluster.local), verifiez que la resolution fonctionne sur le nouveau cluster. Un changement de version de CoreDNS ou une configuration differente peut casser la resolution.

Erreur 4 : migrer un vendredi. Ca semble evident, mais on le voit encore. Planifiez la bascule un mardi ou mercredi matin, quand toute l'equipe est disponible et qu'il reste 3 jours ouvres pour reagir en cas de probleme.

Outils recommandes pour la migration

Voici les outils open source que nous utilisons systematiquement pour les migrations Kubernetes en production :

Velero : sauvegarde et restauration de ressources Kubernetes et de volumes persistants. Indispensable pour l'audit initial et le plan de rollback. Supporte S3, GCS, Azure Blob et Swift comme backends de stockage.

kubectl-neat : nettoie les exports YAML de kubectl en supprimant les champs generes automatiquement (status, managedFields, annotations systeme). Essentiel pour obtenir des manifests propres et reutilisables sur le nouveau cluster.

kubectx / kubens : switch rapide entre clusters et namespaces. Quand vous travaillez en parallele sur deux clusters, une erreur de contexte kubectl peut avoir des consequences desastreuses. kubectx rend le switch explicite et visible.

k9s : interface TUI pour surveiller l'etat de vos clusters en temps reel. Indispensable pendant la phase de bascule pour monitorer les pods, les events, et les logs en direct.

Lens : si vous preferez une interface graphique, Lens permet de gerer plusieurs clusters simultanement avec une vue unifiee. Pratique pour comparer l'etat des workloads entre le cluster source et le cluster cible.