public/rancher-docs
1
0
Fork 0
mirror of https://github.com/rancher/rancher-docs.git synced 2026-05-16 18:13:17 +00:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #3785 from jtravee/Updating-URL-Migration

Browse Source 
Updated Rancher URL migration instructions
This commit is contained in:
Jen Travinski
2022-02-01 09:08:55 -05:00
committed by GitHub
parent 307965585b ec12cfa628
commit fa8e62ace0
1 changed files with 5 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/rancher/v2.6/en/backups/migrating-rancher/_index.md
+5 -3
View File
@@ -9,7 +9,7 @@ If you are migrating Rancher to a new Kubernetes cluster, you don't need to inst
These instructions assume you have [created a backup](../back-up-rancher) and you have already installed a new Kubernetes cluster where Rancher will be deployed.
It is required to use the same hostname that was set as the server URL in the first cluster.
>**Warning:** It is required to use the same hostname that was set as the server URL in the first cluster. If not done, downstream clusters will show as unavailable in the cluster management page of the UI, and you won't be able to click inside the cluster or on the cluster's <b>Explore</b> button.
Rancher version must be v2.5.0 and up
@@ -41,7 +41,9 @@ For an **air-gapped environment**, use the option below to pull the `backup-rest
>
> - Note that when making or restoring backups for v1.22, the Rancher version and the local cluster's Kubernetes version should be the same. The Kubernetes version should be considered when restoring a backup since the supported apiVersion in the cluster and in the backup file could be different.
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, `accessKey` and `secretKey` containing the s3 credentials like this:
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 - `accessKey` and `secretKey` - that contain the S3 credentials.
**Warning:** The values `accessKey` and `secretKey` in the example below must be base64-encoded first when creating the object directly. If not encoded first, the pasted values will cause errors when you are attempting to backup or restore.
```yaml
apiVersion: v1
@@ -54,7 +56,7 @@ stringData:
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
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.