Migrating Namespaces and Workloads from Geddes (RKE1) to Geddes2 (RKE2)¶
This guide explains how to migrate namespaces and workloads between the Geddes (RKE1) cluster and the Geddes2 (RKE2) cluster using Rancher and kubectl.
Recommended Migration Workflow¶
- Configure kubeconfig contexts
- Create namespace on Geddes2
- Export resources from Geddes
- Clean YAML manifests
- Validate YAML files
- Deploy resources to Geddes2
- Verify workloads and services
Configure kubectl Contexts¶
To migrate namespaces between Geddes and Geddes2, first add both cluster kubeconfigs as contexts in your local kubectl configuration.
Step 1 — Download kubeconfig from Rancher¶
For each cluster:
- Open Rancher
- Navigate to the cluster
- Click Kubeconfig
- Copy or download the kubeconfig
You should end up with files similar to:
Step 2 — Test Each kubeconfig Separately¶
Verify that each kubeconfig can successfully connect to its cluster.
Test Geddes (RKE1)¶
Test Geddes2 (RKE2)¶
If both commands work successfully, continue to the next step.
Step 3 — Merge kubeconfigs¶
Temporarily merge both kubeconfig files:
Then merge them into your default kubeconfig:
Step 4 — Verify Contexts¶
Verify that both cluster contexts are available:
Example output:
Step 5 — Test Switching Contexts¶
Switch to Geddes¶
Verify access:
If this command works, your context and permissions are configured correctly.
Switch to Geddes2¶
Step 6 — Use Contexts Directly¶
You can now run commands against either cluster directly.
Geddes¶
```bash id="p8m4qn" kubectl --context geddes get ns
Export and Deploy YAML File¶
Important¶
This step is performed after:
- Exporting the namespace from Geddes
- Creating the namespace on Geddes2
Step 1 — Export Resources from Geddes¶
You can export workloads individually or export the full namespace.
Example A — Export Individual Resource Types¶
```bash id="z4m8qt" kubectl --context geddes -n my-namespace get deployment -o yaml > deployment.yaml
kubectl --context geddes -n my-namespace get statefulset -o yaml > statefulset.yaml
kubectl --context geddes -n my-namespace get daemonset -o yaml > daemonset.yaml
kubectl --context geddes -n my-namespace get job -o yaml > job.yaml
kubectl --context geddes -n my-namespace get cronjob -o yaml > cronjob.yaml
You can repeat this process for:
- statefulsets
- services
- configmaps
- ingresses
- secrets
Example C — Export All Resources Using Script¶
Script overview
The script is an interactive Bash utility that exports Kubernetes resources from a selected namespace into organized YAML files.
What the Script Does
The script performs the following actions:
- Prompts the user for a Kubernetes context, in this case this should be 'geddes'
- Prompts for the namespace to export
- Verifies the namespace exists. If the namespace does not exist, the script exits with an error.
- Presents a list of Kubernetes resource types
- Allows the user to select which resources to export
- Creates directories automatically
- Exports each selected resource as an individual YAML file
- Organizes the files into resource-specific folders
Display Available Resource Types
The script presents the following Kubernetes resource types:
For each resource type, the user is prompted:
Only selected resources are exported.
Create Export Directory Structure
The script automatically creates a folder structure under:
Example:
Each resource type gets its own directory.
Export Resources as YAML Files
The script exports every discovered resource individually using kubectl.
Example exported files:
Each file contains the full Kubernetes YAML manifest for that resource.
Important Notes
This script requires the Python PyYAML package.
Install it using:
Exported YAML Contains Cluster Metadata
The exported YAML files include:
- Kubernetes runtime metadata
- Rancher-generated metadata
- resource versions
- status information
Before deploying these manifests to another cluster, the files should be cleaned using a cleanup script.
Secrets
The script exports Kubernetes secrets exactly as stored in the cluster.
Use caution when handling exported secret files.
Persistent Volumes
PVC objects may export successfully, but underlying storage data is not migrated automatically.
Additional storage migration steps may be required.
Full Script
Expand the section below to view and copy the complete export-resources.py script
View full export-resources.py script
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 | |
Step 2 — Resource Cleanup Before Deployment to Geddes2¶
After exporting a namespace, the YAML files contain cluster-specific metadata that must be removed before deploying to Geddes2.
This cleanup process removes:
- RKE1-specific metadata
- Rancher-generated metadata
- Kubernetes runtime metadata
Cleaning exported YAML files helps prevent deployment conflicts and removes unnecessary cluster-specific information before importing workloads into the Geddes2 cluster.
Cleanup Multiple YAML Files (Namespace Folder Cleanup)¶
This script:
- Cleans all YAML files recursively
- Processes all folders under a namespace directory
- Removes Kubernetes and Rancher-generated metadata
- Overwrites the original YAML files (in-place cleanup)
Important:¶
- This script overwrites existing YAML files with the cleaned version. There is no backup unless you create one manually.
- The script must be executed in the directory where the exported namespace folder exists. You may modify the script if your folder location is different.
The script will:
- scan all folders under
namespace/my-namespace - process every
.yamlfile - overwrite each file with cleaned content
Python Cleanup Script¶
Expand the section below to view and copy the complete cleanup_multiple_yaml.py script.
View full cleanup_multiple_yaml.py script
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 | |
Cleanup a Single YAML File¶
The following Python utility is designed to clean individual Kubernetes YAML manifests exported from geddes cluster.
Example Usage¶
-
Clean a Single YAML File
This prints the cleaned YAML output to the terminal.
Python Cleanup Script¶
Expand the section below to view and copy the complete cleanup_single_yaml.py script.
View full cleanup_single_yaml.py script
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 | |
Step 3 — Basic Validation (Recommended)¶
Validate all YAML files after cleanup and before deployment to Geddes2.
This verifies:
- YAML syntax
- Kubernetes API compatibility
- cluster compatibility
Example A — Validate Single YAML File¶
or
Example B — Validate Entire Directory¶
Not recommended for large exports because troubleshooting can become difficult.
Example C — Validate Each File Individually (Recommended)¶
This approach is safer and easier for debugging.
Step 4 — Resource Deployment on Geddes2¶
After cleanup and validation, deploy the resources to Geddes2.
Example A — Deploy Single YAML File¶
Ensure your YAML contains:
Deploy using:
Example B — Deploy Entire Namespace Folder¶
If using the export-resources.sh script, the exported structure will look like:
Deploy all resources:
Important Notes¶
Persistent Volume Data¶
PVC objects migrate, but the underlying storage data usually does not.
Persistent application data must be migrated separately.
Secrets¶
Some secrets should not be migrated directly:
- service-account-token secrets
- Helm release secrets
- auto-generated certificates