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

OpenShift Container Platform 4.10

Migração para o OpenShift Container Platform 4

Resumo

Este documento fornece instruções para migrar seu cluster do OpenShift Container Platform da versão 3 para a versão 4.

Capítulo 1. Visão geral da migração do OpenShift Container Platform 3 para a versão 4

Os clusters do OpenShift Container Platform 4 são diferentes dos clusters do OpenShift Container Platform 3. Os clusters do OpenShift Container Platform 4 contêm novas tecnologias e funcionalidades que resultam em um cluster que é autogerenciável, flexível e automatizado. Para saber mais sobre a migração do OpenShift Container Platform 3 para a versão 4, consulte Sobre a migração do OpenShift Container Platform 3 para a versão 4.

1.1. Diferenças entre o OpenShift Container Platform 3 e 4

Antes de migrar o OpenShift Container Platform 3 para a versão 4, confira as diferenças entre o OpenShift Container Platform 3 e 4. Revise as seguintes informações:

1.2. Considerações sobre o planejamento da rede

Antes de migrar o OpenShift Container Platform 3 para a versão 4, revise as diferenças entre o OpenShift Container Platform 3 e 4 para obter informações sobre as seguintes áreas:

Você pode migrar cargas de trabalho de aplicativos com estado do OpenShift Container Platform 3 para a versão 4 na granularidade de um namespace. Para saber mais sobre o MTC, consulte Como compreender um MTC.

1.3. Instalação do MTC

Revise as seguintes tarefas para instalar o MTC:

1.4. Atualização de MTC

Você atualiza o Migration Toolkit for Containers (MTC) no OpenShift Container Platform 4.10 usando o OLM. Para atualizar o MTC no OpenShift Container Platform 3, reinstale o Migration Toolkit for Containers Operator herdado.

1.5. Revisão das listas de verificação antes da migração

Antes de migrar suas cargas de trabalho de aplicativos com o Migration Toolkit for Containers (MTC), revise as listas de verificação antes da migração.

1.6. Migração de aplicativos

Você pode migrar seus aplicativos usando o console web ou a linha de comando do MTC.

1.7. Opções avançadas de migração

É possível automatizar as migrações e modificar recursos personalizados do MTC para melhorar o desempenho das migrações em larga escala usando as seguintes opções:

1.8. Solução de problemas de migrações

Você pode realizar as seguintes tarefas de solução de problemas:

1.9. Reversão de uma migração

Você pode reverter uma migração usando o console web do MTC, usando a CLI, ou manualmente.

1.10. Desinstalação do MTC e exclusão de recursos

Você pode desinstalar o MTC e excluir os recursos dele para limpar o cluster.

Capítulo 2. Sobre a migração do OpenShift Container Platform 3 para a versão 4

O OpenShift Container Platform 4 contém novas tecnologias e funcionalidades que resultam em um cluster que é autogerenciável, flexível e automatizado. Os clusters do OpenShift Container Platform 4 são implantados e gerenciados de forma muito diferente do OpenShift Container Platform 3.

A maneira mais eficaz de migrar o OpenShift Container Platform 3 para a versão 4 é utilizar um pipeline de CI/CD para automatizar as implantações em uma estrutura de gerenciamento do ciclo de vida de aplicativos.

Se você não tiver um pipeline de CI/CD ou se estiver migrando aplicativos com estado, será possível usar o Migration Toolkit for Containers (MTC) para migrar suas cargas de trabalho de aplicativos.

Para fazer a transição com êxito para o OpenShift Container Platform 4, revise as seguintes informações:

Diferenças entre o OpenShift Container Platform 3 e 4
  • Arquitetura
  • Instalação e atualização
  • Considerações sobre armazenamento, rede, registro em log, segurança e monitoramento
Sobre o Migration Toolkit for Containers
  • Fluxo de trabalho
  • Sistema de arquivos e métodos de cópia de snapshots para volumes persistentes (PVs)
  • Migração direta de volume
  • Migração direta de imagem
Opções avançadas de migração
  • Automatização de migração com hooks de migração
  • Uso da API do MTC
  • Exclusão de recursos de um plano de migração
  • Configuração do recurso personalizado MigrationController para migrações em larga escala
  • Habilitação de redimensionamento automático de PV para migração direta de volume
  • Habilitação de clientes Kubernetes em cache para um desempenho melhor

Para conferir os novos recursos e aprimoramentos, mudanças técnicas e problemas conhecidos, consulte as notas de lançamento do MTC.

Capítulo 3. Diferenças entre o OpenShift Container Platform 3 e 4

O OpenShift Container Platform 4.10 introduz mudanças e aprimoramentos de arquitetura. Os procedimentos que você usava para gerenciar seu cluster do OpenShift Container Platform 3 podem não ser aplicáveis ao OpenShift Container Platform 4.

Para obter informações sobre a configuração de cluster do OpenShift Container Platform 4, revise as seções apropriadas da documentação do OpenShift Container Platform. Para obter informações sobre novos recursos e outras mudanças técnicas notáveis, revise as notas de lançamento do OpenShift Container Platform 4.10.

Não é possível atualizar seu cluster existente do OpenShift Container Platform 3 para o OpenShift Container Platform 4. Você deve começar com uma nova instalação do OpenShift Container Platform 4. Há ferramentas disponíveis para auxiliar na migração de suas configurações do plano de controle e cargas de trabalho de aplicativos.

3.1. Arquitetura

Com o OpenShift Container Platform 3, os administradores implantavam individualmente os hosts do Red Hat Enterprise Linux (RHEL), e então instalavam o OpenShift Container Platform sobre esses hosts para formar um cluster. Os administradores eram responsáveis pela configuração adequada desses hosts e por realizar atualizações.

O OpenShift Container Platform 4 representa uma mudança significativa no modo como os clusters do OpenShift Container Platform são implantados e gerenciados. O OpenShift Container Platform 4 inclui novas tecnologias e funcionalidades, como Operadores, conjuntos de máquinas e o Red Hat Enterprise Linux CoreOS (RHCOS), que são fundamentais para a operação do cluster. Essa mudança tecnológica permite que os clusters gerenciem automaticamente algumas funções anteriormente desempenhadas pelos administradores. Isto também garante a estabilidade e a consistência da plataforma, além de simplificar a instalação e o dimensionamento.

Para obter mais informações, consulte Arquitetura do OpenShift Container Platform.

Infraestrutura imutável

O OpenShift Container Platform 4 usa o Red Hat Enterprise Linux CoreOS (RHCOS), que é projetado para executar aplicativos em contêineres, e oferece uma instalação eficiente, um gerenciamento baseado em Operador e atualizações simplificadas. O RHCOS é um host de contêineres imutável, em vez de um sistema operacional personalizável como o RHEL. O RHCOS permite que a o OpenShift Container Platform 4 gerencie e automatize a implantação do host de contêineres subjacente. O RHCOS é uma parte da OpenShift Container Platform, o que significa que tudo é executado dentro de um contêiner e é implantado utilizando o OpenShift Container Platform.

No OpenShift Container Platform 4, os nós do plano de controle devem executar o RHCOS, garantindo que a automação de toda a pilha seja mantida para o plano de controle. Isso torna a implantação de atualizações um processo muito mais fácil do que no OpenShift Container Platform 3.

Para obter mais informações, consulte Red Hat Enterprise Linux CoreOS (RHCOS).

Operadores

Os Operadores são um método de empacotamento, implantação e gerenciamento de um aplicativo do Kubernetes. Os Operadores aliviam a complexidade operacional da execução de outro software. Eles cuidam do seu ambiente e usam o estado atual para tomar decisões em tempo real. Os Operadores avançados são projetados para fazer atualizações e reagir automaticamente a falhas.

Para obter mais informações, consulte Como compreender Operadores.

3.2. Instalação e atualização

Processo de instalação

Para instalar o OpenShift Container Platform 3.11, você preparou seus hosts do Red Hat Enterprise Linux (RHEL), definiu todos os valores de configuração necessários para seu cluster e, então, executou um playbook do Ansible para instalar e configurar o cluster.

No OpenShift Container Platform 4.10, você usa o programa de instalação do OpenShift para criar um conjunto mínimo de recursos necessários para um cluster. Depois que o cluster estiver em execução, você usa Operadores para fazer configurações adicionais no cluster e instalar novos serviços. Após o primeiro boot, os sistemas Red Hat Enterprise Linux CoreOS (RHCOS) são gerenciados pelo Machine Config Operator (MCO), que é executado no cluster do OpenShift Container Platform.

Para obter mais informações, consulte Processo de instalação.

Se você quiser adicionar máquinas de trabalho do Red Hat Enterprise Linux (RHEL) ao seu cluster do OpenShift Container Platform 4.10, use um playbook do Ansible para unir as máquinas de trabalho do RHEL depois que o cluster estiver em execução. Para obter mais informações, consulte Adição de máquinas de computação do RHEL a um cluster do OpenShift Container Platform.

Opções de infraestrutura

No OpenShift Container Platform 3.11, você instalava seu cluster na infraestrutura que preparava e mantinha. Além de fornecer sua própria infraestrutura, o OpenShift Container Platform 4 oferece uma opção para implantar um cluster na infraestrutura que o programa de instalação do OpenShift Container Platform provisiona e que o cluster mantém.

Para obter mais informações, consulte Visão geral da instalação do OpenShift Container Platform.

Atualização do seu cluster

No OpenShift Container Platform 3.11, você atualizava seu cluster executando playbooks do Ansible. No OpenShift Container Platform 4.10, o cluster gerencia suas próprias atualizações, incluindo atualizações do Red Hat Enterprise Linux CoreOS (RHCOS) nos nós do cluster. Você pode atualizar facilmente o cluster usando o console web ou o comando oc adm upgrade a partir da OpenShift CLI, e os Operadores serão atualizados automaticamente. Se seu cluster do OpenShift Container Platform 4.10 tiver máquinas de trabalho do RHEL, você ainda precisará executar um playbook do Ansible para atualizar essas máquinas.

Para obter mais informações, consulte Atualização de clusters.

3.3. Considerações sobre a migração

Revise as mudanças e outras considerações que possam afetar sua transição do OpenShift Container Platform 3.11 para o OpenShift Container Platform 4.

3.3.1. Considerações sobre armazenamento

Revise as mudanças no armazenamento a seguir, que devem ser levadas em consideração ao fazer a transição do OpenShift Container Platform 3.11 para o OpenShift Container Platform 4.10.

Armazenamento persistente de volume local

O armazenamento local só será compatível se o Local Storage Operator for usado no OpenShift Container Platform 4.10. Ele não é compatível com o uso do método do provisionador local do OpenShift Container Platform 3.11.

Para obter mais informações, consulte Armazenamento persistente usando volumes locais.

Armazenamento persistente do FlexVolume

O local do plugin FlexVolume do OpenShift Container Platform 3.11 mudou. O novo local no OpenShift Container Platform 4.10 é /etc/kubernetes/kubelet-plugins/volume/exec. Os plugins FlexVolume anexáveis não são mais compatíveis.

Para obter mais informações, consulte Armazenamento persistente usando FlexVolume.

Armazenamento persistente da Container Storage Interface (CSI)

O armazenamento persistente usando a Container Storage Interface (CSI) era Prévia de Tecnologia no OpenShift Container Platform 3.11. O OpenShift Container Platform 4.10 é fornecido com vários drivers CSI. Você também pode instalar seu próprio driver.

Para obter mais informações, consulte Armazenamento persistente usando a Container Storage Interface (CSI).

Red Hat OpenShift Container Storage

O Red Hat OpenShift Container Storage 3, que está disponível para uso com o OpenShift Container Platform 3.11, utiliza o Red Hat Gluster Storage como armazenamento subjacente.

O Red Hat OpenShift Container Storage 4, que está disponível para uso com o OpenShift Container Platform 4, utiliza o Red Hat Ceph Storage como armazenamento subjacente.

Para obter mais informações, consulte Armazenamento persistente usando o Red Hat OpenShift Container Storage e o artigo sobre matriz de interoperabilidade.

Opções de armazenamento persistente sem suporte

O suporte para as opções a seguir de armazenamento persistente do OpenShift Container Platform 3.11 mudou no OpenShift Container Platform 4.10:

  • GlusterFS não é mais compatível.
  • CephFS como produto autônomo não é mais compatível.
  • Ceph RBD como produto autônomo não é mais compatível.

Se você usava uma dessas opções no OpenShift Container Platform 3.11, será preciso escolher uma opção diferente de armazenamento persistente para compatibilidade total no OpenShift Container Platform 4.10.

Para obter mais informações, consulte Como compreender o armazenamento persistente.

3.3.2. Considerações sobre rede

Revise as mudanças a seguir na rede, que devem ser levadas em consideração ao fazer a transição do OpenShift Container Platform 3.11 para o OpenShift Container Platform 4.10.

Modo de isolamento de rede

O modo padrão de isolamento de rede do OpenShift Container Platform 3.11 era ovs-subnet, embora os usuários usassem frequentemente ovn-multitenant. O modo padrão de isolamento de rede do OpenShift Container Platform 4.10 é controlado por uma política de rede.

Se seu cluster do OpenShift Container Platform 3.11 utilizava os modos ovs-subnet ou ovs-multitenant, é recomendável mudar para uma política de rede para seu cluster do OpenShift Container Platform 4.10. As políticas de rede têm suporte upstream, são mais flexíveis e oferecem a funcionalidade do ovs-multitenant. Se quiser manter o comportamento do ovs-multitenant ao usar uma política de rede no OpenShift Container Platform 4.10, siga as etapas para configurar o isolamento multilocatário usando uma política de rede.

Para obter mais informações, consulte Sobre a política de rede.

3.3.3. Considerações sobre registro em log

Revise as mudanças no registro em log a seguir, que devem ser levadas em consideração ao fazer a transição do OpenShift Container Platform 3.11 para o OpenShift Container Platform 4.10.

Implantação do OpenShift Logging

O OpenShift Container Platform 4 fornece um mecanismo simples de implantação do OpenShift Logging, utilizando um recurso personalizado Cluster Logging.

Para obter mais informações, consulte Instalação do OpenShift Logging.

Dados de registro em log agregados

Não é possível transferir seus dados de registro em log agregados do OpenShift Container Platform 3.11 para seu cluster novo do OpenShift Container Platform 4.

Para obter mais informações, consulte Sobre o OpenShift Logging.

Configurações de registro em log sem suporte

Algumas configurações de registro em log disponíveis no OpenShift Container Platform 3.11 não são mais compatíveis no OpenShift Container Platform 4.10.

Para obter mais informações sobre os casos de registro em log explicitamente sem suporte, consulte Manutenção e suporte.

3.3.4. Considerações sobre segurança

Revise as mudanças na segurança a seguir, que devem ser levadas em consideração ao fazer a transição do OpenShift Container Platform 3.11 para o OpenShift Container Platform 4.10.

Acesso não autenticado a pontos de extremidade de descoberta

No OpenShift Container Platform 3.11, um usuário não autenticado podia acessar pontos de extremidade de descoberta (por exemplo, /api/* e /apis/*). Por motivos de segurança, o acesso não autenticado a pontos de extremidade de descoberta não é mais permitido no OpenShift Container Platform 4.10. Caso precise permitir o acesso não autenticado, é possível definir as configurações de RBAC conforme necessário; no entanto, certifique-se de considerar as implicações para a segurança, pois isso pode expor componentes internos do cluster à rede externa.

Provedores de identidade

A configuração dos provedores de identidade mudou no OpenShift Container Platform 4, incluindo as seguintes mudanças notáveis:

  • O provedor de identidade de cabeçalho de solicitação no OpenShift Container Platform 4.10 requer TLS mútuo, o que não ocorria no OpenShift Container Platform 3.11.
  • A configuração do provedor de identidade do OpenID Connect foi simplificada no OpenShift Container Platform 4.10. Agora ela obtém dados, que anteriormente tinham de ser especificados no OpenShift Container Platform 3.11, a partir do ponto de extremidade /.well-known/openid-configuration do provedor.

Para obter mais informações, consulte Como compreender a configuração de provedores de identidade.

Formato de armazenamento de token OAuth

Os tokens de portador OAuth HTTP recém-criados não correspondem mais aos nomes de seus objetos de tokens de acesso OAuth. Agora, os nomes dos objetos são um hash do token de portador e não contêm mais informações confidenciais. Isso reduz o risco de vazamento de informações confidenciais.

3.3.5. Considerações sobre monitoramento

Revise as mudanças no monitoramento a seguir, que devem ser levadas em consideração ao fazer a transição do OpenShift Container Platform 3.11 para o OpenShift Container Platform 4.10.

Alerta do monitoramento da disponibilidade de infraestrutura

O alerta padrão que é acionado para garantir a disponibilidade da estrutura de monitoramento era chamado de DeadMansSwitch no OpenShift Container Platform 3.11. Ele foi renomeado como Watchdog no OpenShift Container Platform 4. Se você tiver configurado a integração do PagerDuty com esse alerta no OpenShift Container 3.11, será preciso configurar a integração do PagerDuty para o alerta Watchdog no OpenShift Container Platform 4.

Para obter mais informações, consulte Aplicação de configuração personalizada do Alertmanager.

Capítulo 4. Considerações sobre a rede

Revise as estratégias de redirecionamento de seu tráfego de rede dos aplicativos após a migração.

4.1. Considerações sobre DNS

O domínio DNS do cluster de destino é diferente do domínio do cluster de origem. Por padrão, os aplicativos obtêm FQDNs do cluster de destino após a migração.

Para preservar o domínio DNS de origem dos aplicativos migrados, selecione uma das duas opções descritas abaixo.

4.1.1. Isolamento do domínio DNS do cluster de destino em relação aos clientes

É possível permitir que as solicitações de clientes enviadas ao domínio DNS do cluster de origem cheguem ao domínio DNS do cluster de destino sem que o cluster de destino seja exposto aos clientes.

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.
Nota
  • O componente de rede exterior deve encerrar todas as conexões TLS seguras. Se as conexões passarem para o balanceador de carga do cluster de destino, o FQDN do aplicativo ficará exposto ao cliente e ocorrerão erros de certificado.
  • Os aplicativos não devem retornar aos clientes links que faça referência ao domínio do cluster de destino. Caso contrário, partes do aplicativo podem não ser carregadas ou não funcionar corretamente.

4.1.2. Configuração do cluster de destino para aceitar o domínio DNS de origem

É possível configurar o cluster de destino para aceitar solicitações para um aplicativo migrado no domínio DNS do cluster de origem.

Procedimento

Tanto para o acesso HTTP não seguro quanto o seguro, realize as seguintes etapas:

  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.

Para um acesso HTTPS seguro, realize a seguinte etapa adicional:

  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.

Recursos adicionais

4.2. Estratégias de redirecionamento de tráfego de rede

Após uma migração com êxito, você deve redirecionar o tráfego de rede dos seus aplicativos sem estado do cluster de origem para o cluster de destino.

As estratégias de redirecionamento do tráfego de rede se baseiam nas seguintes suposições:

  • Os pods dos aplicativos estão em execução tanto nos clusters de origem quanto nos de destino.
  • Cada aplicativo tem uma rota que contém o nome do host do cluster de origem.
  • A rota com o nome do host do cluster de origem contém um certificado CA.
  • Para HTTPS, o certificado CA do roteador de destino contém um nome alternativo da entidade para o registro DNS curinga do cluster de origem.

Considere as seguintes estratégias e selecione a que atenda aos seus objetivos.

  • Redirecionamento de todo o tráfego de rede para todos os aplicativos ao mesmo tempo

    Altere o registro DNS curinga do cluster de origem para apontar para o endereço IP virtual (VIP) do roteador do cluster de destino.

    Essa estratégia é adequada para aplicativos simples ou migrações pequenas.

  • Redirecionamento do tráfego de rede para aplicativos específicos

    Crie um registro DNS para cada aplicativo com o nome do host do cluster de origem apontando para o VIP do roteador do cluster de destino. Esse registro DNS tem precedência sobre o registro DNS curinga do cluster de origem.

  • Redirecionamento gradual do tráfego de rede para aplicativos específicos

    1. Crie um proxy que possa direcionar o tráfego tanto para o VIP do roteador do cluster de origem quanto para o VIP do roteador do cluster de destino, para cada aplicativo.
    2. Crie um registro DNS para cada aplicativo com o nome do host do cluster de origem apontando para o proxy.
    3. Configure a entrada do proxy do aplicativo para encaminhar uma porcentagem do tráfego ao VIP do roteador do cluster de destino e o restante do tráfego ao VIP do roteador do cluster de origem.
    4. Aumente gradualmente a porcentagem do tráfego encaminhado ao VIP do roteador do cluster de destino, até que todo o tráfego da rede seja redirecionado.
  • Redirecionamento do tráfego baseado no usuário para aplicativos específicos

    Usando esta estratégia, é possível filtrar os cabeçalhos TCP/IP das solicitações de usuários para redirecionar o tráfego de rede para grupos predefinidos de usuários. Isso permite testar o processo de redirecionamento em populações específicas de usuários, antes de redirecionar todo o tráfego de rede.

    1. Crie um proxy que possa direcionar o tráfego tanto para o VIP do roteador do cluster de origem quanto para o VIP do roteador do cluster de destino, para cada aplicativo.
    2. Crie um registro DNS para cada aplicativo com o nome do host do cluster de origem apontando para o proxy.
    3. Configure a entrada do proxy do aplicativo para encaminhar o tráfego que corresponda a um determinado padrão de cabeçalho, como test customers, ao VIP do roteador do cluster de destino e encaminhar o restante do tráfego ao VIP do roteador do cluster de origem.
    4. Redirecione o tráfego ao VIP do roteador do cluster de destino em etapas, até que todo o tráfego esteja no VIP do roteador do cluster de destino.

Capítulo 5. Sobre o Migration Toolkit for Containers

O Migration Toolkit for Containers (MTC) permite que você migre cargas de trabalho de aplicativos com estado do OpenShift Container Platform 3 para a versão 4.10 na granularidade de um namespace.

Importante

Antes de iniciar sua migração, certifique-se de rever as diferenças entre o OpenShift Container Platform 3 e 4.

O MTC fornece um console web e uma API, com base nos recursos personalizados do Kubernetes, para ajudar você a controlar a migração e minimizar o tempo de inatividade dos aplicativos.

O console do MTC é instalado no cluster de destino por padrão. É possível configurar o Migration Toolkit for Containers Operator para instalar o console em um cluster de origem do OpenShift Container Platform 3 ou em um cluster remoto.

O MTC é compatível com o sistema de arquivos e os métodos de cópia de dados de snapshots para a migração de dados a partir do cluster de origem para o cluster de destino. Você pode selecionar um método adequado ao seu ambiente e que seja compatível com seu provedor de armazenamento.

O catálogo de serviços foi descontinuado no OpenShift Container Platform 4. Você pode migrar recursos de carga de trabalho provisionados com o catálogo de serviços do OpenShift Container Platform 3 para a versão 4, mas não será possível realizar ações do catálogo de serviços como provision, deprovision ou update nessas cargas de trabalho após a migração. O console do MTC exibirá uma mensagem se não for possível migrar os recursos do catálogo de serviços.

5.1. Terminologia

Tabela 5.1. Terminologia do MTC

TermoDefinição

Cluster de origem

O cluster a partir do qual os aplicativos são migrados.

Cluster de destino[1]

O cluster para o qual os aplicativos são migrados.

Repositório de replicação

Armazenamento de objetos usado para copiar imagens, volumes e objetos do Kubernetes durante a migração indireta ou para objetos do Kubernetes durante a migração direta de volumes ou migração direta de imagens.

O repositório de replicação deve ser acessível a todos os clusters.

Cluster de host

O cluster no qual o pod migration-controller e o console web estão em execução. Geralmente, o cluster de host é o cluster de destino, mas isso não é obrigatório.

O cluster de host não requer uma rota de registro exposto para a migração direta da imagem.

Cluster remoto

Um cluster remoto é geralmente o cluster de origem, mas isso não é necessário.

Um cluster remoto requer um recurso personalizado Secret que contenha o token de conta de serviço migration-controller.

Um cluster remoto requer uma rota de registro segura exposta para a migração direta da imagem.

Migração indireta

Imagens, volumes e objetos do Kubernetes são copiados 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.

Migração direta de volume

Os volumes persistentes são copiados diretamente do cluster de origem para o cluster de destino.

Migração direta de imagem

As imagens são copiadas diretamente do cluster de origem para o cluster de destino.

Migração em etapas

Os dados são copiados para o cluster de destino sem interromper o aplicativo.

Executar várias vezes uma migração em etapas reduz a duração da migração de substituição.

Migração de substituição

O aplicativo é interrompido no cluster de origem e os recursos dele são migrados para o cluster de destino.

Migração de estado

O estado do aplicativo é migrado copiando as reivindicações específicas de volume persistente e os objetos do Kubernetes para o cluster de destino.

Migração de reversão

A migração de reversão reverte uma migração concluída.

1 Chamado de cluster alvo no console web do MTC.

5.2. Fluxo de trabalho do MTC

Você pode migrar os recursos do Kubernetes, dados de volumes persistentes e imagens de contêineres internos para o OpenShift Container Platform 4.10 usando o console web do Migration Toolkit for Containers (MTC) ou a API do Kubernetes.

O MTC migra os seguintes recursos:

  • Um namespace especificado em um plano de migração.
  • Recursos com escopo de namespace: quando o MTC migra um namespace, ele migra todos os objetos e recursos associados a esse namespace, como serviços ou pods. Além disso, se um recurso que existe no namespace, mas não no nível do cluster, depender de um recurso no nível do cluster, o MTC migrará ambos os recursos.

    Por exemplo, uma restrição de contexto de segurança (SCC) é um recurso que existe no nível do cluster, e uma conta de serviço (SA) é um recurso que existe no nível do namespace. Se uma SA existir em um namespace migrado pelo MTC, o MTC localizará automaticamente quaisquer SCCs que estejam ligadas à SA e também as migrará. Da mesma maneira, o MTC migra reivindicações de volumes persistentes vinculadas aos volumes persistentes do namespace.

    Nota

    Talvez seja necessário migrar manualmente recursos com escopo de cluster, dependendo do recurso.

  • Recursos personalizados (CRs) e definições de recursos personalizados (CRDs): o MTC migra automaticamente CRs e CRDs no nível do namespace.

A migração de um aplicativo com o console web do MTC envolve as seguintes etapas:

  1. Instale o Migration Toolkit for Containers Operator em todos os clusters.

    É possível instalar o Migration Toolkit for Containers Operator em um ambiente restrito com acesso limitado ou sem acesso à internet. Os clusters de origem e de destino devem ter acesso uns aos outros pela rede e a um registro espelhado.

  2. Configure o repositório de replicação, um armazenamento de objetos intermediário que o MTC utiliza para migrar os dados.

    Os clusters de origem e de destino devem ter acesso à rede do repositório de replicação durante a migração. Se estiver usando um servidor proxy, você deverá configurá-lo para permitir o tráfego de rede entre o repositório de replicação e os clusters.

  3. Adicione o cluster de origem ao console web do MTC.
  4. Adicione o repositório de replicação ao console web do MTC.
  5. Crie um plano de migração, com uma das seguintes opções de migração de dados:

    • Copy: o MTC copia os dados do cluster de origem para o repositório de replicação, e do repositório de replicação para o cluster de destino.

      Nota

      Se estiver usando a migração direta de imagem ou a migração direta de volume, as imagens ou os volumes serão copiados diretamente do cluster de origem para o cluster de destino.

      migration PV copy
    • Move: o MTC 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. O volume remoto deve ser acessível aos clusters de origem e de destino.

      Nota

      Embora o repositório de replicação não apareça neste diagrama, ele é necessário para a migração.

      migration PV move
  6. Execute o plano de migração com uma das seguintes opções:

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

      É possível executar várias vezes uma migração em etapas para que a maioria dos dados seja copiada para o destino antes da migração. A execução de uma ou mais migrações em etapas reduz a duração da migração de substituição.

    • Cutover: interrompe o aplicativo no cluster de origem e move os recursos para o cluster de destino.

      Opcional: você pode desmarcar a caixa de seleção Halt transactions on the source cluster during migration.

Migração de aplicativos do OCP 3 para a versão 4

5.3. Sobre os métodos de cópia de dados

O Migration Toolkit for Containers (MTC) é compatível com o sistema de arquivos e os métodos de cópia de dados de snapshots para a migração de dados a partir do cluster de origem para o cluster de destino. Você pode selecionar um método adequado ao seu ambiente e que seja compatível com seu provedor de armazenamento.

5.3.1. Método de cópia de sistema de arquivos

O MTC copia os arquivos de dados do cluster de origem para o repositório de replicação, e de lá para o cluster de destino.

O método de cópia de sistema de arquivos usa Restic para a migração indireta ou Rsync para a migração direta de volumes.

Tabela 5.2. Resumo do método de cópia de sistema de arquivos

BenefíciosLimitações
  • Os clusters podem ter diferentes classes de armazenamento.
  • Compatível com todos os provedores de armazenamento S3.
  • Verificação de dados opcional com checksum.
  • Compatível com a migração direta de volume, o que aumenta significativamente o desempenho.
  • Mais lento que o método de cópia de snapshots.
  • A verificação de dados opcional reduz significativamente o desempenho.

5.3.2. Método de cópia de snapshots

O MTC copia um snapshot dos dados do cluster de origem para o repositório de replicação de um provedor de nuvem. Os dados são restaurados no cluster de destino.

O método de cópia de snapshot pode ser usado com Amazon Web Services, Google Cloud Provider e Microsoft Azure.

Tabela 5.3. Resumo do método de cópia de snapshot

BenefíciosLimitações
  • Mais rápido do que o método de cópia de sistema de arquivos.
  • O provedor de nuvem deve dar suporte a snapshots.
  • Os clusters devem estar no mesmo provedor de nuvem.
  • Os clusters devem estar no mesmo local ou região.
  • Os clusters devem ter a mesma classe de armazenamento.
  • A classe de armazenamento deve ser compatível com snapshots.
  • Não é compatível com a migração direta de volume.

5.4. Migração direta de volume e migração direta de imagem

Você pode usar a migração direta de imagem (DIM) e a migração direta de volume (DVM) para migrar imagens e dados diretamente do cluster de origem para o cluster de destino.

Se a DVM for executada com nós em diferentes zonas de disponibilidade, a migração poderá falhar porque os pods migrados não poderão acessar a reivindicação de volume persistente.

A DIM e a DVM têm benefícios significativos em termos de desempenho porque são ignoradas as etapas intermediárias de backup de arquivos do cluster de origem para o repositório de replicação e de restauração de arquivos do repositório de replicação para o cluster de destino. Os dados são transferidos com Rsync.

A DIM e a DVM têm pré-requisitos adicionais.

Capítulo 6. Instalação do Migration Toolkit for Containers

É possível instalar o Migration Toolkit for Containers (MTC) no OpenShift Container Platform 3 e 4.

Depois de instalar o Migration Toolkit for Containers Operator no OpenShift Container Platform 4.10 usando o Operator Lifecycle Manager, instale manualmente o Migration Toolkit for Containers Operator herdado no OpenShift Container Platform 3.

Por padrão, o console web do MTC e o pod Migration Controller são executados no cluster de destino. Você pode configurar o manifesto de recurso personalizado Migration Controller para executar o console web do MTC e o pod Migration Controller em um cluster de origem ou em um cluster remoto.

Depois de instalar o MTC, configure um armazenamento de objetos para ser usado como um repositório de replicação.

Para desinstalar o MTC, consulte Desinstalação do MTC e exclusão de recursos.

6.1. Diretrizes de compatibilidade

Você deve instalar o Operador do Migration Toolkit for Containers (MTC) compatível com sua versão do OpenShift Container Platform.

Não é possível instalar o MTC 1.6 no OpenShift Container Platform 4.5, ou versões anteriores, porque as versões da API de definição de recursos personalizados são incompatíveis.

Você pode migrar cargas de trabalho de um cluster de origem com o MTC 1.5.3 para um cluster de destino com o MTC 1.6, desde que o recurso personalizado MigrationController e o console web do MTC estejam em execução no cluster de destino.

Tabela 6.1. Compatibilidade entre o OpenShift Container Platform e o MTC

Versão do OpenShift Container PlatformVersão do MTCMigration Toolkit for Containers Operator

4.5 e anteriores

1.5.3

Migration Toolkit for Containers Operator herdado, instalado manualmente com o arquivo operator.yml.

4.6 e posteriores

Versão 1.6.x z-stream mais recente

Migration Toolkit for Containers Operator, instalado com o Operator Lifecycle Manager.

6.2. Instalação do Migration Toolkit for Containers Operator herdado no OpenShift Container Platform 3

É possível instalar manualmente o Migration Toolkit for Containers Operator herdado no OpenShift Container Platform 3.

Pré-requisitos

  • Você deve estar conectado como um usuário com os privilégios cluster-admin em todos os clusters.
  • Você deve ter acesso a registr.redhat.io.
  • Você deve ter podman instalado.
  • Você deve criar um segredo para o fluxo de imagem e copiá-lo em todos os nós no cluster.

Procedimento

  1. Faça login em register.redhat.io com suas credenciais do Portal do Cliente da Red Hat:

    $ sudo podman login registry.redhat.io
  2. Faça download do arquivo operator.yml:

    $ sudo podman cp $(sudo podman create \
      registry.redhat.io/rhmtc/openshift-migration-legacy-rhel8-operator:v1.5.3):/operator.yml ./
  3. Faça download do arquivo controller.yml:

    $ sudo podman cp $(sudo podman create \
      registry.redhat.io/rhmtc/openshift-migration-legacy-rhel8-operator:v1.5.3):/controller.yml ./
  4. Faça login no seu cluster do OpenShift Container Platform 3.
  5. Verifique se o cluster consegue fazer a autenticação com registry.redhat.io:

    $ oc run test --image registry.redhat.io/ubi8 --command sleep infinity
  6. Crie o objeto do Migration Toolkit for Containers Operator:

    $ oc create -f operator.yml

    Exemplo de saída

    namespace/openshift-migration created
    rolebinding.rbac.authorization.k8s.io/system:deployers created
    serviceaccount/migration-operator created
    customresourcedefinition.apiextensions.k8s.io/migrationcontrollers.migration.openshift.io created
    role.rbac.authorization.k8s.io/migration-operator created
    rolebinding.rbac.authorization.k8s.io/migration-operator created
    clusterrolebinding.rbac.authorization.k8s.io/migration-operator created
    deployment.apps/migration-operator created
    Error from server (AlreadyExists): error when creating "./operator.yml":
    rolebindings.rbac.authorization.k8s.io "system:image-builders" already exists 1
    Error from server (AlreadyExists): error when creating "./operator.yml":
    rolebindings.rbac.authorization.k8s.io "system:image-pullers" already exists

    1
    Você pode ignorar as mensagens Error from server (AlreadyExists). Elas são geradas pelo Migration Toolkit for Containers Operator, que cria recursos para versões anteriores do OpenShift Container Platform 3, fornecidos em versões posteriores.
  7. Crie o objeto MigrationController:

    $ oc create -f controller.yml
  8. Verifique se os pods do MTC estão em execução:

    $ oc get pods -n openshift-migration

6.3. Instalação do Migration Toolkit for Containers Operator no OpenShift Container Platform 4.10

Instale o Migration Toolkit for Containers Operator no OpenShift Container Platform 4.10 usando o Operator Lifecycle Manager.

Pré-requisitos

  • Você deve estar conectado como um usuário com os privilégios cluster-admin em todos os clusters.

Procedimento

  1. No console web do OpenShift Container Platform, clique em OperatorsOperatorHub.
  2. Use o campo Filter by keyword para encontrar Migration Toolkit for Containers Operator.
  3. Selecione Migration Toolkit for Containers Operator e clique em Install.
  4. Clique em Install.

    Na página Installed Operators, o Migration Toolkit for Containers Operator será exibido no projeto openshift-migration com o status Succeeded.

  5. Clique em Migration Toolkit for Containers Operator.
  6. Em Provided APIs, localize o bloco Migration Controller e clique em Create Instance.
  7. Clique em Create.
  8. Clique em WorkloadsPods para verificar se os pods do MTC estão em execução.

6.4. Configuração de proxies

Para o OpenShift Container Platform 4.1 e versões anteriores, é necessário configurar proxies no manifesto de recurso personalizado (CR) MigrationController depois da instalação do Migration Toolkit for Containers Operator, pois essas versões não são compatíveis com um objeto proxy de todo o cluster.

Para o OpenShift Container Platform 4.2 a 4.10, o Migration Toolkit for Containers (MTC) herda as configurações de proxy do cluster. Você poderá alterar os parâmetros do proxy se desejar substituir as configurações do proxy do cluster.

É necessário configurar os proxies para permitir o protocolo SPDY e encaminhar o cabeçalho Upgrade HTTP para o servidor de API. Caso contrário, será exibido um erro Upgrade request required. O CR MigrationController usa SPDY para executar comandos em pods remotos. O cabeçalho Upgrade HTTP é necessário para abrir uma conexão websocket com o servidor de API.

Migração direta de volume

Se você estiver realizando uma migração direta de volume (DVM) a partir de um cluster de origem atrás de um proxy, será necessário configurar um proxy Stunnel. O Stunnel cria um túnel transparente entre os clusters de origem e de destino para a conexão TCP sem alterar os certificados.

A DVM permite apenas um proxy. O cluster de origem não poderá acessar a rota do cluster de destino se o cluster de destino também estiver atrás de um proxy.

Pré-requisitos

  • Você deve estar conectado como um usuário com os privilégios cluster-admin em todos os clusters.

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

Para obter mais informações, consulte Configuração de proxy para todo o cluster.

6.5. Configuração de um repositório de replicação

Você deve configurar um armazenamento de objetos para ser usado como um repositório de replicação. O Migration Toolkit for Containers (MTC) copia os dados 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.

O MTC é compatível com sistema de arquivos e métodos de cópia de dados de snapshots para a migração de dados do cluster de origem para o cluster de destino. Você pode selecionar um método adequado ao seu ambiente e que seja compatível com seu provedor de armazenamento.

Os seguintes provedores de armazenamento são compatíveis:

6.5.1. Pré-requisitos

  • Todos os clusters devem ter acesso ininterrupto à rede do repositório de replicação.
  • Se você utilizar um servidor proxy com um repositório de replicação hospedado internamente, será necessário garantir que o proxy permita o acesso ao repositório de replicação.

6.5.2. Recuperação de credenciais do Multicloud Object Gateway

Você deve recuperar as credenciais do Multicloud Object Gateway (MCG) e o ponto de extremidade S3 para configurar o MCG como um repositório de replicação para o Migration Toolkit for Containers (MTC). É necessário recuperar as credenciais do Multicloud Object Gateway (MCG) para criar um recurso personalizado (CR) secret para a API OpenShift para proteção de dados (OADP).

O MCG é um componente do OpenShift Container Storage.

Pré-requisitos

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.

6.5.3. Configuração da Amazon Web Services

O armazenamento de objetos Amazon Web Services (AWS) S3 é configurado como um repositório de replicação para o Migration Toolkit for Containers (MTC).

Pré-requisitos

  • A AWS CLI deve estar instalada.
  • O bucket de armazenamento AWS S3 deve estar acessível aos clusters de origem e de destino.
  • Se estiver usando o método de cópia de snapshots:

    • Você deve ter acesso ao Elastic Block Store (EBS) do EC2.
    • Os clusters de origem e de destino devem estar na mesma região.
    • Os clusters de origem e de destino devem ter a mesma classe de armazenamento.
    • A classe de armazenamento deve ser compatível com snapshots.

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.

6.5.4. Configuração da Google Cloud Platform

Um bucket de armazenamento da Google Cloud Platform (GCP) é configurado como um repositório de replicação para o Migration Toolkit for Containers (MTC).

Pré-requisitos

  • As ferramentas de CLI gcloud e gsutil devem estar instaladas. Para obter detalhes, consulte a documentação do Google Cloud.
  • O bucket de armazenamento da GCP deve estar acessível aos clusters de origem e de destino.
  • Se estiver usando o método de cópia de snapshots:

    • Os clusters de origem e de destino devem estar na mesma região.
    • Os clusters de origem e de destino devem ter a mesma classe de armazenamento.
    • A classe de armazenamento deve ser compatível com snapshots.

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.

6.5.5. Configuração do Microsoft Azure

Um contêiner de armazenamento do Microsoft Azure Blob é configurado como um repositório de replicação para o Migration Toolkit for Containers (MTC).

Pré-requisitos

  • A Azure CLI deve estar instalada.
  • O contêiner de armazenamento do Azure Blob deve estar acessível aos clusters de origem e de destino.
  • Se estiver usando o método de cópia de snapshots:

    • Os clusters de origem e de destino devem estar na mesma região.
    • Os clusters de origem e de destino devem ter a mesma classe de armazenamento.
    • A classe de armazenamento deve ser compatível com snapshots.

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.

6.5.6. Recursos adicionais

6.6. Desinstalação do MTC e exclusão de recursos

Você pode desinstalar o Migration Toolkit for Containers (MTC) e excluir os recursos dele para limpar o cluster.

Nota

A exclusão dos CRDs velero remove o Velero do cluster.

Pré-requisitos

  • Você deve estar conectado como um usuário com os privilégios cluster-admin.

Procedimento

  1. Exclua o recurso personalizado (CR) MigrationController em todos os clusters:

    $ oc delete migrationcontroller <migration_controller>
  2. Desinstale o Migration Toolkit for Containers Operator no OpenShift Container Platform 4 usando o Operator Lifecycle Manager.
  3. Exclua os recursos com escopo de cluster em todos os clusters executando os seguintes comandos:

    • Definições de recursos personalizados (CRDs) migration:

      $ oc delete $(oc get crds -o name | grep 'migration.openshift.io')
    • CRDs velero:

      $ oc delete $(oc get crds -o name | grep 'velero')
    • Funções de cluster migration:

      $ oc delete $(oc get clusterroles -o name | grep 'migration.openshift.io')
    • Função de cluster migration-operator:

      $ oc delete clusterrole migration-operator
    • Funções de cluster velero:

      $ oc delete $(oc get clusterroles -o name | grep 'velero')
    • Associações de funções de cluster migration:

      $ oc delete $(oc get clusterrolebindings -o name | grep 'migration.openshift.io')
    • Associações de funções de cluster migration-operator:

      $ oc delete clusterrolebindings migration-operator
    • Associações de funções de cluster velero:

      $ oc delete $(oc get clusterrolebindings -o name | grep 'velero')

Capítulo 7. Instalação do Migration Toolkit for Containers em um ambiente de rede restrito

Você pode instalar o Migration Toolkit for Containers (MTC) no OpenShift Container Platform 3 e 4 em um ambiente de rede restrito realizando os seguintes procedimentos:

  1. Crie um catálogo de Operadores espelhado.

    Esse processo cria um arquivo mapping.txt, que contém o mapeamento entre a imagem de registry.redhat.io e sua imagem de registro espelhada. O arquivo mapping.txt é necessário para instalar o Operador no cluster de origem.

  2. Instale o Migration Toolkit for Containers Operator no cluster de destino do OpenShift Container Platform 4.10 usando o Operator Lifecycle Manager.

    Por padrão, o console web do MTC e o pod Migration Controller são executados no cluster de destino. Você pode configurar o manifesto de recurso personalizado Migration Controller para executar o console web do MTC e o pod Migration Controller em um cluster de origem ou em um cluster remoto.

  3. Instale o Migration Toolkit for Containers Operator legacy no cluster de origem do OpenShift Container Platform 3 usando a interface de linha de comando.
  4. Configure o armazenamento de objetos para ser usado como um repositório de replicação.

Para desinstalar o MTC, consulte Desinstalação do MTC e exclusão de recursos.

7.1. Diretrizes de compatibilidade

Você deve instalar o Operador do Migration Toolkit for Containers (MTC) compatível com sua versão do OpenShift Container Platform.

Não é possível instalar o MTC 1.6 no OpenShift Container Platform 4.5, ou versões anteriores, porque as versões da API de definição de recursos personalizados são incompatíveis.

Você pode migrar cargas de trabalho de um cluster de origem com o MTC 1.5.3 para um cluster de destino com o MTC 1.6, desde que o recurso personalizado MigrationController e o console web do MTC estejam em execução no cluster de destino.

Tabela 7.1. Compatibilidade entre o OpenShift Container Platform e o MTC

Versão do OpenShift Container PlatformVersão do MTCMigration Toolkit for Containers Operator

4.5 e anteriores

1.5.3

Migration Toolkit for Containers Operator herdado, instalado manualmente com o arquivo operator.yml.

4.6 e posteriores

Versão 1.6.x z-stream mais recente

Migration Toolkit for Containers Operator, instalado com o Operator Lifecycle Manager.

7.2. Instalação do Migration Toolkit for Containers Operator no OpenShift Container Platform 4.10

Instale o Migration Toolkit for Containers Operator no OpenShift Container Platform 4.10 usando o Operator Lifecycle Manager.

Pré-requisitos

  • Você deve estar conectado como um usuário com os privilégios cluster-admin em todos os clusters.
  • Você deve criar um catálogo de Operadores a partir de uma imagem espelhada em um registro local.

Procedimento

  1. No console web do OpenShift Container Platform, clique em OperatorsOperatorHub.
  2. Use o campo Filter by keyword para encontrar Migration Toolkit for Containers Operator.
  3. Selecione Migration Toolkit for Containers Operator e clique em Install.
  4. Clique em Install.

    Na página Installed Operators, o Migration Toolkit for Containers Operator será exibido no projeto openshift-migration com o status Succeeded.

  5. Clique em Migration Toolkit for Containers Operator.
  6. Em Provided APIs, localize o bloco Migration Controller e clique em Create Instance.
  7. Clique em Create.
  8. Clique em WorkloadsPods para verificar se os pods do MTC estão em execução.

7.3. Instalação do Migration Toolkit for Containers Operator herdado no OpenShift Container Platform 3

É possível instalar manualmente o Migration Toolkit for Containers Operator herdado no OpenShift Container Platform 3.

Pré-requisitos

  • Você deve estar conectado como um usuário com os privilégios cluster-admin em todos os clusters.
  • Você deve ter acesso a registr.redhat.io.
  • Você deve ter podman instalado.
  • Você deve criar um segredo para o fluxo de imagem e copiá-lo em todos os nós no cluster.
  • Você deve ter uma estação de trabalho Linux com acesso à rede para fazer download dos arquivos de registry.redhat.io.
  • Você deve criar uma imagem espelhada do catálogo de Operadores.
  • Você deve instalar o Migration Toolkit for Containers Operator do catálogo de Operadores espelhado no OpenShift Container Platform 4.10.

Procedimento

  1. Faça login em register.redhat.io com suas credenciais do Portal do Cliente da Red Hat:

    $ sudo podman login registry.redhat.io
  2. Faça download do arquivo operator.yml:

    $ sudo podman cp $(sudo podman create \
      registry.redhat.io/rhmtc/openshift-migration-legacy-rhel8-operator:v1.5.3):/operator.yml ./
  3. Faça download do arquivo controller.yml:

    $ sudo podman cp $(sudo podman create \
      registry.redhat.io/rhmtc/openshift-migration-legacy-rhel8-operator:v1.5.3):/controller.yml ./
  4. Obtenha o mapeamento da imagem do Operador executando o seguinte comando:

    $ grep openshift-migration-legacy-rhel8-operator ./mapping.txt | grep rhmtc

    O arquivo mapping.txt foi criado quando você espelhou o catálogo de Operadores. A saída mostra o mapeamento entre a imagem de registro.redhat.io e sua imagem de registro espelhada.

    Exemplo de saída

    registry.redhat.io/rhmtc/openshift-migration-legacy-rhel8-operator@sha256:468a6126f73b1ee12085ca53a312d1f96ef5a2ca03442bcb63724af5e2614e8a=<registry.apps.example.com>/rhmtc/openshift-migration-legacy-rhel8-operator

  5. Atualize os valores de image dos contêineres ansible e operator e o valor de REGISTRY no arquivo operator.yml:

    containers:
      - name: ansible
        image: <registry.apps.example.com>/rhmtc/openshift-migration-legacy-rhel8-operator@sha256:<468a6126f73b1ee12085ca53a312d1f96ef5a2ca03442bcb63724af5e2614e8a> 1
    ...
      - name: operator
        image: <registry.apps.example.com>/rhmtc/openshift-migration-legacy-rhel8-operator@sha256:<468a6126f73b1ee12085ca53a312d1f96ef5a2ca03442bcb63724af5e2614e8a> 2
    ...
        env:
        - name: REGISTRY
          value: <registry.apps.example.com> 3
    1 2
    Especifique seu registro espelhado e o valor de sha256 da imagem do Operador.
    3
    Especifique seu registro espelhado.
  6. Faça login no seu cluster do OpenShift Container Platform 3.
  7. Crie o objeto do Migration Toolkit for Containers Operator:

    $ oc create -f operator.yml

    Exemplo de saída

    namespace/openshift-migration created
    rolebinding.rbac.authorization.k8s.io/system:deployers created
    serviceaccount/migration-operator created
    customresourcedefinition.apiextensions.k8s.io/migrationcontrollers.migration.openshift.io created
    role.rbac.authorization.k8s.io/migration-operator created
    rolebinding.rbac.authorization.k8s.io/migration-operator created
    clusterrolebinding.rbac.authorization.k8s.io/migration-operator created
    deployment.apps/migration-operator created
    Error from server (AlreadyExists): error when creating "./operator.yml":
    rolebindings.rbac.authorization.k8s.io "system:image-builders" already exists 1
    Error from server (AlreadyExists): error when creating "./operator.yml":
    rolebindings.rbac.authorization.k8s.io "system:image-pullers" already exists

    1
    Você pode ignorar as mensagens Error from server (AlreadyExists). Elas são geradas pelo Migration Toolkit for Containers Operator, que cria recursos para versões anteriores do OpenShift Container Platform 3, fornecidos em versões posteriores.
  8. Crie o objeto MigrationController:

    $ oc create -f controller.yml
  9. Verifique se os pods do MTC estão em execução:

    $ oc get pods -n openshift-migration

7.4. Configuração de proxies

Para o OpenShift Container Platform 4.1 e versões anteriores, é necessário configurar proxies no manifesto de recurso personalizado (CR) MigrationController depois da instalação do Migration Toolkit for Containers Operator, pois essas versões não são compatíveis com um objeto proxy de todo o cluster.

Para o OpenShift Container Platform 4.2 a 4.10, o Migration Toolkit for Containers (MTC) herda as configurações de proxy do cluster. Você poderá alterar os parâmetros do proxy se desejar substituir as configurações do proxy do cluster.

É necessário configurar os proxies para permitir o protocolo SPDY e encaminhar o cabeçalho Upgrade HTTP para o servidor de API. Caso contrário, será exibido um erro Upgrade request required. O CR MigrationController usa SPDY para executar comandos em pods remotos. O cabeçalho Upgrade HTTP é necessário para abrir uma conexão websocket com o servidor de API.

Migração direta de volume

Se você estiver realizando uma migração direta de volume (DVM) a partir de um cluster de origem atrás de um proxy, será necessário configurar um proxy Stunnel. O Stunnel cria um túnel transparente entre os clusters de origem e de destino para a conexão TCP sem alterar os certificados.

A DVM permite apenas um proxy. O cluster de origem não poderá acessar a rota do cluster de destino se o cluster de destino também estiver atrás de um proxy.

Pré-requisitos

  • Você deve estar conectado como um usuário com os privilégios cluster-admin em todos os clusters.

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

Para obter mais informações, consulte Configuração de proxy para todo o cluster.

7.5. Configuração de um repositório de replicação

O Multicloud Object Gateway é a única opção compatível para um ambiente de rede restrito.

O MTC é compatível com sistema de arquivos e métodos de cópia de dados de snapshots para a migração de dados do cluster de origem para o cluster de destino. Você pode selecionar um método adequado ao seu ambiente e que seja compatível com seu provedor de armazenamento.

7.5.1. Pré-requisitos

  • Todos os clusters devem ter acesso ininterrupto à rede do repositório de replicação.
  • Se você utilizar um servidor proxy com um repositório de replicação hospedado internamente, será necessário garantir que o proxy permita o acesso ao repositório de replicação.

7.5.2. Recuperação de credenciais do Multicloud Object Gateway

É necessário recuperar as credenciais do Multicloud Object Gateway (MCG) para criar um recurso personalizado (CR) secret para a API OpenShift para proteção de dados (OADP).

O MCG é um componente do OpenShift Container Storage.

Pré-requisitos

Procedimento

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

7.5.3. Recursos adicionais

7.6. Desinstalação do MTC e exclusão de recursos

Você pode desinstalar o Migration Toolkit for Containers (MTC) e excluir os recursos dele para limpar o cluster.

Nota

A exclusão dos CRDs velero remove o Velero do cluster.

Pré-requisitos

  • Você deve estar conectado como um usuário com os privilégios cluster-admin.

Procedimento

  1. Exclua o recurso personalizado (CR) MigrationController em todos os clusters:

    $ oc delete migrationcontroller <migration_controller>
  2. Desinstale o Migration Toolkit for Containers Operator no OpenShift Container Platform 4 usando o Operator Lifecycle Manager.
  3. Exclua os recursos com escopo de cluster em todos os clusters executando os seguintes comandos:

    • Definições de recursos personalizados (CRDs) migration:

      $ oc delete $(oc get crds -o name | grep 'migration.openshift.io')
    • CRDs velero:

      $ oc delete $(oc get crds -o name | grep 'velero')
    • Funções de cluster migration:

      $ oc delete $(oc get clusterroles -o name | grep 'migration.openshift.io')
    • Função de cluster migration-operator:

      $ oc delete clusterrole migration-operator
    • Funções de cluster velero:

      $ oc delete $(oc get clusterroles -o name | grep 'velero')
    • Associações de funções de cluster migration:

      $ oc delete $(oc get clusterrolebindings -o name | grep 'migration.openshift.io')
    • Associações de funções de cluster migration-operator:

      $ oc delete clusterrolebindings migration-operator
    • Associações de funções de cluster velero:

      $ oc delete $(oc get clusterrolebindings -o name | grep 'velero')

Capítulo 8. Atualização do Migration Toolkit for Containers

Você pode atualizar o Migration Toolkit for Containers (MTC) no OpenShift Container Platform 4.10 usando o Operator Lifecycle Manager.

Para atualizar o MTC no OpenShift Container Platform 3, reinstale o Migration Toolkit for Containers Operator herdado.

Importante

Se estiver atualizando a partir da versão 1.3 do MTC, realize um procedimento adicional para atualizar o recurso personalizado (VR) MigPlan.

8.1. Atualização do Migration Toolkit for Containers no OpenShift Container Platform 4.10

Você pode atualizar o Migration Toolkit for Containers (MTC) no OpenShift Container Platform 4.10 usando o Operator Lifecycle Manager.

Pré-requisitos

  • Você deve estar conectado como um usuário com os privilégios cluster-admin.

Procedimento

  1. No console do OpenShift Container Platform, navegue até OperatorsInstalled Operators.

    Os Operadores com atualização pendente exibem um status Upgrade available.

  2. Clique em Migration Toolkit for Containers Operator.
  3. Clique na guia Subscription. Todas as atualizações que exigem aprovação são exibidas ao lado de Upgrade Status. Por exemplo, pode ser exibida a mensagem 1 requires approval.
  4. Clique em 1 requires approval e, então, clique em Preview Install Plan.
  5. Analise os recursos listados como disponíveis para atualização e clique em Approve.
  6. Navegue de volta para a página Operators → Installed Operators para monitorar o progresso da atualização. Quando o processo for concluído, o status mudará para Succeeded e Up to date.
  7. Clique em Migration Toolkit for Containers Operator.
  8. Em Provided APIs, localize o bloco Migration Controller e clique em Create Instance.
  9. Clique em WorkloadsPods para verificar se os pods do MTC estão em execução.

8.2. Atualização do Migration Toolkit for Containers no OpenShift Container Platform 3

Para atualizar o Migration Toolkit for Containers no OpenShift Container Platform 3, instale manualmente o Migration Toolkit for Containers Operator herdado.

Pré-requisitos

  • Você deve estar conectado como um usuário com os privilégios cluster-admin.
  • Você deve ter acesso a registr.redhat.io.
  • Você deve ter podman instalado.

Procedimento

  1. Faça login em register.redhat.io com suas credenciais do Portal do Cliente da Red Hat:

    $ sudo podman login registry.redhat.io
  2. Faça download do arquivo operator.yml:

    $ sudo podman cp $(sudo podman create \
      registry.redhat.io/rhmtc/openshift-migration-legacy-rhel8-operator:v1.5.3):/operator.yml ./
  3. Substitua o Migration Toolkit for Containers Operator:

    $ oc replace --force -f operator.yml
  4. Dimensione a implantação migration-operator para 0 para interromper a implantação:

    $ oc scale -n openshift-migration --replicas=0 deployment/migration-operator
  5. Dimensione a implantação migration-operator para 1 para iniciar a implantação e aplicar as mudanças:

    $ oc scale -n openshift-migration --replicas=1 deployment/migration-operator
  6. Verifique se migration-operator foi atualizado:

    $ oc -o yaml -n openshift-migration get deployment/migration-operator | grep image: | awk -F ":" '{ print $NF }'
  7. Faça download do arquivo controller.yml:

    $ sudo podman cp $(sudo podman create \
      registry.redhat.io/rhmtc/openshift-migration-legacy-rhel8-operator:v1.5.3):/controller.yml ./
  8. Crie o objeto migration-controller:

    $ oc create -f controller.yml
  9. Se você adicionou anteriormente o cluster do OpenShift Container Platform 3 ao console web do MTC, será necessário atualizar o token da conta de serviço no console web, pois o processo de atualização exclui e restaura o namespace openshift-migration:

    1. Obtenha o token da conta de serviço:

      $ oc sa get-token migration-controller -n openshift-migration
    2. No console web do MTC, clique em Clusters.
    3. Clique no menu de opções kebab ao lado do cluster e selecione Edit.
    4. Digite o novo token da conta de serviço no campo Service account token.
    5. Clique em Update cluster e, então, clique em Close.
  10. Verifique se os pods do MTC estão em execução:

    $ oc get pods -n openshift-migration

8.3. Atualização do MTC 1.3 para a versão 1.6

Se estiver atualizando o Migration Toolkit for Containers (MTC) 1.3.x para a versão 1.6, você deverá atualizar o manifesto de recurso personalizado (CR) MigPlan no cluster onde o pod MigrationController está em execução.

Como os parâmetros indirectImageMigration e indirectVolumeMigration não existem no MTC 1.3, o valor padrão deles na versão 1.4 é false, o que significa que a migração direta de imagem e a migração direta de volume estão habilitadas. Como os requisitos de migração direta não são cumpridos, o plano de migração não pode atingir um estado Ready a menos que esses valores de parâmetro sejam alterados para true.

Pré-requisitos

  • Você deve estar conectado como um usuário com os privilégios cluster-admin.

Procedimento

  1. Faça login no cluster onde o pod MigrationController está em execução.
  2. Obtenha o manifesto de CR MigPlan:

    $ oc get migplan <migplan> -o yaml -n openshift-migration
  3. Atualize os seguintes valores de parâmetro e salve o arquivo como migplan.yaml:

    ...
    spec:
      indirectImageMigration: true
      indirectVolumeMigration: true
  4. Substitua o manifesto de CR MigPlan para aplicar as mudanças:

    $ oc replace -f migplan.yaml -n openshift-migration
  5. Obtenha o manifesto de CR MigPlan atualizado para verificar as mudanças:

    $ oc get migplan <migplan> -o yaml -n openshift-migration

Capítulo 9. Listas de verificação antes da migração

Antes de migrar suas cargas de trabalho de aplicativos com o Migration Toolkit for Containers (MTC), revise as listas de verificação a seguir.

9.1. Recursos

  • ❏ Se seu aplicativo utiliza uma rede de serviços interna ou uma rota externa para se comunicar com os serviços, a rota relevante existe.
  • ❏ Se seu aplicativo utiliza recursos no nível do cluster, você os recriou no cluster de destino.
  • ❏ Você excluiu volumes persistentes (PVs), fluxos de imagem e outros recursos que não deseja migrar.
  • ❏ Foi feito um backup dos dados do PV para o caso de um aplicativo apresentar um comportamento inesperado após a migração e os dados serem corrompidos.

9.2. Cluster de origem

  • ❏ O cluster atende aos requisitos mínimos de hardware.
  • ❏ Você instalou a versão herdada correta do Migration Toolkit for Containers Operator:

    • operator-3.7.yml na versão 3.7 do OpenShift Container Platform.
    • operator.yml versões 3.9 a 4.5 do OpenShift Container Platform.
  • ❏ A versão do MTC é a mesma em todos os clusters.
  • ❏ Todos os nós têm uma assinatura ativa do OpenShift Container Platform.
  • ❏ Você já executou todas as tarefas de execução única.
  • ❏ Você já realizou todas as verificações de integridade ambiental.
  • ❏ Você verificou a existência de PVs com configurações anormais travados em um estado Terminating, executando o seguinte comando:

    $ oc get pv
  • ❏ Você verificou se há pods com um status diferente de Running ou Completed, executando o seguinte comando:

    $ oc get pods --all-namespaces | egrep -v 'Running | Completed'
  • ❏ Você verificou a existência de pods com uma alta contagem de reinicializações, executando o seguinte comando:

    $ oc get pods --all-namespaces --field-selector=status.phase=Running \
      -o json | jq '.items[]|select(any( .status.containerStatuses[]; \
      .restartCount > 3))|.metadata.name'

    Mesmo se os pods estiverem em um estado Running, uma alta contagem de reinicializações pode indicar problemas subjacentes.

  • ❏ Você removeu build, implantações e imagens antigas de todos os namespaces que serão migrados por prune.
  • ❏ O registro interno utiliza um tipo de armazenamento compatível.
  • ❏ Apenas migração direta de imagens: o registro interno está exposto ao tráfego externo.
  • ❏ Você pode ler e gravar imagens no registro.
  • ❏ O cluster etcd está íntegro.
  • ❏ O tempo médio de resposta do servidor de API no cluster de origem é inferior a 50 ms.
  • ❏ Os certificados do cluster são válidos por toda a duração do processo de migração.
  • ❏ Você verificou a existência de solicitações de assinatura de certificado pendentes, executando o seguinte comando:

    $ oc get csr -A | grep pending -i
  • ❏ O provedor de identidade está em execução.

9.3. Cluster de destino

  • ❏ Você instalou o Migration Toolkit for Containers Operator versão 1.5.1.
  • ❏ Todos os pré-requisitos do MTC foram atendidos.
  • ❏ O cluster atende aos requisitos mínimos de hardware para a plataforma específica e o método de instalação; por exemplo, em bare-metal.
  • ❏ O cluster tem classes de armazenamento definidas para os tipos de armazenamento utilizados pelo cluster de origem; por exemplo, volume de blocos, sistema de arquivos ou armazenamento de objetos.

    Nota

    NFS não requer uma classe de armazenamento definida.

  • ❏ O cluster tem a configuração de rede e as permissões corretas para acessar serviços externos — por exemplo, bancos de dados, repositórios de códigos fontes, registros de imagens de contêineres e ferramentas de CI/CD.
  • ❏ Aplicativos e serviços externos que utilizam serviços fornecidos pelo cluster têm a configuração de rede e as permissões corretas para acessar o cluster.
  • ❏ As dependências internas da imagem do contêiner são atendidas.

    Se um aplicativo utiliza uma imagem interna no namespace openshift incompatível com o OpenShift Container Platform 4.10, é possível atualizar manualmente a tag do fluxo de imagem do OpenShift Container Platform 3 com podman.

  • ❏ O cluster de destino e o repositório de replicação têm espaço de armazenamento suficiente.
  • ❏ O provedor da identidade está funcionando.
  • ❏ Os registros DNS para o seu aplicativo existem no cluster de destino.
  • ❏ Defina o valor do parâmetro annotation.openshift.io/host.generate como true para cada rota do OpenShift Container Platform, a fim de atualizar o nome do host do cluster de destino. Caso contrário, as rotas migradas conservarão o nome do host do cluster de origem.
  • ❏ Certificados utilizados por seu aplicativo existem no cluster de destino.
  • ❏ Você configurou regras de firewall apropriadas no cluster de destino.
  • ❏ Você configurou corretamente o balanceamento de carga no cluster de destino.
  • ❏ Se você migrar objetos para um namespace existente no cluster de destino que tenha o mesmo nome do namespace sendo migrado da fonte, o namespace de destino não contém objetos com um nome e um tipo idênticos aos dos objetos sendo migrados.

    Nota

    Não crie namespaces para seu aplicativo no cluster de destino antes da migração, pois isso pode causar mudanças de cotas.

9.4. Desempenho

  • ❏ A rede da migração tem uma taxa de transferência mínima de 10 Gbps.
  • ❏ Os clusters têm recursos suficientes para a migração.

    Nota

    Os clusters exigem memória, CPUs e armazenamento adicionais para executar uma migração em adição às cargas de trabalho normais. As necessidades reais de recursos dependem do número de recursos do Kubernetes que estão sendo migrados em um único plano de migração. É necessário testar as migrações em um ambiente de não produção, para estimar as necessidades de recursos.

  • ❏ A memória e o uso da CPU dos nós estão íntegros.
  • ❏ O desempenho do disco do etcd dos clusters foi verificado com fio.

Capítulo 10. Migração dos aplicativos

Você pode migrar seus aplicativos usando o console web do Migration Toolkit for Containers (MTC) ou a linha de comando.

É possível usar a migração em etapas e a migração de substituição para migrar um aplicativo entre clusters:

  • A migração em etapas copia os dados do cluster de origem para o cluster de destino sem interromper o aplicativo. Você pode executar uma migração em etapas várias vezes para reduzir a duração da migração de substituição.
  • A migração de substituição interrompe as transações no cluster de origem e move os recursos para o cluster de destino.

É possível usar a migração de estado para migrar o estado de um aplicativo:

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

A maioria dos recursos com escopo de cluster ainda não é manipulada pelo MTC. Se seus aplicativos exigem recursos com escopo de cluster, talvez seja necessário criá-los manualmente no cluster de destino.

Durante a migração, o MTC preserva as seguintes anotações de namespace:

  • openshift.io/sa.scc.mcs
  • openshift.io/sa.scc.supplemental-groups
  • openshift.io/sa.scc.uid-range

Essas anotações preservam o intervalo de UID, assegurando que os contêineres mantenham suas permissões de sistema de arquivos no cluster de destino. Há um risco de que as UIDs migradas possam duplicar as UIDs em um namespace existente ou futuro no cluster de destino.

10.1. Pré-requisitos para a migração

  • Você deve estar conectado como um usuário com os privilégios cluster-admin em todos os clusters.

Migração direta de imagem

  • Você deve garantir que o registro interno seguro do cluster de origem esteja exposto.
  • Você deve criar uma rota ao registro exposto.

Migração direta de volume

  • Se seus clusters utilizam proxies, você deve configurar um proxy TCP Stunnel.

Imagens internas

  • Se seu aplicativo utiliza imagens internas do namespace openshift, você deve garantir que as versões necessárias das imagens estejam presentes no cluster de destino.

    É possível atualizar manualmente uma tag de fluxo de imagem para usar uma imagem obsoleta do OpenShift Container Platform 3 em um cluster do OpenShift Container Platform 4.10.

Clusters

  • O cluster de origem deve ser atualizado para a versão mais recente do MTC z-stream.
  • A versão do MTC deve ser a mesma em todos os clusters.

Rede

  • Os clusters têm acesso de rede irrestrito uns aos outros e ao repositório de replicação.
  • Se você copiar os volumes persistentes com move, os clusters deverão ter acesso de rede irrestrito aos volumes remotos.
  • Você deve habilitar as seguintes portas em um cluster do OpenShift Container Platform 3:

    • 8443 (servidor de API)
    • 443 (rotas)
    • 53 (DNS)
  • Você deve habilitar as seguintes portas em um cluster do OpenShift Container Platform 4:

    • 6443 (servidor de API)
    • 443 (rotas)
    • 53 (DNS)
  • Você deverá habilitar a porta 443 no repositório de replicação se estiver usando TLS.

Volumes persistentes (PVs)

  • Os PVs devem ser válidos.
  • Os PVs devem estar vinculados a reivindicações de volume persistente.
  • Se você usar snapshots para copiar os PVs, os seguintes pré-requisitos adicionais serão aplicáveis:

    • O provedor de nuvem deve dar suporte a snapshots.
    • Os PVs devem ter o mesmo provedor de nuvem.
    • Os PVs devem estar localizados na mesma região geográfica.
    • Os PVs devem ter a mesma classe de armazenamento.

Recursos adicionais para os pré-requisitos de migração

10.2. Migração de aplicativos usando o console web do MTC

Você pode configurar clusters e um repositório de replicação usando o console web do MTC. Então, poderá criar e executar um plano de migração.

10.2.1. Inicialização do console web do MTC

Você pode iniciar o console web do Migration Toolkit for Containers (MTC) em um navegador.

Pré-requisitos

  • O console web do MTC deve ter acesso à rede do console web do OpenShift Container Platform.
  • O console web do MTC deve ter acesso à rede do servidor de autorização OAuth.

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.

10.2.2. Adição de um cluster ao console web do MTC

Você pode adicionar um cluster ao console web do Migration Toolkit for Containers (MTC).

Pré-requisitos

  • Se estiver usando snapshots do Azure para copiar dados:

    • Você deve especificar o nome do grupo de recursos do Azure para o cluster.
    • Os clusters devem estar no mesmo grupo de recursos do Azure.
    • Os clusters devem estar na mesma localização geográfica.
  • Se estiver usando a migração direta de imagem, você deverá expor uma rota ao registro de imagens do cluster de origem.

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.

10.2.3. Adição do repositório de replicação ao console web do MTC

Você pode adicionar um armazenamento de objetos como um repositório de replicação ao web console do Migration Toolkit for Containers (MTC).

O MTC é compatível com os seguintes provedores de armazenamento:

  • Amazon Web Services (AWS) S3
  • Multi-Cloud Object Gateway (MCG)
  • Armazenamento genérico de objetos S3, como Minio ou Ceph S3
  • Google Cloud Provider (GCP)
  • Microsoft Azure Blob

Pré-requisitos

  • Você deve configurar o armazenamento de objetos como um repositório de replicação.

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.

10.2.4. Criação de um plano de migração no console web do MTC

Você pode criar um plano de migração no console web do Migration Toolkit for Containers (MTC).

Pré-requisitos

  • Você deve estar conectado como um usuário com os privilégios cluster-admin em todos os clusters.
  • Você deve garantir que a mesma versão do MTC esteja instalada em todos os clusters.
  • Você deve adicionar os clusters e o repositório de replicação ao console web do MTC.
  • Se quiser usar o método de cópia de dados move para migrar um volume persistente (PV), os clusters de origem e de destino devem ter acesso de rede ininterrupto ao volume remoto.
  • Se quiser usar a migração direta de imagem, especifique a rota exposta ao registro de imagem do cluster de origem. Isso pode ser feito usando o console web do MTC ou atualizando o manifesto de recurso personalizado MigCluster.

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.

Recursos adicionais

10.2.5. Execução de um plano de migração no console web do MTC

Você pode migrar aplicativos e dados com o plano de migração que criou no console web do Migration Toolkit for Containers (MTC).

Nota

Durante a migração, o MTC define a política de recuperação de volumes persistentes (PVs) migrados como Retain no cluster de destino.

O recurso personalizado Backup contém uma anotação PVOriginalReclaimPolicy que indica a política de recuperação original. Você pode restaurar manualmente a política de recuperação dos PVs migrados.

Pré-requisitos

O console web do MTC deve conter o seguinte:

  • O cluster de origem em um estado Ready
  • O cluster de destino em estado de Ready
  • Repositório de replicação
  • Plano de migração válido

Procedimento

  1. Faça login no console web do MTC e clique em Migration plans.
  2. Clique no menu de opções kebab , 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 HomeProjects.
    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 WorkloadsPods para verificar se os pods estão em execução no namespace migrado.
    5. Clique em StoragePersistent volumes para verificar se os volumes persistentes migrados estão corretamente provisionados.

Capítulo 11. Opções avançadas de migração

Você pode automatizar suas migrações e modificar os recursos personalizados MigPlan e MigrationController para fazer migrações em larga escala e melhorar o desempenho.

11.1. Terminologia

Tabela 11.1. Terminologia do MTC

TermoDefinição

Cluster de origem

O cluster a partir do qual os aplicativos são migrados.

Cluster de destino[1]

O cluster para o qual os aplicativos são migrados.

Repositório de replicação

Armazenamento de objetos usado para copiar imagens, volumes e objetos do Kubernetes durante a migração indireta ou para objetos do Kubernetes durante a migração direta de volumes ou migração direta de imagens.

O repositório de replicação deve ser acessível a todos os clusters.

Cluster de host

O cluster no qual o pod migration-controller e o console web estão em execução. Geralmente, o cluster de host é o cluster de destino, mas isso não é obrigatório.

O cluster de host não requer uma rota de registro exposto para a migração direta da imagem.

Cluster remoto

Um cluster remoto é geralmente o cluster de origem, mas isso não é necessário.

Um cluster remoto requer um recurso personalizado Secret que contenha o token de conta de serviço migration-controller.

Um cluster remoto requer uma rota de registro segura exposta para a migração direta da imagem.

Migração indireta

Imagens, volumes e objetos do Kubernetes são copiados 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.

Migração direta de volume

Os volumes persistentes são copiados diretamente do cluster de origem para o cluster de destino.

Migração direta de imagem

As imagens são copiadas diretamente do cluster de origem para o cluster de destino.

Migração em etapas

Os dados são copiados para o cluster de destino sem interromper o aplicativo.

Executar várias vezes uma migração em etapas reduz a duração da migração de substituição.

Migração de substituição

O aplicativo é interrompido no cluster de origem e os recursos dele são migrados para o cluster de destino.

Migração de estado

O estado do aplicativo é migrado copiando as reivindicações específicas de volume persistente e os objetos do Kubernetes para o cluster de destino.

Migração de reversão

A migração de reversão reverte uma migração concluída.

1 Chamado de cluster alvo no console web do MTC.

11.2. Migração de aplicativos usando a linha de comando

Você pode migrar aplicativos com o API do MTC usando a interface de linha de comando (CLI) para automatizar a migração.

11.2.1. Pré-requisitos para a migração

  • Você deve estar conectado como um usuário com os privilégios cluster-admin em todos os clusters.

Migração direta de imagem

  • Você deve garantir que o registro interno seguro do cluster de origem esteja exposto.
  • Você deve criar uma rota ao registro exposto.

Migração direta de volume

  • Se seus clusters utilizam proxies, você deve configurar um proxy TCP Stunnel.

Imagens internas

  • Se seu aplicativo utiliza imagens internas do namespace openshift, você deve garantir que as versões necessárias das imagens estejam presentes no cluster de destino.

    É possível atualizar manualmente uma tag de fluxo de imagem para usar uma imagem obsoleta do OpenShift Container Platform 3 em um cluster do OpenShift Container Platform 4.10.

Clusters

  • O cluster de origem deve ser atualizado para a versão mais recente do MTC z-stream.
  • A versão do MTC deve ser a mesma em todos os clusters.

Rede

  • Os clusters têm acesso de rede irrestrito uns aos outros e ao repositório de replicação.
  • Se você copiar os volumes persistentes com move, os clusters deverão ter acesso de rede irrestrito aos volumes remotos.
  • Você deve habilitar as seguintes portas em um cluster do OpenShift Container Platform 3:

    • 8443 (servidor de API)
    • 443 (rotas)
    • 53 (DNS)
  • Você deve habilitar as seguintes portas em um cluster do OpenShift Container Platform 4:

    • 6443 (servidor de API)
    • 443 (rotas)
    • 53 (DNS)
  • Você deverá habilitar a porta 443 no repositório de replicação se estiver usando TLS.

Volumes persistentes (PVs)

  • Os PVs devem ser válidos.
  • Os PVs devem estar vinculados a reivindicações de volume persistente.
  • Se você usar snapshots para copiar os PVs, os seguintes pré-requisitos adicionais serão aplicáveis:

    • O provedor de nuvem deve dar suporte a snapshots.
    • Os PVs devem ter o mesmo provedor de nuvem.
    • Os PVs devem estar localizados na mesma região geográfica.
    • Os PVs devem ter a mesma classe de armazenamento.

11.2.2. Criação de uma rota de registro para migração direta de imagem

Para a migração direta de imagem, você deve criar uma rota para o registro interno exposto em todos os clusters remotos.

Pré-requisitos

  • O registro interno deve estar exposto ao tráfego externo em todos os clusters remotos.

    O registro do OpenShift Container Platform 4 é exposto por padrão.

    O registro do OpenShift Container Platform 3 deve ser exposto manualmente.

Procedimento

  • Para criar uma rota para um registro do OpenShift Container Platform 3, execute o seguinte comando:

    $ oc create route passthrough --service=docker-registry -n default
  • Para criar uma rota para um registro do OpenShift Container Platform 4, execute o seguinte comando:

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

11.2.3. Configuração de proxies

Para o OpenShift Container Platform 4.1 e versões anteriores, é necessário configurar proxies no manifesto de recurso personalizado (CR) MigrationController depois da instalação do Migration Toolkit for Containers Operator, pois essas versões não são compatíveis com um objeto proxy de todo o cluster.

Para o OpenShift Container Platform 4.2 a 4.10, o Migration Toolkit for Containers (MTC) herda as configurações de proxy do cluster. Você poderá alterar os parâmetros do proxy se desejar substituir as configurações do proxy do cluster.

É necessário configurar os proxies para permitir o protocolo SPDY e encaminhar o cabeçalho Upgrade HTTP para o servidor de API. Caso contrário, será exibido um erro Upgrade request required. O CR MigrationController usa SPDY para executar comandos em pods remotos. O cabeçalho Upgrade HTTP é necessário para abrir uma conexão websocket com o servidor de API.

Migração direta de volume

Se você estiver realizando uma migração direta de volume (DVM) a partir de um cluster de origem atrás de um proxy, será necessário configurar um proxy Stunnel. O Stunnel cria um túnel transparente entre os clusters de origem e de destino para a conexão TCP sem alterar os certificados.

A DVM permite apenas um proxy. O cluster de origem não poderá acessar a rota do cluster de destino se o cluster de destino também estiver atrás de um proxy.

Pré-requisitos

  • Você deve estar conectado como um usuário com os privilégios cluster-admin em todos os clusters.

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

11.2.4. Migração de aplicativos usando a API do MTC

Você pode migrar um aplicativo a partir da linha de comando usando a API do Migration Toolkit for Containers (MTC).

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

11.2.5. Migração de estado

Você pode realizar migrações repetíveis somente de estado usando o Migration Toolkit for Containers (MTC) para migrar reivindicações de volume persistente (PVCs) que constituem o estado de um aplicativo. Para migrar as PVCs especificadas, exclua as outras PVCs do plano de migração. Os dados do volume persistente (PV) são copiados para o cluster de destino. As referências do PV não são movidas. Os pods do aplicativo continuam em execução no cluster de origem. É possível mapear as PVCs para garantir que as PVCs de origem e de destino estejam sincronizados.

Você pode realizar uma migração única de objetos do Kubernetes que constituem o estado de um aplicativo.

Se tiver um pipeline de CI/CD, você poderá migrar componentes sem estado, implantando-os no cluster de destino. Então, você poderá migrar os componentes com estado usando o MTC.

É possível realizar uma migração de estado entre clusters ou dentro do mesmo cluster.

Importante

A migração de estado migra apenas os componentes que constituem o estado de um aplicativo. Se deseja migrar um namespace inteiro, use a migração em etapas ou de substituição.

Recursos adicionais

11.3. Hooks de migração

Você pode adicionar até quatro hooks de migração a um único plano de migração, com cada hook sendo executado em uma etapa diferente da migração. Os hooks de migração realizam tarefas como personalização da inatividade dos aplicativos, migração manual de tipos de dados sem suporte e atualização de aplicativos após a migração.

Um hook de migração é executado em um cluster de origem ou de destino, em uma das seguintes etapas de migração:

  • PreBackup: antes que o backup dos recursos seja feito no cluster de origem.
  • PostBackup: depois que o backup dos recursos for feito no cluster de origem.
  • PreRestore: antes que os recursos sejam restaurados no cluster de destino.
  • PostRestore: depois que os recursos forem restaurados no cluster de destino.

É possível criar um hook criando um playbook do Ansible que seja executado com a imagem padrão do Ansible ou com um contêiner de hook personalizado.

Playbook do Ansible

O playbook do Ansible é montado em um contêiner de hook como um mapa de configuração. O contêiner de hook é executado como um trabalho, usando o cluster, a conta de serviço e o namespace especificados no recurso personalizado MigPlan. O trabalho continua a ser executado até atingir o limite padrão de 6 tentativas ou uma conclusão com êxito. Isso prosseguirá mesmo se o pod inicial for removido ou encerrado.

A imagem padrão do tempo de execução do Ansible é registry.redhat.io/rhmtc/openshift-migration-hook-runner-rhel7:1.6. Essa imagem é baseada na imagem do Ansible Runner e inclui python-openshift para recursos do Kubernetes para o Ansible e um binário oc atualizado.

Contêiner de hook personalizado

É possível usar um contêiner de hook personalizado em vez da imagem padrão do Ansible.

11.3.1. Criação de playbook do Ansible para um hook de migração

Você pode criar um playbook do Ansible para usar como um hook de migração. O hook é adicionado a um plano de migração usando o console web do MTC ou especificando valores para os parâmetros spec.hooks no manifesto de recurso personalizado (CR) MigPlan.

O playbook do Ansible é montado em um contêiner de hook como um mapa de configuração. O contêiner do hook é executado como um trabalho, usando o cluster, a conta de serviço e o namespace especificados no CR MigPlan. O contêiner do hook usa um token de conta de serviço especificado para que as tarefas não exijam autenticação antes de serem executadas no cluster.

11.3.1.1. Módulos do Ansible

Você pode usar o módulo shell do Ansible para executar comandos oc.

Exemplo de módulo shell

- hosts: localhost
  gather_facts: false
  tasks:
  - name: get pod name
    shell: oc get po --all-namespaces

Você pode usar os módulos kubernetes.core, como k8s_info, para interagir com os recursos do Kubernetes.

Exemplo de módulo k8s_facts

- hosts: localhost
  gather_facts: false
  tasks:
  - name: Get pod
    k8s_info:
      kind: pods
      api: v1
      namespace: openshift-migration
      name: "{{ lookup( 'env', 'HOSTNAME') }}"
    register: pods

  - name: Print pod name
    debug:
      msg: "{{ pods.resources[0].metadata.name }}"

Você pode usar o módulo fail para produzir um status de saída não zero nos casos em que um status de saída não zero normalmente não seria produzido, assegurando que o êxito ou a falha de um hook sejam detectados. Os hooks são executados como trabalhos e o status de êxito ou falha de um hook é baseado no status de saída do contêiner do trabalho.

Exemplo de módulo falha

- hosts: localhost
  gather_facts: false
  tasks:
  - name: Set a boolean
    set_fact:
      do_fail: true

  - name: "fail"
    fail:
      msg: "Cause a failure"
    when: do_fail

11.3.1.2. Variáveis de ambiente

O nome do CR MigPlan e os namespaces de migração são passados como variáveis de ambiente ao contêiner do hook. Essas variáveis são acessadas usando o plugin lookup.

Exemplo de variáveis de ambiente

- hosts: localhost
  gather_facts: false
  tasks:
  - set_fact:
      namespaces: "{{ (lookup( 'env', 'migration_namespaces')).split(',') }}"

  - debug:
      msg: "{{ item }}"
    with_items: "{{ namespaces }}"

  - debug:
      msg: "{{ lookup( 'env', 'migplan_name') }}"

11.4. Opções do plano de migração

Você pode excluir, editar e mapear componentes no recurso personalizado (CR) MigPlan.

11.4.1. Exclusão de recursos

Você pode excluir recursos (por exemplo, fluxos de imagens, volumes persistentes (PVs) ou subscrições) de um plano de migração do Migration Toolkit for Containers (MTC) para reduzir a carga de recursos da migração ou para migrar imagens ou PVs com uma ferramenta diferente.

Por padrão, o MTC exclui da migração os recursos do catálogo de serviços e os recursos do Operator Lifecycle Manager (OLM). Esses recursos fazem parte do grupo API do catálogo de serviços e do grupo OLM API, nenhum dos quais é compatível com a migração no momento.

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

11.4.2. Mapeamento de namespaces

Se você mapear namespaces no recurso personalizado (CR) MigPlan, garanta que os namespaces não estejam duplicados nos clusters de origem ou de destino, pois os intervalos de UID e GID dos namespaces são copiados durante a migração.

Dois namespaces de origem mapeados para o mesmo namespace de destino

spec:
  namespaces:
    - namespace_2
    - namespace_1:namespace_2

Se quiser que o namespace de origem seja mapeado para um namespace com o mesmo nome, você não precisa criar um mapeamento. Por padrão, um namespace de origem e um namespace de destino têm o mesmo nome.

Mapeamento incorreto de namespace

spec:
  namespaces:
    - namespace_1:namespace_1

Referência correta de namespace

spec:
  namespaces:
    - namespace_1

11.4.3. Exclusão de reivindicações de volume persistente

Você seleciona as reivindicações de volume persistente (PVCs) para a migração de estado excluindo as PVCs que não deseja migrar. Para excluir PVCs, defina o parâmetro spec.persistentVolumes.pvc.selection.action do recurso personalizado (CR) MigPlan depois da descoberta dos volumes persistentes (PVs).

Pré-requisitos

  • O CR MigPlan está em um estado Ready.

Procedimento

  • Adicione o parâmetro spec.persistentVolumes.pvc.selection.action ao CR MigPlan defina-o como skip:

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigPlan
    metadata:
      name: <migplan>
      namespace: openshift-migration
    spec:
    ...
      persistentVolumes:
      - capacity: 10Gi
        name: <pv_name>
        pvc:
    ...
        selection:
          action: skip

11.4.4. Mapeamento de reivindicações de volume persistente

Você pode migrar dados de volumes persistentes (PV) do cluster de origem para reivindicações de volume persistente (PVCs) que já estão provisionadas no cluster de destino no CR MigPlan mapeando as PVCs. Esse mapeamento garante que as PVCs de destino dos aplicativos migradas sejam sincronizados com as PVCs de origem.

Para mapear PVCs, atualize o parâmetro spec.persistentVolumes.pvc.name no recurso personalizado (CR) MigPlan depois da descoberta dos PVs.

Pré-requisitos

  • O CR MigPlan está em um estado Ready.

Procedimento

  • Atualize o parâmetro spec.persistentVolumes.pvc.name no CR MigPlan:

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigPlan
    metadata:
      name: <migplan>
      namespace: openshift-migration
    spec:
    ...
      persistentVolumes:
      - capacity: 10Gi
        name: <pv_name>
        pvc:
          name: <source_pvc>:<destination_pvc> 1
    1
    Especifique a PVC no cluster de origem e a PVC no cluster de destino. Se a PVC de destino não existir, ele será criada. Você pode usar esse mapeamento para mudar o nome da PVC durante a migração.

11.4.5. Edição de atributos de volume persistente

Depois de criar um recurso personalizado (CR) MigPlan, o CR MigrationController descobre os volumes persistentes (PVs). Os blocos spec.persistentVolumes e status.destStorageClasses são adicionados ao CR MigPlan.

É possível editar os valores no bloco spec.persistentVolumes.selection. Se você alterar valores fora do bloco spec.persistentVolumes.selection, os valores serão substituídos quando o CR MigPlan for reconciliado pelo CR MigrationController.

Nota

O valor padrão do parâmetro spec.persistentVolumes.selection.storageClass é determinado pela seguinte lógica:

  1. Se o PV do cluster de origem for Gluster ou NFS, o padrão será cephfs, para accessMode: ReadWriteMany, ou cephrbd, para accessMode: ReadWriteOnce.
  2. Se o PV não for Gluster nem NFS, ou se ceffs ou cephrbd não estiverem disponíveis, o padrão será uma classe de armazenamento do mesmo provisionador.
  3. Se uma classe de armazenamento para o mesmo provisionador não estiver disponível, o padrão será a classe de armazenamento padrão do cluster de destino.

É possível alterar o valor de storageClass para o valor de qualquer parâmetro name no bloco status.destStorageClasses do CR MigPlan.

Se o valor de storageClass estiver vazio, o PV não terá classe de armazenamento após a migração. Essa opção é apropriada se, por exemplo, você quiser mover o PV para um volume NFS no cluster de destino.

Pré-requisitos

  • O CR MigPlan está em um estado Ready.

Procedimento

  • Edite os valores de spec.persistentVolumes.selection no CR MigPlan:

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigPlan
    metadata:
      name: <migplan>
      namespace: openshift-migration
    spec:
      persistentVolumes:
      - capacity: 10Gi
        name: pvc-095a6559-b27f-11eb-b27f-021bddcaf6e4
        proposedCapacity: 10Gi
        pvc:
          accessModes:
          - ReadWriteMany
          hasReference: true
          name: mysql
          namespace: mysql-persistent
        selection:
          action: <copy> 1
          copyMethod: <filesystem> 2
          verify: true 3
          storageClass: <gp2> 4
          accessMode: <ReadWriteMany> 5
        storageClass: cephfs
    1
    Os valores permitidos são move, copy e skip. Se apenas uma ação for suportada, o valor padrão será a ação suportada. Se várias ações forem suportadas, o valor padrão será copy.
    2
    Os valores permitidos são snapshot e filesystem. O valor padrão é filesystem.
    3
    O parâmetro verify será exibido se você selecionar a opção de verificação para cópia de sistema de arquivos no console web do MTC. Você pode defini-lo como false.
    4
    É possível alterar o valor padrão para o valor de qualquer parâmetro name no bloco status.destStorageClasses do CR MigPlan. Se nenhum valor for especificado, o PV não terá classe de armazenamento após a migração.
    5
    Os valores permitidos são ReadWriteOnce e ReadWriteMany. Se esse valor não for especificado, o padrão será o modo de acesso da PVC do cluster de origem. Só é possível editar o modo de acesso no CR MigPlan. Não é possível editá-lo usando o console web do MTC.
Recursos adicionais

11.4.6. Migração de objetos do Kubernetes

Você pode realizar uma migração única de objetos do Kubernetes que constituem o estado de um aplicativo.

Nota

Após a migração, o parâmetro closed do CR MigPlan é definido como true. Você não pode criar outro CR MigMigration para esse CR MigPlan.

Para adicionar objetos do Kubernetes ao CR MigPlan, use uma das seguintes opções:

  • Adicionar objetos do Kubernetes à seção includedResources.
  • Usar o parâmetro labelSelector para referenciar objetos do Kubernetes rotulados.
  • Adicionar objetos do Kubernetes à seção includedResources e, então, filtrá-los com o parâmetro labelSelector; por exemplo, os recursos Secret e ConfigMap com o rótulo app: frontend.

Procedimento

  • Atualize o CR MigPlan:

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigPlan
    metadata:
      name: <migplan>
      namespace: openshift-migration
    spec:
      includedResources:
      - kind: <kind> 1
        group: ""
      - kind: <kind>
        group: ""
    ...
      labelSelector:
        matchLabels:
          <label> 2
    1
    Especifique o objeto do Kubernetes; por exemplo, Secret ou ConfigMap.
    2
    Especifique o rótulo dos recursos a serem migrados; por exemplo, app: frontend.

11.5. Opções do controlador de migração

Você pode editar os limites do plano de migração, permitir o redimensionamento do volume persistente ou habilitar clientes Kubernetes em cache no recurso personalizado (CR) MigrationController para migrações grandes e para ter um desempenho melhor.

11.5.1. Aumento de limites para migrações grandes

Você pode aumentar os limites em objetos de migração e recursos de contêineres para migrações grandes com o Migration Toolkit for Containers (MTC).

Importante

Teste essas mudanças antes de realizar uma migração em um ambiente de produção.

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.

11.5.2. Habilitação de redimensionamento de volume persistente para migração direta de volume

Você pode habilitar o redimensionamento de volume persistente (PV) para migração direta de volume com o objetivo de evitar que o espaço em disco no cluster de destino acabe.

Quando o uso do disco de um PV atinge um nível configurado, o recurso personalizado (CR) MigrationController compara a capacidade de armazenamento solicitado de uma reivindicação de volume persistente (PVC) à capacidade real provisionada. Em seguida, ele calcula o espaço necessário no cluster de destino.

Um parâmetro pv_resizing_threshold determina quando o redimensionamento de PV é usado. O limite padrão é de 3%. Isso significa que o redimensionamento do PV ocorre quando o uso do disco do PV é superior a 97%. É possível aumentar esse limite para que o redimensionamento de PV ocorra em um nível mais baixo de uso do disco.

A capacidade da PVC é calculada de acordo com os seguintes critérios:

  • Se a capacidade de armazenamento solicitado (spec.resources.requests.storage) da PVC não for igual à sua capacidade real provisionada (status.capacity.storage), será utilizado o maior valor.
  • Se um PV for provisionado por meio de uma PVC e, posteriormente, for alterado de modo que suas capacidades de PV e PVC não mais correspondam, o maior valor será utilizado.

Pré-requisitos

  • As PVCs devem ser anexadas a um ou mais pods em execução para que o CR MigrationController possa executar comandos.

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)

11.5.3. Habilitação de clientes Kubernetes em cache

Você pode habilitar clientes Kubernetes em cache no recurso personalizado (CR) MigrationController para ter um desempenho melhor durante a migração. O maior benefício de desempenho ocorre quando a migração é feita entre clusters em diferentes regiões ou com latência de rede significativa.

Nota

No entanto, tarefas delegadas, como backup Rsync para migração direta de volume ou o backup e restauração do Velero, não mostram um desempenho melhor com clientes em cache.

Clientes em cache exigem memória extra porque o CR MigrationController armazena em cache todos os recursos de API necessários para interagir com os CRs MigCluster. As solicitações que, normalmente, são enviadas ao servidor de API são direcionadas para o cache. O cache vigia o servidor de API para atualizações.

Você poderá aumentar os limites de memória e as solicitações do CR MigrationController se os erros OOMKilled ocorrerem depois da habilitação dos clientes em cache.

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>}]'

Capítulo 12. Solução de problemas

Esta seção descreve os recursos de solução de problemas do Migration Toolkit for Containers (MTC).

Para problemas conhecidos, consulte as notas de lançamento do MTC.

12.1. Fluxo de trabalho do MTC

Você pode migrar os recursos do Kubernetes, dados de volumes persistentes e imagens de contêineres internos para o OpenShift Container Platform 4.10 usando o console web do Migration Toolkit for Containers (MTC) ou a API do Kubernetes.

O MTC migra os seguintes recursos:

  • Um namespace especificado em um plano de migração.
  • Recursos com escopo de namespace: quando o MTC migra um namespace, ele migra todos os objetos e recursos associados a esse namespace, como serviços ou pods. Além disso, se um recurso que existe no namespace, mas não no nível do cluster, depender de um recurso no nível do cluster, o MTC migrará ambos os recursos.

    Por exemplo, uma restrição de contexto de segurança (SCC) é um recurso que existe no nível do cluster, e uma conta de serviço (SA) é um recurso que existe no nível do namespace. Se uma SA existir em um namespace migrado pelo MTC, o MTC localizará automaticamente quaisquer SCCs que estejam ligadas à SA e também as migrará. Da mesma maneira, o MTC migra reivindicações de volumes persistentes vinculadas aos volumes persistentes do namespace.

    Nota

    Talvez seja necessário migrar manualmente recursos com escopo de cluster, dependendo do recurso.

  • Recursos personalizados (CRs) e definições de recursos personalizados (CRDs): o MTC migra automaticamente CRs e CRDs no nível do namespace.

A migração de um aplicativo com o console web do MTC envolve as seguintes etapas:

  1. Instale o Migration Toolkit for Containers Operator em todos os clusters.

    É possível instalar o Migration Toolkit for Containers Operator em um ambiente restrito com acesso limitado ou sem acesso à internet. Os clusters de origem e de destino devem ter acesso uns aos outros pela rede e a um registro espelhado.

  2. Configure o repositório de replicação, um armazenamento de objetos intermediário que o MTC utiliza para migrar os dados.

    Os clusters de origem e de destino devem ter acesso à rede do repositório de replicação durante a migração. Se estiver usando um servidor proxy, você deverá configurá-lo para permitir o tráfego de rede entre o repositório de replicação e os clusters.

  3. Adicione o cluster de origem ao console web do MTC.
  4. Adicione o repositório de replicação ao console web do MTC.
  5. Crie um plano de migração, com uma das seguintes opções de migração de dados:

    • Copy: o MTC copia os dados do cluster de origem para o repositório de replicação, e do repositório de replicação para o cluster de destino.

      Nota

      Se estiver usando a migração direta de imagem ou a migração direta de volume, as imagens ou os volumes serão copiados diretamente do cluster de origem para o cluster de destino.

      migration PV copy
    • Move: o MTC 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. O volume remoto deve ser acessível aos clusters de origem e de destino.

      Nota

      Embora o repositório de replicação não apareça neste diagrama, ele é necessário para a migração.

      migration PV move
  6. Execute o plano de migração com uma das seguintes opções:

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

      É possível executar várias vezes uma migração em etapas para que a maioria dos dados seja copiada para o destino antes da migração. A execução de uma ou mais migrações em etapas reduz a duração da migração de substituição.

    • Cutover: interrompe o aplicativo no cluster de origem e move os recursos para o cluster de destino.

      Opcional: você pode desmarcar a caixa de seleção Halt transactions on the source cluster during migration.

Migração de aplicativos do OCP 3 para a versão 4

Sobre os recursos personalizados do MTC

O Migration Toolkit for Containers (MTC) cria os seguintes recursos personalizados (CRs):

diagrama da arquitetura de migração

20 MigCluster (configuração, cluster do MTC): definição de cluster

20 MigStorage (configuração, cluster do MTC): definição de armazenamento

20 MigPlan (configuração, cluster do MTC): plano de migração

O CR MigPlan descreve os clusters de origem e de destino, o repositório de replicação e os namespaces que estão sendo migrados. Ele é associado a 0, 1 ou muitos CR MigMigration.

Nota

A exclusão de um CR MigPlan exclui os CRs MigMigration associados.

20 BackupStorageLocation (configuração, cluster do MTC): local dos objetos de backup Velero

20 VolumeSnapshotLocation (configuração, cluster do MTC): local dos snapshots do volume Velero

20 MigMigration (ação, cluster do MTC): migração, criado sempre que você prepara ou migra dados. Cada CR MigMigration é associado a um CR MigPlan.

20 Backup (ação, cluster de origem): quando você executa um plano de migração, o CR MigMigration cria dois CRs de backup Velero em cada cluster de origem:

  • CR de backup #1 para objetos do Kubernetes
  • CR de backup #2 para dados de PV

20 Restore (ação, cluster de destino): quando você executa um plano de migração, o CR MigMigration cria dois CRs de restauração Velero no cluster de destino:

  • CR de restauração #1 (usando o CR de backup #2) para dados de PV
  • CR de restauração #2 (usando o CR de backup #1) para objetos do Kubernetes

12.2. Manifestos de recursos personalizados do MTC

O Migration Toolkit for Containers (MTC) utiliza os seguintes manifestos de recursos personalizados (CR) para migrar aplicativos.

12.2.1. DirectImageMigration

O CR DirectImageMigration copia as imagens diretamente do cluster de origem para o cluster de destino.

apiVersion: migration.openshift.io/v1alpha1
kind: DirectImageMigration
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: <direct_image_migration>
spec:
  srcMigClusterRef:
    name: <source_cluster>
    namespace: openshift-migration
  destMigClusterRef:
    name: <destination_cluster>
    namespace: openshift-migration
  namespaces: 1
    - <source_namespace_1>
    - <source_namespace_2>:<destination_namespace_3> 2
1
Um ou mais namespaces contendo imagens a serem migradas. Por padrão, o namespace de destino tem o mesmo nome do namespace de origem.
2
Namespace de origem mapeado para um namespace de destino com um nome diferente.

12.2.2. DirectImageStreamMigration

O CR DirectImageStreamMigration copia referências do fluxo de imagens diretamente do cluster de origem para o cluster de destino.

apiVersion: migration.openshift.io/v1alpha1
kind: DirectImageStreamMigration
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: <direct_image_stream_migration>
spec:
  srcMigClusterRef:
    name: <source_cluster>
    namespace: openshift-migration
  destMigClusterRef:
    name: <destination_cluster>
    namespace: openshift-migration
  imageStreamRef:
    name: <image_stream>
    namespace: <source_image_stream_namespace>
  destNamespace: <destination_image_stream_namespace>

12.2.3. DirectVolumeMigration

O CR DirectVolumeMigration copia volumes persistentes (PVs) diretamente do cluster de origem para o cluster de destino.

apiVersion: migration.openshift.io/v1alpha1
kind: DirectVolumeMigration
metadata:
  name: <direct_volume_migration>
  namespace: openshift-migration
spec:
  createDestinationNamespaces: false 1
  deleteProgressReportingCRs: false 2
  destMigClusterRef:
    name: <host_cluster> 3
    namespace: openshift-migration
  persistentVolumeClaims:
  - name: <pvc> 4
    namespace: <pvc_namespace>
  srcMigClusterRef:
    name: <source_cluster>
    namespace: openshift-migration
1
Defina como true para criar namespaces para os VPs no cluster de destino.
2
Defina como true para excluir os CRs DirectVolumeMigrationProgress após a migração. O padrão é false para que os CRs DirectVolumeMigrationProgress sejam mantidos para a solução de problemas.
3
Atualize o nome do cluster se o cluster de destino não for o cluster de host.
4
Especifique um ou mais PVCs a serem migrados.

12.2.4. DirectVolumeMigrationProgress

O CR DirectVolumeMigrationProgress mostra o progresso do CR DirectVolumeMigration.

apiVersion: migration.openshift.io/v1alpha1
kind: DirectVolumeMigrationProgress
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: <direct_volume_migration_progress>
spec:
  clusterRef:
    name: <source_cluster>
    namespace: openshift-migration
  podRef:
    name: <rsync_pod>
    namespace: openshift-migration

12.2.5. MigAnalytic

O CR MigAnalytic coleta o número de imagens, os recursos do Kubernetes e a capacidade de volume persistente (PV) de um CR MigPlan associado.

Você pode configurar os dados que ele coleta.

apiVersion: migration.openshift.io/v1alpha1
kind: MigAnalytic
metadata:
  annotations:
    migplan: <migplan>
  name: <miganalytic>
  namespace: openshift-migration
  labels:
    migplan: <migplan>
spec:
  analyzeImageCount: true 1
  analyzeK8SResources: true 2
  analyzePVCapacity: true 3
  listImages: false 4
  listImagesLimit: 50 5
  migPlanRef:
    name: <migplan>
    namespace: openshift-migration
1
Opcional: retorna o número de imagens.
2
Opcional: retorna o número, o tipo e a versão da API dos recursos do Kubernetes.
3
Opcional: retorna a capacidade do PV.
4
Retorna uma lista de nomes de imagens. O padrão é false para que a saída não seja excessivamente longa.
5
Opcional: especifique o número máximo de nomes de imagens que serão retornados se listImages for true.

12.2.6. MigCluster

O CR MigCluster define um cluster de host, local ou remoto.

apiVersion: migration.openshift.io/v1alpha1
kind: MigCluster
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: <host_cluster> 1
  namespace: openshift-migration
spec:
  isHostCluster: true 2
# The 'azureResourceGroup' parameter is relevant only for Microsoft Azure.
  azureResourceGroup: <azure_resource_group> 3
  caBundle: <ca_bundle_base64> 4
  insecure: false 5
  refresh: false 6
# The 'restartRestic' parameter is relevant for a source cluster.
  restartRestic: true 7
# The following parameters are relevant for a remote cluster.
  exposedRegistryPath: <registry_route> 8
  url: <destination_cluster_url> 9
  serviceAccountSecretRef:
    name: <source_secret> 10
    namespace: openshift-config
1
Atualize o nome do cluster se o pod migration-controller não estiver em execução nesse cluster.
2
O pod migration-controller estará em execução no cluster se o valor for true.
3
Somente Microsoft Azure: especifique o grupo de recursos.
4
Opcional: se você tiver criado um pacote de certificados para certificados CA autoassinados e se o valor do parâmetro insecure para false, especifique o pacote de certificados codificados em base64.
5
Defina como true para desabilitar a verificação SSL.
6
Defina como true para validar o cluster.
7
Defina como true para reiniciar os pods Restic no cluster de origem após a criação de pods Stage.
8
Somente cluster remoto e migração direta de imagem: especifique o caminho de registro seguro exposto.
9
Apenas cluster remoto: especifique a URL.
10
Apenas cluster remoto: especifique o nome do objeto Secret.

12.2.7. MigHook

O CR MigHook define um hook de migração que executa um código personalizado em uma etapa específica da migração. Você pode criar até quatro hooks de migração. Cada hook é executado durante uma fase diferente da migração.

Você pode configurar o nome do hook, a duração o tempo de execução, uma imagem personalizada e o cluster onde o hook será executado.

As fases de migração e os namespaces dos hooks são configurados no CR MigPlan.

apiVersion: migration.openshift.io/v1alpha1
kind: MigHook
metadata:
  generateName: <hook_name_prefix> 1
  name: <mighook> 2
  namespace: openshift-migration
spec:
  activeDeadlineSeconds: 1800 3
  custom: false 4
  image: <hook_image> 5
  playbook: <ansible_playbook_base64> 6
  targetCluster: source 7
1
Opcional: um hash exclusivo é anexado ao valor desse parâmetro para que cada hook de migração tenha um nome exclusivo. Não é necessário especificar o valor do parâmetro name.
2
Especifique o nome do hook de migração, a menos que você especifique o valor do parâmetro generateName.
3
Opcional: especifique o número máximo de segundos que um hook pode ser executado O padrão é 1800.
4
O hook será uma imagem personalizada se true. A imagem personalizada pode incluir Ansible ou ser criada em uma linguagem de programação diferente.
5
Especifique a imagem personalizada; por exemplo, quay.io/konveyor/hook-runner:latest. Obrigatório se custom for true.
6
Playbook do Ansible codificado em Base64. Obrigatório se custom for false.
7
Especifique o cluster no qual o hook será executado. Os valores válidos são source ou destination.

12.2.8. MigMigration

O CR MigMigration executa um CR MigPlan.

Você pode configurar um CR Migmigration para executar uma migração em etapas ou incremental, para cancelar uma migração em andamento ou para reverter uma migração concluída.

apiVersion: migration.openshift.io/v1alpha1
kind: MigMigration
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: <migmigration>
  namespace: openshift-migration
spec:
  canceled: false 1
  rollback: false 2
  stage: false 3
  quiescePods: true 4
  keepAnnotations: true 5
  verify: false 6
  migPlanRef:
    name: <migplan>
    namespace: openshift-migration
1
Defina como true para cancelar uma migração em andamento.
2
Defina como true para reverter uma migração concluída.
3
Defina como true para executar uma migração em etapas. Os dados são copiados de modo incremental, e os pods no cluster de origem não são interrompidos.
4
Defina como true para interromper o aplicativo durante a migração. Os pods no cluster de origem são dimensionados para 0 após a etapa Backup.
5
Defina como true para manter os rótulos e as anotações aplicadas durante a migração.
6
Definido como true para verificar o status dos pods migrados no cluster de destino e para retornar os nomes dos pods que não estão em um estado Running.

12.2.9. MigPlan

O CR MigPlan define os parâmetros de um plano de migração.

Você pode configurar namespaces de destino, fases de hook e uma migração direta ou indireta.

Nota

Por padrão, um namespace de destino tem o mesmo nome do namespace de origem. Se você configurar um namespace de destino diferente, garanta que os namespaces não estejam duplicados nos clusters de origem ou de destino, pois os intervalos de UID e GID são copiados durante a migração.

apiVersion: migration.openshift.io/v1alpha1
kind: MigPlan
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: <migplan>
  namespace: openshift-migration
spec:
  closed: false 1
  srcMigClusterRef:
    name: <source_cluster>
    namespace: openshift-migration
  destMigClusterRef:
    name: <destination_cluster>
    namespace: openshift-migration
  hooks: 2
    - executionNamespace: <namespace> 3
      phase: <migration_phase> 4
      reference:
        name: <hook> 5
        namespace: <hook_namespace> 6
      serviceAccount: <service_account> 7
  indirectImageMigration: true 8
  indirectVolumeMigration: false 9
  migStorageRef:
    name: <migstorage>
    namespace: openshift-migration
  namespaces:
    - <source_namespace_1> 10
    - <source_namespace_2>
    - <source_namespace_3>:<destination_namespace_4> 11
  refresh: false  12
1
A migração foi concluída se true. Você não pode criar outro CR MigMigration para esse CR MigPlan.
2
Opcional: é possível especificar até quatro hooks de migração. Cada hook deve ser executado durante uma fase de migração diferente.
3
Opcional: especifique o namespace no qual o hook será executado.
4
Opcional: especifique a fase de migração durante a qual um hook será executado. Um hook pode ser atribuído a uma fase. Os valores válidos são PreBackup, PostBackup, PreRestore e PostRestore.
5
Opcional: especifique o nome do CR MigHook.
6
Opcional: especifique o namespace do CR MigHook.
7
Opcional: especifique uma conta de serviço com privilégios cluster-admin.
8
A migração direta de imagem é desativada se true. As imagens são copiadas do cluster de origem para o repositório de replicação, e do repositório de replicação para o cluster de destino.
9
A migração direta de volume é desativada se true. Os PVs são copiados do cluster de origem para o repositório de replicação, e do repositório de replicação para o cluster de destino.
10
Especifique um ou mais namespaces de origem. Se você especificar apenas o namespace de origem, o namespace de destino será idêntico.
11
Especifique o namespace de destino se ele for diferente do namespace de origem.
12
O CR MigPlan é validado se true.

12.2.10. MigStorage

O CR MigStorage descreve o armazenamento de objetos para o repositório de replicação.

Compatibilidade com Amazon Web Services (AWS), Microsoft Azure, Google Cloud Storage, Multi-Cloud Object Gateway e armazenamento genérico de nuvem compatível com S3.

A AWS e o método de cópia de snapshot têm parâmetros adicionais.

apiVersion: migration.openshift.io/v1alpha1
kind: MigStorage
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: <migstorage>
  namespace: openshift-migration
spec:
  backupStorageProvider: <backup_storage_provider> 1
  volumeSnapshotProvider: <snapshot_storage_provider> 2
  backupStorageConfig:
    awsBucketName: <bucket> 3
    awsRegion: <region> 4
    credsSecretRef:
      namespace: openshift-config
      name: <storage_secret> 5
    awsKmsKeyId: <key_id> 6
    awsPublicUrl: <public_url> 7
    awsSignatureVersion: <signature_version> 8
  volumeSnapshotConfig:
    awsRegion: <region> 9
    credsSecretRef:
      namespace: openshift-config
      name: <storage_secret> 10
  refresh: false 11
1
Especifique o provedor de armazenamento.
2
Somente método de cópia de snapshot: especifique o provedor de armazenamento.
3
Somente AWS: especifique o nome do bucket.
4
Somente AWS: especifique a região do bucket; por exemplo, us-east-1.
5
Especifique o nome do objeto Secret que você criou para o armazenamento.
6
Somente AWS: se você estiver usando o AWS Key Management Service, especifique o identificador exclusivo da chave.
7
Somente AWS: se você concedeu acesso público ao bucket AWS, especifique a URL do bucket.
8
Somente AWS: especifique a versão da assinatura da AWS para autenticar solicitações ao bucket; por exemplo, 4.
9
Somente método de cópia de snapshot: especifique a região geográfica dos clusters.
10
Somente método de cópia de snapshot: especifique o nome do objeto Secret que você criou para o armazenamento.
11
Defina como true para validar o cluster.

12.3. Logs e ferramentas de depuração

Esta seção descreve os logs e as ferramentas de depuração que você pode usar na solução de problemas.

12.3.1. Visualização dos recursos do plano de migração

Para visualizar os recursos do plano de migração para monitorar uma migração em execução ou para solucionar problemas de uma migração com falhas, use o console web MTC e a interface de linha de comando (CLI).

Procedimento

  1. No console web do MTC, clique em Migration Plans.
  2. Clique no número de Migrations, ao lado de um plano de migração, para exibir a página Migrations.
  3. Clique em uma migração para exibir os Migration details.
  4. Expanda Migration resources para ver os recursos da migração e o status deles em um modo de exibição de árvore.

    Nota

    Para solucionar problemas de falha em uma migração, comece com um recurso de alto nível que tenha falhado e, então, percorra a árvore de recursos em direção aos recursos de nível inferior.

  5. Clique no menu de opções kebab , ao lado de um recurso, e selecione uma das seguintes opções:

    • Copy oc describe command copia o comando para a área de transferência.

      • Faça login no cluster relevante e, então, execute o comando.

        As condições e os eventos do recurso são exibidos no formato YAML.

    • Copy oc logs command copia o comando para a área de transferência.

      • Faça login no cluster relevante e, então, execute o comando.

        Se o recurso der suporte a filtragem de logs, um log filtrado será exibido.

    • View JSON exibe os dados dos recursos em formato JSON em um navegador da web

      Os dados são os mesmos da saída do comando oc get <resource>.

12.3.2. Visualização do log de um plano de migração

É possível visualizar um log agregado de um plano de migração. Use o console web do MTC para copiar um comando para a área de transferência e, então, execute o comando a partir da interface de linha de comando (CLI).

O comando exibe os logs filtrados dos seguintes pods:

  • Migration Controller
  • Velero
  • Restic
  • Rsync
  • Stunnel
  • Registry

Procedimento

  1. No console web do MTC, clique em Migration Plans.
  2. Clique no número de Migrations ao lado de um plano de migração.
  3. Clique em View logs.
  4. Clique no ícone de copiar para copiar o comando oc logs para a área de transferência.
  5. Faça login no cluster relevante e insira o comando na CLI.

    O log agregado do plano de migração será exibido.

12.3.3. Uso do leitor de logs de migração

Você pode usar o leitor de logs de migração para exibir uma única visão filtrada de todos os logs de migração.

Procedimento

  1. Obtenha o pod mig-log-reader:

    $ oc -n openshift-migration get pods | grep log
  2. Insira o seguinte comando para exibir um único log de migração:

    $ oc -n openshift-migration logs -f <mig-log-reader-pod> -c color 1
    1
    A opção -c plain exibe o log sem cores.

12.3.4. Acesso às métricas de desempenho

O recurso personalizado (CR) MigrationController registra as métricas e faz pull delas para o armazenamento de monitoramento no cluster. É possível consultar as métricas usando a Prometheus Query Language (PromQL) para diagnosticar problemas de desempenho da migração. Todas as métricas são redefinidas quando o pod Migration Controller é reiniciado.

É possível acessar as métricas de desempenho e executar consultas usando o console web do OpenShift Container Platform.

Procedimento

  1. No console web do OpenShift Container Platform, clique em ObserveMetrics.
  2. Digite uma consulta PromQL, selecione uma janela de tempo para exibir e clique em Run Queries.

    Se seu navegador da web não exibir todos os resultados, use o console do Prometheus.

12.3.4.1. Métricas fornecidas

O recurso personalizado (CR) MigrationController fornece métricas para a contagem do CR MigMigration e para suas solicitações de API.

12.3.4.1.1. cam_app_workload_migrations

Esta métrica é uma contagem dos CRs MigMigration ao longo do tempo. Ela é útil para visualização em conjunto com as métricas mtc_client_request_count e mtc_client_request_elapsed para coletar informações de solicitação de API com mudanças de status da migração. Esta métrica está incluída na Telemetria.

Tabela 12.1. Métrica cam_app_workload_migrations

Nome do rótulo consultávelExemplo de valores de rótuloDescrição do rótulo

status

running, idle, failed, completed

Status do CR MigMigration

type

stage, final

Tipo do CR MigMigration

12.3.4.1.2. mtc_client_request_count

Esta métrica é uma contagem cumulativa das solicitações de API do Kubernetes emitidas por MigrationController. Não é incluída na Telemetria.

Tabela 12.2. Métrica mtc_client_request_count

Nome do rótulo consultávelExemplo de valores de rótuloDescrição do rótulo

cluster

https://migcluster-url:443

Cluster em relação ao qual a solicitação foi emitida

component

MigPlan, MigCluster

API do subcontrolador que emitiu a solicitação

function

(*ReconcileMigPlan).Reconcile

Função a partir da qual o pedido foi emitido

kind

SecretList, Deployment

O tipo do Kubernetes para o qual a solicitação foi emitida

12.3.4.1.3. mtc_client_request_elapsed

Esta métrica é uma latência acumulada, em milissegundos, das solicitações de API do Kubernetes emitidas por MigrationController. Não é incluída na Telemetria.

Tabela 12.3. Métrica mtc_client_request_elapsed

Nome do rótulo consultávelExemplo de valores de rótuloDescrição do rótulo

cluster

https://cluster-url.com:443

Cluster em relação ao qual a solicitação foi emitida

component

migplan, migcluster

API do subcontrolador que emitiu a solicitação

function

(*ReconcileMigPlan).Reconcile

Função a partir da qual o pedido foi emitido

kind

SecretList, Deployment

O recurso do Kubernetes para o qual a solicitação foi emitida

12.3.4.1.4. Consultas úteis

A tabela lista algumas consultas úteis que podem ser usadas para monitorar o desempenho.

Tabela 12.4. Consultas úteis

ConsultaDescrição

mtc_client_request_count

Número de solicitações de API emitidas, classificadas por tipo de solicitação

sum(mtc_client_request_count)

Número total de solicitações de API emitidas

mtc_client_request_elapsed

Latência da solicitação de API, classificada por tipo de solicitação

sum(mtc_client_request_elapsed)

Latência total das solicitações de API

sum(mtc_client_request_elapsed) / sum(mtc_client_request_count)

Latência média das solicitações de API

mtc_client_request_elapsed / mtc_client_request_count

Latência média das solicitações de API, classificada por tipo de solicitação

cam_app_workload_migrations{status="running"} * 100

Contagem das migrações em execução, multiplicada por 100 para facilitar a visualização ao lado das contagens de solicitações

12.3.5. Uso da ferramenta must-gather

Você pode coletar logs, métricas e informações sobre os recursos personalizados do MTC usando a ferramenta must-gather.

Os dados de must-gather devem ser anexados a todos os casos de clientes.

É possível coletar dados por um período de uma hora ou de 24 horas, bem como visualizar os dados com o console do Prometheus.

Pré-requisitos

  • Você deve estar conectado ao cluster do OpenShift Container Platform como um usuário com a função cluster-admin.
  • A OpenShift CLI (oc) deve estar instalada.

Procedimento

  1. Navegue até o diretório onde deseja armazenar os dados de must-gather.
  2. Execute o comando oc adm must-gather para uma das seguintes opções de coleta de dados:

    • Para coletar dados da última hora:

      $ oc adm must-gather --image=registry.redhat.io/rhmtc/openshift-migration-must-gather-rhel8:v1.6

      Os dados são salvos como must-gather/must-gather.tar.gz. Você pode enviar esse arquivo para um caso de suporte no Portal do Cliente da Red Hat.

    • Para coletar dados das últimas 24 horas:

      $ oc adm must-gather --image=registry.redhat.io/rhmtc/openshift-migration-must-gather-rhel8:v1.6 \
        -- /usr/bin/gather_metrics_dump

      Essa operação pode levar muito tempo. Os dados são salvos como must-gather/metrics/prom_data.tar.gz.

Visualização de dados de métricas com o console do Prometheus

Você pode visualizar os dados de métricas com o console do Prometheus.

Procedimento

  1. Descompacte o arquivo prom_data.tar.gz:

    $ tar -xvzf must-gather/metrics/prom_data.tar.gz
  2. Crie uma instância local do Prometheus:

    $ make prometheus-run

    O comando gera como saída a URL do Prometheus.

    Saída

    Started Prometheus on http://localhost:9090

  3. Inicie um navegador da web e navegue até a URL para visualizar os dados usando o console web do Prometheus.
  4. Depois de ver os dados, exclua os dados e a instância do Prometheus:

    $ make prometheus-cleanup

12.3.6. Depuração de recursos do Velero com a ferramenta Velero CLI

Você pode depurar os recursos personalizados (CRs) Backup e Restore e recuperar logs com a ferramenta Velero CLI.

A ferramenta Velero CLI fornece informações mais detalhadas do que a ferramenta OpenShift CLI.

Sintaxe

Use o comando oc exec para executar um comando da Velero CLI:

$ oc exec $(oc get pods -n openshift-migration -o name | grep velero) \
  -- ./velero <backup_restore_cr> <command> <cr_name>

Exemplo

$ oc exec $(oc get pods -n openshift-migration -o name | grep velero) \
  -- ./velero backup describe 0e44ae00-5dc3-11eb-9ca8-df7e5254778b-2d8ql

Você pode especificar velero-<pod> -n openshift-migration no lugar de $(oc get pods -n openshift-migration -o name | grep velero).

Exemplo

$ oc exec velero-<pod> -n openshift-migration -- ./velero backup describe 0e44ae00-5dc3-11eb-9ca8-df7e5254778b-2d8ql

Opção de ajuda

Use a opção de velero --help para listar todos os comandos da Velero CLI:

$ oc exec $(oc get pods -n openshift-migration -o name | grep velero) -- ./velero --help
Comando de descrição

Use o comando velero describe para recuperar um resumo dos avisos e erros associados a um CR Backup ou Restore:

$ oc exec $(oc get pods -n openshift-migration -o name | grep velero) \
  -- ./velero <backup_restore_cr> describe <cr_name>

Exemplo

$ oc exec $(oc get pods -n openshift-migration -o name | grep velero) \
  -- ./velero backup describe 0e44ae00-5dc3-11eb-9ca8-df7e5254778b-2d8ql

Comando de logs

Use o comando velero logs para recuperar os logs de um CR Backup ou Restore:

$ oc exec $(oc get pods -n openshift-migration -o name | grep velero) \
  -- ./velero <backup_restore_cr> logs <cr_name>

Exemplo

$ oc exec $(oc get pods -n openshift-migration -o name | grep velero) \
  -- ./velero restore logs ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf

12.3.7. Depuração de uma falha de migração parcial

Você pode depurar uma mensagem de aviso de falha de migração parcial usando a Velero CLI para examinar os logs do recurso personalizado (CR) Restore.

Uma falha parcial ocorre quando o Velero se depara com um problema que não causa a falha de uma migração. Por exemplo, se uma definição de recurso personalizado (CRD) estiver ausente ou se houver uma discrepância entre as versões da CRD nos clusters de origem e de destino, a migração será concluída, mas o CR não será criado no cluster de destino.

O Velero registra em log o problema como uma falha parcial e, então, processa o resto dos objetos no CR Backup.

Procedimento

  1. Verifique o status de um CR MigMigration:

    $ oc get migmigration <migmigration> -o yaml

    Exemplo de saída

    status:
      conditions:
      - category: Warn
        durable: true
        lastTransitionTime: "2021-01-26T20:48:40Z"
        message: 'Final Restore openshift-migration/ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf: partially failed on destination cluster'
        status: "True"
        type: VeleroFinalRestorePartiallyFailed
      - category: Advisory
        durable: true
        lastTransitionTime: "2021-01-26T20:48:42Z"
        message: The migration has completed with warnings, please look at `Warn` conditions.
        reason: Completed
        status: "True"
        type: SucceededWithWarnings

  2. Verifique o status do CR Restore usando o comando describe do Velero:

    $ oc exec $(oc get pods -n openshift-migration -o name | grep velero) -n openshift-migration -- ./velero restore describe <restore>

    Exemplo de saída

    Phase:  PartiallyFailed (run 'velero restore logs ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf' for more information)
    
    Errors:
      Velero:     <none>
      Cluster:    <none>
      Namespaces:
        migration-example:  error restoring example.com/migration-example/migration-example: the server could not find the requested resource

  3. Verifique os logs do CR Restore usando o comando logs do Velero:

    $ oc exec $(oc get pods -n openshift-migration -o name | grep velero) -n openshift-migration -- ./velero restore logs <restore>

    Exemplo de saída

    time="2021-01-26T20:48:37Z" level=info msg="Attempting to restore migration-example: migration-example" logSource="pkg/restore/restore.go:1107" restore=openshift-migration/ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf
    time="2021-01-26T20:48:37Z" level=info msg="error restoring migration-example: the server could not find the requested resource" logSource="pkg/restore/restore.go:1170" restore=openshift-migration/ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf

    A mensagem de erro de log do CR Restore, the server could not find the requested resource, indica a causa da migração parcialmente com falha.

12.3.8. Uso dos recursos personalizados do MTC para a solução de problemas

Você pode verificar os seguintes recursos personalizados (CRs) do Migration Toolkit for Containers (MTC) para solucionar um problema de falha na migração:

  • MigCluster
  • MigStorage
  • MigPlan
  • BackupStorageLocation

    O CR BackupStorageLocation contém um rótulo migrationcontroller para identificar a instância do MTC que criou o CR:

        labels:
          migrationcontroller: ebe13bee-c803-47d0-a9e9-83f380328b93
  • VolumeSnapshotLocation

    O CR VolumeSnapshotLocation contém um rótulo migrationcontroller para identificar a instância do MTC que criou o CR:

        labels:
          migrationcontroller: ebe13bee-c803-47d0-a9e9-83f380328b93
  • MigMigration
  • Backup

    O MTC altera a política de recuperação de volumes persistentes (PVs) migrados como Retain no cluster de destino. O CR Backup contém uma anotação openshift.io/orig-reclaim-policy que indica a política de recuperação original. Você pode restaurar manualmente a política de recuperação dos PVs migrados.

  • Restore

Procedimento

  1. Liste os CRs MigMigration no namespace openshift-migration:

    $ oc get migmigration -n openshift-migration

    Exemplo de saída

    NAME                                   AGE
    88435fe0-c9f8-11e9-85e6-5d593ce65e10   6m42s

  2. Inspecione o CR MigMigration:

    $ oc describe migmigration 88435fe0-c9f8-11e9-85e6-5d593ce65e10 -n openshift-migration

    A saída é semelhante aos exemplos a seguir.

Exemplo de saída de MigMigration

name:         88435fe0-c9f8-11e9-85e6-5d593ce65e10
namespace:    openshift-migration
labels:       <none>
annotations:  touch: 3b48b543-b53e-4e44-9d34-33563f0f8147
apiVersion:  migration.openshift.io/v1alpha1
kind:         MigMigration
metadata:
  creationTimestamp:  2019-08-29T01:01:29Z
  generation:          20
  resourceVersion:    88179
  selfLink:           /apis/migration.openshift.io/v1alpha1/namespaces/openshift-migration/migmigrations/88435fe0-c9f8-11e9-85e6-5d593ce65e10
  uid:                 8886de4c-c9f8-11e9-95ad-0205fe66cbb6
spec:
  migPlanRef:
    name:        socks-shop-mig-plan
    namespace:   openshift-migration
  quiescePods:  true
  stage:         false
status:
  conditions:
    category:              Advisory
    durable:               True
    lastTransitionTime:  2019-08-29T01:03:40Z
    message:               The migration has completed successfully.
    reason:                Completed
    status:                True
    type:                  Succeeded
  phase:                   Completed
  startTimestamp:         2019-08-29T01:01:29Z
events:                    <none>

Exemplo de saída do CR de backup #2 do Velero que descreve os dados do PV

apiVersion: velero.io/v1
kind: Backup
metadata:
  annotations:
    openshift.io/migrate-copy-phase: final
    openshift.io/migrate-quiesce-pods: "true"
    openshift.io/migration-registry: 172.30.105.179:5000
    openshift.io/migration-registry-dir: /socks-shop-mig-plan-registry-44dd3bd5-c9f8-11e9-95ad-0205fe66cbb6
    openshift.io/orig-reclaim-policy: delete
  creationTimestamp: "2019-08-29T01:03:15Z"
  generateName: 88435fe0-c9f8-11e9-85e6-5d593ce65e10-
  generation: 1
  labels:
    app.kubernetes.io/part-of: migration
    migmigration: 8886de4c-c9f8-11e9-95ad-0205fe66cbb6
    migration-stage-backup: 8886de4c-c9f8-11e9-95ad-0205fe66cbb6
    velero.io/storage-location: myrepo-vpzq9
  name: 88435fe0-c9f8-11e9-85e6-5d593ce65e10-59gb7
  namespace: openshift-migration
  resourceVersion: "87313"
  selfLink: /apis/velero.io/v1/namespaces/openshift-migration/backups/88435fe0-c9f8-11e9-85e6-5d593ce65e10-59gb7
  uid: c80dbbc0-c9f8-11e9-95ad-0205fe66cbb6
spec:
  excludedNamespaces: []
  excludedResources: []
  hooks:
    resources: []
  includeClusterResources: null
  includedNamespaces:
  - sock-shop
  includedResources:
  - persistentvolumes
  - persistentvolumeclaims
  - namespaces
  - imagestreams
  - imagestreamtags
  - secrets
  - configmaps
  - pods
  labelSelector:
    matchLabels:
      migration-included-stage-backup: 8886de4c-c9f8-11e9-95ad-0205fe66cbb6
  storageLocation: myrepo-vpzq9
  ttl: 720h0m0s
  volumeSnapshotLocations:
  - myrepo-wv6fx
status:
  completionTimestamp: "2019-08-29T01:02:36Z"
  errors: 0
  expiration: "2019-09-28T01:02:35Z"
  phase: Completed
  startTimestamp: "2019-08-29T01:02:35Z"
  validationErrors: null
  version: 1
  volumeSnapshotsAttempted: 0
  volumeSnapshotsCompleted: 0
  warnings: 0

Exemplo de saída do CR de backup #2 do Velero que descreve os recursos do Kubernetes

apiVersion: velero.io/v1
kind: Restore
metadata:
  annotations:
    openshift.io/migrate-copy-phase: final
    openshift.io/migrate-quiesce-pods: "true"
    openshift.io/migration-registry: 172.30.90.187:5000
    openshift.io/migration-registry-dir: /socks-shop-mig-plan-registry-36f54ca7-c925-11e9-825a-06fa9fb68c88
  creationTimestamp: "2019-08-28T00:09:49Z"
  generateName: e13a1b60-c927-11e9-9555-d129df7f3b96-
  generation: 3
  labels:
    app.kubernetes.io/part-of: migration
    migmigration: e18252c9-c927-11e9-825a-06fa9fb68c88
    migration-final-restore: e18252c9-c927-11e9-825a-06fa9fb68c88
  name: e13a1b60-c927-11e9-9555-d129df7f3b96-gb8nx
  namespace: openshift-migration
  resourceVersion: "82329"
  selfLink: /apis/velero.io/v1/namespaces/openshift-migration/restores/e13a1b60-c927-11e9-9555-d129df7f3b96-gb8nx
  uid: 26983ec0-c928-11e9-825a-06fa9fb68c88
spec:
  backupName: e13a1b60-c927-11e9-9555-d129df7f3b96-sz24f
  excludedNamespaces: null
  excludedResources:
  - nodes
  - events
  - events.events.k8s.io
  - backups.velero.io
  - restores.velero.io
  - resticrepositories.velero.io
  includedNamespaces: null
  includedResources: null
  namespaceMapping: null
  restorePVs: true
status:
  errors: 0
  failureReason: ""
  phase: Completed
  validationErrors: null
  warnings: 15

12.4. Problemas e preocupações comuns

Esta seção descreve problemas e preocupações comuns que podem causar transtornos durante a migração.

12.4.1. Atualização de imagens internas obsoletas

Se seu aplicativo utiliza imagens do namespace openshift, as versões necessárias das imagens devem estar presentes no cluster de destino.

Se uma imagem do OpenShift Container Platform 3 for descontinuada no OpenShift Container Platform 4.10, você poderá atualizar manualmente a tag de fluxo de imagem usando podman.

Pré-requisitos

  • Você deve ter podman instalado.
  • Você deve estar conectado como um usuário com os privilégios cluster-admin.
  • Se estiver usando registros inseguros, adicione seus valores de host de registro à seção [registries.insecure] de /etc/container/registries.conf para garantir que podman não encontre um erro de verificação TLS.
  • Os registros internos devem estar expostos nos clusters de origem e de destino.

Procedimento

  1. Assegure que os registros internos estejam expostos nos clusters do OpenShift Container Platform 3 e 4.

    O registro interno é exposto por padrão no OpenShift Container Platform 4.

  2. Se estiver usando registros inseguros, adicione seus valores de host de registro à seção [registries.insecure] de /etc/container/registries.conf para garantir que podman não encontre um erro de verificação TLS.
  3. Acesse o registro do OpenShift Container Platform 3:

    $ podman login -u $(oc whoami) -p $(oc whoami -t) --tls-verify=false <registry_url>:<port>
  4. Acesse o registro do OpenShift Container Platform 4:

    $ podman login -u $(oc whoami) -p $(oc whoami -t) --tls-verify=false <registry_url>:<port>
  5. Faça pull da imagem do OpenShift Container Platform 3:

    $ podman pull <registry_url>:<port>/openshift/<image>
  6. Marque a imagem do OpenShift Container Platform 3 para o registro do OpenShift Container Platform 4:

    $ podman tag <registry_url>:<port>/openshift/<image> \ 1
      <registry_url>:<port>/openshift/<image> 2
    1
    Especifique a URL e a porta do registro para o cluster OpenShift Container Platform 3.
    2
    Especifique a URL e a porta do registro para o cluster do OpenShift Container Platform 4.
  7. Efetue push da imagem para o registro do OpenShift Container Platform 4:

    $ podman push <registry_url>:<port>/openshift/<image> 1
    1
    Especifique o cluster do OpenShift Container Platform 4.
  8. Verificar se a imagem tem um fluxo de imagem válido:

    $ oc get imagestream -n openshift | grep <image>

    Exemplo de saída

    NAME      IMAGE REPOSITORY                                                      TAGS    UPDATED
    my_image  image-registry.openshift-image-registry.svc:5000/openshift/my_image  latest  32 seconds ago

12.4.2. A migração direta de volume não é concluída

Se a migração direta de volume não for concluída, o cluster de destino talvez não tenha as mesmas anotações de node-selector que o cluster de origem.

O Migration Toolkit for Containers (MTC) migra namespaces com todas as anotações para preservar as restrições do contexto de segurança e os requisitos de agendamento. Durante a migração direta de volume, o MTC cria pods de transferência Rsync no cluster de destino, nos namespaces que foram migrados do cluster de origem. Se um namespace do cluster de destino não tiver as mesmas anotações que o namespace do cluster de origem, não será possível programar os pods de transferência Rsync. Os pods Rsync permanecem em um estado Pending.

Você pode identificar e corrigir esse problema executando o procedimento a seguir.

Procedimento

  1. Verifique o status do CR MigMigration:

    $ oc describe migmigration <pod> -n openshift-migration

    A saída inclui a seguinte mensagem de status:

    Exemplo de saída

    Some or all transfer pods are not running for more than 10 mins on destination cluster

  2. No cluster de origem, obtenha os detalhes de um namespace migrado:

    $ oc get namespace <namespace> -o yaml 1
    1
    Especifique o namespace migrado.
  3. No cluster de destino, edite o namespace migrado:

    $ oc edit namespace <namespace>
  4. Adicione as anotações de openshift.io/node-selector ausentes ao namespace migrado, como no seguinte exemplo:

    apiVersion: v1
    kind: Namespace
    metadata:
      annotations:
        openshift.io/node-selector: "region=east"
    ...
  5. Execute novamente o plano de migração.

12.4.3. Mensagens de erro e resoluções

Esta seção descreve mensagens de erro comuns que você pode encontrar com o Migration Toolkit for Containers (MTC) e como resolver as causas subjacentes delas.

12.4.3.1. Erro de certificado CA exibido ao acessar o console do MTC pela primeira vez

Se uma mensagem CA certificate error for exibida na primeira vez que você tentar acessar o console do MTC, a causa provável é o uso de certificados CA autoassinados em um dos clusters.

Para resolver esse problema, acesse a URL de oauth-authorization-server exibida na mensagem de erro e aceite o certificado. Para resolver esse problema permanentemente, acrescente o certificado ao repositório confiável do seu navegador da web.

Se uma mensagem Unauthorized for exibida após a aceitação do certificado, navegue até o console do MTC e atualize a página web.

12.4.3.2. Erro de tempo limite de OAuth no console do MTC

Se uma mensagem connection has timed out for exibida no console do MTC depois que você aceitar um certificado autoassinado, as causas provavelmente serão as seguintes:

Para determinar a causa do tempo limite:

  • Inspecione a página web do console do MTC com um inspetor web do navegador.
  • Verifique a existência de erros no log do pod Migration UI.

12.4.3.3. Certificado assinado por erro de autoridade desconhecida

Se você usar um certificado autoassinado para proteger um cluster ou um repositório de replicação para o Migration Toolkit for Containers (MTC), a verificação do certificado poderá falhar com a seguinte mensagem de erro: Certificate signed by unknown authority.

É possível criar um arquivo de pacote de certificados CA personalizado e carregá-lo no console web do MTC quando você adicionar um cluster ou um repositório de replicação.

Procedimento

Faça download de um certificado CA a partir de um ponto de extremidade remoto e salve-o como um arquivo de pacote de CA:

$ echo -n | openssl s_client -connect <host_FQDN>:<port> \ 1
  | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > <ca_bundle.cert> 2
1
Especifique o FQDN do host e a porta do ponto de extremidade; por exemplo, api.my-cluster.example.com:6443.
2
Especifique o nome do arquivo do pacote de CA.

12.4.3.4. Erros de local de armazenamento de backup no log do pod Velero

Se um recurso personalizado Velero Backup contiver uma referência a um local de armazenamento de backup (BSL) que não existe, o log do pod Velero poderá exibir as seguintes mensagens de erro:

$ oc logs <MigrationUI_Pod> -n openshift-migration

Você pode ignorar essas mensagens de erro. Um BSL ausente não pode causar a falha de uma migração.

12.4.3.5. Erro de tempo limite de backup do volume de pod no log do pod Velero

Se uma migração falhar porque Restic atingiu o tempo limite, o seguinte erro será exibido no log do pod Velero.

level=error msg="Error backing up item" backup=velero/monitoring error="timed out waiting for all PodVolumeBackups to complete" error.file="/go/src/github.com/heptio/velero/pkg/restic/backupper.go:165" error.function="github.com/heptio/velero/pkg/restic.(*backupper).BackupPodVolumes" group=v1

O valor padrão de restic_timeout é de uma hora. É possível aumentar esse parâmetro para migrações grandes, mas tenha em mente que um valor maior pode atrasar o retorno de mensagens de erro.

Procedimento

  1. No console web do OpenShift Container Platform, navegue até OperatorsInstalled Operators.
  2. Clique em Migration Toolkit for Containers Operator.
  3. Na guia MigrationController, clique em migration-controller.
  4. Na guia YAML, atualize o seguinte valor de parâmetro:

    spec:
      restic_timeout: 1h 1
    1
    As unidades válidas são h (horas), m (minutos) e s (segundos); por exemplo, 3h30m15s.
  5. Clique em Salve.

12.4.3.6. Erros de verificação de Restic no recurso personalizado MigMigration

Se ocorrer uma falha na verificação de dados ao migrar um volume persistente com o método de cópia de dados de sistema de arquivos, o seguinte erro será exibido no CR MigMigration.

Exemplo de saída

status:
  conditions:
  - category: Warn
    durable: true
    lastTransitionTime: 2020-04-16T20:35:16Z
    message: There were verify errors found in 1 Restic volume restores. See restore `<registry-example-migration-rvwcm>`
      for details 1
    status: "True"
    type: ResticVerifyErrors 2

1
A mensagem de erro identifica o nome do CR Restore.
2
ResticVerifyErrors é um tipo de aviso de erro geral que inclui erros de verificação.
Nota

Um erro de verificação de dados não causa a falha do processo de migração.

Você pode verificar o CR Restore para identificar a fonte do erro da verificação de dados.

Procedimento

  1. Faça login no cluster de destino.
  2. Visualize o CR Restore:

    $ oc describe <registry-example-migration-rvwcm> -n openshift-migration

    A saída identifica o volume persistente com erros PodVolumeRestore.

    Exemplo de saída

    status:
      phase: Completed
      podVolumeRestoreErrors:
      - kind: PodVolumeRestore
        name: <registry-example-migration-rvwcm-98t49>
        namespace: openshift-migration
      podVolumeRestoreResticErrors:
      - kind: PodVolumeRestore
        name: <registry-example-migration-rvwcm-98t49>
        namespace: openshift-migration

  3. Visualize o CR PodVolumeRestore:

    $ oc describe <migration-example-rvwcm-98t49>

    A saída identifica o pod Restic que registrou os erros no log.

    Exemplo de saída

      completionTimestamp: 2020-05-01T20:49:12Z
      errors: 1
      resticErrors: 1
      ...
      resticPod: <restic-nr2v5>

  4. Visualize o log do pod Restic para localizar os erros:

    $ oc logs -f <restic-nr2v5>

12.4.3.7. Erro de permissão de migração de armazenamento NFS com root_squash habilitado

Se você estiver migrando dados de armazenamento NFS e root_squash estiver habilitado, Restic será mapeado para nfsnobody e não terá permissão para fazer a migração. O seguinte erro será exibido no log do pod Restic.

Exemplo de saída

backup=openshift-migration/<backup_id> controller=pod-volume-backup error="fork/exec /usr/bin/restic: permission denied" error.file="/go/src/github.com/vmware-tanzu/velero/pkg/controller/pod_volume_backup_controller.go:280" error.function="github.com/vmware-tanzu/velero/pkg/controller.(*podVolumeBackupController).processBackup" logSource="pkg/controller/pod_volume_backup_controller.go:280" name=<backup_id> namespace=openshift-migration

É possível resolver esse problema criando um grupo complementar para Restic e adicionando a ID do grupo ao manifesto de CR MigrationController.

Procedimento

  1. Crie um grupo complementar para Restic no armazenamento NFS.
  2. Defina o bit setgid nos diretórios NFS para que a propriedade do grupo seja herdada.
  3. Adicione o parâmetro restic_supplemental_groups ao manifesto de CR MigrationController nos clusters de origem e de destino:

    spec:
      restic_supplemental_groups: <group_id> 1
    1
    Especifique a ID do grupo complementar.
  4. Aguarde até que os pods Restic sejam reiniciados, para que as mudanças sejam aplicadas.

12.4.4. Problemas conhecidos

Esta versão tem os seguintes problemas conhecidos:

  • Durante a migração, o Migration Toolkit for Containers (MTC) preserva as seguintes anotações no namespace:

    • openshift.io/sa.scc.mcs
    • openshift.io/sa.scc.supplemental-groups
    • openshift.io/sa.scc.uid-range

      Essas anotações preservam o intervalo de UID, assegurando que os contêineres mantenham suas permissões de sistema de arquivos no cluster de destino. Há um risco de que as UIDs migradas possam duplicar as UIDs em um namespace existente ou futuro no cluster de destino. (BZ#1748440)

  • A maioria dos recursos com escopo de cluster ainda não é manipulada pelo MTC. Se seus aplicativos exigem recursos com escopo de cluster, talvez seja necessário criá-los manualmente no cluster de destino.
  • Se ocorrer uma falha na migração, o plano de migração não reterá as configurações personalizadas do PV para os pods desativados. É preciso reverter manualmente a migração, excluir o plano de migração e criar um novo plano de migração com suas configurações de PV. (BZ#1784899)
  • Se uma migração grande falhar porque o Restic atingiu o tempo limite, você poderá aumentar o valor do parâmetro restic_timeout (padrão: 1h) no manifesto de recurso personalizado (CR) MigrationController.
  • Se você selecionar a opção de verificação de dados para PVs que são migrados com o método de cópia do sistema de arquivos, o desempenho será significativamente mais lento.
  • Se você estiver migrando dados do armazenamento NFS e root_squash estiver habilitado, Restic será mapeado para nfsnobody. Ocorrerá uma falha na migração, e um erro de permissão será exibido no log do pod Restic. (BZ#1873641)

    É possível resolver esse problema adicionando grupos complementares de Restic ao manifesto de CR MigrationController:

    spec:
    ...
      restic_supplemental_groups:
      - 5555
      - 6666
  • Se você realizar uma migração direta de volume com nós em diferentes zonas de disponibilidade ou conjuntos de disponibilidade, a migração poderá falhar porque os pods migrados não poderão acessar a PVC. (BZ#1947487)

12.5. Reversão de uma migração

Você pode reverter uma migração usando o console web do MTC ou a CLI.

Também é possível reverter uma migração manualmente.

12.5.1. Reversão de uma migração usando o console web do MTC

Você pode reverter uma migração usando o console web do Migration Toolkit for Containers (MTC).

Nota

Os seguintes recursos permanecem nos namespaces migrados para depuração após falha em uma migração de volume direto (DVM):

  • Mapas de configuração (clusters de origem e de destino)
  • Objetos Secret (clusters de origem e de destino)
  • CRs Rsync (cluster de origem)

Esses recursos não afetam a reversão. Você pode excluí-los manualmente.

Posteriormente, se você executar o mesmo plano de migração com êxito, os recursos da migração com falha serão excluídos automaticamente.

Se seu aplicativo tiver sido interrompido durante uma migração com falha, você deverá reverter a migração para evitar corrupção de dados no volume persistente.

A reversão não será necessária se o aplicativo não tiver sido interrompido durante a migração, pois o aplicativo original ainda estará em execução no cluster de origem.

Procedimento

  1. No console web do MTC, clique em Migration plans.
  2. Clique no menu de opções kebab , ao lado de um plano de migração, e selecione Rollback em Migration.
  3. Clique em Rollback e aguarde a conclusão da reversão.

    Nos detalhes do plano de migração, será exibida a mensagem Rollback succeeded.

  4. Verifique se a reversão foi concluída com êxito no console web do OpenShift Container Platform do cluster de origem:

    1. Clique em HomeProjects.
    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 WorkloadsPods para verificar se os pods estão em execução no namespace migrado.
    5. Clique em StoragePersistent volumes para verificar se o volume persistente migrado está corretamente provisionado.

12.5.2. Reversão de uma migração usando a interface de linha de comando

Para reverter uma migração, você pode criar um recurso personalizado (CR) MigMigration usando a interface de linha de comando.

Nota

Os seguintes recursos permanecem nos namespaces migrados para depuração após falha em uma migração de volume direto (DVM):

  • Mapas de configuração (clusters de origem e de destino)
  • Objetos Secret (clusters de origem e de destino)
  • CRs Rsync (cluster de origem)

Esses recursos não afetam a reversão. Você pode excluí-los manualmente.

Posteriormente, se você executar o mesmo plano de migração com êxito, os recursos da migração com falha serão excluídos automaticamente.

Se seu aplicativo tiver sido interrompido durante uma migração com falha, você deverá reverter a migração para evitar corrupção de dados no volume persistente.

A reversão não será necessária se o aplicativo não tiver sido interrompido durante a migração, pois o aplicativo original ainda estará em execução no cluster de origem.

Procedimento

  1. Crie um CR MigMigration com base no seguinte exemplo:

    $ cat << EOF | oc apply -f -
    apiVersion: migration.openshift.io/v1alpha1
    kind: MigMigration
    metadata:
      labels:
        controller-tools.k8s.io: "1.0"
      name: <migmigration>
      namespace: openshift-migration
    spec:
    ...
      rollback: true
    ...
      migPlanRef:
        name: <migplan> 1
        namespace: openshift-migration
    EOF
    1
    Especifique o nome do CR MigPlan associado.
  2. No console web do MTC, verifique se os recursos do projeto migrado foram removidos do cluster de destino.
  3. Verifique se os recursos do projeto migrado estão presentes no cluster de origem e se o aplicativo está em execução.

12.5.3. Reversão manual de uma migração

Você pode reverter manualmente uma migração com falha excluindo os pods stage e reativando o aplicativo.

Se você executar o mesmo plano de migração com êxito, os recursos da migração com falha serão excluídos automaticamente.

Nota

Os seguintes recursos permanecem nos namespaces migrados após falha em uma migração de volume direto (DVM):

  • Mapas de configuração (clusters de origem e de destino)
  • Objetos Secret (clusters de origem e de destino)
  • CRs Rsync (cluster de origem)

Esses recursos não afetam a reversão. Você pode excluí-los manualmente.

Procedimento

  1. Exclua os pods stage em todos os clusters:

    $ oc delete $(oc get pods -l migration.openshift.io/is-stage-pod -n <namespace>) 1
    1
    Namespaces especificados no CR MigPlan.
  2. Reative o aplicativo no cluster de origem dimensionando as réplicas para seu número antes da migração:

    $ oc scale deployment <deployment> --replicas=<premigration_replicas>

    A anotação migration.openshift.io/preQuiesceReplicas no CR Deployment exibe o número de réplicas antes da migração:

    apiVersion: extensions/v1beta1
    kind: Deployment
    metadata:
      annotations:
        deployment.kubernetes.io/revision: "1"
        migration.openshift.io/preQuiesceReplicas: "1"
  3. Verifique se os pods do aplicativo estão em execução no cluster de origem:

    $ oc get pod -n <namespace>

Recursos adicionais