Práticas recomendadas de planejamento

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

O Migrate for Anthos and GKE fornece ferramentas para serem executadas em uma carga de trabalho da VM e determinar a adequação da carga de trabalho para migração a um contêiner. Veja mais informações em:

O Migrate for Anthos and GKE são recomendados para determinados tipos de cargas de trabalho do Linux e do Windows, que são detalhados abaixo.

Opção adequada

Linux

Os aplicativos do Linux que são ideais para migração usando o Migrate for Anthos and GKE 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 for Anthos e o GKE 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 for Anthos incluem cargas de trabalho que atendem a todas as seguintes características:

  • 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 for Anthos and GKE são compatíveis com esses sistemas operacionais de VM.

Opção inadequada

Linux

No caso do Linux, os aplicativos e servidores que não são adequados para migração com o Migrate for Anthos and GKE 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 (links em inglês) 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 for Anthos and GKE, 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 (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 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 for Anthos and GKE gere definições PersistentVolume e PersistentVolumeClaim, primeiro edite o plano de migração para ativar a montagem de cliente NFS.

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

Servidores NFS no modo kernel

As VMs com servidores NFS em execução no modo kernel não podem ser migradas para o GKE com o Migrate for Anthos and GKE. 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 de dados do Cloud ou o Data Transfer Appliance

  2. Copiar dados com gsutil 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.

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á o 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 for Anthos and GKE alcançam apenas o nível de execução 3. As VMs migradas para o GKE com o Migrate for Anthos and GKE serão inicializadas no contêiner no nível de execução 3 (em inglês) 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 for Anthos and GKE 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 for Anthos and GKE desativam automaticamente iptables, ip6tables e firewall. Para ver uma lista completa dos serviços desativados pelo Migrate for Anthos and GKE, faça o download do arquivo blocklist.yaml.

Como personalizar serviços desativados

Por padrão, o Migrate for Anthos and GKE desativam 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 for Anthos.

Para mais informações, consulte Atualizações de imagens pós-migração.