Este documento foi traduzido usando tecnologia de tradução automática de máquina. Sempre trabalhamos para apresentar traduções precisas, mas não oferecemos nenhuma garantia em relação à integridade, precisão ou confiabilidade do conteúdo traduzido. Em caso de qualquer discrepância, a versão original em inglês prevalecerá e constituirá o texto official.

Migrando SUSE Rancher Prime para um Novo Cluster

Se você está migrando o Rancher para um novo cluster Kubernetes, não é necessário instalar o Rancher no novo cluster primeiro. Se o Rancher for restaurado em um novo cluster com o Rancher já instalado, isso pode causar problemas.

Pré-requisitos

Estas instruções assumem que você já criou um backup e instalou um novo cluster Kubernetes onde o Rancher será implantado. O backup é específico para o aplicativo Rancher e pode migrar apenas o aplicativo Rancher.

Você deve usar o mesmo nome de host que foi definido como a URL do servidor no cluster original. Se não o fizer, clusters downstream aparecerão como indisponíveis na página de gerenciamento de clusters da GUI, e você não poderá clicar dentro do cluster ou no botão Explorar do cluster.

A versão do Rancher deve ser v2.5.0 ou superior

O Rancher pode ser instalado em qualquer cluster Kubernetes, incluindo clusters Kubernetes hospedados, como os clusters Amazon EKS. Para ajuda na instalação do Kubernetes, consulte a documentação da distribuição do Kubernetes. Distribuições Kubernetes criadas pelo Rancher, como, mas não se limitando a, RKE ou K3s, também podem ser usadas.

Como o Rancher pode ser instalado em qualquer cluster Kubernetes, você pode usar este método de backup e restauração para migrar o Rancher de um cluster Kubernetes para qualquer outro cluster Kubernetes. Este método apenas migra recursos relacionados ao Rancher e não afetará outros aplicativos no cluster. Consulte a matriz de suporte para identificar quais tipos e versões de clusters Kubernetes são suportados para a sua versão do Rancher.

1. Instale o chart Helm rancher-backup

Instale o rancher-backup chart:

Adicione o repositório Helm:

helm repo add rancher-charts https://charts.rancher.io
helm repo update

Defina uma variável CHART_VERSION, selecionando uma versão de chart rancher-backup compatível com a sua versão do Rancher. Veja a matriz de suporte, na seção Aplicativos do Rancher / Ferramentas de Cluster, para ver quais versões rancher-backup são suportadas:
```
CHART_VERSION=<chart-version>
```

Instale os charts:

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

O acima assume um ambiente com conectividade de saída para o Docker Hub.

Para um ambiente air-gapped, use os seguintes valores do Helm para obter as imagens backup-restore-operator e kubectl do seu registro privado ao instalar o chart Helm rancher-backup.

--set image.repository=<registry>/rancher/backup-restore-operator --set global.kubectl.repository=<registry>/rancher/kubectl

Se o host que executa os comandos do Helm for também air-gapped e não puder acessar charts.rancher.io, baixe os charts em um host não air-gapped e, em seguida, instale-os a partir de arquivos locais no host air-gapped.

Em um host não air-gapped:

helm repo add rancher-charts https://charts.rancher.io
helm repo update
helm fetch rancher-charts/rancher-backup-crd --version $CHART_VERSION
helm fetch rancher-charts/rancher-backup --version $CHART_VERSION

Copie os arquivos rancher-backup-crd-<chart-version>.tgz e rancher-backup-<chart-version>.tgz para o host air-gapped, depois use-os para instalar os charts:

helm install rancher-backup-crd ./rancher-backup-crd-<chart-version>.tgz -n cattle-resources-system --create-namespace
helm install rancher-backup ./rancher-backup-<chart-version>.tgz -n cattle-resources-system --set image.repository=<registry>/rancher/backup-restore-operator --set global.kubectl.repository=<registry>/rancher/kubectl

2. Restaure a partir de backup usando um recurso personalizado de Restore

Ao usar o armazenamento de objetos S3 como a fonte de backup para uma restauração que requer credenciais, crie um Secret objeto neste cluster para adicionar as credenciais do S3. Os dados secretos devem ter duas chaves - accessKey e secretKey, que contêm as credenciais do S3.

O segredo pode ser criado em qualquer namespace, este exemplo usa o namespace padrão.
```
kubectl create secret generic s3-creds \
  --from-literal=accessKey=<access key> \
  --from-literal=secretKey=<secret key>
```
Adicione sua chave de acesso e chave secreta como valores para accessKey e secretKey no comando acima.

Crie um Restore objeto:

Durante uma migração, prune deve ser definido como false. Veja o exemplo abaixo:

# restore-migration.yaml
apiVersion: resources.cattle.io/v1
kind: Restore
metadata:
  name: restore-migration
spec:
  backupFilename: backup-b0450532-cee1-4aa1-a881-f5f48a007b1c-2020-09-15T07-27-09Z.tar.gz
  // highlight-next-line
  prune: false
  // highlight-next-line
  encryptionConfigSecretName: encryptionconfig
  storageLocation:
    s3:
      credentialSecretName: s3-creds
      credentialSecretNamespace: default
      bucketName: backup-test
      folder: ecm1
      region: us-west-2
      endpoint: s3.us-west-2.amazonaws.com

Importante

O campo encryptionConfigSecretName deve ser usado apenas se seu backup foi criado com a criptografia habilitada.

Se isso se aplica, forneça o nome do objeto Secret contendo o arquivo de configuração de criptografia. Se você tiver apenas o arquivo de configuração de criptografia, mas não tiver o segredo criado neste cluster, use os seguintes passos para criar o segredo:

Crie um arquivo de configuração de criptografia
O comando abaixo usa um arquivo chamado encryption-provider-config.yaml, com a flag --from-file. Execute o abaixo uma vez que o EncryptionConfiguration esteja salvo em um arquivo chamado encryption-provider-config.yaml:
```
kubectl create secret generic encryptionconfig \
  --from-file=./encryption-provider-config.yaml \
  -n cattle-resources-system
```

Aplique o manifesto e monitore o status de Restore:

Aplique o recurso do objeto Restore:
```
kubectl apply -f restore-migration.yaml
```
Observe o status de Restore:
```
kubectl get restore
```

Observe os logs de restauração:

kubectl logs -n cattle-resources-system --tail 100 -f -l app.kubernetes.io/instance=rancher-backup

Uma vez que o recurso de Restauração tenha o status Completed, você pode continuar a instalação do cert-manager e do Rancher.

Ao migrar o Rancher entre duas distribuições Kubernetes diferentes (por exemplo, de K3s para RKE2), o objeto representando o cluster local deve ser modificado para permitir que o Rancher detecte a nova distribuição. Após a conclusão da restauração, e antes de iniciar o Rancher no novo cluster, edite o objeto do cluster local:

kubectl edit clusters.management.cattle.io local

Altere o valor de status.driver para imported.
Remova status.provider.
Remova todo o mapa status.version.
Remova o rótulo com a chave provider.cattle.io em metadata.labels.
Remova a anotação com a chave management.cattle.io/current-cluster-controllers-version em metadata.annotations.
Remova todo o mapa spec.rke2Config ou spec.k3sConfig, se presente.
Grave as mudanças.

Observe que remover spec.rke2Config ou spec.k3sConfig apagará sua configuração de fazer upgrade específica da distribuição para o cluster local. Pode ser reconfigurado se a nova distribuição for configurável para o cluster local.

3. Instale o cert-manager

Siga os passos para instalar o cert-manager na documentação sobre a instalação do cert-manager no Kubernetes.

4. Inicie o Rancher com o Helm

Use a mesma versão do Helm para instalar o Rancher, que foi usada no primeiro cluster.

helm install rancher rancher-prime/rancher \
  --namespace cattle-system \
  --set hostname=<same hostname as the server URL from the first Rancher server> \
  --version x.y.z

Se o ambiente original do Rancher estiver em execução, você pode coletar os valores atuais com um kubeconfig para o ambiente original:

helm get values rancher -n cattle-system -o yaml > rancher-values.yaml

Esses valores podem ser reutilizados usando o arquivo rancher-values.yaml. Certifique-se de mudar o kubeconfig para o novo ambiente do Rancher.

helm install rancher rancher-prime/rancher -n cattle-system -f rancher-values.yaml --version x.y.z

5. Redirecionar o tráfego para o novo cluster

Após a migração ser concluída, atualize seus registros DNS e quaisquer balanceadores de carga, para que o tráfego seja roteado corretamente para o cluster migrado. Lembre-se de que você deve usar o mesmo nome de host que foi definido como a URL do servidor no cluster original.

As instruções completas sobre como redirecionar o tráfego para o cluster migrado variam com base no seu ambiente específico. Consulte a documentação do seu provedor de hospedagem para mais detalhes.

6. Reduzir a escala da instância original do Rancher

Após redirecionar o tráfego para o novo ambiente do Rancher, reduza a escala da instância original do Rancher para 0 réplicas para que ela não entre em contato com seus clusters gerenciados.

Manter o servidor antigo ativo pode fazer com que os agentes continuem contatando o original server-url, o que muitas vezes deixa os clusters presos em Atualizando no novo ambiente.

kubectl scale deployment rancher -n cattle-system --replicas=0

Se você desejar manter o ambiente original do Rancher em funcionamento, também pode reiniciar os pods cattle-cluster-agent em cada cluster conectado ao seu ambiente do Rancher.

kubectl rollout restart deployment cattle-cluster-agent -n cattle-system

Isso aciona uma reinicialização gradual do agente para que ele restabeleça a conexão com o novo ambiente do Rancher.