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.

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.

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 :

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

Last updated