Migration RKE vers RKE2
Vue d'ensemble
Alors que cegedim.cloud adopte RKE2 (Rancher Kubernetes Engine 2) comme distribution Kubernetes standard pour tous les clusters exécutant la version 1.31 et supérieure, les clients disposant de clusters existants basés sur RKE peuvent avoir besoin de migrer leurs charges de travail pour bénéficier d'une sécurité améliorée, de fonctionnalités de conformité et d'un support à long terme.
Ce guide décrit les stratégies de migration disponibles pour vous aider à effectuer la transition de RKE vers RKE2 avec un minimum de perturbations.
Pourquoi Migrer vers RKE2 ?
La migration de RKE vers RKE2 offre plusieurs avantages :
Sécurité Améliorée : RKE2 est construit avec la sécurité comme objectif principal, intégrant les normes CIS Kubernetes Benchmark par défaut
Conformité Améliorée : Répond aux exigences de conformité strictes (FIPS 140-2 disponible avec le CNI Canal)
Développement Actif : RKE2 reçoit des mises à jour continues et de nouvelles fonctionnalités, tandis que RKE est en mode maintenance
Meilleures Performances : Architecture optimisée pour améliorer les performances et la stabilité du cluster
Accès aux Dernières Versions de Kubernetes : Support pour Kubernetes 1.31 et au-delà
Options CNI Avancées : Support pour des fournisseurs CNI haute performance comme Cilium avec des capacités eBPF
Comparaison RKE vs RKE2
Support de Version Kubernetes
Jusqu'à 1.32
1.31 et supérieure
Renforcement de la Sécurité
Configuration manuelle requise
CIS Kubernetes Benchmark par défaut
Statut de Développement
Mode maintenance
Développement actif
Options CNI
Canal uniquement
Canal, Calico, Cilium
Conformité FIPS 140-2
Non disponible
Disponible avec CNI Canal
Réseau eBPF
Non disponible
Disponible avec CNI Cilium
Déploiement kube-proxy
Toujours déployé
Non déployé lors de l'utilisation de Cilium (eBPF natif)
Taille Maximale du Cluster
Jusqu'à 200 nœuds
Jusqu'à 2 000 nœuds (avec Calico ou Cilium)
Stratégies de Migration
cegedim.cloud propose deux approches de migration pour s'adapter aux différentes exigences des clients, capacités techniques et contraintes opérationnelles :
Stratégie 1 : Migration Autonome des Charges de Travail
Cette stratégie est recommandée pour les clients disposant :
D'une forte expertise Kubernetes
De pratiques d'infrastructure-as-code bien documentées
De flexibilité pour gérer leur propre calendrier de migration
D'un désir de contrôle complet sur le processus de migration
Aperçu du Processus
Préparation
Provisionner un nouveau cluster RKE2 via ITCare
Configurer le nouveau cluster avec les fournisseurs CNI et Ingress souhaités
Configurer la connectivité réseau entre les anciens et nouveaux clusters si nécessaire
Migration des Applications
Exporter les manifestes d'application, configurations et secrets depuis le cluster RKE
Examiner et mettre à jour toutes les versions d'API Kubernetes dépréciées (utiliser l'outil
kubent)Déployer les applications sur le nouveau cluster RKE2
Valider la fonctionnalité des applications dans le nouvel environnement
Migration des Données
Sauvegarder les volumes persistants depuis le cluster RKE
Restaurer les données vers les volumes persistants dans le cluster RKE2
Vérifier l'intégrité des données après la migration
Bascule du Trafic
Mettre à jour les enregistrements DNS pour pointer vers le nouveau cluster RKE2
Surveiller les performances des applications et les logs
Effectuer les procédures de rollback si des problèmes sont détectés
Décommissionnement
Une fois la migration validée, décommissionner l'ancien cluster RKE via ITCare
Avantages
Contrôle total sur le calendrier et l'approche de migration
Capacité à effectuer des migrations graduelles et par phases
Opportunité d'optimiser les configurations pendant la migration
Aucune dépendance vis-à-vis de la disponibilité de l'équipe de support
Considérations
Nécessite une connaissance approfondie de Kubernetes
Le client est responsable de toutes les activités de migration
Peut nécessiter plus de temps pour la planification et l'exécution
Stratégie 2 : Migration Semi-Automatisée avec Support IT
Cette stratégie est idéale pour les clients qui :
Préfèrent l'assistance de l'équipe de support IT de cegedim.cloud
Ont des charges de travail complexes nécessitant des conseils d'experts
Souhaitent tirer parti des outils d'automatisation pour une migration plus rapide
Ont besoin de support pour des environnements de production critiques
Aperçu du Processus
Demande de Migration
Soumettre un ticket de support via ITCare demandant une assistance pour la migration de RKE vers RKE2
Fournir des détails sur vos charges de travail, dépendances et préférences de calendrier de migration
Planifier une session de planification avec l'équipe de support
Exécution de Migration Automatisée
L'équipe IT de cegedim.cloud utilise Velero (outil de sauvegarde et restauration Kubernetes) et l'automatisation Ansible pour :
Créer des sauvegardes complètes de votre cluster RKE (y compris les charges de travail, configurations et volumes persistants)
Provisionner un nouveau cluster RKE2 avec des spécifications équivalentes
Restaurer les charges de travail sur le nouveau cluster RKE2
Migrer les données des volumes persistants
Tâches de Reconfiguration Client
Après la migration automatisée, les clients sont responsables de :
Mises à jour des Pipelines CI/CD : Mettre à jour vos pipelines CI/CD (Jenkins, GitLab CI, GitHub Actions, etc.) pour pointer vers le kubeconfig et les points d'accès API du nouveau cluster RKE2
Connexions PaaS Externes : Reconfigurer les connexions vers d'autres services PaaS cegedim.cloud :
Vault : Mettre à jour les configurations de la méthode d'authentification Kubernetes
Bases de données : Vérifier les chaînes de connexion et les politiques réseau
Stockage Objet : Mettre à jour les identifiants et points d'accès S3 si nécessaire
Outils de Surveillance : Reconfigurer les intégrations Prometheus, Grafana ou autres outils de surveillance
Intégrations Externes : Mettre à jour tous les services tiers ou systèmes externes qui se connectent à votre cluster
DNS et Load Balancers : Coordonner la bascule du trafic avec l'équipe IT
Tests et Validation : Effectuer des tests complets pour s'assurer que toutes les applications fonctionnent correctement
Support Post-Migration
L'équipe IT reste disponible pour résoudre tout problème pendant la période de stabilisation
Assistance pour l'optimisation et le réglage des performances si nécessaire
Avantages
Migration plus rapide avec des outils d'automatisation
Conseils d'experts de l'équipe IT cegedim.cloud
Risque réduit de perte de données avec la sauvegarde/restauration Velero
Support pour des scénarios complexes et le dépannage
Considérations
Nécessite une coordination avec le planning de l'équipe de support IT
Le client doit toujours gérer les reconfigurations spécifiques aux applications
Peut impliquer des coûts de support (consultez votre Service Delivery Manager)
Liste de Vérification pour la Planification de Migration
Quelle que soit la stratégie de migration que vous choisissez, utilisez cette liste de vérification pour assurer une transition en douceur :
Bonnes Pratiques
Avant la Migration
Tester d'abord en Non-Production : Toujours migrer les environnements de développement ou de staging avant la production
Documenter l'État Actuel : Prendre des notes détaillées sur la configuration actuelle de votre cluster RKE
Valider les Sauvegardes : Tester les procédures de restauration de sauvegarde avant de commencer la migration
Réviser les Quotas de Ressources : S'assurer que le nouveau cluster RKE2 dispose de ressources adéquates
Pendant la Migration
Minimiser les Changements : Éviter de faire des modifications de configuration au cluster RKE pendant la migration
Surveiller les Deux Clusters : Garder un œil attentif sur les anciens et nouveaux clusters pendant la bascule
Maintenir la Communication : Tenir les parties prenantes informées de l'avancement de la migration
Documenter les Problèmes : Enregistrer tous les problèmes rencontrés pour référence future
Après la Migration
Surveillance des Performances : Surveiller les performances des applications pendant au moins 48 heures après la migration
Analyse des Logs : Examiner les logs pour détecter toute erreur ou avertissement
Nettoyage : Décommissionner l'ancien cluster RKE uniquement après avoir confirmé que le nouveau cluster est stable
Mise à Jour de la Documentation : Mettre à jour toute la documentation pour refléter les détails du nouveau cluster RKE2
Obtenir de l'Aide
Si vous avez besoin d'assistance pour votre migration de RKE vers RKE2 :
Pour la Planification de Migration : Contactez votre Service Delivery Manager pour discuter de la meilleure approche pour votre cas d'usage
Pour le Support Technique : Soumettez un ticket via ITCare avec le sujet "Demande de Migration RKE vers RKE2"
Pour les Problèmes d'Urgence : Soumettez un ticket ITCare si vous rencontrez des problèmes critiques pendant la migration
Ressources Supplémentaires
Documentation Velero - Outil de sauvegarde et restauration utilisé dans les migrations semi-automatisées
Guide de Dépréciation d'API Kubernetes - Informations sur les changements de version d'API
Documentation RKE2 - Documentation officielle RKE2
Bonnes Pratiques de Migration Kubernetes - Conseils généraux de migration
Les migrations réussies nécessitent une planification et une exécution minutieuses. N'hésitez pas à contacter l'équipe de support cegedim.cloud pour obtenir des conseils à n'importe quelle étape de votre parcours de migration.
Last updated

