# 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 %}


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://academy.cegedim.cloud/compute/containers-k8s/k8s-get-started/k8s-migration-rke-to-rke2.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.