Práticas recomendadas de planejamento

Este tópico oferece conselhos para migrações de aplicativos para o Google Kubernetes Engine (GKE) ou GKE Enterprise, com base nas migrações de aplicativos reais que foram realizados com o Migrate to Containers.

A CLI do discovery client da Central de migração ou a CLI mcdc é uma ferramenta usada para determinar 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 usando o Migrate to Containers incluem 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 as seguintes características operacionais:

  • Baixo ciclo de trabalho e cargas de trabalho com picos
  • 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 abaixo em Não é uma boa opção.

Windows

Os aplicativos do Windows que são adequados para migração usando o Migrate to Containers incluem cargas de trabalho que atendem a todas as características a seguir:

  • IIS 7 ou posterior, ASP.NET com .NET Framework 3.5 ou posterior
  • Níveis 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ção inadequada

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 sem o IIS 7 ou superior instalado não são adequadas para a migração. Outros tipos de aplicativos que não são adequados para migração incluem:

  • Aplicativos com dependências em GPUs ou TPUs
  • Aplicativos de rede de baixo nível
  • Aplicativos de área de trabalho, 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 verifique se eles são acessíveis e endereçáveis a partir da sua nuvem privada virtual.

Planejar os nomes dos serviços do Kubernetes

Se suas 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 do Kubernetes.

A especificação de implantação gerada pelo processo de migração contém um objeto Service headless sugerido do tipo "ClusterIP". "ClusterIP" significa que não há balanceamento de carga, e um único IP interno de cluster acessível apenas a partir do cluster. O controlador de endpoints do Kubernetes modificará 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 suas 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 de hosts da VM de origem para o GKE ainda não foi automatizada. Os nomes e IPs no arquivo de 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 precisam ser colocados 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, preparo 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, a rede VPC ou a rede interna de clusters. Isso oferece a oportunidade de controlar e restringir 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 típico de três camadas tem 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. Os outros níveis não são acessíveis diretamente de fora do cluster do GKE. Uma política de acesso à rede 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 de NFS como volumes permanentes

Quando você cria o plano de migração, as montagens de cliente NFS na VM de origem são descobertas e adicionadas automaticamente ao plano gerado.

Enquanto as ativações são adicionadas ao plano, elas são desativadas por padrão. Isso significa que as definições PersistentVolume e PersistentVolumeClaim não são incluídas no arquivo deployment_spec.yaml quando você gera artefatos de migração. Se você quiser que o Migrate to Containers gere definições de PersistentVolume e PersistentVolumeClaim, primeiro edite o plano de migração para ativar a ativação do cliente NFS.

Consulte Como personalizar montagens de NFS para mais informações.

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 para uma solução NFS nativa da nuvem.

Como migrar dados de compartilhamentos NFS de origem

Se sua VM de origem estiver usando uma montagem de compartilhamento NFS, esses dados não poderão ser migrados automaticamente. 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, consulte o seguinte:

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

  2. Copiar dados com gcloud storage rsync (do compartilhamento do arquivo de origem para o bucket e, então, do bucket para o compartilhamento de arquivos na nuvem).

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

  4. Utilitários de OSS, como o Rsync.

Garantir que os bancos de dados estejam acessíveis

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

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

Como alternativa, é possível 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 seus aplicativos dependem de metadados injetados (por exemplo, variáveis de ambiente), você precisa garantir que esses metadados estejam disponíveis no GKE. Se o mesmo método de injeção de metadados não estiver disponível, o GKE oferecerá ConfigMaps e o Secrets.

Configurar os serviços necessários para iniciar no nível de execução 3

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

Desativar serviços desnecessários

O Migrate to Containers desativa automaticamente os serviços específicos de hardware ou ambiente, além de um conjunto predefinido de outros serviços executados em VMs. Esses serviços não serão necessários depois que você migrar suas cargas de trabalho para contêineres.

Por exemplo, o Migrate to Containers desativa automaticamente o iptables, ip6tables e o firewall. Para ver uma lista completa dos serviços desativados pelo Migrate to Containers, faça o download do arquivo blocklist.yaml.

Como personalizar serviços desativados

Por padrão, a opção "Migrate to Containers" desativa os serviços desnecessários listados acima. Também é possível definir sua própria lista personalizada de serviços que será desativada 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 a serem desativados no contêiner migrado.

Manter e atualizar VMs migradas

Usando 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.

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

A seguir