Migrar da AWS para o Google Cloud: migrar do Amazon EKS para o GKE

Last reviewed 2024-08-02 UTC

O Google Cloud fornece ferramentas, produtos, orientações e serviços profissionais para migrar do Amazon Elastic Kubernetes Service (Amazon EKS) para o Google Kubernetes Engine (GKE). Neste documento, ajudamos a projetar, implementar e validar um plano para migrar do Amazon EKS para o GKE. Este documento também fornece orientações se você estiver avaliando a oportunidade de migrar e quiser explorar como pode ser esse processo. Além de ser executado no Amazon Elastic Compute Cloud (Amazon EC2), o Amazon EKS tem algumas outras opções de implantação, como o Amazon EKS nas saídas da AWS e o Amazon EKS em qualquer lugar. Este documento se concentra no Amazon EKS no EC2.

Este documento faz parte de uma série com várias partes sobre migração da AWS para o Google Cloud que inclui os seguintes documentos:

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:

  1. Avaliar e descobrir suas cargas de trabalho e seus dados.
  2. Planejar e criar uma base no Google Cloud.
  3. Migrar suas cargas de trabalho e seus dados para o Google Cloud.
  4. 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 de origem

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:

  1. Criar um inventário abrangente das suas cargas de trabalho.
  2. Catalogar suas cargas de trabalho de acordo com as propriedades e dependências delas.
  3. Treine e instrua suas equipes no Google Cloud.
  4. Criar experimentos e provas de conceito no Google Cloud.
  5. Calcule o custo total de propriedade (TCO) do ambiente de destino.
  6. Escolha a estratégia de migração para suas cargas de trabalho.
  7. Escolha as ferramentas de migração.
  8. Defina o plano e o cronograma de migração.
  9. 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:

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

Depois de criar esses inventários, você:

  1. Avalie os processos operacionais e de implantação do ambiente de origem.
  2. 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.

Ferramentas para criar o inventário do ambiente de origem

Para criar o inventário dos clusters do Amazon EKS, recomendamos que você use o Migration Center, a plataforma unificada do Google Cloud que ajuda a acelerar sua jornada de nuvem de ponta a ponta do ambiente atual para o Google Cloud. A Central de migração permite importar dados do Amazon EKS e de outros recursos da AWS. Em seguida, a Central de migração recomenda serviços relevantes do Google Cloud para que você possa migrar.

Criar o inventário de clusters e cargas de trabalho do Amazon EKS

Os dados fornecidos pelo Migration Center podem não capturar totalmente as dimensões em que você tem interesse. Nesse caso, é possível integrar esses dados aos resultados de outros mecanismos de coleta de dados criados com base em APIs e ferramentas de desenvolvedor da AWS e na interface de linha de comando da AWS.

Além dos dados recebidos da Central de migração, considere os seguintes pontos de dados para cada cluster do Amazon EKS que você quer migrar:

  • Considere aspectos e recursos específicos do Amazon EKS para cada cluster do Amazon EKS, incluindo:
    • Clusters particulares
    • Controle de acesso de endpoint do cluster
    • Criptografia do secret
    • Grupos de nós gerenciados e nós autogerenciados
    • Tags em recursos do Amazon EKS
    • AMIs personalizadas da Amazon no EKS
    • Uso do Amazon EKS Fargate
    • Uso do Prometheus gerenciado do Amazon EKS
    • Configuração da autenticação do OpenID Connect
  • Avalie como você está se autenticando nos clusters do Amazon EKS e como configurou o AWS Identity and Access Management (IAM) para o Amazon EKS.
  • Avalie a configuração de rede dos clusters do Amazon EKS.

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:

  1. Criar uma hierarquia de recursos.
  2. Configurar o Identity and Access Management (IAM) do Google Cloud.
  3. configurar o faturamento
  4. Configurar a conectividade de rede.
  5. Aumentar sua segurança.
  6. 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:

  1. Provisione e configure o ambiente do GKE.
  2. Configure os clusters do GKE.
  3. Refazer as cargas de trabalho.
  4. Refatorar os processos operacionais e de implantação
  5. Migre dados do seu ambiente de origem para o Google Cloud.
  6. Implante as cargas de trabalho no ambiente do GKE.
  7. Valide as cargas de trabalho e o ambiente do GKE.
  8. Exponha cargas de trabalho em execução no GKE.
  9. Desloque o tráfego do ambiente de origem para o ambiente do GKE.
  10. 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:

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:

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:

  1. Verifique se você tem as credenciais e permissões necessárias para acessar os clusters no ambiente de origem e no GKE.
  2. 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.
  3. Refatore qualquer objeto incompatível para torná-lo compatível com o GKE ou desative-o.
  4. Migre esses objetos para os clusters do GKE.
  5. 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:

  1. Analise os recursos específicos do ambiente de origem, como complementos, extensões e integrações.
  2. Adote soluções alternativas adequadas do GKE.
  3. 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:

  1. Encontre soluções alternativas adequadas do GKE.
  2. 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:

  1. Provisione repositórios de artefatos no Google Cloud. Por exemplo, é possível usar o Artifact Registry para armazenar artefatos e criar dependências.
  2. Refatore seus processos de build para armazenar artefatos no ambiente de origem e no Artifact Registry.
  3. 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.
  4. Refactorize seus processos de build para armazenar artefatos apenas no Artifact Registry.
  5. 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.
  6. 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.

Migrar dados

O GKE oferece suporte a vários serviços de armazenamento de dados, como armazenamento em bloco, armazenamento em bloco bruto, armazenamento de arquivos e armazenamento de objetos. Para mais informações, consulte Visão geral do armazenamento para clusters do GKE.

Para migrar dados para o ambiente do GKE, faça o seguinte:

  1. Provisione e configure toda a infraestrutura de armazenamento necessária.
  2. Configure provisionadores de StorageClass nos clusters do GKE. Nem todos os provisionadores do StorageClass são compatíveis com todos os ambientes. Antes de implantar um provisionador do StorageClass, recomendamos que você avalie a compatibilidade dele com o GKE e as dependências.
  3. Configure StorageClasses.
  4. Configure PersistentVolumes e PersistentVolumeClaims para armazenar os dados a serem migrados.
  5. Migre dados do ambiente de origem para esses PersistentVolumes. As especificidades dessa migração de dados dependem das características do ambiente de origem.

Para migrar dados do ambiente de origem para o ambiente do Google Cloud, recomendamos que você projete um plano de migração de dados seguindo as orientações em Migrar para o Google Cloud: transferir grandes conjuntos de dados.

Migrar dados do EKS para o GKE

A AWS oferece várias opções de armazenamento de dados para o Amazon EKS. Este documento se concentra nos seguintes cenários de migração de dados:

  • Migre dados de volumes do Amazon EBS para recursos PersistentVolume do GKE.
  • Copie dados dos volumes do Amazon EBS para o Amazon S3 ou para o Cloud Storage e migre os dados para os recursos PersistentVolume do GKE.
Migrar dados de volumes do Amazon EBS para PersistentVolumes do GKE

É possível migrar dados de volumes do Amazon EBS para recursos PersistentVolume do GKE usando uma das seguintes abordagens:

  • Copie dados diretamente dos volumes do Amazon EBS para os discos permanentes do Compute Engine:
    1. Provisione instâncias do Amazon EC2 e anexe os volumes do Amazon EBS que contêm os dados a serem migrados.
    2. Provisione instâncias do Compute Engine com discos permanentes vazios que tenham capacidade suficiente para armazenar os dados a serem migrados.
    3. Execute uma ferramenta de sincronização de dados, como o rsync, para copiar dados dos volumes do Amazon EBS para os discos permanentes do Compute Engine.
    4. Remover os discos permanentes das instâncias do Compute Engine.
    5. Desative as instâncias do Compute Engine.
    6. Configure os discos permanentes como recursos PersistentVolume do GKE.
  • Migre instâncias do Amazon EC2 e volumes do Amazon EBS para o Compute Engine:
    1. Provisione instâncias do Amazon EC2 e anexe os volumes do Amazon EBS que contêm os dados a serem migrados.
    2. Migre as instâncias do Amazon EC2 e os volumes do Amazon EBS para o Compute Engine com o Migrate for Virtual Machines.
    3. Remover os discos permanentes das instâncias do Compute Engine.
    4. Desative as instâncias do Compute Engine.
    5. Configure os discos permanentes como recursos PersistentVolume do GKE.

Para mais informações sobre como migrar instâncias do Amazon EC2 para o Compute Engine, consulte Migrar da AWS para o Google Cloud: migrar do Amazon EC2 para o Compute Engine.

Para mais informações sobre o uso de discos permanentes do Compute Engine como recursos do PersistentVolume GKE, consulte Como usar discos permanentes preexistentes como PersistentVolumes.

Copiar dados de volumes do Amazon EBS para uma mídia provisória e migrar para PersistentVolumes do GKE

Em vez de migrar diretamente dos volumes do Amazon EBS para os recursos PersistentVolume do GKE diretamente, é possível usar uma mídia provisória, como um armazenamento de objetos:

  1. Faça upload de dados de volumes do Amazon EBS para uma mídia temporária, como um bucket do Amazon S3 ou do Cloud Storage.
  2. Faça o download dos dados da mídia provisória para seus recursos PersistentVolume do GKE.

Em determinados cenários, o uso de várias mídias pode simplificar a transferência de dados com base nas configurações de rede e segurança. Por exemplo, é possível fazer o upload inicial dos dados para um bucket do S3, copiá-los desse bucket para um bucket do Cloud Storage e, por fim, fazer o download dos dados para os volumes permanentes. Seja qual for a abordagem escolhida, para garantir uma transição tranquila enquanto observa considerações importantes, recomendamos que você consulte Migrar da AWS para o Google Cloud: migrar do Amazon S3 para o Cloud Storage.

Escolha uma opção de migração

A melhor opção de migração depende das suas necessidades e requisitos específicos, como as considerações a seguir:

  • A quantidade de dados que você precisa migrar.
    • Se você tiver uma pequena quantidade de dados para migrar, como alguns arquivos de dados, use ferramentas como o rsync para copiar os dados diretamente nos discos permanentes do Compute Engine. Essa opção é relativamente rápida, mas pode não ser adequada para uma grande quantidade de dados.
    • Se você tiver uma grande quantidade de dados para migrar, use o Migrate to Virtual Machines para migrar os dados para o Compute Engine. Essa opção é mais complexa do que copiar dados diretamente, mas é mais confiável e escalável.
  • O tipo de dados que você precisa migrar.
  • Sua conectividade de rede entre os ambientes de origem e de destino.
    • Se você não conseguir estabelecer a conectividade de rede direta entre as instâncias do AWS EC2 e do Compute Engine, use o Amazon S3 ou o Cloud Storage para armazenar os dados temporariamente durante a migração para o Compute Engine. Essa opção pode ser mais barata porque não será necessário manter as instâncias do EC2 e do Compute Engine em execução simultaneamente.
  • Seu cronograma de migração.
    • Se você tiver uma largura de banda de rede limitada ou uma grande quantidade de dados e sua linha do tempo não estiver limitada, considere usar um Transfer Appliance para mover os dados do AWS para Google Cloud.

Independente da opção escolhida, é importante testar a migração antes de ativá-la. Eles ajudam a identificar possíveis problemas e a garantir que a migração seja bem-sucedida.

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:

  1. Desative as cargas de trabalho em execução nos clusters do ambiente de origem.
  2. Exclua os clusters no ambiente de origem.
  3. 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:

  1. Avaliar o ambiente, as equipes e o ciclo de otimização atuais.
  2. Estabeleça suas metas e requisitos de otimização.
  3. Otimize o ambiente e as equipes.
  4. 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

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

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

A seguir

Colaboradores

Autores: