Práticas recomendadas de planejamento

Este tópico contém orientações para migrações de aplicativos para o Google Kubernetes Engine (GKE) ou GKE Enterprise, com base nas migrações reais realizadas com o Migrate to Containers.

A CLI do discovery client do Migration Center, ou CLI mcdc, é uma ferramenta que determina a compatibilidade da carga de trabalho da VM para migração para um contêiner.

O Migrate to Containers é recomendado para determinados tipos de cargas de trabalho do Linux e do Windows, detalhadas abaixo.

Compatibilidade adequada

Linux

Os aplicativos Linux ideais para migração com o Migrate to Containers contém as seguintes arquiteturas de aplicativos:

  • Servidores da Web/de aplicativos
  • Middleware de lógica de negócios (por exemplo, Tomcat)
  • Pilhas de várias camadas e VMs (por exemplo, LAMP)
  • Bancos de dados pequenos e médios (por exemplo, MySQL e PostgreSQL)

Além disso, os aplicativos mais adequados para migração com o Migrate to Containers têm estas características operacionais:

  • Baixo ciclo de trabalho e cargas de trabalho intensas
  • Ambientes de laboratório para desenvolvimento, teste e treinamento
  • Serviços sempre ativados e de baixa carga

Em geral, a maioria das cargas de trabalho do Linux é compatível com a migração, exceto aquelas listadas em Opções incompatíveis.

Windows

As cargas de trabalho dos aplicativos do Windows adequados para migração com o Migrate to Containers contêm estas características:

  • IIS 7 ou posterior, ASP.NET com .NET Framework 3.5 ou posterior
  • Camadas de lógica e Web
  • WS2008 R2 ou superior

Suporte ao sistema operacional

O Migrate to Containers é compatível com estes sistemas operacionais de VM.

Opções incompatíveis

Linux

No Linux, os aplicativos e servidores que não são adequados para migração com o Migrate to Containers incluem:

  • Bancos de dados na memória grandes e de alto desempenho
  • VMs com drivers de kernel especiais (por exemplo, NFS em modo kernel)
  • Dependências de hardware específico
  • Software com licenças vinculadas a determinado registro de ID de hardware

Windows

No Windows, as cargas de trabalho que não têm o IIS 7 ou superior não são adequadas para a migração. Outros tipos de aplicativos inadequados para a migração são:

  • Aplicativos com dependências em GPUs ou TPUs
  • Aplicativos de redes de baixo nível
  • Aplicativos de área de trabalho, protocolo RDP e VDI
  • Aplicativos com BYOL

Regras de acesso à rede e de DNS

Antes de migrar para o GKE, compreenda os recursos de rede e os serviços usados pelas cargas de trabalho migradas e confirme que estão acessíveis e endereçáveis pela nuvem privada virtual.

Planejar os nomes de serviços do Kubernetes

Se as cargas de trabalho dependem do DNS para acessar serviços, é necessário planejar o esquema de namespace, as políticas de rede e os nomes de serviço (links em inglês) do Kubernetes.

A especificação de implantação gerada pelo processo de migração contém a sugestão de um objeto Service headless do tipo "ClusterIP". "ClusterIP" significa que há um único IP interno de cluster acessível apenas pelo cluster, sem balanceamento de carga. O controlador de endpoints do Kubernetes modifica a configuração de DNS para retornar registros (endereços) que apontam para os pods, rotulados com "app": "app-name" no deployment_spec.yaml.

Criar e aplicar serviços para conexões com pods e contêineres

Depois de migrar uma carga de trabalho, os nomes do host não são mais aplicáveis. Para permitir conexões com as cargas de trabalho, crie e aplique serviços.

Identificar e configurar nomes e IPs migrados

O GKE gerencia o arquivo /etc/hosts. No Migrate to Containers, a adaptação do arquivo hosts da VM de origem para o GKE ainda não foi automatizada. Os nomes e IPs do arquivo hosts na VM migrada precisam ser identificados e configurados como hostAliases (em inglês).

Colocar serviços dependentes no mesmo namespace

Os serviços que dependem uns dos outros devem ficar no mesmo namespace do Kubernetes e usar nomes DNS curtos (por exemplo, app e db) para se comunicar. Essa configuração também ajuda a replicar vários ambientes de aplicativos, como produção, organização e teste.

Controlar a superfície de acesso com a rede do GKE

O GKE tem controles de rede sofisticados. Os pods podem ser acessados de diferentes redes, como a Internet pública, redes VPC ou redes internas de clusters. Isso controla e restringe ainda mais a superfície de acesso a uma carga de trabalho, sem a complexidade extra do gerenciamento de VLANs, filtros ou regras de roteamento.

Por exemplo, um aplicativo comum pode ter camadas de front-end, de aplicativo e de banco de dados. Quando migrado para o Google Cloud, o serviço de front-end é configurado com um LoadBalancer na rede VPC. As outras camadas não podem ser acessadas diretamente de fora do cluster do GKE. Uma política de acesso à rede (em inglês) garante que o serviço do aplicativo seja acessível somente pelos pods de front-end da rede interna do cluster. Outra política garante que os pods de banco de dados sejam acessíveis somente pelos pods do aplicativo.

NFS

Definir montagens NFS como volumes permanentes

Ao criar o plano de migração, as montagens NFS cliente na VM de origem são descobertas e adicionadas automaticamente ao plano gerado.

As montagens são adicionadas ao plano, mas ficam desativadas por padrão. Isso significa que as definições PersistentVolume e PersistentVolumeClaim não são incluídas no arquivo deployment_spec.yaml ao gerar artefatos de migração. Se você quiser que o Migrate to Containers gere definições PersistentVolume e PersistentVolumeClaim, edite o plano de migração para ativar a montagem NFS cliente.

Consulte mais informações em Como personalizar montagens NFS.

Servidores NFS no modo kernel

VMs com servidores NFS em execução no modo kernel não podem ser migradas para o GKE com o Migrate to Containers. Essas VMs precisam ser migradas para as VMs no Compute Engine. Outra opção é usar o Filestore como uma solução NFS nativa da nuvem.

Como migrar dados de compartilhamentos NFS de origem

Se a VM de origem usar uma montagem de compartilhamento NFS, esses dados não podem ser migrados de forma automática. Monte o compartilhamento no contêiner de carga de trabalho migrado usando um volume permanente NFS ou, se o compartilhamento NFS de origem for remoto, copie os dados para outro compartilhamento de arquivos que forneça acesso de menor latência ao cluster.

Para opções de cópia de dados, confira o seguinte:

  1. Serviço de Transferência do Cloud Storage ou Transfer Appliance.

  2. Copiar dados com gcloud storage rsync do compartilhamento de arquivos de origem para o bucket e do bucket para o compartilhamento de arquivos na nuvem.

  3. Soluções de terceiros, como o SnapMirror para o Cloud Volumes da NetApp.

  4. Utilitários de código aberto (OSS, na sigla em inglês), como o Rsync.

Verificar se os bancos de dados estão acessíveis

Caso o aplicativo dependa de um banco de dados que seja executado localmente na VM ou em uma máquina externa, o banco de dados ainda precisa ficar acessível pelo novo pod migrado. É necessário validar se a política de firewall de rede permite o acesso ao banco de dados pelo cluster.

Para migrar o banco de dados para o Google Cloud, recomendamos usar o Database Migration Service.

A outra opção é executar o banco de dados dentro do cluster. Para mais informações, consulte Planejar suas implantações de banco de dados no GKE.

Verificar se os metadados injetados estão disponíveis

Se os aplicativos dependem de metadados injetados (por exemplo, variáveis de ambiente), esses metadados precisam ficar disponíveis no GKE. Se o mesmo método de injeção de metadados não estiver disponível, o GKE oferece o ConfigMaps e secrets.

Configurar os serviços necessários para iniciar no runlevel 3

As cargas de trabalho do Migrate to Containers alcançam apenas o runlevel 3. As VMs migradas para o GKE com o Migrate to Containers serão inicializadas no contêiner no runlevel 3 do Linux. Alguns serviços (por exemplo, X11 ou XDM, para acesso GUI remoto com VNC) são configurados por padrão para serem iniciados apenas no runlevel 5. Todos os serviços necessários devem ser configurados para iniciar no nível de execução 3.

Desativar serviços desnecessários

O Migrate to Containers desativa automaticamente os processos específicos de hardware ou ambiente e um conjunto predefinido de serviços executados em VMs. Esses serviços não serão necessários depois que as cargas de trabalho forem migradas para contêineres.

Por exemplo, o Migrate to Containers desativa automaticamente o iptables, o ip6tables e o firewalld. Para conferir uma lista completa dos serviços desativados pelo Migrate to Containers, baixe o arquivo blocklist.yaml.

Como personalizar serviços desativados

Por padrão, o Migrate to Containers desativa os serviços desnecessários listados acima. Também é possível definir uma lista personalizada de serviços que serão desativados em um contêiner migrado. Para isso, personalize o plano de migração para definir uma lista de bloqueio. Com uma lista de bloqueio, você especifica um ou mais serviços que serão desativados no contêiner migrado.

Manter e atualizar VMs migradas

Com os artefatos gerados durante a migração, é possível aplicar patches de segurança e atualizações de software do SO no modo de usuário e do aplicativo, editar configurações incorporadas, adicionar ou substituir arquivos e atualizar o software de ambiente de execução do Migrate to Containers.

Consulte mais informações em Atualizações de imagens pós-migração.

A seguir