Migration RKE to RKE2
Overview
As cegedim.cloud transitions to RKE2 (Rancher Kubernetes Engine 2) as the standard Kubernetes distribution for all clusters running version 1.31 and above, customers with existing RKE-based clusters may need to migrate their workloads to benefit from enhanced security, compliance features, and long-term support.
This guide outlines the available migration strategies to help you transition from RKE to RKE2 with minimal disruption.
Why Migrate to RKE2?
Migrating from RKE to RKE2 offers several benefits:
Enhanced Security: RKE2 is built with security as a primary focus, incorporating CIS Kubernetes Benchmark standards by default
Improved Compliance: Meets stringent compliance requirements (FIPS 140-2 available with Canal CNI)
Active Development: RKE2 receives ongoing updates and new features, while RKE is in maintenance mode
Better Performance: Optimized architecture for improved cluster performance and stability
Access to Latest Kubernetes Versions: Support for Kubernetes 1.31 and beyond
Advanced CNI Options: Support for high-performance CNI providers like Cilium with eBPF capabilities
RKE vs RKE2 Comparison
Kubernetes Version Support
Up to 1.32
1.31 and above
Security Hardening
Manual configuration required
CIS Kubernetes Benchmark by default
Development Status
Maintenance mode
Active development
CNI Options
Canal only
Canal, Calico, Cilium
FIPS 140-2 Compliance
Not available
Available with Canal CNI
eBPF Networking
Not available
Available with Cilium CNI
kube-proxy Deployment
Always deployed
Not deployed when using Cilium (eBPF native)
Maximum Cluster Size
Up to 200 nodes
Up to 2,000 nodes (with Calico or Cilium)
Migration Strategies
cegedim.cloud offers two migration approaches to accommodate different customer requirements, technical capabilities, and operational constraints:
Strategy 1: Autonomous Workload Migration
This strategy is recommended for customers with:
Strong Kubernetes expertise
Well-documented infrastructure-as-code practices
Flexibility to manage their own migration timeline
Desire for complete control over the migration process
Process Overview
Preparation
Provision a new RKE2 cluster through ITCare
Configure the new cluster with desired CNI and Ingress providers
Set up network connectivity between old and new clusters if needed
Application Migration
Export application manifests, configurations, and secrets from the RKE cluster
Review and update any deprecated Kubernetes API versions (use
kubenttool)Deploy applications to the new RKE2 cluster
Validate application functionality in the new environment
Data Migration
Back up persistent volumes from the RKE cluster
Restore data to persistent volumes in the RKE2 cluster
Verify data integrity after migration
Traffic Cutover
Update DNS records to point to the new RKE2 cluster
Monitor application performance and logs
Perform rollback procedures if issues are detected
Decommissioning
Once the migration is validated, decommission the old RKE cluster through ITCare
Advantages
Full control over migration timing and approach
Ability to perform gradual, phased migrations
Opportunity to optimize configurations during migration
No dependency on support team availability
Considerations
Requires in-depth Kubernetes knowledge
Customer is responsible for all migration activities
May require more time for planning and execution
Strategy 2: Semi-Automated Migration with IT Support
This strategy is ideal for customers who:
Prefer assistance from cegedim.cloud IT support team
Have complex workloads requiring expert guidance
Want to leverage automation tools for faster migration
Need support for critical production environments
Process Overview
Migration Request
Submit a support ticket through ITCare requesting RKE to RKE2 migration assistance
Provide details about your workloads, dependencies, and migration timeline preferences
Schedule a planning session with the support team
Automated Migration Execution
cegedim.cloud IT team uses Velero (Kubernetes backup and restore tool) and Ansible automation to:
Create comprehensive backups of your RKE cluster (including workloads, configurations, and persistent volumes)
Provision a new RKE2 cluster with equivalent specifications
Restore workloads to the new RKE2 cluster
Migrate persistent volume data
Customer Reconfiguration Tasks
After the automated migration, customers are responsible for:
CI/CD Pipeline Updates: Update your CI/CD pipelines (Jenkins, GitLab CI, GitHub Actions, etc.) to point to the new RKE2 cluster's kubeconfig and API endpoints
External PaaS Connections: Reconfigure connections to other cegedim.cloud PaaS services:
Vault: Update Kubernetes auth method configurations
Databases: Verify connection strings and network policies
Object Storage: Update S3 credentials and endpoints if needed
Monitoring Tools: Reconfigure Prometheus, Grafana, or other monitoring integrations
External Integrations: Update any third-party services or external systems that connect to your cluster
DNS and Load Balancers: Coordinate traffic cutover with the IT team
Testing and Validation: Perform comprehensive testing to ensure all applications function correctly
Post-Migration Support
The IT team remains available to troubleshoot any issues during the stabilization period
Assistance with performance tuning and optimization if needed
Advantages
Faster migration with automation tools
Expert guidance from cegedim.cloud IT team
Reduced risk of data loss with Velero backup/restore
Support for complex scenarios and troubleshooting
Considerations
Requires coordination with IT support team schedule
Customer must still handle application-specific reconfigurations
May involve support costs (consult your Service Delivery Manager)
Migration Planning Checklist
Regardless of the migration strategy you choose, use this checklist to ensure a smooth transition:
Best Practices
Before Migration
Test in Non-Production First: Always migrate development or staging environments before production
Document Current State: Take detailed notes about your current RKE cluster configuration
Validate Backups: Test backup restoration procedures before starting migration
Review Resource Quotas: Ensure the new RKE2 cluster has adequate resources
During Migration
Minimize Changes: Avoid making configuration changes to the RKE cluster during migration
Monitor Both Clusters: Keep close watch on both old and new clusters during cutover
Maintain Communication: Keep stakeholders informed of migration progress
Document Issues: Record any problems encountered for future reference
After Migration
Performance Monitoring: Monitor application performance for at least 48 hours after migration
Log Analysis: Review logs for any errors or warnings
Cleanup: Decommission the old RKE cluster only after confirming the new cluster is stable
Documentation Update: Update all documentation to reflect the new RKE2 cluster details
Getting Help
If you need assistance with your RKE to RKE2 migration:
For Migration Planning: Contact your Service Delivery Manager to discuss the best approach for your use case
For Technical Support: Submit a ticket through ITCare with the subject "RKE to RKE2 Migration Request"
For Emergency Issues: Submit an ITCare ticket if you encounter critical problems during migration
Additional Resources
Velero Documentation - Backup and restore tool used in semi-automated migrations
Kubernetes API Deprecation Guide - Information about API version changes
RKE2 Documentation - Official RKE2 documentation
Kubernetes Migration Best Practices - General migration guidance
Successful migrations require careful planning and execution. Don't hesitate to reach out to the cegedim.cloud support team for guidance at any stage of your migration journey.
Last updated