Migrar contêineres para o Google Cloud: migrar do Kubernetes para o GKE

Last reviewed 2024-06-22 UTC

Este documento ajuda você a planejar, projetar e implementar a migração de um ambiente autogerenciado do Kubernetes para o Google Kubernetes Engine (GKE). Se feita incorretamente, a migração de aplicativos de um ambiente para outro pode ser uma tarefa desafiadora. Portanto, você precisa planejar e executar a migração com cuidado.

Este documento é útil se você planeja migrar de um ambiente autogerenciado do Kubernetes para o GKE. É possível que seu ambiente seja executado localmente, em um ambiente de hospedagem particular ou em outro provedor de nuvem. Este documento também é útil se você estiver avaliando a oportunidade de migrar e quiser saber como funciona esse processo.

O GKE é um serviço do Kubernetes gerenciado pelo Google que pode ser usado para implantar e operar aplicativos conteinerizados em escala usando a infraestrutura do Google. Ele oferece recursos que ajudam a gerenciar seu ambiente do Kubernetes, como:

Duas edições: GKE Standard e GKE Enterprise. Com o GKE Standard, você tem acesso a um nível padrão de recursos principais. Com o GKE Enterprise, você tem acesso a todos os recursos do GKE. Para mais informações, consulte Edições do GKE.
Dois modos de operação: padrão e Autopilot. Com o padrão, você gerencia a infraestrutura subjacente e a configuração de cada nó no cluster do GKE. Com o Autopilot, o GKE gerencia a infraestrutura subjacente, como configuração de nós, escalonamento automático, upgrades automáticos, segurança de referência e configuração de rede. Para mais informações sobre os modos de operação do GKE, consulte Escolher um modo de operação do GKE.
Contrato de nível de serviço exclusivo do setor para pods ao usar o Autopilot em várias zonas.
Criação e exclusão automatizadas de pools de nós com provisionamento automático de nós.
Redes de vários clusters gerenciadas pelo Google para ajudar você a projetar e implementar arquiteturas distribuídas e altamente disponíveis para suas cargas de trabalho.

Para mais informações sobre o GKE, consulte a visão geral do GKE.

Para essa migração para o Google Cloud, recomendamos que você siga o framework de migração descrito em Migrar para o Google Cloud: primeiros passos.

No diagrama a seguir, veja o caminho da sua jornada de migração.

Caminho de migração com quatro fases.

É possível migrar do seu ambiente de origem para o Google Cloud em uma série de iterações. Por exemplo, é possível migrar algumas cargas de trabalho primeiro e outras mais tarde. Para cada iteração de migração separada, siga as fases do framework de migração geral:

Avaliar e descobrir suas cargas de trabalho e seus dados.
Planejar e criar uma base no Google Cloud.
Migrar suas cargas de trabalho e seus dados para o Google Cloud.
Otimizar seu ambiente do Google Cloud.

Para mais informações sobre as fases desse framework, consulte Migrar para o Google Cloud: primeiros passos.

Para elaborar um plano de migração eficaz, recomendamos que você valide cada etapa do plano e use uma estratégia de reversão. Para ajudar você a validar o plano de migração, consulte Migrar para o Google Cloud: práticas recomendadas para validar um plano de migração.

Avaliar o ambiente

Na fase de avaliação, você determina os requisitos e as dependências para migrar seu ambiente de origem para o Google Cloud.

A fase de avaliação é fundamental para o sucesso da migração. Você precisa ter um excelente conhecimento das cargas de trabalho que quer migrar, dos requisitos, das dependências e do ambiente atual. Você precisa saber seu ponto de partida para planejar e executar uma migração do Google Cloud.

A fase de avaliação consiste nas tarefas a seguir:

Criar um inventário abrangente das suas cargas de trabalho.
Catalogar suas cargas de trabalho de acordo com as propriedades e dependências delas.
Treine e instrua suas equipes no Google Cloud.
Criar experimentos e provas de conceito no Google Cloud.
Calcule o custo total de propriedade (TCO) do ambiente de destino.
Escolha a estratégia de migração para suas cargas de trabalho.
Escolha as ferramentas de migração.
Defina o plano e o cronograma de migração.
Valide seu plano de migração.

Para mais informações sobre a fase de avaliação e essas tarefas, consulte Migrar para o Google Cloud: avaliar e descobrir cargas de trabalho. As seções a seguir são baseadas nas informações desse documento.

Criar seus inventários

Para definir o escopo da migração, crie dois inventários:

O inventário dos clusters.
O inventário das cargas de trabalho implantadas nesses clusters.

Depois de criar esses inventários, você:

Avalie os processos operacionais e de implantação do ambiente de origem.
Avalie os serviços de suporte e as dependências externas.

Criar o inventário dos clusters

Para criar o inventário dos clusters, considere o seguinte para cada cluster:

Número e tipo de nós. Quando você sabe a quantidade de nós e as características de cada nó no ambiente atual, você dimensiona os clusters ao migrar para o GKE. Os nós no novo ambiente podem ser executados em uma geração de arquitetura de hardware diferente daquelas que você usa no ambiente. O desempenho de cada geração de arquitetura é diferente. Portanto, o número de nós necessários no novo ambiente pode ser diferente do ambiente. Avalie qualquer tipo de hardware que você esteja usando nos nós, como dispositivos de armazenamento de alto desempenho, GPUs e TPUs. Avalie qual imagem do sistema operacional você está usando nos nós.
Cluster interno ou externo. Avalie a quais agentes, internos ou externos, cada cluster está exposto. Para oferecer suporte aos casos de uso, essa avaliação inclui as cargas de trabalho em execução no cluster e as interfaces que interagem com os clusters.
Multilocação Se você estiver gerenciando clusters multilocatários no seu ambiente, avalie se ele funciona no novo ambiente do Google Cloud. Agora é um bom momento para avaliar como melhorar seus clusters multilocatários porque sua estratégia multilocatário influencia a forma como você cria sua base no Google Cloud.
Versão do Kubernetes Colete informações sobre a versão do Kubernetes dos clusters para avaliar se há incompatibilidade entre essas versões e as disponíveis no GKE. Se você estiver executando uma versão mais antiga ou lançada recentemente do Kubernetes, talvez esteja usando recursos indisponíveis no GKE. Talvez os recursos estejam obsoletos ou a versão do Kubernetes que os envia ainda não esteja disponível no GKE.
Ciclo de upgrade do Kubernetes. Para manter um ambiente confiável, entenda como você está lidando com upgrades do Kubernetes e como seu ciclo de upgrade está relacionado aos upgrades do GKE.
Pools de nós. Se você estiver usando qualquer forma de agrupamento de nós, considere como esses agrupamentos são mapeados para o conceito de pools de nós no GKE porque seus critérios de agrupamento talvez não sejam adequados para o GKE.
Inicialização do nó. Avalie como inicializar cada nó antes de marcá-lo como disponível para executar suas cargas de trabalho. Assim, é possível transferir esses procedimentos de inicialização para o GKE.
Configuração de rede. Avalie a configuração de rede dos clusters, a alocação de endereços IP, como você configurou os plug-ins de rede, como você configurou os servidores DNS e os provedores de serviços DNS, se você configurou alguma forma de NAT ou SNAT para esses clusters e se eles fazem parte de um ambiente de vários clusters.
Compliance: avalie todos os requisitos regulamentares e de compliance que seus clusters precisam atender e se você está atendendo a esses requisitos.
Cotas e limites. Avalie como você configurou cotas e limites para seus clusters. Por exemplo, quantos pods cada nó pode executar? Quantos nós um cluster pode ter?
Rótulos e tags Avalie os metadados aplicados a clusters, pools de nós e nós e como você os usa. Por exemplo, você pode estar gerando relatórios com atribuição de custo detalhada e baseada em rótulos.

Os itens a seguir que você avalia no seu inventário concentram-se na segurança da infraestrutura e dos clusters do Kubernetes:

Namespaces: Se você usa namespaces do Kubernetes nos clusters para separar recursos logicamente, avalie quais recursos estão em cada namespace e entenda por que você criou essa separação. Por exemplo, é possível usar namespaces como parte da sua estratégia de multilocação. Talvez você tenha cargas de trabalho implantadas em namespaces reservados para componentes do sistema do Kubernetes e talvez não tenha tanto controle no GKE.
Controle de acesso baseado em papéis (RBAC) Se você usa a autorização RBAC nos clusters, liste uma descrição de todos os ClusterRoles e ClusterRoleBindings configurados nos clusters.
Políticas de rede: Liste todas as políticas de rede configuradas nos clusters e entenda como as políticas de rede funcionam no GKE.
Contextos de segurança do pod. Colete informações sobre os Contextos de segurança do pod que você configurou nos clusters e saiba como eles funcionam no GKE.
Contas de serviço. Se algum processo no cluster estiver interagindo com o servidor da API Kubernetes, colete informações sobre as contas de serviço que estão sendo usadas.

Ao criar o inventário dos clusters do Kubernetes, talvez você descubra que alguns dos clusters precisam ser desativados como parte da migração. Verifique se o plano de migração inclui a suspensão do uso desses recursos.

Criar o inventário das cargas de trabalho do Kubernetes

Depois de concluir o inventário de clusters do Kubernetes e avaliar a segurança do ambiente, crie o inventário das cargas de trabalho implantadas nesses clusters. Ao avaliar suas cargas de trabalho, colete informações sobre os seguintes aspectos:

Pods e controladores. Para dimensionar os clusters no novo ambiente, avalie quantas instâncias de cada carga de trabalho você implantou e se está usando cotas de recursos, e calcule os limites de consumo de recursos. Reúna informações sobre as cargas de trabalho em execução nos nós do plano de controle de cada cluster e os controladores que cada carga de trabalho usa. Por exemplo, quantas implantações você está usando? Quantos DaemonSets você está usando?
Jobs e CronJobs. Os clusters e as cargas de trabalho podem precisar executar jobs ou cron jobs como parte dos procedimentos de inicialização ou operação. Avalie quantas instâncias de Jobs e CronJobs você implantou e as responsabilidades e critérios de conclusão de cada instância.
Escalonadores automáticos do Kubernetes. Para migrar as políticas de escalonamento automático no novo ambiente, saiba como o escalonador automático horizontal de pods e o escalonador automático de pods vertical funcionam no GKE.
Cargas de trabalho sem estado e com estado. As cargas de trabalho sem estado não armazenam dados ou estado no cluster nem no armazenamento permanente. Os aplicativos com estado salvam dados para uso posterior. Para cada carga de trabalho, avalie quais componentes são sem estado e quais são com estado, tendo em vista que migrar cargas de trabalho com estado normalmente é mais difícil do que migrar sem estado.
Recursos do Kubernetes. No inventário do cluster, você sabe qual versão do Kubernetes cada cluster executa. Revise as Notas de lançamento de cada versão do Kubernetes para saber quais recursos são enviados e quais recursos estão obsoletos. Em seguida, avalie suas cargas de trabalho em relação aos recursos do Kubernetes necessários. A meta desta tarefa é saber se você está usando recursos obsoletos ou que ainda não estão disponíveis no GKE. Se você encontrar recursos indisponíveis, migre dos recursos obsoletos e adote os novos quando eles estiverem disponíveis no GKE.
Storage. Para cargas de trabalho com estado, avalie se elas usam PersistenceVolumeClaims. Liste todos os requisitos de armazenamento, como tamanho e modo de acesso, e como esses PersistenceVolumeClaims são mapeados para PersistenceVolumes. Para contabilizar o crescimento futuro, avalie se você precisa expandir qualquer PersistenceVolumeClaim.
Configuração e injeção de segredo. Para evitar a recriação dos artefatos implantáveis sempre que houver uma alteração na configuração do ambiente, injete a configuração e os segredos nos pods usando ConfigMaps e Secrets. Para cada carga de trabalho, avalie quais ConfigMaps e Secrets a carga de trabalho está usando e como você está preenchendo esses objetos.
Dependências Suas cargas de trabalho provavelmente não funcionam isoladamente. Talvez elas tenham dependências internas ao cluster ou dependências de sistemas externos. Colete as dependências para cada carga de trabalho e se as cargas de trabalho tiverem tolerância quando as dependências estiverem indisponíveis. Por exemplo, dependências comuns incluem sistemas de arquivos distribuídos, bancos de dados, plataformas de distribuição secretas, sistemas de gerenciamento de identidade e acesso, mecanismos de descoberta de serviços e outros sistemas externos.
Serviços do Kubernetes Para expor suas cargas de trabalho a clientes internos e externos, use Serviços. Para cada serviço, você precisa saber o tipo. Para serviços expostos externamente, avalie como esses serviços interagem com o restante da sua infraestrutura. Por exemplo, como sua infraestrutura é compatível com serviços LoadBalancer, objetos de gateway e objetos de Ingresso? Quais controladores de Entrada você implantou nos clusters?
Service mesh. Se você estiver usando uma malha de serviço no ambiente, avalie como ela é configurada. Você também precisa saber quantos clusters ela abrange, quais serviços fazem parte da malha e como modificar a topologia da malha.
Taints e tolerâncias e afinidade e antiafinidade. Para cada pod e nó, avalie se você configurou taints, tolerâncias ou afinidades de nós para personalizar a programação de pods nos clusters do Kubernetes. Essas propriedades também fornecem insights sobre possíveis configurações não homogêneas de nós ou pods e podem fazer com que os pods, os nós ou ambos precisem ser avaliados com foco e cuidado especiais. Por exemplo, se você configurou um conjunto específico de pods para ser programado apenas em determinados nós no cluster do Kubernetes, isso pode significar que os pods precisam de recursos especializados disponíveis apenas nesses nós.
Autenticação: avalie como as cargas de trabalho são autenticadas em recursos no cluster e em recursos externos.

Avaliar serviços de suporte e dependências externas

Depois de avaliar os clusters e as cargas de trabalho, avalie o restante dos serviços e aspectos de suporte na infraestrutura, como os seguintes:

StorageClasses e PersistentVolumes. Avalie como sua infraestrutura faz backup de PersistentVolumeClaims listando StorageClasses para provisionamento dinâmico e PersistentVolumes provisionados estaticamente. Para cada PersistentVolume, considere os seguintes itens: capacidade, modo de volume, modo de acesso, classe, política de reivindicação, opções de ativação e afinidade de nó.
VolumeSnapshots e VolumeSnapshotContents. Para cada PersistentVolume, avalie se você configurou algum VolumeSnapshot, e se precisa migrar algum VolumeSnapshotContents existente.
Drivers da interface de armazenamento em contêineres (CSI, na sigla em inglês) Se implantados nos clusters, avalie se esses drivers são compatíveis com o GKE e se é necessário adaptar a configuração dos volumes para trabalhar com drivers CSI compatíveis com o GKE
Armazenamento de dados. Se você depender de sistemas externos para provisionar PersistentVolumes, forneça uma maneira para as cargas de trabalho no ambiente do GKE usarem esses sistemas. A localidade dos dados afeta o desempenho das cargas de trabalho com estado porque a latência entre os sistemas externos e o ambiente do GKE é proporcional à distância entre eles. Para cada sistema de armazenamento de dados externo, considere o tipo, como volumes de blocos, armazenamento de arquivos ou armazenamento de objetos, e quaisquer requisitos de desempenho e disponibilidade que precisam ser cumpridos.
Recursos personalizados e complementos do Kubernetes. Colete informações sobre os recursos personalizados do Kubernetes e os complementos do Kubernetes implantados nos clusters porque eles podem não funcionar no GKE ou talvez seja necessário modificá-los. Por exemplo, se um recurso personalizado interagir com um sistema externo, será necessário avaliar se isso é aplicável ao seu ambiente do Google Cloud.
Backup. Avalie como você está fazendo backup da configuração dos clusters e dos dados de carga de trabalho com estado no ambiente de origem.

Avaliar os processos operacionais e de implantação

É fundamental ter um entendimento claro de como seus processos operacionais e de implantação funcionam. Eles são parte fundamental das práticas que preparam e mantêm o ambiente de produção e as cargas de trabalho executadas nele.

Os processos operacionais e de implantação podem criar os artefatos necessários para as cargas de trabalho funcionarem. Portanto, colete informações sobre cada tipo de artefato. Por exemplo, um artefato pode ser um pacote de sistema operacional, um pacote de implantação de aplicativo, uma imagem do sistema operacional, uma imagem de contêiner ou qualquer outra coisa.

Além do tipo de artefato, considere como você conclui as seguintes tarefas:

Desenvolva seus workloads. Avalie os processos que as equipes de desenvolvimento têm para criar suas cargas de trabalho. Por exemplo, como suas equipes de desenvolvimento projetam, codificam e testam suas cargas de trabalho?
Gerar os artefatos implantados no ambiente de origem. Para implantar as cargas de trabalho no ambiente de origem, você pode gerar artefatos implantáveis, como imagens de contêiner ou do sistema operacional, ou personalizar artefatos existentes, como imagens de sistema operacional de terceiros, instalando e configurando software. A coleta de informações sobre como você gera esses artefatos ajuda a garantir que os artefatos gerados sejam adequados para implantação no Google Cloud.
Armazene os artefatos. Se você produzir artefatos armazenados em um registro de artefatos no ambiente de origem, será necessário disponibilizá-los no ambiente do Google Cloud. Para fazer isso, use estratégias como as seguintes:
- Estabeleça um canal de comunicação entre os ambientes: torne os artefatos no ambiente de origem acessíveis pelo ambiente de destino do Google Cloud.
- Refatorar o processo de compilação do artefato: conclua uma pequena refatoração do ambiente de origem para que seja possível armazenar artefatos nos ambientes de origem e de destino. Essa abordagem oferece suporte à migração por meio da criação de uma infraestrutura como um repositório de artefatos antes da implementação dos processos de compilação de artefatos no ambiente de destino do Google Cloud. É possível implementar essa abordagem diretamente ou aproveitar a abordagem anterior de estabelecer um canal de comunicação primeiro.
Ter artefatos disponíveis nos ambientes de origem e de destino permite que você se concentre na migração sem precisar implementar processos de criação de artefatos no ambiente de destino do Google Cloud como parte da migração.
Ler e assinar o código. Como parte dos processos de build de artefatos, você pode usar a verificação de código para se proteger contra vulnerabilidades comuns e exposição não intencional à rede, além de assinar o código para garantir que apenas códigos confiáveis sejam executados nos seus ambientes.
Implante artefatos no ambiente de origem. Depois de gerar artefatos implantáveis, você pode implantá-los no ambiente de origem. Recomendamos que você avalie cada processo de implantação. A avaliação ajuda a garantir que os processos de implantação sejam compatíveis com o Google Cloud. Isso também ajuda você a entender o esforço necessário para refatorar os processos. Por exemplo, se os processos de implantação funcionarem apenas com o ambiente de origem, talvez seja necessário refatorá-los para segmentar o ambiente do Google Cloud.
Injetar a configuração do ambiente de execução. Talvez você esteja injetando a configuração do ambiente de execução para clusters, ambientes de execução ou implantações de carga de trabalho específicos. A configuração pode inicializar variáveis de ambiente e outros valores de configuração, como segredos, credenciais e chaves. Para garantir que os processos de injeção de configuração do ambiente de execução funcionem no Google Cloud, recomendamos que você avalie como está configurando as cargas de trabalho executadas no ambiente de origem.
Geração de registros, monitoramento e criação de perfis. Avalie os processos de registro, monitoramento e criação de perfil que você tem para monitorar a integridade do ambiente de origem, as métricas de interesse e como você consome os dados fornecidos por esses processos.
Autenticação de cluster. Avalie como você está fazendo a autenticação no seu ambiente de origem.
Provisione e configure seus recursos. Para preparar o ambiente de origem, é possível que você tenha projetado e implementado processos que provisionem e configurem recursos. Por exemplo, você pode usar o Terraform com ferramentas de gerenciamento de configuração para provisionar e configurar recursos no ambiente de origem.

Planejar e criar sua base

Na fase de planejamento e criação, você provisiona e configura a infraestrutura para fazer o seguinte:

Oferecer suporte às cargas de trabalho no ambiente do Google Cloud.
Conectar os ambientes de origem e do Google Cloud para concluir a migração.

A fase de criação e planejamento é composta pelas seguintes tarefas:

Criar uma hierarquia de recursos.
Configurar o Identity and Access Management (IAM) do Google Cloud.
configurar o faturamento
Configurar a conectividade de rede.
Aumentar sua segurança.
Configurar a geração de registros, o monitoramento e os alertas.

Para mais informações sobre cada uma dessas tarefas, consulte Migrar para o Google Cloud: planeje e crie sua base.

As seções a seguir integram as considerações em Migrar para o Google Cloud: planejar e criar sua base.

Planejar para multilocação

Para projetar uma hierarquia de recursos eficiente, considere como suas estruturas empresariais e organizacionais são mapeadas para o Google Cloud. Por exemplo, caso precise de um ambiente multilocatário no GKE, é possível escolher entre as seguintes opções:

Criação de um projeto do Google Cloud para cada locatário.
Compartilhamento de um projeto entre locatários diferentes e provisionamento de vários clusters do GKE.
Uso de namespaces do Kubernetes.

Sua escolha depende das suas necessidades de isolamento, complexidade e escalabilidade. Por exemplo, um projeto por locatário faz com que os locatários sejam isolados, mas o gerenciamento da hierarquia de recursos se torna mais complexo devido ao grande número de projetos. No entanto, embora o gerenciamento de namespaces do Kubernetes seja relativamente mais fácil do que uma hierarquia de recursos complexa, essa opção não garante tanto isolamento. Por exemplo, o plano de controle pode ser compartilhado entre os locatários. Para mais informações, consulte Multilocação de cluster.

Configure o gerenciamento de identidade e acesso

O GKE oferece suporte a várias opções para gerenciar o acesso a recursos no seu projeto do Google Cloud e nos clusters dele usando o RBAC. Para mais informações, consulte Controle de acesso.

Configurar a rede do GKE

A configuração de rede é um aspecto fundamental do seu ambiente. Antes de provisionar e configurar qualquer cluster, recomendamos que você avalie o modelo de rede do GKE, as práticas recomendadas para redes do GKE e como planejar endereços IP ao migrar para o GKE.

Configurar o monitoramento e os alertas

Ter uma visão clara do desempenho da infraestrutura e das cargas de trabalho é fundamental para encontrar áreas de melhoria. O GKE tem integrações avançadas com o Google Cloud Observability. Assim, você recebe informações de registro e monitoramento sobre clusters e cargas de trabalho do GKE dentro desses clusters.

Migrar dados e implantar cargas de trabalho

Na fase de implantação, faça o seguinte:

Provisione e configure o ambiente do GKE.
Configure os clusters do GKE.
Refazer as cargas de trabalho.
Refatorar os processos operacionais e de implantação
Migre dados do seu ambiente de origem para o Google Cloud.
Implante as cargas de trabalho no ambiente do GKE.
Valide as cargas de trabalho e o ambiente do GKE.
Exponha cargas de trabalho em execução no GKE.
Desloque o tráfego do ambiente de origem para o ambiente do GKE.
Desativar o ambiente de origem.

Provisionar e configurar seu ambiente do Google Cloud

Antes de migrar qualquer carga de trabalho para o novo ambiente do Google Cloud, você precisa provisionar os clusters do GKE.

O GKE oferece suporte à ativação de determinados recursos em clusters existentes, mas alguns só podem ser ativados na criação do cluster. Para evitar interrupções e simplificar a migração, recomendamos que você ative os recursos necessários na criação do cluster. Caso contrário, talvez seja necessário destruir e recriar os clusters caso os recursos necessários não possam ser ativados após a criação de um cluster.

Após a fase de avaliação, você tem conhecimento suficiente para provisionar os clusters do GKE no novo ambiente do Google Cloud para atender às suas necessidades. Para provisionar os clusters, considere o seguinte:

O número de clusters, o número de nós por cluster, os tipos de clusters, a configuração de cada cluster e cada nó e os planos de escalonabilidade de cada cluster.
O modo de operação de cada cluster. O GKE oferece dois modos de operação para clusters: GKE Autopilot e GKE Standard.
O número de clusters particulares.
A escolha entre rede nativa de VPC ou baseada em roteador.
As versões do Kubernetes e os canais de lançamento necessários nos clusters do GKE.
Os pools de nós para agrupar logicamente os nós nos clusters do GKE e caso seja necessário criar pools de nós automaticamente com o provisionamento automático de nós.
Os procedimentos de inicialização que é possível transferir do seu ambiente para o ambiente do GKE e novos procedimentos que podem ser implementados. Por exemplo, é possível inicializar automaticamente os nós do GKE implementando um ou vários procedimentos de inicialização com privilégios para cada nó ou pool de nós nos clusters.
Os planos de escalonabilidade para cada cluster.
Os recursos adicionais do GKE necessários, como o Cloud Service Mesh e os complementos do GKE, como o Backup para GKE.

Para mais informações sobre o provisionamento de clusters do GKE, consulte:

Gerenciamento de frotas

Ao provisionar seus clusters do GKE, você pode perceber que precisa de um grande número deles para oferecer suporte a todos os casos de uso do seu ambiente. Por exemplo, talvez seja necessário separar a produção de ambientes não de produção ou separar serviços entre equipes ou regiões geográficas. Para mais informações, consulte Casos de uso de vários clusters.

À medida que o número de clusters aumenta, o ambiente do GKE pode ficar mais difícil de operar, porque gerenciar um grande número de clusters apresenta desafios operacionais e de escalonamento significativos. O GKE oferece ferramentas e recursos para ajudar a gerenciar frotas, um agrupamento lógico de clusters do Kubernetes. Para mais informações, consulte Gerenciamento de frotas.

Rede de vários clusters

Para melhorar a confiabilidade do ambiente do GKE e distribuir as cargas de trabalho em vários clusters do GKE, use:

Descoberta de serviços de vários clusters, um mecanismo de descoberta e invocação de serviços entre clusters. Os serviços são detectáveis e acessíveis em clusters do GKE. Para mais informações, consulte Descoberta de serviços de vários clusters.
Gateways de vários clusters, um mecanismo de balanceamento de carga de tráfego de entrada entre clusters. Para mais informações, consulte Como implantar gateways de vários clusters.
Malha de vários clusters no Cloud Service Mesh gerenciado. Para mais informações, consulte Configurar uma malha de vários clusters.

Para mais informações sobre como migrar de um ambiente do GKE de cluster único para um ambiente do GKE de vários clusters, consulte Migrar para a rede de vários clusters.

Configure os clusters do GKE

Depois de provisionar os clusters do GKE e antes de implantar qualquer carga de trabalho ou migrar dados, configure namespaces, RBAC, políticas de rede, Contas de serviços, e outros objetos do Kubernetes e do GKE para cada cluster do GKE.

Para configurar objetos do Kubernetes e do GKE nos clusters do GKE, recomendamos que você faça o seguinte:

Verifique se você tem as credenciais e permissões necessárias para acessar os clusters no ambiente de origem e no GKE.
Avalie se os objetos nos clusters do Kubernetes no ambiente de origem são compatíveis com o GKE e como as implementações que respaldam esses objetos são diferentes do ambiente de origem e do GKE.
Refatore qualquer objeto incompatível para torná-lo compatível com o GKE ou desative-o.
Migre esses objetos para os clusters do GKE.
Configure todos os objetos adicionais necessários nos clusters do GKE.

Config Sync

Para ajudar você a adotar as práticas recomendadas do GitOps para gerenciar a configuração dos clusters do GKE à medida que o GKE é dimensionado, recomendamos o uso do Config Sync, um serviço do GitOps para implantar configurações de uma fonte de verdade. Por exemplo, é possível armazenar os clusters do GKE em um repositório Git e usar o Config Sync para aplicar essa configuração.

Para mais informações, consulte Arquitetura do Config Sync.

Policy Controller

O Controlador de Políticas ajuda a aplicar e impor políticas programáveis para garantir que os clusters e workloads do GKE sejam executados de forma segura e em compliance. À medida que o ambiente do GKE é dimensionado, é possível usar o Policy Controller para aplicar automaticamente políticas, pacotes de políticas e restrições a todos os clusters do GKE. Por exemplo, você pode restringir os repositórios de onde as imagens do contêiner podem ser extraídas ou exigir que cada namespace tenha pelo menos um rótulo para garantir o rastreamento preciso do consumo de recursos.

Para mais informações, consulte Controlador de políticas.

Refazer suas cargas de trabalho

Uma prática recomendada para projetar cargas de trabalho conteinerizadas é evitar dependências da plataforma de orquestração de contêineres. Isso nem sempre é possível na prática devido aos requisitos e ao design das cargas de trabalho. Por exemplo, as cargas de trabalho podem depender de recursos específicos do ambiente que estão disponíveis apenas no ambiente de origem, como complementos, extensões e integrações.

Embora seja possível migrar a maioria das cargas de trabalho como estão para o GKE, talvez seja necessário fazer mais esforços para refazer cargas de trabalho que dependem de recursos específicos do ambiente para minimizar essas dependências, eventualmente mudando para alternativas disponíveis no GKE.

Para refatorar as cargas de trabalho antes de migrá-las para o GKE, faça o seguinte:

Analise os recursos específicos do ambiente de origem, como complementos, extensões e integrações.
Adote soluções alternativas adequadas do GKE.
Refazer as cargas de trabalho.

Analisar os recursos específicos do ambiente de origem

Se você estiver usando recursos específicos do ambiente de origem e suas cargas de trabalho dependerem deles, faça o seguinte:

Encontre soluções alternativas adequadas do GKE.
Refatore suas cargas de trabalho para usar as soluções alternativas do GKE.

Como parte dessa análise, recomendamos que você faça o seguinte:

Considere se é possível descontinuar qualquer um desses recursos específicos do ambiente de origem.
Avalie a importância de um recurso específico do ambiente de origem para o sucesso da migração.

Adote soluções alternativas adequadas do GKE

Depois de analisar os recursos específicos do ambiente de origem e mapeá-los para soluções alternativas adequadas do GKE, você adota essas soluções no seu ambiente do GKE. Para reduzir a complexidade da migração, recomendamos o seguinte:

Evite adotar soluções alternativas do GKE para recursos específicos do ambiente de origem que você pretende descontinuar.
Concentre-se em adotar soluções alternativas do GKE para os recursos mais importantes específicos do ambiente de origem e planeje projetos de migração dedicados para o restante.

Refazer suas cargas de trabalho

Embora a maioria das cargas de trabalho funcione como está no GKE, talvez seja necessário refatorar algumas delas, especialmente se elas dependem de recursos específicos do ambiente de origem para os quais você adotou soluções alternativas do GKE.

Essa refatoração pode envolver:

Descritores de objetos do Kubernetes, como implantações e serviços expressos no formato YAML.
Descritores de imagem de contêiner, como Dockerfiles e Containerfiles.
Código-fonte das cargas de trabalho.

Para simplificar o esforço de refatoração, recomendamos que você se concentre em aplicar o menor número de mudanças necessárias para tornar suas cargas de trabalho adequadas ao GKE e correções de bugs críticas. Você pode planejar outras melhorias e mudanças como parte de projetos futuros.

Refatorar os processos operacionais e de implantação

Depois de refatorar as cargas de trabalho, refatore os processos operacionais e de implantação para fazer o seguinte:

Provisione e configure recursos no ambiente do Google Cloud, em vez de provisionar recursos no ambiente de origem.
Crie e configure cargas de trabalho e implante-as no Google Cloud em vez de implantá-las no ambiente de origem.

Você coletou informações sobre esses processos durante a fase de avaliação anterior.

O tipo de refatoração que você precisa considerar para esses processos depende de como você os projetou e implementou. A refatoração também depende do estado final desejado para cada processo. Por exemplo, considere o seguinte:

Talvez você tenha implementado esses processos no ambiente da AWS e queira projetar e implementar processos semelhantes no Google Cloud. Por exemplo, é possível refatorar esses processos para usar o Cloud Build, o Cloud Deploy e o Infrastructure Manager.
Talvez você tenha implementado esses processos em outro ambiente de terceiros fora do ambiente de origem. Nesse caso, é necessário refatorar esses processos para definir como destino o ambiente do Google Cloud em vez de o ambiente de origem.
Uma combinação das abordagens anteriores.

A refatoração de processos operacionais e de implantação pode ser complexa e exigir um esforço significativo. Se você tentar realizar essas tarefas como parte da migração de carga de trabalho, a migração de carga de trabalho poderá se tornar mais complexa e expor você a riscos. Depois de avaliar os processos operacionais e de implantação, você provavelmente entenderá o design e a complexidade deles. Se você acredita que requer um esforço significativo para refatorar seus processos operacionais e de implantação, recomendamos considerar a refatoração desses processos como parte de um projeto dedicado e separado.

Para mais informações sobre como projetar e implementar processos de implantação no Google Cloud, consulte:

Este documento se concentra nos processos de implantação que produzem os artefatos a serem implantados e os implantam no ambiente de execução de destino. A estratégia de refatoração depende muito da complexidade desses processos. A lista a seguir descreve uma possível estratégia geral de refatoração:

Provisione repositórios de artefatos no Google Cloud. Por exemplo, é possível usar o Artifact Registry para armazenar artefatos e criar dependências.
Refatore seus processos de build para armazenar artefatos no ambiente de origem e no Artifact Registry.
Refatore os processos de implantação para implantar cargas de trabalho no ambiente de destino do Google Cloud. Por exemplo, você pode começar implantando um pequeno subconjunto das suas cargas de trabalho no Google Cloud usando artefatos armazenados no Artifact Registry. Em seguida, aumente gradualmente o número de cargas de trabalho implantadas no Google Cloud até que todas as cargas de trabalho a serem migradas sejam executadas no Google Cloud.
Refactorize seus processos de build para armazenar artefatos apenas no Artifact Registry.
Se necessário, migre versões anteriores dos artefatos a serem implantado dos repositórios no ambiente de origem para o Artifact Registry. Por exemplo, é possível copiar imagens de contêiner para o Artifact Registry.
Desative os repositórios no ambiente de origem quando não precisar mais deles.

Para facilitar as revisões devido a problemas inesperados durante a migração, é possível armazenar imagens de contêiner nos repositórios de artefatos atuais no Google Cloud enquanto a migração está em andamento. Por fim, como parte da desativação do ambiente de origem, é possível refatorar os processos de criação de imagens de contêiner para armazenar artefatos apenas no Google Cloud.

Embora não seja crucial para o sucesso de uma migração, talvez seja necessário migrar as versões anteriores dos artefatos do ambiente de origem para os repositórios de artefatos no Google Cloud. Por exemplo, para oferecer suporte ao reversão de cargas de trabalho para pontos arbitrários no tempo, talvez seja necessário migrar versões anteriores dos artefatos para o Artifact Registry. Para mais informações, consulte Migrar imagens de um registro de terceiros.

Se você estiver usando o Artifact Registry para armazenar artefatos, recomendamos que configure controles para ajudar a proteger seus repositórios de artefatos, como controle de acesso, prevenção de exfiltração de dados, verificação de vulnerabilidade e autorização binária. Para mais informações, consulte Controlar o acesso e proteger artefatos.

Implantar suas cargas de trabalho

Quando os processos de implantação estiverem prontos, implante as cargas de trabalho no GKE. Para ver mais informações, leia Visão geral de como implantar cargas de trabalho.

Para preparar as cargas de trabalho para implantação no GKE, recomendamos que você analise os descritores do Kubernetes, porque alguns recursos do Google Cloud que o GKE provisiona automaticamente são configuráveis usando rótulos e annotations do Kubernetes, em vez de ter que provisionar esses recursos manualmente. Por exemplo, é possível provisionar um balanceador de carga interno em vez de um externo adicionando uma anotação a um serviço LoadBalancer.

Validar suas cargas de trabalho

Depois de implantar cargas de trabalho no ambiente do GKE, mas antes de expô-las aos usuários, recomendamos que você realize testes e validação abrangentes. Esse teste pode ajudar a verificar se as cargas de trabalho estão se comportando conforme o esperado. Por exemplo, você pode fazer o seguinte:

Realizar testes de integração, teste de carga, teste de conformidade, teste de confiabilidade e outros procedimentos de verificação que ajudam a garantir que suas cargas de trabalho estejam funcionando dentro dos parâmetros esperados e de acordo com as especificações deles.
Examinar registros, métricas e relatórios de erros no Google Cloud Observability para identificar possíveis problemas e identificar tendências para antecipá-los.

Para mais informações sobre a validação da carga de trabalho, consulte Como testar a confiabilidade.

Expor as cargas de trabalho

Depois de concluir o teste de validação das cargas de trabalho em execução no ambiente do GKE, exponha suas cargas de trabalho para torná-las acessíveis.

Para expor cargas de trabalho em execução no ambiente do GKE, use os serviços do Kubernetes e uma malha de serviço.

Para mais informações sobre como expor cargas de trabalho em execução no GKE, consulte:

Transferir o tráfego para seu ambiente do Google Cloud

Depois de verificar se as cargas de trabalho estão em execução no ambiente do GKE e depois de expô-las aos clientes, você transfere o tráfego do ambiente de origem para o ambiente do GKE. Para evitar migrações em grande escala e todos os riscos relacionados, recomendamos transferir gradualmente o tráfego do ambiente de origem para o GKE.

Dependendo de como você criou o ambiente do GKE, há várias opções para implementar um mecanismo de balanceamento de carga que transfira gradualmente o tráfego do ambiente de origem para o ambiente de destino. Por exemplo, é possível implementar uma política de resolução de DNS que resolva registros DNS de acordo com alguma política para resolver uma determinada porcentagem de solicitações para endereços IP pertencentes ao ambiente do GKE. Também é possível implementar um mecanismo de balanceamento de carga usando endereços IP virtuais e balanceadores de carga de rede.

Depois de começar a transferir gradualmente o tráfego para o ambiente do GKE, recomendamos que você monitore o comportamento das cargas de trabalho à medida que as cargas aumentam.

Por fim, você realizará uma substituição, que acontece ao transferir todo o tráfego do ambiente de origem para o ambiente do GKE.

Para mais informações sobre balanceamento de carga, consulte Balanceamento de carga no front-end.

Desative o ambiente de origem

Depois que as cargas de trabalho no ambiente do GKE estiverem exibindo as solicitações corretamente, desative o ambiente de origem.

Antes de começar a desativar recursos no ambiente de origem, recomendamos que você faça o seguinte:

Faça backup dos dados para ajudar a restaurar os recursos no ambiente de origem.
Notifique os usuários antes de desativar o ambiente.

Para desativar o ambiente de origem, faça o seguinte:

Desative as cargas de trabalho em execução nos clusters do ambiente de origem.
Exclua os clusters no ambiente de origem.
Exclua os recursos associados a esses clusters, como grupos de segurança, balanceadores de carga e redes virtuais.

Para evitar a saída de recursos órfãos, a ordem em que os recursos são desativados no ambiente de origem é importante. Por exemplo, determinados provedores exigem a desativação dos serviços do Kubernetes que levem à criação de balanceadores de carga antes de poderem desativar as redes virtuais que contêm esses balanceadores de carga.

Otimizar seu ambiente do Google Cloud.

A otimização é a última fase da migração. Nesta fase, você repete as tarefas de otimização até que o ambiente de destino atenda aos requisitos de otimização. As etapas de cada iteração são as seguintes:

Avaliar o ambiente, as equipes e o ciclo de otimização atuais.
Estabeleça suas metas e requisitos de otimização.
Otimize o ambiente e as equipes.
Ajustar o loop de otimização.

Repita essa sequência até alcançar suas metas de otimização.

Para mais informações sobre como otimizar o ambiente do Google Cloud, consulte Migrar para o Google Cloud: otimizar o ambiente e Processo de otimização de performance.

As seções a seguir integram as considerações em Migrar para o Google Cloud: otimize seu ambiente.

Estabelecer seus requisitos de otimização

Os requisitos de otimização ajudam a restringir o escopo da iteração de otimização atual. Para mais informações sobre os requisitos e as metas de otimização, consulte Estabelecer os requisitos e as metas de otimização.

Para estabelecer os requisitos de otimização do seu ambiente do GKE, considere os seguintes aspectos:

Segurança, privacidade e compliance: ajudam a melhorar a postura de segurança do seu ambiente do GKE.
Confiabilidade: ajuda a melhorar a disponibilidade, a escalonabilidade e a resiliência do seu ambiente do GKE.
Otimização de custos: ajuda a otimizar o consumo de recursos e os gastos resultantes do seu ambiente do GKE.
Eficiência operacional: ajuda a manter e operar seu ambiente do GKE de forma eficiente.
Otimização de desempenho: ajuda a otimizar o desempenho das cargas de trabalho implantadas no seu ambiente do GKE.

segurança, privacidade e conformidade

Monitore a postura de segurança dos clusters do GKE. É possível usar o painel de postura de segurança para receber recomendações opinativas e acionáveis que ajudam a melhorar a postura de segurança do seu ambiente do GKE.
Aumente a proteção do seu ambiente do GKE. Entenda o modelo de segurança do GKE e como aumentar a segurança dos clusters do GKE.
Implemente uma cadeia de suprimentos de software segura. Para cargas de trabalho de segurança essencial, implemente um fornecimento de software seguro com nos clusters do GKE usando o Software Delivery Shield.

Confiabilidade

Melhorar a confiabilidade dos clusters. Para ajudar você a projetar um GKE mais resilient a interrupções zonais improváveis, prefira clusters regionais em vez de zonais ou de várias zonas.
Backup e restauração de cargas de trabalho. Configure um fluxo de trabalho de backup e restauração de carga de trabalho com o Backup para GKE.

Otimização de custos

Para mais informações sobre como otimizar o custo do seu ambiente do GKE, consulte:

Eficiência operacional

Para evitar problemas que afetam seu ambiente de produção, recomendamos que você:

Projete os clusters do GKE para serem fungíveis. Considerando os clusters como faturáveis e automatizando o provisionamento e a configuração, é possível simplificar e generalizar os processos operacionais para mantê-los e também simplificar futuras migrações e upgrades de cluster do GKE. Por exemplo, se você precisar fazer upgrade de um cluster do GKE faturável para uma nova versão do GKE, será possível provisionar e configurar automaticamente um novo cluster atualizado, implantar cargas de trabalho automaticamente no novo cluster e desativar o cluster antigo e desatualizado do GKE.
Monitorar as métricas de interesse. Verifique se todas as métricas de interesse sobre seus clusters e cargas de trabalho estão sendo coletadas corretamente. Além disso, verifique se todos os alertas relevantes que usam essas métricas como entradas estão em vigor e funcionando.

Para mais informações sobre como configurar o monitoramento, a geração de registros e o perfil no seu ambiente do GKE, consulte:

Otimização de desempenho

Configure o escalonamento automático de clusters e o provisionamento automático de nós. Redimensione automaticamente seu cluster do GKE de acordo com a demanda usando o escalonamento automático de cluster e o provisionamento automático de nós.
Escalar cargas de trabalho automaticamente. O GKE oferece suporte a vários mecanismos de escalonamento, como:
- Escalone cargas de trabalho com base em métricas.
- Faça o escalonamento automático de cargas de trabalho alterando o formato do número de pods das cargas de trabalho do Kubernetes configurando o escalonamento automático horizontal de pods.
- Escalone cargas de trabalho automaticamente ajustando as solicitações e os limites de recursos configurando o escalonamento automático de pods vertical.

Para mais informações, consulte Sobre a escalonabilidade do GKE.

A seguir

Saiba quando buscar ajuda para suas migrações.
Para mais arquiteturas de referência, diagramas e práticas recomendadas, confira a Central de arquitetura do Cloud.

Colaboradores

Autor: Marco Ferrari | Arquiteto de soluções na nuvem