If you are migrating Rancher to a new Kubernetes cluster, you don't need to install Rancher on the new cluster first. If Rancher is restored to a new cluster with Rancher already installed, it can cause problems.
These instructions assume that you have created a backup and already installed a new Kubernetes cluster where Rancher will be deployed. The backup is specific to the Rancher application and can only migrate the Rancher application.
It is required to use the same hostname that was set as the server URL in the first cluster.
Rancher version must be v2.5.0 and up
Rancher can be installed on any Kubernetes cluster, including hosted Kubernetes clusters such as Amazon EKS clusters. For help installing Kubernetes, refer to the documentation of the Kubernetes distribution. One of Rancher's Kubernetes distributions may also be used:
Since Rancher can be installed on any Kubernetes cluster, you can use this backup and restore method to migrate Rancher from one Kubernetes cluster to any other Kubernetes cluster. This method only migrates Rancher-related resources and won't affect other applications on the cluster. Refer to the support matrix to identify which Kubernetes cluster types and versions are supported for your Rancher version.
1. Install the rancher-backup Helm chart
Install version 1.x.x of the rancher-backup chart. The following assumes a connected environment with access to DockerHub:
helm repo add rancher-charts https://charts.rancher.io
helm repo update
helm install rancher-backup-crd rancher-charts/rancher-backup-crd -n cattle-resources-system --create-namespace --version $CHART_VERSION
helm install rancher-backup rancher-charts/rancher-backup -n cattle-resources-system --version $CHART_VERSION
For an **air-gapped environment**, use the option below to pull the `backup-restore-operator` image from your private registry when installing the rancher-backup-crd helm chart. ``` --set image.repository $REGISTRY/rancher/backup-restore-operator ```
2. Restore from backup using a Restore custom resource
If you are using an S3 store as the backup source, and need to use your S3 credentials for restore, create a secret in this cluster using your S3 credentials. The Secret data must have two keys,
secretKey containing the s3 credentials like this:
accessKey: <Enter your base64-encoded access key>
secretKey: <Enter your base64-encoded secret key>
This secret can be created in any namespace, with the above example it will get created in the default namespace
In the Restore custom resource,
prune must be set to false.
Create a Restore custom resource like the example below:
Important: The field
encryptionConfigSecretNamemust be set only if your backup was created with encryption enabled. Provide the name of the Secret containing the encryption config file. If you only have the encryption config file, but don't have a secret created with it in this cluster, use the following steps to create the secret:
The encryption configuration file must be named
encryption-provider-config.yaml, and the
--from-fileflag must be used to create this secret. So save your
EncryptionConfigurationin a file called
encryption-provider-config.yamland run this command:
kubectl create secret generic encryptionconfig \
Then apply the resource:
kubectl apply -f migrationResource.yaml
3. Install cert-manager
Follow the steps to install cert-manager in the documentation about installing cert-manager on Kubernetes.
4. Bring up Rancher with Helm
Use the same version of Helm to install Rancher, that was used on the first cluster.
helm install rancher rancher-latest/rancher \
--namespace cattle-system \
--set hostname=<same hostname as the server URL from the first Rancher server> \