Migration RKE1 vers RKE2 : enjeux et solutions

La migration de RKE1 (Rancher Kubernetes Engine 1) vers RKE2 représente une étape majeure pour les entreprises exploitant des clusters Kubernetes gérés par Rancher. RKE1, historiquement utilisé pour le provisionnement et la gestion des clusters Kubernetes on-premise, repose sur une architecture monolithique et utilise Docker comme runtime de conteneurs, désormais déprécié par Kubernetes. Sa fin de support officielle, en juillet 2025 (et en février 2026 pour sa dernière version de Kubernetes supportée) après 7 ans de bons et loyaux services, impose une transition vers RKE2, une distribution Kubernetes nouvelle génération, conçue pour répondre aux exigences modernes de sécurité, scalabilité et conformité.

RKE2, fondé sur K3s, adopte une architecture immutable, un agent léger, et des mécanismes de mise à jour automatisés, tout en intégrant nativement des standards de sécurité avancés (CIS Kubernetes Benchmark, FIPS 140-2). Cette migration n'est pas une simple mise à jour, mais une transformation profonde qui impacte les workflows DevOps, la gestion des workloads et nécessite de "re-plateformer", c'est à dire créer un nouveau cluster Kubernetes et migrer.

Ce guide s'adresse aux équipes DevOps, SRE et administrateurs système qui n'ont pas encore migré leurs clusters Rancher de RKE1 vers RKE2. Il vise à éclairer les enjeux techniques et stratégiques de cette migration, tout en fournissant une feuille de route détaillée, des exemples concrets, des snippets de code, et des liens vers la documentation officielle. L'objectif est de permettre une migration réussie, minimisant les risques et assurant la continuité des services.

Comprendre les différences clés entre RKE1 et RKE2

Architecture et runtime de conteneurs

RKE1 utilise Docker pour déployer et gérer les composants du plan de contrôle (Control Plane) ainsi que le runtime des conteneurs Kubernetes. Cette dépendance à Docker est devenue un frein, car Kubernetes a abandonné Docker comme runtime officiel au profit de containerd. RKE2, quant à lui, adopte containerd, offrant une meilleure sécurité, une gestion plus efficace des ressources, et la possibilité de miroir de registres de conteneurs, ce qui facilite la gestion des images dans des environnements air-gapped ou sécurisés.

Gestion des composants du plan de contrôle (Control Plane)

RKE1 déploie les composants du Control Plane (Kubelet, Kube-proxy, Api Kube, ...) via Docker, tandis que RKE2 les lance en tant que static pods gérés par le kubelet. Cette différence impacte la gestion des mises à jour et la stabilité des clusters. RKE2 bénéficie d'un mécanisme de rolling updates automatisé, réduisant les temps d'indisponibilité et simplifiant la maintenance.

Cluster API (CAPI) et terminologie

RKE2 est construit sur le framework Cluster API (CAPI), ce qui peut entraîner des comportements différents, notamment le reprovisionnement des nœuds lors de modifications de la configuration du cluster. Cette approche favorise une gestion plus dynamique et déclarative des clusters, alignée avec les pratiques cloud-native. La terminologie évolue également : par exemple, les « node templates » de RKE1 deviennent des « machine pools » dans RKE2.

Plugins CNI et réseau

RKE1 supportait plusieurs plugins CNI (Canal, Flannel, Calico, Weave), tandis que RKE2 propose une intégration native avec Calico, Cilium, et Multus, offrant des capacités réseau avancées, notamment la gestion de multiples interfaces réseau par pod, essentielle pour les cas d'usage télécoms ou edge computing.

Sécurité et conformité

RKE2 est conçu pour répondre aux exigences de sécurité les plus strictes, notamment la conformité FIPS 140-2, le support SELinux, et la conformité aux benchmarks CIS Kubernetes. Il intègre également un scanner de vulnérabilités (Trivy) dans le pipeline de build, réduisant les risques liés aux CVEs. Ces caractéristiques font de RKE2 une plateforme adaptée aux environnements réglementés (gouvernement, finance, santé).

Intégration avec Rancher

RKE1 était intégré à Rancher via une méthode open source non standardisée, tandis que RKE2 utilise Cluster API, facilitant une meilleure intégration, une gestion plus automatisée, et une observabilité améliorée dans Rancher 2.6+.

Support des workloads Windows

RKE1 utilisait des taints et tolérations pour gérer les nœuds Windows, alors que RKE2 utilise des sélecteurs de nœuds par défaut, simplifiant la gestion des workloads hybrides (Linux et Windows).

Prérequis et préparation à la migration

Audit de l'existant

Avant toute migration, un audit complet des clusters RKE1 est indispensable. Cela inclut :

• Inventaire des clusters : nombre de nœuds, rôles, versions Kubernetes, workloads critiques, dépendances (storage classes, ingress controllers, CRDs).
• Compatibilité des applications : vérifier les APIs dépréciées via kubectl api-resources ou des outils comme Pluralith.
• Sauvegardes : sauvegarder etcd, les volumes persistants, et les configurations Rancher avec des outils comme Velero ou Restic.
• Dépendances externes : identifier les intégrations avec des solutions de monitoring (Prometheus, Grafana), CI/CD (ArgoCD, Flux), ou stockage (Longhorn, Rook).

Environnement de test

Il est recommandé de créer un cluster RKE2 miroir pour valider la migration :

• Stratégie de replica : déployer un cluster RKE2 parallèle pour tester la compatibilité et la performance.
• Outils de validation : utiliser sonobuoy ou kube-bench pour tester la conformité et la stabilité du nouveau cluster.

Planification des ressources

• Temps estimé : la migration peut prendre de quelques heures à plusieurs jours selon la taille et la complexité du cluster.
• Équipe nécessaire : administrateurs Kubernetes, experts réseau, responsables sécurité.
• Fenêtre de maintenance : choisir une période de faible activité pour minimiser l'impact.

Chemins de migration possibles

Stratégies de migration

Méthodes de migration

• Export/Import YAML : export des ressources via kubectl get all --all-namespaces -o yaml > backup.yaml puis application dans le nouveau cluster. Adapté aux workloads sans état (stateless), mais ne migre pas les volumes persistants.
• DR-Syncer: outil de réplication des déploiements, services, ConfigMaps, secrets et volumes persistants entre clusters, minimisant les temps d'arrêt.
• Outils de backup/restauration : Velero, CloudCasa, permettant de sauvegarder et restaurer l'ensemble des workloads y compris les volumes persistants, avec support du stockage objet (S3, MinIO).
• Redeploy (GitOps) : mise à jour du cluster cible via pipelines CI/CD et outils GitOps (ArgoCD, Flux) pour une gestion déclarative et automatisée.

Problèmes courants et dépannage

Problèmes de services critiques manquants

• Symptômes : applications en échec faute de dépendances (cert-manager, Prometheus, ArgoCD).
• Solution : déployer les services cluster-wide avant la migration des workloads.

Problèmes de ressources cluster-scoped manquantes

• Symptômes : échecs liés à des ClusterRoles, RoleBindings ou CRDs manquants.
• Solution : exporter et appliquer les CRDs avant la migration, vérifier les règles RBAC.

Problèmes de secrets non stockés externement

• Symptômes : applications plantant à cause de secrets perdus.
• Solution : externaliser les secrets via Vault, AWS Secrets Manager, ou Kubernetes External Secrets.

Problèmes de compatibilité des versions d'API

• Symptômes : incompatibilités entre versions d'API des ressources.
• Solution : utiliser des outils comme CloudCasa pour transformer les ressources, vérifier la compatibilité.

Problèmes de connectivité réseau

• Symptômes : problèmes de communication entre pods ou nœuds.
• Solution : vérifier les configurations réseau, mettre à jour les politiques réseau, tester avec kubectl get networkpolicy -A.

Problèmes de capacité des nœuds

• Symptômes : nœuds surchargés ou insuffisants.
• Solution : vérifier la capacité des nœuds avec kubectl get nodes, ajuster la configuration.

Problèmes de restauration des volumes persistants

• Symptômes : échecs lors de la restauration des volumes persistants.
• Solution : vérifier la compatibilité des classes de stockage, utiliser le mappage des classes de stockage.

Problèmes de compatibilité des ressources personnalisées

• Symptômes : échecs liés à des différences dans les CRDs.
• Solution : vérifier les CRDs installés, installer les contrôleurs requis, envisager une migration progressive.

Problèmes de DNS et de découverte de service

• Symptômes : applications ne communiquant pas après migration.
• Solution : vérifier la configuration CoreDNS, les points de terminaison des services, mettre à jour les configurations DNS et load balancers.

Post-migration et optimisation

• Validation : effectuer des tests de charge (k6, locust), vérifier les SLOs, valider les services avec les équipes applicatives.
• Optimisation : activer les features optionnelles, configurer les autoscalers, intégrer les outils Rancher pour la maintenance continue.
• Maintenance : utiliser system-upgrade-controller pour les mises à jour automatisées, intégrer les outils de backup et monitoring.

Conclusion

La migration de RKE1 vers RKE2 est une étape incontournable pour les entreprises souhaitant maintenir un environnement Kubernetes sécurisé, performant et conforme aux standards modernes. Cette migration, bien que complexe, peut être réussie grâce à une planification rigoureuse, une compréhension approfondie des différences entre RKE1 et RKE2, et l'utilisation d'outils adaptés.

Les équipes DevOps, SRE et administrateurs système doivent s'appuyer sur les meilleures pratiques exposées dans ce guide, en adaptant les stratégies de migration aux spécificités de leur environnement, et en anticipant les problèmes courants pour garantir une transition fluide.

En migrant vers RKE2, les entreprises bénéficieront d'une plateforme Kubernetes plus robuste, sécurisée, scalable et intégrée à Rancher, répondant aux exigences croissantes des architectures cloud-native modernes.

Tableau comparatif synthétique des différences RKE1 vs RKE2