Práticas recomendadas de planeamento

Este tópico oferece sugestões para migrações de aplicações para o Google Kubernetes Engine (GKE) ou o GKE Enterprise, com base em migrações de aplicações reais que foram realizadas com o Migrate to Containers.

A CLI do cliente de descoberta do centro de migração ou a CLI mcdc é uma ferramenta que usa para determinar a adequação da carga de trabalho da VM para a migração para um contentor.

Cargas de trabalho recomendadas

A migração para contentores é recomendada para determinados tipos de cargas de trabalho do Linux e do Windows, que são detalhados abaixo.

Adequado

Linux

As aplicações Linux adequadas para migração através do Migrate to Containers incluem as seguintes arquiteturas de aplicações:

• Servidores de aplicações/Web
• Middleware de lógica de negócio (por exemplo, Tomcat)
• Pilhas de várias VMs e vários níveis (por exemplo, LAMP)
• Bases de dados de tamanho pequeno/médio (por exemplo, MySQL e PostgreSQL)

Além disso, as aplicações mais adequadas para a migração com a ferramenta Migrate to Containers têm as seguintes características operacionais:

• Ciclo de trabalho baixo e cargas de trabalho intermitentes
• Ambientes de laboratório de desenvolvimento, testes e preparação
• Serviços sempre ativados e com carga baixa

Em geral, a maioria das cargas de trabalho do Linux é compatível com a migração, exceto as cargas de trabalho explicitamente indicadas abaixo em Não é uma boa opção.

Windows

As aplicações Windows adequadas para a migração através da ferramenta Migrate to Containers incluem cargas de trabalho que cumprem todas as seguintes características:

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

Apoio técnico a sistemas operativos

A migração para contentores é compatível com os seguintes sistemas operativos de VMs.

Não é uma boa opção

Linux

Para o Linux, as aplicações e os servidores que não são adequados para a migração com o Migrate to Containers incluem:

• Alto desempenho e grandes bases de dados na memória
• VMs com controladores de kernel especiais (por exemplo, NFS no modo de kernel)
• Dependências de hardware específico
• Software com licenças associadas a um determinado registo de ID de hardware

Windows

Para o Windows, as cargas de trabalho sem o IIS 7 ou superior instalado não são adequadas para a migração. Outros tipos de aplicações não adequados para migração incluem:

• Aplicações com dependências em GPUs ou TPUs
• Aplicações de rede de baixo nível
• Aplicações de computador, RDP e IATV
• Aplicações com BYOL

Regras de acesso à rede e DNS

Antes de migrar para o GKE, certifique-se de que compreende os recursos de rede e os serviços usados pelas cargas de trabalho migradas, e certifique-se de que são acessíveis e endereçáveis a partir da sua nuvem privada virtual.

Planeie os nomes dos serviços do Kubernetes

Se as suas cargas de trabalho dependem do DNS para aceder aos serviços, tem de planear o seu esquema de espaço de nomes do Kubernetes, as políticas de rede e os nomes de serviços.

A especificação de implementação gerada pelo processo de migração contém um objeto Service sem cabeçalho sugerido do tipo "ClusterIP". "ClusterIP" significa que não existe balanceamento de carga e que existe um único IP interno do cluster acessível apenas a partir do cluster. O controlador de pontos finais do Kubernetes modifica a configuração de DNS para devolver registos (endereços) que apontam para os pods, que estão etiquetados com "app": "app-name" no deployment_spec.yaml.

Nota: os nomes dos serviços do Kubernetes são mais limitados do que o que o DNS permite.

Crie e aplique serviços para ligações a pods e contentores

Após a migração de uma carga de trabalho, os nomes de anfitriões deixam de ser aplicáveis. Para permitir ligações aos seus cargas de trabalho, crie e aplique serviços.

Identifique e configure nomes e IPs migrados

O GKE gere o ficheiro /etc/hosts. Em Migrar para contentores, a adaptação do ficheiro hosts da VM de origem para o GKE ainda não está automatizada. Os nomes e os IPs no ficheiro hosts na VM migrada têm de ser identificados e configurados como hostAliases.

Coloque os serviços dependentes no mesmo espaço de nomes

Os serviços que dependem uns dos outros devem ser colocados no mesmo namespace do Kubernetes e usar nomes DNS curtos (por exemplo, app e db) para comunicar. Esta configuração também ajuda a replicar vários ambientes de aplicações, como produção, preparação e teste.

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

O GKE tem controlos de rede sofisticados. Os pods podem ser acedidos a partir de diferentes redes, como a Internet pública, a rede VPC ou a rede de cluster interna. Isto oferece a oportunidade de controlar e restringir ainda mais a superfície de acesso a uma carga de trabalho sem a complexidade adicional da gestão de VLANs, filtros ou regras de encaminhamento.

Por exemplo, uma aplicação típica de três camadas tem camadas de frontend, de aplicação e de base de dados. Quando migrado para o Google Cloud, o serviço de front-end é configurado com um LoadBalancer na rede da VPC. Os outros níveis não são diretamente acessíveis a partir do exterior do cluster do GKE. Uma política de acesso à rede garante que o serviço de aplicação só é acessível pelos pods de front-end a partir da rede de cluster interna. Outra política garante que os pods da base de dados só são acessíveis pelos pods da aplicação.

NFS

Defina montagens NFS como volumes persistentes

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

Embora os pontos de montagem sejam adicionados ao plano, estão desativados por predefinição. Isto significa que as definições de PersistentVolume e PersistentVolumeClaim não estão incluídas no ficheiro deployment_spec.yaml quando gera artefactos de migração. Se quiser que a ferramenta Migrate to Containers gere definições de PersistentVolume e PersistentVolumeClaim, tem de editar primeiro o plano de migração para ativar a montagem do cliente NFS.

Consulte o artigo Personalizar montagens NFS para mais informações.

Nota: a migração para contentores requer que as montagens NFS sejam acessíveis a partir do cluster de implementação que aloja a carga de trabalho do contentor migrado. No entanto, a opção Migrar para contentores não valida essa conetividade. Não é possível iniciar um contentor migrado com um problema de conetividade, e pode ter de editar o ficheiro deployment_spec.yaml para corrigir o problema. Consulte o artigo Aceda a instâncias do Filestore com o controlador CSI do Filestore para mais informações.

Nota: a utilização do NFS através de um link VPN pode ter um desempenho reduzido devido ao aumento da latência e à redução da largura de banda.

Servidores NFS no modo kernel

Não é possível migrar VMs com servidores NFS em execução no modo de kernel para o GKE com o Migrate to Containers. Estas VMs têm de ser migradas para VMs no Compute Engine. Em alternativa, pode usar o Filestore para uma solução NFS nativa da nuvem.

Migrar dados de partilhas NFS de origem

Se a VM de origem estiver a usar uma montagem de partilha NFS, estes dados não podem ser migrados automaticamente. Monte a partilha no contentor da carga de trabalho migrada através de um volume persistente do NFS ou, se a partilha do NFS de origem for remota, copie os dados para outra partilha de ficheiros que ofereça um 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 armazenamento ou Transfer Appliance.

2. Copiar dados com gcloud storage rsync (da partilha de ficheiros de origem para o contentor e, em seguida, do contentor para a partilha de ficheiros na nuvem).

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

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

Certifique-se de que as bases de dados estão acessíveis

Caso a sua aplicação dependa de uma base de dados, quer seja uma que seja executada localmente na VM ou numa máquina externa, tem de garantir que a base de dados continua acessível a partir do novo pod migrado. Tem de validar se a sua política de firewall de rede permite o acesso do cluster à base de dados.

Para migrar a base de dados para Google Cloud, recomendamos que use o Database Migration Service

Em alternativa, pode executar a base de dados no cluster. Para mais informações, consulte o artigo Planeie as implementações da base de dados no GKE.

Certifique-se de que os metadados injetados estão disponíveis

Se as suas aplicações dependerem de metadados injetados (por exemplo, variáveis de ambiente), tem de garantir que estes metadados estão disponíveis no GKE. Se o mesmo método de injeção de metadados não estiver disponível, o GKE oferece ConfigMaps e Secrets.

Configure os serviços necessários para serem iniciados no nível de execução 3

As cargas de trabalho do Migrate to Containers só atingem o nível de execução 3. As VMs migradas para o GKE com o Migrate to Containers são iniciadas no contentor no nível de execução 3 do Linux. Determinados serviços (por exemplo, X11 ou XDM, para acesso remoto à GUI através do VNC) estão configurados por predefinição para serem iniciados apenas no nível de execução 5. Todos os serviços necessários devem ser configurados para serem iniciados no nível de execução 3.

Desative os serviços desnecessários

A migração para contentores desativa automaticamente os serviços específicos do hardware ou do ambiente, bem como um conjunto predefinido de serviços adicionais executados em VMs. Estes serviços não são necessários depois de migrar as suas cargas de trabalho para contentores.

Por exemplo, o Migrate to Containers desativa automaticamente o iptables, o ip6tables e o firewalld. Para uma lista completa dos serviços desativados pela migração para contentores, transfira o ficheiro blocklist.yaml.

Personalizar serviços desativados

Por predefinição, a ferramenta Migre para contentores desativa os serviços desnecessários indicados acima. Também pode definir a sua própria lista personalizada de serviços a desativar num contentor migrado personalizando o plano de migração para definir uma lista de bloqueios. Com uma lista de bloqueio, especifica um ou mais serviços a desativar num contentor migrado.

Faça a manutenção e atualize as VMs migradas

Usando os artefactos que gera durante a migração, pode aplicar atualizações de software do SO no modo de utilizador e da aplicação, patches de segurança, editar configurações incorporadas, adicionar ou substituir ficheiros e atualizar o software de tempo de execução do Migrate to Containers.

Para mais informações, consulte o artigo Atualizações de imagens após a migração.

O que se segue?

• Saiba mais sobre a avaliação offline.