Migração da versão 3 para a 4

Procedimento

1. Coloque um componente de rede exterior, como um balanceador de carga de aplicativo ou um proxy reverso, entre os clientes e o cluster de destino.
2. Atualize a FQDN do aplicativo no cluster de origem no servidor DNS para retornar o endereço IP do componente de rede exterior.
3. Configure o componente de rede para enviar as solicitações recebidas para o aplicativo no domínio de origem ao balanceador de carga no domínio do cluster de destino.
4. Crie um registro DNS curinga para o domínio *.apps.source.example.com que aponte para o endereço IP do balanceador de carga do cluster de origem.
5. Crie um registro DNS para cada aplicativo que aponte para o endereço IP do componente de rede exterior na frente do cluster de destino. Um registro DNS específico tem prioridade mais alta do que um registro curinga; por isso, não ocorrem conflitos quando o FQDN é resolvido.

1. Crie uma rota no projeto do cluster de destino que seja configurada para aceitar pedidos endereçados ao FQDN do aplicativo no cluster de origem:

   $ oc expose svc <app1-svc> --hostname <app1.apps.source.example.com> \
    -n <app1-namespace>

   Com essa nova rota implantada, o servidor aceitará qualquer solicitação para esse FQDN e a enviará aos pods do aplicativo correspondentes. Além disso, ao migrar o aplicativo, outra rota será criada no domínio do cluster de destino. As solicitações chegarão ao aplicativo migrado usando qualquer um desses nomes de host.

2. Crie um registro DNS com seu provedor DNS que aponte o FQDN do aplicativo no cluster de origem para o endereço IP do balanceador de carga padrão do cluster de destino. Isso redirecionará o tráfego do cluster de origem para o cluster de destino.

   O FQDN do aplicativo é resolvido para o balanceador de carga do cluster de destino. O roteador do controlador de entrada padrão aceita solicitações para esse FQDN porque uma rota para esse nome de host está exposta.

1. Substitua o certificado x509 do controlador de entrada padrão criado durante o processo de instalação por um certificado personalizado.

2. Configure esse certificado para incluir os domínios DNS curinga dos clusters de origem e de destino no campo subjectAltName.

   O novo certificado será válido para proteger conexões feitas usando qualquer um dos domínios DNS.

Procedimento

1. Obtenha o ponto de extremidade S3, AWS_ACCESS_KEY_IDe AWS_SECRET_ACCESS_KEY executando o comando describe no recurso personalizado NooBaa.

   Essas credenciais são usadas para adicionar o MCG como um repositório de replicação.

Procedimento

1. Defina a variável BUCKET:

   $ BUCKET=<your_bucket>

2. Defina a variável REGION:

   $ REGION=<your_region>

3. Crie um bucket AWS S3:

   $ aws s3api create-bucket \
       --bucket $BUCKET \
       --region $REGION \
       --create-bucket-configuration LocationConstraint=$REGION 

   1

   1

   us-east-1 não é compatível com LocationConstraint. Se sua região for us-east-1, omita --create-bucket-configuration LocationConstraint=$REGION.

4. Crie um usuário de IAM:

   $ aws iam create-user --user-name velero 

   1

   1

   Se quiser usar o Velero para fazer backup de vários clusters com vários buckets S3, crie um nome de usuário exclusivo para cada cluster.

5. Crie um arquivo velero-policy.json:

   $ cat > velero-policy.json <<EOF
   {
       "Version": "2012-10-17",
       "Statement": [
           {
               "Effect": "Allow",
               "Action": [
                   "ec2:DescribeVolumes",
                   "ec2:DescribeSnapshots",
                   "ec2:CreateTags",
                   "ec2:CreateVolume",
                   "ec2:CreateSnapshot",
                   "ec2:DeleteSnapshot"
               ],
               "Resource": "*"
           },
           {
               "Effect": "Allow",
               "Action": [
                   "s3:GetObject",
                   "s3:DeleteObject",
                   "s3:PutObject",
                   "s3:AbortMultipartUpload",
                   "s3:ListMultipartUploadParts"
               ],
               "Resource": [
                   "arn:aws:s3:::${BUCKET}/*"
               ]
           },
           {
               "Effect": "Allow",
               "Action": [
                   "s3:ListBucket"
               ],
               "Resource": [
                   "arn:aws:s3:::${BUCKET}"
               ]
           }
       ]
   }
   EOF

6. Anexe as políticas para dar ao usuário velero as permissões necessárias:

   $ aws iam put-user-policy \
     --user-name velero \
     --policy-name velero \
     --policy-document file://velero-policy.json

7. Crie uma chave de acesso para o usuário velero:

   $ aws iam create-access-key --user-name velero

   Exemplo de saída

   {
     "AccessKey": {
           "UserName": "velero",
           "Status": "Active",
           "CreateDate": "2017-07-31T22:24:41.576Z",
           "SecretAccessKey": <AWS_SECRET_ACCESS_KEY>,
           "AccessKeyId": <AWS_ACCESS_KEY_ID>
     }
   }

   Registre AWS_SECRET_ACCESS_KEY e AWS_ACCESS_KEY_ID. As credenciais são usadas para adicionar a AWS como um repositório de replicação.

Procedimento

1. Faça login na GCP:

   $ gcloud auth login

2. Defina a variável BUCKET:

   $ BUCKET=<bucket> 

   1

   1

   Especifique o nome do seu bucket.

3. Crie o bucket de armazenamento:

   $ gsutil mb gs://$BUCKET/

4. Defina a variável PROJECT_ID do seu projeto ativo:

   $ PROJECT_ID=$(gcloud config get-value project)

5. Crie uma conta de serviço:

   $ gcloud iam service-accounts create velero \
       --display-name "Velero service account"

6. Liste suas contas de serviços:

   $ gcloud iam service-accounts list

7. Defina a variável SERVICE_ACCOUNT_EMAIL para corresponder ao valor de email:

   $ SERVICE_ACCOUNT_EMAIL=$(gcloud iam service-accounts list \
       --filter="displayName:Velero service account" \
       --format 'value(email)')

8. Anexe as políticas para dar ao usuário velero as permissões necessárias:

   $ ROLE_PERMISSIONS=(
       compute.disks.get
       compute.disks.create
       compute.disks.createSnapshot
       compute.snapshots.get
       compute.snapshots.create
       compute.snapshots.useReadOnly
       compute.snapshots.delete
       compute.zones.get
   )

9. Crie a função personalizada velero.server:

   $ gcloud iam roles create velero.server \
       --project $PROJECT_ID \
       --title "Velero Server" \
       --permissions "$(IFS=","; echo "${ROLE_PERMISSIONS[*]}")"

10. Adicione a associação da política de IAM ao projeto:

    $ gcloud projects add-iam-policy-binding $PROJECT_ID \
        --member serviceAccount:$SERVICE_ACCOUNT_EMAIL \
        --role projects/$PROJECT_ID/roles/velero.server

11. Atualize a conta de serviço de IAM:

    $ gsutil iam ch serviceAccount:$SERVICE_ACCOUNT_EMAIL:objectAdmin gs://${BUCKET}

12. Salve as chaves da conta de serviço de IAM no arquivo credentials-velero no diretório atual:

    $ gcloud iam service-accounts keys create credentials-velero \
        --iam-account $SERVICE_ACCOUNT_EMAIL

    O arquivo credentials-velero é usado para adicionar a GCP como um repositório de replicação.

Procedimento

1. Faça login no Azure:

   $ az login

2. Defina a variável AZURE_RESOURCE_GROUP:

   $ AZURE_RESOURCE_GROUP=Velero_Backups

3. Crie um grupo de recursos do Azure:

   $ az group create -n $AZURE_RESOURCE_GROUP --location CentralUS 

   1

   1

   Especifique seu local.

4. Defina a variável AZURE_STORAGE_ACCOUNT_ID:

   $ AZURE_STORAGE_ACCOUNT_ID="velero$(uuidgen | cut -d '-' -f5 | tr '[A-Z]' '[a-z]')"

5. Crie uma conta de armazenamento do Azure:

   $ az storage account create \
       --name $AZURE_STORAGE_ACCOUNT_ID \
       --resource-group $AZURE_BACKUP_RESOURCE_GROUP \
       --sku Standard_GRS \
       --encryption-services blob \
       --https-only true \
       --kind BlobStorage \
       --access-tier Hot

6. Defina a variável BLOB_CONTAINER:

   $ BLOB_CONTAINER=velero

7. Crie um contêiner de armazenamento do Azure Blob:

   $ az storage container create \
     -n $BLOB_CONTAINER \
     --public-access off \
     --account-name $AZURE_STORAGE_ACCOUNT_ID

8. Crie uma entidade de serviço e credenciais para velero:

   $ AZURE_SUBSCRIPTION_ID=`az account list --query '[?isDefault].id' -o tsv` \
     AZURE_TENANT_ID=`az account list --query '[?isDefault].tenantId' -o tsv` \
     AZURE_CLIENT_SECRET=`az ad sp create-for-rbac --name "velero" \
     --role "Contributor" --query 'password' -o tsv` \
     AZURE_CLIENT_ID=`az ad sp list --display-name "velero" \
     --query '[0].appId' -o tsv`

9. Salve as credenciais da entidade de serviço no arquivo credentials-velero:

   $ cat << EOF > ./credentials-velero
   AZURE_SUBSCRIPTION_ID=${AZURE_SUBSCRIPTION_ID}
   AZURE_TENANT_ID=${AZURE_TENANT_ID}
   AZURE_CLIENT_ID=${AZURE_CLIENT_ID}
   AZURE_CLIENT_SECRET=${AZURE_CLIENT_SECRET}
   AZURE_RESOURCE_GROUP=${AZURE_RESOURCE_GROUP}
   AZURE_CLOUD_NAME=AzurePublicCloud
   EOF

   O arquivo credentials-velero é usado para adicionar o Azure como um repositório de replicação.

Procedimento

1. Obtenha o ponto de extremidade S3, AWS_ACCESS_KEY_IDe AWS_SECRET_ACCESS_KEY executando o comando describe no recurso personalizado NooBaa.

Procedimento

1. Faça login no cluster do OpenShift Container Platform onde o MTC foi instalado.

2. Obtenha a URL do console web do MTC digitando o seguinte comando:

   $ oc get -n openshift-migration route/migration -o go-template='https://{{ .spec.host }}'

   A saída se assemelha ao seguinte: https://migration-openshift-migration.apps.cluster.openshift.com.

3. Inicie um navegador e navegue até o console web do MTC.

   Nota

   Se você tentar acessar o console web do MTC imediatamente após a instalação do Migration Toolkit for Containers Operator, o console talvez não seja carregado porque o Operador ainda estará configurando o cluster. Aguarde alguns minutos e tente novamente.

4. Se estiver usando certificados CA autoassinados, você será solicitado a aceitar o certificado CA do servidor de API do cluster de origem. A página web guiará você ao longo do processo de aceitação dos certificados restantes.
5. Faça login com seu nome de usuário e sua senha do OpenShift Container Platform.

Procedimento

1. Faça login no cluster.

2. Obtenha o token da conta de serviço migration-controller:

   $ oc sa get-token migration-controller -n openshift-migration

   Exemplo de saída

   eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJtaWciLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlY3JldC5uYW1lIjoibWlnLXRva2VuLWs4dDJyIiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQubmFtZSI6Im1pZyIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6ImE1YjFiYWMwLWMxYmYtMTFlOS05Y2NiLTAyOWRmODYwYjMwOCIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDptaWc6bWlnIn0.xqeeAINK7UXpdRqAtOj70qhBJPeMwmgLomV9iFxr5RoqUgKchZRG2J2rkqmPm6vr7K-cm7ibD1IBpdQJCcVDuoHYsFgV4mp9vgOfn9osSDp2TGikwNz4Az95e81xnjVUmzh-NjDsEpw71DH92iHV_xt2sTwtzftS49LpPW2LjrV0evtNBP_t_RfskdArt5VSv25eORl7zScqfe1CiMkcVbf2UqACQjo3LbkpfN26HAioO2oH0ECPiRzT0Xyh-KwFutJLS9Xgghyw-LD9kPKcE_xbbJ9Y4Rqajh7WdPYuB0Jd9DPVrslmzK-F6cgHHYoZEv0SvLQi-PO0rpDrcjOEQQ

3. No console web do MTC, clique em Clusters.
4. Clique em Add cluster.

5. Preencha os seguintes campos:

   • Cluster name: o nome do cluster pode conter letras minúsculas (a-z) e números (0-9). Ele não pode conter espaços ou caracteres internacionais.
   • URL: especifique a URL do servidor de API; por exemplo, https://<www.example.com>:8443.
   • Service account token: cole o token de conta de serviço migration-controller.

   • Exposed route host to image registry: se estiver usando a migração direta de imagem, especifique a rota exposta ao registro de imagem do cluster de origem.

     Para criar a rota, execute o seguinte comando:

     • Para o OpenShift Container Platform 3:

       $ oc create route passthrough --service=docker-registry --port=5000 -n default

     • Para o OpenShift Container Platform 4:

       $ oc create route passthrough --service=image-registry --port=5000 -n openshift-image-registry

   • Azure cluster: selecione esta opção se usar snapshots do Azure para copiar seus dados.
   • Azure resource group: este campo será exibido se Azure cluster for selecionado. Especifique o grupo de recursos do Azure.
   • Require SSL verification: opcional; selecione esta opção para verificar as conexões SSL ao cluster.
   • CA bundle file: este campo será exibido se a opção Require SSL verification for selecionada. Se tiver criado um arquivo de pacote de certificados CA personalizado para certificados autoassinados, clique em Browse, selecione o arquivo de pacote de CA e carregue-o.

6. Clique em Add cluster.

   O cluster aparecerá na lista Clusters.

Procedimento

1. No console web do MTC, clique em Replication repositories.
2. Clique em Add repository.

3. Selecione um Storage provider type e preencha os seguintes campos:

   • AWS para provedores S3, incluindo AWS e MCG:

     • Replication repository name: especifique o nome do repositório de replicação no console web do MTC.
     • S3 bucket name: especifique o nome do bucket S3.
     • S3 bucket region: especifique a região do bucket S3. Obrigatório para AWS S3. Opcional para alguns provedores S3. Verifique a documentação do produto do seu provedor S3 para conferir os valores esperados.
     • S3 endpoint: especifique a URL do serviço S3, não o bucket; por exemplo, https://<s3-storage.apps.cluster.com>. Obrigatório para um provedor S3 genérico. Você deve usar o prefixo https://.
     • S3 provider access key: especifique <AWS_SECRET_ACCESS_KEY> para AWS ou a chave de acesso do provedor S3 para MCG e outros provedores S3.
     • S3 provider secret access key: especifique <AWS_ACCESS_KEY_ID> para AWS ou a chave de acesso secreta do provedor S3 para MCG e outros provedores S3.
     • Require SSL verification: desmarque esta caixa de seleção se estiver usando um provedor S3 genérico.
     • Se você criou um pacote de certificados CA personalizados para certificados autoassinados, clique em Browse e navegue até o arquivo codificado em Base64.

   • GCP:

     • Replication repository name: especifique o nome do repositório de replicação no console web do MTC.
     • GCP bucket name: especifique o nome do bucket GCP.
     • GCP credential JSON blob: especifique a cadeia de caracteres no arquivo credentials-velero.

   • Azure:

     • Replication repository name: especifique o nome do repositório de replicação no console web do MTC.
     • Azure resource group: especifique o grupo de recursos do armazenamento do Azure Blob.
     • Azure storage account name: especifique o nome da conta de armazenamento do Azure Blob.
     • Azure credentials - INI file contents: especifique a cadeia de caracteres no arquivo credentials-velero.
4. Clique em Add repository e aguarde a validação da conexão.

5. Clique em Close.

   O novo repositório aparecerá na lista Replication repositories.

Procedimento

1. No console web do MTC, clique em Migration plans.
2. Clique em Add migration plan.

3. Informe o Plan name.

   O nome do plano de migração não deve exceder 253 caracteres alfanuméricos minúsculos (a-z, 0-9) e não deve conter espaços nem sublinhados(_).

4. Selecione um Source cluster, um Target clustere um Repository.
5. Clique em Next.
6. Selecione os projetos para a migração.
7. Opcional: clique no ícone de edição ao lado de um projeto para mudar o namespace de destino.
8. Clique em Next.

9. Selecione um Migration type para cada PV:

   • A opção Copy copia os dados do PV de um cluster de origem para o repositório de replicação e, então, restaura os dados em um PV recém-criado, com características similares, no cluster de destino.
   • A opção Move desmonta um volume remoto (por exemplo, NFS) do cluster de origem, cria um recurso de PV no cluster de destino apontando para o volume remoto e, então, monta o volume remoto no cluster de destino. Os aplicativos em execução no cluster de destino usam o mesmo volume remoto que o cluster de origem estava usando.
10. Clique em Next.

11. Selecione um Copy method para cada PV:

    • Snapshot copy faz o backup e restaura os dados usando a funcionalidade de snapshot do provedor de nuvem. Isso é significativamente mais rápido do que Filesystem copy.

    • Filesystem copy faz backup dos arquivos no cluster de origem e os restaura no cluster de destino.

      O método de cópia de sistema de arquivos é necessário para a migração direta do volume.

12. Você pode selecionar Verify copy para verificar os dados migrados com Filesystem copy. Os dados são verificados gerando um checksum para cada arquivo de origem e verificando o checksum após a restauração. A verificação dos dados reduz significativamente o desempenho.

13. Selecione uma Target storage class.

    Se selecionou Filesystem copy, você pode mudar a classe de armazenamento de destino.

14. Clique em Next.

15. Na página Migration options, a opção Direct image migration será selecionada se você especificar uma rota de registro de imagem exposta para o cluster de origem. A opção de Direct PV migration será selecionada se você estiver migrando dados com Filesystem copy.

    As opções de migração direta copiam as imagens e os arquivos diretamente do cluster de origem para o cluster de destino. Essa opção é muito mais rápida do que copiar imagens e arquivos do cluster de origem para o repositório de replicação e, então, do repositório de replicação para o cluster de destino.

16. Clique em Next.

17. Opcional: clique em Add Hook para adicionar um hook ao plano de migração.

    Um hook executa um código personalizado. Você pode adicionar até quatro hooks a um único plano de migração. Cada hook é executado durante uma etapa diferente da migração.

    1. Informe o nome do diferente a ser exibido no console web.
    2. Se o diferente for um playbook do Ansible, selecione Ansible playbook e clique em Browse para carregar o playbook ou cole o conteúdo do playbook no campo.
    3. Opcional: especifique uma imagem de tempo de execução do Ansible se não estiver usando a imagem de hook padrão.

    4. Se o hook não for um playbook do Ansible, selecione Custom container image e especifique o nome e o caminho da imagem.

       Uma imagem personalizada de contêiner pode incluir playbooks do Ansible.

    5. Selecione Source cluster ou Target cluster.
    6. Informe o Service account name e o Service account namespace.

    7. Selecione a etapa de migração para o hook:

       • preBackup: antes que o backup da carga de trabalho do aplicativo seja feito no cluster de origem
       • postBackup: depois que o backup da carga de trabalho do aplicativo for feito no cluster de origem
       • preRestore: antes que a carga de trabalho do aplicativo seja restaurada no cluster de destino
       • postRestore: depois que a carga de trabalho do aplicativo for restaurada no cluster de destino
    8. Clique em Add.

18. Clique em Finish.

    O plano de migração será exibido na lista Migration plans.

Procedimento

1. Faça login no console web do MTC e clique em Migration plans.

2. Clique no menu de opções , ao lado de um plano de migração, e selecione uma das seguintes opções em Migration:

   • Stage copia os dados do cluster de origem para o cluster de destino sem interromper o aplicativo.

   • Cutover interrompe as transações no cluster de origem e move os recursos para o cluster de destino.

     Opcional: na caixa de diálogo Cutover migration, você pode desmarcar a caixa de seleção Halt transactions on the source cluster during migration.

   • State copia reivindicações de volume persistente (PVCs) e recursos do Kubernetes selecionados que constituem o estado de um aplicativo. Você pode usar a migração de estado para migrar um namespace dentro do mesmo cluster.

     Importante

     Não use a migração de estado para migrar um namespace entre clusters. Em vez disso, use a migração em etapas ou de substituição.

     • Selecione um ou mais PVCs no caixa de diálogo State migration e clique em Migrate.

3. Quando a migração for concluída, verifique se o aplicativo foi migrado com êxito no console web do OpenShift Container Platform:

   1. Clique em Home → Projects.
   2. Clique no projeto migrado para ver o status dele.
   3. Na seção Routes, clique em Location para verificar se o aplicativo está funcionando, se aplicável.
   4. Clique em Workloads → Pods para verificar se os pods estão em execução no namespace migrado.
   5. Clique em Storage → Persistent volumes para verificar se os volumes persistentes migrados estão corretamente provisionados.

Procedimento

1. Obtenha o manifesto de CR MigrationController:

   $ oc get migrationcontroller <migration_controller> -n openshift-migration

2. Atualize os parâmetros de proxy:

   apiVersion: migration.openshift.io/v1alpha1
   kind: MigrationController
   metadata:
     name: <migration_controller>
     namespace: openshift-migration
   ...
   spec:
     stunnel_tcp_proxy: http://<username>:<password>@<ip>:<port> 

   1

   
     httpProxy: http://<username>:<password>@<ip>:<port> 

   2

   
     httpsProxy: http://<username>:<password>@<ip>:<port> 

   3

   
     noProxy: example.com 

   4

   1

   URL do proxy Stunnel para a migração direta de volume.

   2

   URL do proxy para a criação de conexões HTTP fora do cluster. O esquema de URL deve ser http.

   3

   URL do proxy para a criação de conexões HTTPS fora do cluster. Se isso não for especificado, então, httpProxy será usado para conexões HTTP e HTTPS.

   4

   Lista separada por vírgulas de nomes de domínio de destino, domínios, endereços IP ou outros CIDRs de rede para excluir o proxy.

   Preceda um domínio com . para corresponder apenas subdomínios. Por exemplo, .y. corresponde x.y.com, mas não y.com. Use * para ignorar o proxy para todos os destinos. Se você aumentar os trabalhadores que não estão incluídos na rede definida pelo campo networking.machineNetwork[].cidr da configuração da instalação, será necessário adicioná-los à lista para evitar problemas de conexão.

   Este campo será ignorado se os campos httpProxy e httpsProxy não estiverem definidos.

3. Salve o manifesto como migration-controller.yaml.

4. Aplique o manifesto atualizado:

   $ oc replace -f migration-controller.yaml -n openshift-migration

Procedimento

1. Crie um manifesto de CR MigCluster para o cluster de host:

   $ cat << EOF | oc apply -f -
   apiVersion: migration.openshift.io/v1alpha1
   kind: MigCluster
   metadata:
     name: <host_cluster>
     namespace: openshift-migration
   spec:
     isHostCluster: true
   EOF

2. Criar um manifesto de objeto Secret para cada cluster remoto:

   $ cat << EOF | oc apply -f -
   apiVersion: v1
   kind: Secret
   metadata:
     name: <cluster_secret>
     namespace: openshift-config
   type: Opaque
   data:
     saToken: <sa_token> 

   1

   
   EOF

   1

   Especifique o token da conta de serviço (SA) migration-controller codificada em base64 do cluster remoto. É possível obter o token executando o seguinte comando:

   $ oc sa get-token migration-controller -n openshift-migration | base64 -w 0

3. Crie um manifesto de CR MigCluster para cada cluster remoto:

   $ cat << EOF | oc apply -f -
   apiVersion: migration.openshift.io/v1alpha1
   kind: MigCluster
   metadata:
     name: <remote_cluster> 

   1

   
     namespace: openshift-migration
   spec:
     exposedRegistryPath: <exposed_registry_route> 

   2

   
     insecure: false 

   3

   
     isHostCluster: false
     serviceAccountSecretRef:
       name: <remote_cluster_secret> 

   4

   
       namespace: openshift-config
     url: <remote_cluster_url> 

   5

   
   EOF

   1

   Especifique o CR Cluster do cluster remoto.

   2

   Opcional: para migração direta de imagem, especifique a rota do registro exposto.

   3

   A verificação SSL é ativada se false. Os certificados CA não são exigidos nem verificados se true.

   4

   Especifique o objeto Secret do cluster remoto.

   5

   Especifique a URL do cluster remoto.

4. Verifique se todos os clusters estão em um estado Ready:

   $ oc describe cluster <cluster>

5. Crie um manifesto de objeto Secret para o repositório de replicação:

   $ cat << EOF | oc apply -f -
   apiVersion: v1
   kind: Secret
   metadata:
     namespace: openshift-config
     name: <migstorage_creds>
   type: Opaque
   data:
     aws-access-key-id: <key_id_base64> 

   1

   
     aws-secret-access-key: <secret_key_base64> 

   2

   
   EOF

   1

   Especifique a ID da chave no formato base64.

   2

   Especifique a chave secreta no formato base64.

   As credenciais da AWS são codificadas em base64 por padrão. Para outros provedores de armazenamento, você deve codificar suas credenciais executando o seguinte comando com cada chave:

   $ echo -n "<key>" | base64 -w 0 

   1

   1

   Especifique a ID da chave ou a chave secreta. Ambas as chaves devem ser codificadas em base64.

6. Crie um manifesto de CR MigStorage para o repositório de replicação:

   $ cat << EOF | oc apply -f -
   apiVersion: migration.openshift.io/v1alpha1
   kind: MigStorage
   metadata:
     name: <migstorage>
     namespace: openshift-migration
   spec:
     backupStorageConfig:
       awsBucketName: <bucket> 

   1

   
       credsSecretRef:
         name: <storage_secret> 

   2

   
         namespace: openshift-config
     backupStorageProvider: <storage_provider> 

   3

   
     volumeSnapshotConfig:
       credsSecretRef:
         name: <storage_secret> 

   4

   
         namespace: openshift-config
     volumeSnapshotProvider: <storage_provider> 

   5

   
   EOF

   1

   Especifique o nome do bucket.

   2

   Especifique o CR Segredos do armazenamento de objetos. Você deve garantir que as credenciais armazenadas no CR Secret do armazenamento de objetos estejam corretas.

   3

   Especifique o provedor de armazenamento.

   4

   Opcional: se estiver copiando dados usando snapshots, especifique o CR Secret do armazenamento de objetos. Você deve garantir que as credenciais armazenadas no CR Secret do armazenamento de objetos estejam corretas.

   5

   Opcional: se estiver copiando dados usando snapshots, especifique o provedor de armazenamento.

7. Verifique se o CR MigStorage está em um estado Ready:

   $ oc describe migstorage <migstorage>

8. Crie um manifesto de CR MigPlan:

   $ cat << EOF | oc apply -f -
   apiVersion: migration.openshift.io/v1alpha1
   kind: MigPlan
   metadata:
     name: <migplan>
     namespace: openshift-migration
   spec:
     destMigClusterRef:
       name: <host_cluster>
       namespace: openshift-migration
     indirectImageMigration: true 

   1

   
     indirectVolumeMigration: true 

   2

   
     migStorageRef:
       name: <migstorage> 

   3

   
       namespace: openshift-migration
     namespaces:
       - <source_namespace_1> 

   4

   
       - <source_namespace_2>
       - <source_namespace_3>:<destination_namespace> 

   5

   
     srcMigClusterRef:
       name: <remote_cluster> 

   6

   
       namespace: openshift-migration
   EOF

   1

   A migração direta de imagem é ativada se false.

   2

   A migração direta de volume é ativada se false.

   3

   Especifique o nome da instância do CR MigStorage.

   4

   Especifique um ou mais namespaces de origem. Por padrão, o namespace de destino tem o mesmo nome.

   5

   Especifique um namespace de destino se ele for diferente do namespace de origem.

   6

   Especifique o nome da instância MigCluster do cluster de origem.

9. Verifique se a instância MigPlan está em um estado Ready:

   $ oc describe migplan <migplan> -n openshift-migration

10. Crie um manifesto de CR MigMigration para iniciar a migração definida na instância MigPlan:

    $ cat << EOF | oc apply -f -
    apiVersion: migration.openshift.io/v1alpha1
    kind: MigMigration
    metadata:
      name: <migmigration>
      namespace: openshift-migration
    spec:
      migPlanRef:
        name: <migplan> 

    1

    
        namespace: openshift-migration
      quiescePods: true 

    2

    
      stage: false 

    3

    
      rollback: false 

    4

    
    EOF

    1

    Especifique o nome do CR MigPlan.

    2

    Os pods no cluster de origem são interrompidos antes da migração se true.

    3

    Uma migração em etapas, que copia a maioria dos dados sem parar o aplicativo, é realizada se true.

    4

    Uma migração concluída é revertida se true.

11. Verifique a migração observando o progresso do CR MigMigration

    $ oc watch migmigration <migmigration> -n openshift-migration

    A saída se assemelha ao seguinte:

    Exemplo de saída

    Name:         c8b034c0-6567-11eb-9a4f-0bc004db0fbc
    Namespace:    openshift-migration
    Labels:       migration.openshift.io/migplan-name=django
    Annotations:  openshift.io/touch: e99f9083-6567-11eb-8420-0a580a81020c
    API Version:  migration.openshift.io/v1alpha1
    Kind:         MigMigration
    ...
    Spec:
      Mig Plan Ref:
        Name:       migplan
        Namespace:  openshift-migration
      Stage:        false
    Status:
      Conditions:
        Category:              Advisory
        Last Transition Time:  2021-02-02T15:04:09Z
        Message:               Step: 19/47
        Reason:                InitialBackupCreated
        Status:                True
        Type:                  Running
        Category:              Required
        Last Transition Time:  2021-02-02T15:03:19Z
        Message:               The migration is ready.
        Status:                True
        Type:                  Ready
        Category:              Required
        Durable:               true
        Last Transition Time:  2021-02-02T15:04:05Z
        Message:               The migration registries are healthy.
        Status:                True
        Type:                  RegistriesHealthy
      Itinerary:               Final
      Observed Digest:         7fae9d21f15979c71ddc7dd075cb97061895caac5b936d92fae967019ab616d5
      Phase:                   InitialBackupCreated
      Pipeline:
        Completed:  2021-02-02T15:04:07Z
        Message:    Completed
        Name:       Prepare
        Started:    2021-02-02T15:03:18Z
        Message:    Waiting for initial Velero backup to complete.
        Name:       Backup
        Phase:      InitialBackupCreated
        Progress:
          Backup openshift-migration/c8b034c0-6567-11eb-9a4f-0bc004db0fbc-wpc44: 0 out of estimated total of 0 objects backed up (5s)
        Started:        2021-02-02T15:04:07Z
        Message:        Not started
        Name:           StageBackup
        Message:        Not started
        Name:           StageRestore
        Message:        Not started
        Name:           DirectImage
        Message:        Not started
        Name:           DirectVolume
        Message:        Not started
        Name:           Restore
        Message:        Not started
        Name:           Cleanup
      Start Timestamp:  2021-02-02T15:03:18Z
    Events:
      Type    Reason   Age                 From                     Message
      ----    ------   ----                ----                     -------
      Normal  Running  57s                 migmigration_controller  Step: 2/47
      Normal  Running  57s                 migmigration_controller  Step: 3/47
      Normal  Running  57s (x3 over 57s)   migmigration_controller  Step: 4/47
      Normal  Running  54s                 migmigration_controller  Step: 5/47
      Normal  Running  54s                 migmigration_controller  Step: 6/47
      Normal  Running  52s (x2 over 53s)   migmigration_controller  Step: 7/47
      Normal  Running  51s (x2 over 51s)   migmigration_controller  Step: 8/47
      Normal  Ready    50s (x12 over 57s)  migmigration_controller  The migration is ready.
      Normal  Running  50s                 migmigration_controller  Step: 9/47
      Normal  Running  50s                 migmigration_controller  Step: 10/47

Procedimento

1. Edite o manifesto de recurso personalizado MigrationController:

   $ oc edit migrationcontroller <migration_controller> -n openshift-migration

2. Atualize a seção spec adicionando um parâmetro para excluir recursos específicos ou adicionando um recurso ao parâmetro excluded_resources se ele não tiver o próprio parâmetro de exclusão:

   apiVersion: migration.openshift.io/v1alpha1
   kind: MigrationController
   metadata:
     name: migration-controller
     namespace: openshift-migration
   spec:
     disable_image_migration: true 

   1

   
     disable_pv_migration: true 

   2

   
     ...
     excluded_resources: 

   3

   
     - imagetags
     - templateinstances
     - clusterserviceversions
     - packagemanifests
     - subscriptions
     - servicebrokers
     - servicebindings
     - serviceclasses
     - serviceinstances
     - serviceplans
     - operatorgroups
     - events
     - events.events.k8s.io

   1

   Adicione disable_image_migration: true para excluir fluxos de imagem da migração. Não edite o parâmetro excluded_resources. imagestreams é adicionar a excluded_resources quando o pod MigrationController é reiniciado.

   2

   Adicione disable_pv_migration: true para excluir PVs do plano de migração. Não edite o parâmetro excluded_resources. persistentvolumes e persistentvolumeclaims são adicionados a excluded_resources quando o pod MigrationController é reiniciado. Desabilitar a migração de PVs também desabilita a descoberta de PVs quando o plano de migração é criado.

   3

   É possível adicionar recursos do OpenShift Container Platform à lista excluded_resources list. Não exclua os recursos excluídos por padrão. A migração desses recursos é problemática, e eles devem ser excluídos.

3. Aguarde dois minutos para que o pod MigrationController seja reiniciado para que as mudanças sejam aplicadas.

4. Verifique se o recurso foi excluído:

   $ oc get deployment -n openshift-migration migration-controller -o yaml | grep EXCLUDED_RESOURCES -A1

   A saída contém os recursos excluídos:

   Exemplo de saída

       - name: EXCLUDED_RESOURCES
         value:
         imagetags,templateinstances,clusterserviceversions,packagemanifests,subscriptions,servicebrokers,servicebindings,serviceclasses,serviceinstances,serviceplans,imagestreams,persistentvolumes,persistentvolumeclaims

Procedimento

1. Edite o manifesto de recurso personalizado (CR) MigrationController:

   $ oc edit migrationcontroller -n openshift-migration

2. Atualize os seguintes parâmetros:

   ...
   mig_controller_limits_cpu: "1" 

   1

   
   mig_controller_limits_memory: "10Gi" 

   2

   
   ...
   mig_controller_requests_cpu: "100m" 

   3

   
   mig_controller_requests_memory: "350Mi" 

   4

   
   ...
   mig_pv_limit: 100 

   5

   
   mig_pod_limit: 100 

   6

   
   mig_namespace_limit: 10 

   7

   
   ...

   1

   Especifica o número de CPUs disponíveis para o CR MigrationController.

   2

   Especifica a quantidade de memória disponível para o CR MigrationController.

   3

   Especifica o número de unidades de CPU disponíveis para solicitações do CR MigrationController. 100m representa 0,1 unidade de CPU (100 * 1e-3).

   4

   Especifica a quantidade de memória disponível para solicitações do CR MigrationController.

   5

   Especifica o número de volumes persistentes que podem ser migrados.

   6

   Especifica o número de pods que podem ser migrados.

   7

   Especifica o número de namespaces que podem ser migrados.

3. Crie um plano de migração que utilize os parâmetros atualizados para verificar as mudanças.

   Se seu plano de migração exceder os limites do CR MigrationController, o console do MTC exibirá uma mensagem de aviso quando você salvar o plano de migração.

Procedimento

1. Faça login no cluster de host.

2. Habilite o redimensionamento de PV corrigindo o CR MigrationController:

   $ oc patch migrationcontroller migration-controller -p '{"spec":{"enable_dvm_pv_resizing":true}}' \ 

   1

   
     --type='merge' -n openshift-migration

   1

   Defina o valor como false para desabilitar o redimensionamento de PV.

3. Opcional: atualize o parâmetro pv_resizing_threshold para aumentar o limite:

   $ oc patch migrationcontroller migration-controller -p '{"spec":{"pv_resizing_threshold":41}}' \ 

   1

   
     --type='merge' -n openshift-migration

   1

   O valor padrão é 3.

   Quando o limite é excedido, a seguinte mensagem de status é exibida no status do CR MigPlan:

   status:
     conditions:
   ...
     - category: Warn
       durable: true
       lastTransitionTime: "2021-06-17T08:57:01Z"
       message: 'Capacity of the following volumes will be automatically adjusted to avoid disk capacity issues in the target cluster:  [pvc-b800eb7b-cf3b-11eb-a3f7-0eae3e0555f3]'
       reason: Done
       status: "False"
       type: PvCapacityAdjustmentRequired

   Nota

   Para armazenamento gp2 da AWS, essa mensagem não será exibida a menos que pv_resizing_threshold seja 42% ou maior, devido à forma como o gp2 calcula o uso e o tamanho do volume. (BZ#1973148)

Procedimento

1. Habilite os clientes em cache executando o seguinte comando:

   $ oc -n openshift-migration patch migrationcontroller migration-controller --type=json --patch \
     '[{ "op": "replace", "path": "/spec/mig_controller_enable_cache", "value": true}]'

2. Opcional: aumente os limites de memória do CR MigrationController executando o seguinte comando:

   $ oc -n openshift-migration patch migrationcontroller migration-controller --type=json --patch \
     '[{ "op": "replace", "path": "/spec/mig_controller_limits_memory", "value": <10Gi>}]'

3. Opcional: aumente as solicitações de memória do CR MigrationController executando o seguinte comando:

   $ oc -n openshift-migration patch migrationcontroller migration-controller --type=json --patch \
     '[{ "op": "replace", "path": "/spec/mig_controller_requests_memory", "value": <350Mi>}]'