# 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. {% hint style="info" %} RKE2 est une distribution Kubernetes entièrement conforme qui se concentre sur la sécurité et la conformité, particulièrement conçue pour répondre aux exigences du gouvernement fédéral américain. Elle offre un renforcement de la sécurité amélioré et des opérations simplifiées par rapport à RKE. {% endhint %} ## 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 | Fonctionnalité | RKE | RKE2 (cegedim.cloud) | | --------------------------------- | ------------------------------ | -------------------------------------------------------- | | **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 1. **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 2. **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 3. **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 4. **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 5. **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 1. **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 2. **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 3. **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 4. **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 : * [ ] **Évaluation de l'Inventaire** : Documenter toutes les applications, services et dépendances exécutés dans votre cluster RKE * [ ] **Vérification de Version d'API** : Utiliser `kubent` pour identifier les versions d'API Kubernetes dépréciées * [ ] **Vérification de Sauvegarde** : S'assurer que toutes les données critiques ont des sauvegardes valides * [ ] **Exigences Réseau** : Identifier les politiques réseau, les règles de pare-feu et les exigences de connectivité * [ ] **Cartographie des Intégrations** : Lister tous les systèmes externes, services PaaS et pipelines CI/CD qui se connectent à votre cluster * [ ] **Plan de Tests** : Définir les cas de test et les critères de validation pour le nouveau cluster RKE2 * [ ] **Plan de Rollback** : Documenter les procédures de rollback en cas de problèmes de migration * [ ] **Plan de Communication** : Notifier les parties prenantes et les utilisateurs du calendrier de migration * [ ] **Tâches Post-Migration** : Créer une liste de vérification de toutes les tâches de reconfiguration requises après la migration ## 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](https://itcare.cegedim.cloud) 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](https://velero.io/docs/) - Outil de sauvegarde et restauration utilisé dans les migrations semi-automatisées * [Guide de Dépréciation d'API Kubernetes](https://kubernetes.io/docs/reference/using-api/deprecation-guide/) - Informations sur les changements de version d'API * [Documentation RKE2](https://docs.rke2.io/) - Documentation officielle RKE2 * [Bonnes Pratiques de Migration Kubernetes](https://kubernetes.io/docs/tasks/administer-cluster/migrating-from-dockershim/) - Conseils généraux de migration {% hint style="success" %} 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. {% endhint %} --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://academy.cegedim.cloud/francais/calcul/conteneurs-k8s/k8s-didacticiels/k8s-migration-rke-vers-rke2.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.