# Migration RKE to RKE2

## Overview <a href="#k8smigration-overview" id="k8smigration-overview"></a>

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.

{% hint style="info" %}
RKE2 is a fully conformant Kubernetes distribution that focuses on security and compliance, particularly designed to meet U.S. Federal Government requirements. It provides improved security hardening and simplified operations compared to RKE.
{% endhint %}

## Why Migrate to RKE2? <a href="#k8smigration-whymigrate" id="k8smigration-whymigrate"></a>

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

| Feature                        | RKE                           | RKE2 (cegedim.cloud)                         |
| ------------------------------ | ----------------------------- | -------------------------------------------- |
| **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 <a href="#k8smigration-strategies" id="k8smigration-strategies"></a>

**cegedim.cloud** offers two migration approaches to accommodate different customer requirements, technical capabilities, and operational constraints:

### Strategy 1: Autonomous Workload Migration <a href="#k8smigration-autonomousmigration" id="k8smigration-autonomousmigration"></a>

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

1. **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
2. **Application Migration**
   * Export application manifests, configurations, and secrets from the RKE cluster
   * Review and update any deprecated Kubernetes API versions (use `kubent` tool)
   * Deploy applications to the new RKE2 cluster
   * Validate application functionality in the new environment
3. **Data Migration**
   * Back up persistent volumes from the RKE cluster
   * Restore data to persistent volumes in the RKE2 cluster
   * Verify data integrity after migration
4. **Traffic Cutover**
   * Update DNS records to point to the new RKE2 cluster
   * Monitor application performance and logs
   * Perform rollback procedures if issues are detected
5. **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 <a href="#k8smigration-semiautomatedmigration" id="k8smigration-semiautomatedmigration"></a>

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

1. **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
2. **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
3. **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
4. **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 <a href="#k8smigration-checklist" id="k8smigration-checklist"></a>

Regardless of the migration strategy you choose, use this checklist to ensure a smooth transition:

* [ ] **Inventory Assessment**: Document all applications, services, and dependencies running in your RKE cluster
* [ ] **API Version Check**: Use `kubent` to identify deprecated Kubernetes API versions
* [ ] **Backup Verification**: Ensure all critical data has valid backups
* [ ] **Network Requirements**: Identify network policies, firewall rules, and connectivity requirements
* [ ] **Integration Mapping**: List all external systems, PaaS services, and CI/CD pipelines that connect to your cluster
* [ ] **Testing Plan**: Define test cases and validation criteria for the new RKE2 cluster
* [ ] **Rollback Plan**: Document rollback procedures in case of migration issues
* [ ] **Communication Plan**: Notify stakeholders and users of the migration schedule
* [ ] **Post-Migration Tasks**: Create a checklist of all reconfiguration tasks required after migration

## Best Practices <a href="#k8smigration-bestpractices" id="k8smigration-bestpractices"></a>

### 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 <a href="#k8smigration-gettinghelp" id="k8smigration-gettinghelp"></a>

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](https://itcare.cegedim.cloud) with the subject "RKE to RKE2 Migration Request"
* **For Emergency Issues**: Submit an ITCare ticket if you encounter critical problems during migration

## Additional Resources <a href="#k8smigration-resources" id="k8smigration-resources"></a>

* [Velero Documentation](https://velero.io/docs/) - Backup and restore tool used in semi-automated migrations
* [Kubernetes API Deprecation Guide](https://kubernetes.io/docs/reference/using-api/deprecation-guide/) - Information about API version changes
* [RKE2 Documentation](https://docs.rke2.io/) - Official RKE2 documentation
* [Kubernetes Migration Best Practices](https://kubernetes.io/docs/tasks/administer-cluster/migrating-from-dockershim/) - General migration guidance

{% hint style="success" %}
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.
{% endhint %}