Migrer d'OpenShift 3 vers OpenShift 4 : la méthode étape par étape

Passer d'OpenShift 3.11 à OpenShift 4 n'est pas une simple mise à jour. C'est une migration vers une nouvelle plateforme. J'ai accompagné ce type de transition dans un contexte d'entreprise soumis à des exigences de conformité : voici la méthode que j'applique pour limiter les risques et les interruptions.

Pourquoi on ne « met pas à jour » d'OpenShift 3 vers 4

OpenShift 4 a été repensé en profondeur. Le cluster est piloté par des Operators, les nœuds tournent sous Red Hat Enterprise Linux CoreOS et la plateforme se met à jour via le Cluster Version Operator. L'installation, la configuration de l'authentification, le monitoring et la journalisation ne fonctionnent plus de la même façon qu'en 3.x.

Conséquence : il n'existe pas de chemin de mise à jour en place. On construit un nouveau cluster OpenShift 4, puis on y déplace les applications.

Étape 1 — Inventorier l'existant

Une migration réussie commence par une cartographie précise :

• les namespaces, leurs propriétaires et leur criticité ;
• les workloads stateless et stateful, avec leurs volumes persistants et classes de stockage ;
• les DeploymentConfigs, BuildConfigs, ImageStreams et templates utilisés ;
• les dépendances externes : bases de données, DNS, certificats, pare-feu, intégrations ;
• les quotas, les droits RBAC et les éventuelles Security Context Constraints personnalisées.

Cet inventaire sert à regrouper les applications en vagues de migration, des moins critiques aux plus sensibles.

Étape 2 — Construire le cluster cible comme du code

Le nouveau cluster doit être reproductible dès le premier jour. Je décris l'infrastructure avec Terraform, la configuration avec Ansible, et la configuration du cluster (authentification LDAP, RBAC, quotas, NetworkPolicies, monitoring) avec OpenShift GitOps (Argo CD). Si le cluster doit être reconstruit, tout est dans Git.

Points à trancher à ce stade : le dimensionnement, le stockage via des drivers CSI, le réseau (OVN-Kubernetes est le plugin par défaut des versions récentes) et la stratégie d'exposition (Routes, Ingress Controllers, certificats).

Étape 3 — Préparer les applications

La migration est le bon moment pour moderniser :

• remplacer progressivement les DeploymentConfigs par des Deployments Kubernetes standards ;
• retirer les API dépréciées des manifestes ;
• externaliser la configuration dans des ConfigMaps et des Secrets ;
• remplacer l'isolation du mode « multitenant » d'OpenShift SDN par des NetworkPolicies explicites.

Étape 4 — Redéployer plutôt que copier, quand c'est possible

Pour les applications stateless dont les manifestes sont dans Git, le plus propre est souvent de les redéployer sur le nouveau cluster via la chaîne CI/CD ou Argo CD, plutôt que de copier des objets hérités. On repart d'une base saine et versionnée.

Pour les applications stateful, Red Hat fournit le Migration Toolkit for Containers (MTC). Il migre les ressources d'un namespace et les données des volumes persistants d'un cluster source vers un cluster cible, en passant par un dépôt de réplication de type stockage objet.

Étape 5 — Migrer par vagues, avec un pilote

Je commence toujours par un namespace pilote non critique pour valider toute la chaîne : droits, réseau, stockage, DNS, certificats et supervision. Ensuite, chaque vague suit le même déroulé :

1. Migration « stage » : copie des données pendant que l'application tourne encore sur la source, pour réduire la durée de la bascule ;
2. Fenêtre de bascule : arrêt de l'application source, dernière synchronisation, démarrage sur la cible ;
3. Bascule DNS vers les nouvelles routes ;
4. Validation fonctionnelle avec les équipes applicatives.

Étape 6 — Valider, observer, garder un plan de retour

Après chaque bascule, je surveille les Golden Signals (latence, trafic, erreurs, saturation) dans Prometheus et Grafana. L'ancien cluster reste disponible tant que la vague n'est pas validée : en cas de problème, le retour arrière se résume souvent à rebasculer le DNS.

Étape 7 — Décommissionner proprement

Une fois toutes les vagues validées : archivage des configurations, révocation des accès et des certificats de l'ancien cluster, mise à jour de la documentation et des runbooks, puis arrêt de la plateforme 3.x.

En résumé

• OpenShift 4 est une nouvelle plateforme : on migre, on ne met pas à jour.
• Inventaire et vagues de migration d'abord, outils ensuite.
• Cluster cible construit comme du code avec Terraform, Ansible et Argo CD.
• Redéploiement GitOps pour le stateless, MTC pour le stateful.
• Pilote, migration stage, bascule courte, observabilité et plan de retour.

Vous préparez une migration OpenShift ? Découvrez mon accompagnement ou écrivez-moi.