Skip to content

Commit 1d5ae01

Browse files
mattmattoxmattmattox
committed
Update RKE1 to RKE2 migration guide to align with presentation slides and add detailed migration methods
1 parent 04489fa commit 1d5ae01

7 files changed

+2233
-0
lines changed

‎blog/content/post/migrating-rke1-to-rke2-cloudcasa.md‎

Lines changed: 212 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,212 @@
1+
---
2+
title: "Migrating from RKE1 to RKE2 Using CloudCasa: A Backup and Restore Approach"
3+
date: 2025-03-13T01:42:00-05:00
4+
draft: false
5+
tags: ["Kubernetes", "RKE1", "RKE2", "Migration", "CloudCasa", "Backup", "Restore"]
6+
categories:
7+
- Kubernetes
8+
- Migration
9+
- Backup & Recovery
10+
author: "Matthew Mattox - mmattox@support.tools"
11+
description: "A comprehensive guide to migrating workloads from RKE1 to RKE2 using CloudCasa's backup and restore functionality, with step-by-step instructions and best practices."
12+
more_link: "yes"
13+
url: "/migrating-rke1-to-rke2-cloudcasa/"
14+
---
15+
16+
With RKE1 reaching end-of-life on July 31, 2025, organizations need reliable strategies to migrate their workloads to RKE2. CloudCasa offers a powerful backup and restore approach for this migration, providing a comprehensive solution that handles both stateless and stateful workloads.
17+
18+
<!--more-->
19+
20+
## Why Use CloudCasa for RKE1 to RKE2 Migration?
21+
22+
When migrating between Kubernetes distributions like RKE1 and RKE2, using a specialized Kubernetes backup and restore solution offers significant advantages:
23+
24+
- **Comprehensive Resource Coverage:** CloudCasa backs up all Kubernetes resources, including ConfigMaps, Secrets, and CRDs.
25+
- **Persistent Volume Migration:** Seamlessly transfers PVs between clusters with data integrity.
26+
- **Cross-Distribution Compatibility:** Designed to work across different Kubernetes distributions, making it ideal for RKE1 to RKE2 transitions.
27+
- **Minimal Downtime:** Efficient backup and restore processes reduce application unavailability.
28+
- **Multi-Cloud Support:** Works with clusters running in any environment (on-premises, AWS, Azure, GCP).
29+
30+
## Prerequisites for Migration
31+
32+
Before starting the migration process, ensure you have:
33+
34+
1. **CloudCasa Account:** Sign up at [CloudCasa](https://cloudcasa.io) and set up your account.
35+
2. **Cluster Access:** `kubectl` access to both your source RKE1 and destination RKE2 clusters.
36+
3. **RKE2 Cluster Ready:** A functioning RKE2 cluster with sufficient resources to host your workloads.
37+
4. **Storage Classes:** Equivalent storage classes configured in your RKE2 cluster for PV restoration.
38+
5. **Network Connectivity:** Ensure CloudCasa can access both clusters for backup and restore operations.
39+
40+
## Step-by-Step Migration Process
41+
42+
### 1. Set Up CloudCasa on Your RKE1 Cluster
43+
44+
First, install the CloudCasa agent on your source RKE1 cluster:
45+
46+
```bash
47+
# Create the CloudCasa namespace
48+
kubectl create namespace cloudcasa-io
49+
50+
# Add the CloudCasa Helm repository
51+
helm repo add cloudcasa-repo https://cloudcasa-io.github.io/cloudcasa-helm
52+
53+
# Update your Helm repositories
54+
helm repo update
55+
56+
# Install the CloudCasa agent
57+
helm install cloudcasa cloudcasa-repo/cloudcasa-agent \
58+
--namespace cloudcasa-io \
59+
--set cluster_id=YOUR_CLUSTER_ID
60+
```
61+
62+
Replace `YOUR_CLUSTER_ID` with the cluster ID provided in your CloudCasa dashboard after registering your cluster.
63+
64+
### 2. Configure Backup Settings
65+
66+
In the CloudCasa web console:
67+
68+
1. Navigate to "Protection Policies" and create a new policy.
69+
2. Select all relevant namespaces containing your workloads.
70+
3. Enable PV snapshots if you have stateful applications.
71+
4. Choose backup frequency (for migration purposes, a one-time backup is often sufficient).
72+
5. Save your policy.
73+
74+
### 3. Run a Full Cluster Backup
75+
76+
1. Navigate to "Protection" > "On-demand Backup" in the CloudCasa dashboard.
77+
2. Select your RKE1 cluster.
78+
3. Choose "Full Cluster" backup type.
79+
4. Select the namespaces you want to migrate.
80+
5. Enable "Include Persistent Volumes" option.
81+
6. Start the backup process and wait for completion.
82+
83+
### 4. Prepare Your RKE2 Cluster
84+
85+
Before restoring, verify your RKE2 cluster is ready:
86+
87+
```bash
88+
# Verify RKE2 cluster is accessible
89+
kubectl get nodes
90+
91+
# Check storage classes for PV restoration
92+
kubectl get storageclass
93+
94+
# Install the CloudCasa agent on RKE2 cluster
95+
kubectl create namespace cloudcasa-io
96+
97+
helm install cloudcasa cloudcasa-repo/cloudcasa-agent \
98+
--namespace cloudcasa-io \
99+
--set cluster_id=YOUR_RKE2_CLUSTER_ID
100+
```
101+
102+
### 5. Restore Your Workloads to the RKE2 Cluster
103+
104+
From the CloudCasa dashboard:
105+
106+
1. Navigate to "Recovery" > "Kubernetes Restore".
107+
2. Select the backup of your RKE1 cluster.
108+
3. Choose "Restore to a different cluster" option.
109+
4. Select your RKE2 cluster as the destination.
110+
5. Configure restore options:
111+
- Select namespaces to restore
112+
- Choose "Include Persistent Volumes"
113+
- Configure storage class mapping if storage classes differ between clusters
114+
- Set conflict resolution policy (typically "Replace existing resources")
115+
6. Start the restore process.
116+
117+
### 6. Validate the Migration
118+
119+
After the restore completes, verify your applications are functioning correctly:
120+
121+
```bash
122+
# Check all pods are running
123+
kubectl get pods -A
124+
125+
# Verify services are available
126+
kubectl get svc -A
127+
128+
# Test application functionality
129+
# (Application-specific tests)
130+
131+
# Verify PV/PVC status
132+
kubectl get pv,pvc -A
133+
```
134+
135+
## Advanced Configuration Options
136+
137+
### Storage Class Mapping
138+
139+
If your RKE1 and RKE2 clusters use different storage class names, configure mapping during restore:
140+
141+
1. In the restore wizard, expand "Advanced Options".
142+
2. Under "Storage Class Mapping," map your RKE1 storage classes to equivalent RKE2 storage classes.
143+
144+
### Resource Filtering
145+
146+
For granular control over what gets migrated:
147+
148+
1. In the restore wizard, use the "Resource Selection" option.
149+
2. Choose specific resource types to include/exclude.
150+
3. Filter by labels or annotations if needed.
151+
152+
### Handling Custom Resources
153+
154+
CloudCasa handles most CRDs, but some considerations:
155+
156+
1. Verify both clusters have the same CRDs installed.
157+
2. If CRDs differ, install the required controllers on RKE2 before restoring.
158+
3. For complex CRDs, consider a phased migration approach.
159+
160+
## Best Practices and Troubleshooting
161+
162+
### Pre-Migration Checklist
163+
164+
- **Inventory Resources:** Run `kubectl api-resources` on both clusters to identify potential CRD compatibility issues.
165+
- **Test Plan:** Perform a test migration with non-critical workloads first.
166+
- **Destination Capacity:** Ensure RKE2 nodes have sufficient resources for all workloads.
167+
- **Network Policy Compatibility:** Verify network policies work similarly in RKE2.
168+
169+
### Common Issues and Solutions
170+
171+
#### Failed PV Restores
172+
173+
**Issue:** PV restores fail due to storage class incompatibilities.
174+
**Solution:** Ensure destination storage classes support the same provisioners and features. Use storage class mapping during restore.
175+
176+
#### Resource Version Conflicts
177+
178+
**Issue:** API resource version mismatches between RKE1 and RKE2.
179+
**Solution:** Use CloudCasa's transformation rules to adapt resources to the target cluster's API versions.
180+
181+
#### CRD Compatibility
182+
183+
**Issue:** Custom resources fail to restore due to CRD differences.
184+
**Solution:** Install the required CRDs and controllers on the RKE2 cluster before restore.
185+
186+
#### DNS and Service Discovery
187+
188+
**Issue:** Applications can't communicate after migration.
189+
**Solution:** Verify CoreDNS configuration in RKE2 and check service endpoints.
190+
191+
## Post-Migration Steps
192+
193+
After successful migration:
194+
195+
1. **Update DNS/Load Balancers:** Point external traffic to the new RKE2 cluster.
196+
2. **Verify Monitoring:** Ensure monitoring and alerting systems recognize the new resources.
197+
3. **Document Changes:** Record any configuration differences between the clusters.
198+
4. **Plan RKE1 Decommissioning:** Schedule the shutdown of your RKE1 cluster once all workloads are verified.
199+
200+
## Conclusion
201+
202+
Migrating from RKE1 to RKE2 using CloudCasa provides a reliable, comprehensive approach that preserves your entire application state, including persistent volumes. This method is particularly valuable for complex deployments with stateful applications where traditional redeployment strategies would be time-consuming and error-prone.
203+
204+
By following this guide, you can achieve a smooth migration with minimal downtime while ensuring all your workloads, configurations, and data are accurately transferred to your new RKE2 environment.
205+
206+
---
207+
208+
### Additional Resources
209+
- [CloudCasa Documentation](https://docs.cloudcasa.io/)
210+
- [RKE2 Documentation](https://docs.rke2.io/)
211+
- [RKE1 to RKE2 Migration Strategy Overview](https://support.tools/migrating-rke1-to-rke2/)
212+
- [SUSE RKE1 EOL Announcement](https://www.suse.com/support/kb/doc/?id=000021513)

0 commit comments

Comments
 (0)