RKE End of Life by July 2025 – Replatform to RKE2 or K3S
SUSE annonce la fin de vie de KRE ou RKE1. Les sur RKE1 devront migrer sur RKE2. Lancé le 25 janvier 2018, RKE a accompagné de nombreuses équipes durant six ans, marqués par 625 versions.…

SUSE annonce la fin de vie de KRE ou RKE1. Les sur RKE1 devront migrer sur RKE2.
Lancé le 25 janvier 2018, RKE a accompagné de nombreuses équipes durant six ans, marqués par 625 versions. Aujourd'hui, nous entamons le dernier chapitre de l'aventure RKE, et pour beaucoup, une nouvelle page s'ouvre avec RKE2 et K3S.
Bien que RKE ait été une solution fiable, l'évolution des environnements d'orchestration de conteneurs exige désormais une sécurité accrue, une meilleure scalabilité et plus de simplicité.
Pourquoi migrer vers RKE2 ?
RKE repose sur Docker, un runtime conteneur qui n'est plus maintenu. Dès la version 1.24 de Kubernetes, le projet a supprimé Dockershim. RKE2 adopte donc containerd, un runtime largement utilisé dans les distributions Kubernetes, garantissant un environnement plus sécurisé et performant. Ce changement renforce non seulement la stabilité de vos charges de travail en conteneurs, mais s'aligne aussi sur les dernières normes du secteur.
Avantages de RKE2 par rapport à RKE
- Architecture moderne : RKE2 abandonne Docker au profit de containerd, assurant un environnement plus sûr et optimisé.
- Sécurité renforcée : Conçu avec la sécurité au cœur, RKE2 propose des configurations par défaut permettant de passer les benchmarks CIS Kubernetes avec peu d'interventions.
- Conformité : RKE2 est conforme à la norme FIPS 140-2 et minimise les vulnérabilités (CVE) grâce à une analyse approfondie avec Trivy durant le processus de construction.
- Évolutivité : Combinant les points forts de RKE et K3S, RKE2 fournit une plateforme robuste et évolutive adaptée aux exigences modernes.
Comment migrer de RKE à RKE2
Pour migrer vers RKE2, commencez par revoir les besoins de votre plateforme et son architecture, en tenant compte de la scalabilité, de la sécurité et de l’automatisation. Il est essentiel de redéployer les charges de travail de vos clusters RKE vers les clusters RKE2, car la migration "in-place" n’est pas possible.
Voici les grandes étapes de la migration :
- Évaluez et documentez vos clusters RKE et les charges de travail en cours, en identifiant si elles sont sans état (stateless) ou avec état (stateful).
- Déployez le(s) cluster(s) RKE2 et configurez les connexions nécessaires, telles que l'ingress ou le load balancer.
- Migrez les charges de travail du cluster RKE vers RKE2, en prévoyant les étapes de retour arrière pour assurer une transition fluide.
Cette vue d’ensemble est un résumé des grandes étapes ; des ressources plus détaillées sont disponibles pour vous aider dans cette transition.
Restez à l'écoute pour plus de mises à jour et de guides détaillés sur le processus de transition. Merci de faire partie de notre communauté, et nous sommes impatients de poursuivre ce voyage ensemble avec RKE2 et K3S.
Source: https://www.suse.com/c/rke-end-of-life-by-july-2025-replatform-to-rke2-or-k3s/
N'hésitez pas à laisser des commentaires si vous avez des questions ou des suggestions !
Commentaires
Aucun commentaire pour le moment.