Como migrar contêineres para o Google Cloud: como migrar para um ambiente do GKE de vários clusters

Last reviewed 2023-05-08 UTC

Este documento ajuda você a planejar, projetar e implementar a migração de um ambiente do Google Kubernetes Engine (GKE) para um novo ambiente do 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 faz parte de uma série sobre a migração para o Google Cloud. Para uma visão geral da série, consulte Migração para o Google Cloud: como escolher o caminho de migração.

Este documento faz parte de uma série que discute a migração de contêineres para o Google Cloud:

Este documento é útil se você planeja migrar de um ambiente do GKE para outro. Este documento também é útil se você estiver avaliando a oportunidade de migrar e quiser saber como funciona esse processo.

Os motivos para migrar de um ambiente do GKE para outro podem incluir:

  • Como ativar os recursos do GKE disponíveis apenas na criação do cluster. O GKE está em evolução constante com novos recursos e correções de segurança. Para aproveitar a maioria dos novos recursos e correções, talvez seja necessário fazer upgrade dos clusters e dos pools de nós do GKE para uma versão mais recente do GKE, seja por meio de upgrade automático ou manual.

    Alguns novos recursos do GKE não podem ser ativados em clusters existentes e exigem que você crie novos clusters do GKE com esses novos recursos ativados. Por exemplo, ative a rede nativa de VPC no GKE, o Dataplane V2 ou a ocultação de metadados somente quando você cria novos clusters. Não é possível atualizar a configuração dos clusters atuais para ativar esses recursos após a criação.

  • Como implementar um processo de provisionamento e configuração automatizado para sua infraestrutura. Se você provisionar e configurar manualmente sua infraestrutura, poderá projetar e implementar um processo automatizado para provisionar e configurar seus clusters do GKE, em vez de confiar em processos manuais e de erros. propensos a métodos.

Ao projetar a arquitetura do novo ambiente, recomendamos que você considere um ambiente de vários clusters do GKE. Ao provisionar e configurar vários clusters do GKE no ambiente, faça o seguinte:

  • Reduza as chances de introduzir um único ponto de falha na sua arquitetura. Por exemplo, se um cluster sofrer uma interrupção, outros clusters poderão assumir.
  • Aproveite a maior flexibilidade que um ambiente com vários clusters fornece. Por exemplo, ao aplicar alterações em um subconjunto de clusters, é possível limitar o impacto de problemas causados por alterações de configuração incorretas. Em seguida, você pode validar as alterações antes de aplicá-las aos clusters restantes.
  • Deixe suas cargas de trabalho se comunicarem entre clusters. Por exemplo, as cargas de trabalho implantadas em um cluster podem se comunicar com cargas de trabalho implantadas em outro cluster.

As orientações neste documento também se aplicam a um ambiente de cluster único do GKE. Quando você migra para um ambiente do GKE de cluster único, seu ambiente é menos complexo de gerenciar em comparação com um ambiente de vários clusters. No entanto, um ambiente de cluster único não se beneficia do aumento da flexibilidade, confiabilidade e resiliência de um ambiente do GKE de vários clusters.

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

Caminho de migração com quatro fases.

O framework ilustrado no diagrama anterior tem as seguintes fases, que são definidas em Migração para o Google Cloud: primeiros passos:

  1. Como avaliar e descobrir as cargas de trabalho.
  2. Como planejar e criar uma base.
  3. Como implantar suas cargas de trabalho.
  4. Como otimizar seu ambiente.

Siga as fases anteriores durante cada etapa da migração. Este documento também se baseia nos conceitos discutidos em Como migrar contêineres para o Google Cloud: como migrar o Kubernetes para o GKE. Ele inclui links quando apropriado.

Como avaliar seu ambiente

Na fase de avaliação, você reúne informações sobre o ambiente de origem e as cargas de trabalho que você quer migrar. Essa avaliação é crucial para a migração e para redimensionar os recursos necessários para a migração e o ambiente de destino. Na fase de avaliação, faça o seguinte:

  1. Criação de um inventário completo dos seus apps
  2. Catalogue seus apps de acordo com as propriedades e dependências deles.
  3. Treine e instrua suas equipes no Google Cloud.
  4. Crie um experimento e uma prova de conceito no Google Cloud.
  5. Calcule o custo total de propriedade (TCO) do ambiente de destino.
  6. Escolha as cargas de trabalho que você quer migrar primeiro.

As seções a seguir dependem da Migração para o Google Cloud: como avaliar e descobrir suas cargas de trabalho. No entanto, eles fornecem informações específicas para avaliar as cargas de trabalho que você quer migrar para novos clusters do GKE.

Em "Como migrar o Kubernetes para o GKE", Como avaliar seu ambiente descreve como avaliar clusters e recursos do Kubernetes, como ServiceAccounts e PersistentVolumes. As informações também se aplicam à avaliação do ambiente do GKE.

Criar seus inventários

Para definir o escopo da migração, você precisa entender o ambiente atual do Kubernetes. Comece coletando informações sobre os clusters e, em seguida, concentre-se nas cargas de trabalho implantadas nesses clusters e nas dependências delas. No final da fase de avaliação, você tem dois inventários: um para os clusters e outro para as cargas de trabalho implantadas nesses clusters.

Em "Como migrar o Kubernetes para o GKE", Criar os inventários descreve como criar os inventários dos clusters e das cargas de trabalho do Kubernetes. Ele também é aplicável para criar os inventários dos seus ambientes do GKE. Antes de prosseguir com este documento, siga as orientações para criar o inventário dos clusters do Kubernetes.

Depois de seguir as orientações da migração do Kubernetes para o GKE para criar os inventários, você refina os inventários. Para concluir o inventário dos clusters do GKE e dos pools de nós, considere os aspectos e recursos específicos do GKE para cada cluster e pool de nós, incluindo:

Ao criar seu inventário, é possível encontrar alguns clusters do GKE que precisam ser desativados como parte da migração. Alguns recursos do Google Cloud não são excluídos quando você exclui os clusters do GKE que os criaram. Verifique se o plano de migração inclui a suspensão do uso desses recursos.

Para informações sobre outros possíveis aspectos e recursos específicos do GKE, consulte a documentação do GKE.

Concluir a avaliação

Depois de criar os inventários relacionados aos clusters e às cargas de trabalho do GKE, conclua as outras atividades da fase de avaliação em Como migrar contêineres para o Google Cloud: como migrar o Kubernetes para o GKE.

Como planejar e criar sua base

Na fase do plano, você provisiona e configura a base, a infraestrutura em nuvem e os serviços compatíveis com suas cargas de trabalho no Google Cloud. Na fase de planejamento, faça o seguinte:

  • Crie uma hierarquia de recursos.
  • Configurar o gerenciamento de identidade e acesso.
  • Configurar o faturamento.
  • Configurar a conectividade de rede.
  • Aumente sua segurança.
  • Configure o monitoramento e os alertas.

Ao configurar a conectividade de rede, verifique se você tem endereços IP suficientes nas sub-redes para alocar para nós, pods e serviços. Ao configurar a rede para os clusters, planeje cuidadosamente as alocações dos endereços IP. Por exemplo, configure IPs públicos usados de maneira privada para o GKE. Os intervalos de endereços IP secundários definidos para pods e serviços nos clusters não podem ser alterados após a alocação deles. Tenha muito cuidado ao alocar um pod ou intervalo de serviços de /22 (1.024 endereços) ou menos. Caso contrário, talvez você fique sem endereços IP para pods e Serviços conforme o cluster cresce. Para mais informações, consulte Planejamento de intervalo de endereços IP.

Recomendamos que você use uma sub-rede compartilhada separada para balanceadores de carga internos criados para seu ambiente do GKE. Ao usar um serviço do KubernetesRHEL de type: LoadBalancer, é possível especificar uma sub-rede do balanceador de carga. Ao configurar balanceadores de carga internos HTTP(S) internos, é preciso configurar uma sub-rede somente proxy.

Para criar a base do ambiente do GKE, conclua as atividades da fase de planejamento e criação em Como migrar contêineres para o Google Cloud: como migrar o Kubernetes para o GKE.

Como implantar suas cargas de trabalho

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

  1. Provisionar e configurar o ambiente de destino.
  2. Migrar dados do ambiente de origem para o ambiente de destino.
  3. Implante suas cargas de trabalho no ambiente de destino.

Nesta seção, fornecemos informações específicas para implantar cargas de trabalho no GKE. Ele se baseia nas informações em Como migrar o Kubernetes para o GKE: como implantar suas cargas de trabalho.

Avaliar a plataforma e os ambientes de execução

Para ter uma infraestrutura mais flexível, confiável e de fácil manutenção, recomendamos que você projete e implemente uma arquitetura de vários clusters. Em uma arquitetura de vários clusters, você tem vários clusters de produção do GKE no ambiente. Por exemplo, se você provisionar vários clusters do GKE no ambiente, poderá implementar estratégias avançadas de ciclo de vida do cluster, como upgrades contínuos ou upgrades azul-verde. Para mais informações sobre os projetos de arquitetura do GKE de vários clusters e os benefícios deles, consulte Upgrades de vários clusters do GKE usando a entrada de vários clusters.

Quando você executa seu ambiente em vários clusters, há desafios adicionais a serem considerados, como os mostrados a seguir:

  • Você precisa adaptar o gerenciamento de configurações, a descoberta e a comunicação de serviços, os lançamentos de aplicativos e o balanceamento de carga para o tráfego de entrada.
  • Você provavelmente precisa executar software extra no cluster e automação e infraestrutura extras.

Para solucionar esses desafios, talvez você precise de pipelines de integração contínua/implantação contínua (CI/CD) (em inglês) para atualizar a configuração de clusters sequencialmente para minimizar o impacto de erros. Talvez você também precise de balanceadores de carga para distribuir o tráfego de um cluster para outros clusters.

O gerenciamento manual da infraestrutura é propenso a erros e expõe a problemas devido a configurações incorretas e à falta de documentação interna sobre o estado atual da infraestrutura. Para ajudar a reduzir os riscos devidos a esses problemas, recomendamos aplicar a infraestrutura como padrão de código. Ao aplicar esse padrão, o provisionamento da infraestrutura é tratado da mesma maneira que o código-fonte das cargas de trabalho.

Há várias opções de arquitetura para seu ambiente do GKE de vários clusters, descritas posteriormente nesta seção. Escolher uma opção em relação às outras depende de vários fatores, e nenhuma delas é inerentemente melhor do que as outras. Cada ambiente tem seus pontos fortes e fracos. Para escolher um tipo de arquitetura, faça o seguinte:

  1. Estabeleça um conjunto de critérios para avaliar os tipos de arquiteturas de ambientes do GKE de vários clusters.
  2. Avalie cada ambiente de acordo com os critérios de avaliação.
  3. Escolha a opção que melhor atende às suas necessidades.

Para estabelecer os critérios para avaliar os tipos de arquitetura de ambientes de vários clusters do GKE, use a avaliação de ambiente concluída para identificar os recursos necessários. Ordene os recursos de acordo com a importância. Por exemplo, depois de avaliar suas cargas de trabalho e ambiente, considere os seguintes critérios de avaliação, listados em ordem de importância potencial:

  1. Solução gerenciada pelo Google. Você prefere serviços e produtos autogerenciados ou gerenciados pelo Google?
  2. Interfaces para interagir com a arquitetura. Existe alguma interface legível por máquina com que você pode interagir? A interface é definida como um padrão aberto? A interface é compatível com diretivas declarativas, diretivas imperativas ou ambas?
  3. Exponha serviços fora do ambiente do GKE. A arquitetura permite expor suas cargas de trabalho fora do cluster do GKE em que elas são implantadas?
  4. Comunicação entre clusters. A arquitetura é compatível com canais de comunicação entre clusters? Suas cargas de trabalho são compatíveis com uma arquitetura distribuída? Esse critério é importante para oferecer suporte a cargas de trabalho com um design distribuído, como o Jenkins.
  5. Gerenciamento de tráfego. A arquitetura é compatível com recursos avançados de gerenciamento de tráfego, como injeção de falhas, mudança de tráfego e solicitação tempos limite e novas tentativas, disjuntores e espelhamento de tráfego ? Esses recursos estão prontos para serem usados ou você precisa implementá-los sozinho?
  6. Provisione e configure ferramentas adicionais. Você precisa provisionar e configurar outros componentes de hardware ou software?

O Google Cloud oferece as opções a seguir para projetar a arquitetura de um ambiente do GKE de vários clusters. Para escolher a melhor opção para suas cargas de trabalho, primeiro avalie-as de acordo com os critérios de avaliação estabelecidos anteriormente. Use uma escala arbitrária e ordenada para atribuir uma pontuação de cada opção de design a cada critério de avaliação. Por exemplo, é possível atribuir a cada ambiente uma pontuação de uma escala de 1 a 10 em cada critério de avaliação. As opções a seguir são apresentadas em ordem crescente de quanto esforço é necessário para gerenciar o novo ambiente do GKE de vários clusters.

  1. Ingress de vários clusters e descoberta de serviços de vários clusters
  2. Entradas em vários clusters e Anthos Service Mesh
  3. Traffic Director
  4. Atualizações de registro DNS do Kubernetes e autogerenciados

As seções a seguir descrevem essas opções em detalhes e incluem uma lista de critérios para avaliar cada opção. Para atribuir pontuações a alguns dos critérios, leia a documentação do produto. Por exemplo, ao ler a documentação, é possível avaliar o Anthos Service Mesh com alguns critérios de avaliação estabelecidos anteriormente. No entanto, para atribuir pontuações em relação a outros critérios, talvez seja necessário projetar e executar comparações e simulações mais detalhadas. Por exemplo, talvez seja necessário comparar o desempenho de diferentes arquiteturas de GKE de vários clusters para avaliar se elas são adequadas às suas cargas de trabalho.

Ingress de vários clusters e descoberta de serviços de vários clusters

A Entrada de vários clusters é um serviço gerenciado pelo Google que permite expor cargas de trabalho, independentemente do cluster do GKE em que elas estão implantadas. Ele também permite configurar balanceadores de carga compartilhados entre clusters do GKE e entre regiões. Para mais informações sobre como usar a entrada de vários clusters em um ambiente do GKE de vários clusters, consulte Atualizações de vários clusters do GKE usando a entrada de vários clusters e Suporte à migração com a expansão de malha do Istio

A descoberta de serviços de vários clusters é um mecanismo de conectividade e descoberta de serviços entre clusters nativo do Kubernetes para o GKE. A descoberta de serviços de vários clusters é baseado no recurso Serviço do Kubernetes para ajudar os aplicativos a descobrir e se conectar entre si nos limites do cluster. Para avaliar o Ingress de vários clusters e a descoberta de serviços de vários de clusters em relação aos critérios estabelecidos anteriormente, use a lista a seguir, numerada em ordem de importância relativa:

  1. Solução gerenciada pelo Google. A descoberta de serviços de vários clusters é um recurso totalmente gerenciado do GKE. Ele configura recursos (zonas e registros do Cloud DNS, regras de firewall e Traffic Director) para que você não precise gerenciá-los.
  2. Interfaces para interagir com a arquitetura. Os serviços são exportados para outros clusters usando um recurso declarativo do Kubernetes chamado ServiceExport.
  3. Exponha serviços fora do ambiente do GKE. Ao usar o Ingress de vários clusters e a descoberta de serviços de vários clusters, é possível expor as cargas de trabalho fora dos clusters do GKE, independentemente de onde elas foram implantadas.
  4. Comunicação entre clusters. É possível exportar serviços atuais para outros clusters do GKE declarando um objeto ServiceExport. Os clusters do GKE na mesma frota importam automaticamente os serviços exportados usando objetos ServiceExport. A descoberta de vários clusters configura um endereço IP virtual para cada Serviço exportado. A descoberta de serviços de vários clusters configura automaticamente os recursos do Traffic Director, o Cloud DNS e as regras de firewall para descobrir e se conectar aos Serviços usando uma variação simples da convenção do Kubernetes DNS. Por exemplo, para acessar o Serviço my-svc, use o nome my-svc.my-ns.svc.clusterset.local.
  5. Gerenciamento de tráfego. A descoberta de serviços de vários clusters configura a conectividade simples de camada 3/4 e depende do DNS para a descoberta de serviços. Ele não fornece nenhuma capacidade de gerenciamento de tráfego.
  6. Provisionar e configure outras ferramentas. É possível configurar a descoberta de serviços de vários clusters ativando APIs do Google. Não é necessário instalar ferramentas adicionais. Para mais informações, consulte Como migrar contêineres para o Google Cloud: como migrar para um ambiente do GKE de vários clusters com a descoberta de serviços de vários clusters e o Ingress de vários clusters.

Entrada de vários clusters e Anthos Service Mesh

Uma malha de serviço é um padrão de arquitetura que ajuda nos desafios da rede de aplicativos distribuídos. Esses desafios incluem descoberta de serviços, balanceamento de carga, tolerância a falhas, controle de tráfego, observabilidade, autenticação, autorização e criptografia em trânsito. As implementações típicas de malha de serviço consistem em um plano de dados e um plano de controle. O plano de dados é responsável por lidar diretamente com o tráfego e encaminhá-lo para as cargas de trabalho de destino, geralmente usando proxies sidecar. O plano de controle se refere aos componentes que configuram o plano de dados.

Ao implementar o padrão de malha de serviço na infraestrutura, é possível escolher entre dois produtos do Google Cloud: Anthos Service Mesh e Traffic Director. Ambos os produtos fornecem um plano de controle para configurar a rede de camada de aplicativo (L7) em vários clusters do GKE. O Anthos Service Mesh é baseado no Istio e oferece APIs de código aberto declarativas. O Traffic Director é baseado em uma combinação de recursos de balanceamento de carga do Google, tecnologias de código aberto e oferece APIs imperativas do Google.

O Anthos Service Mesh é um pacote de ferramentas gerenciadas pelo Google que permite conectar, gerenciar, proteger e monitorar as cargas de trabalho, independentemente do cluster do GKE em que foram implantadas e sem modificar o código do aplicativo. Para mais informações sobre como usar o Anthos Service Mesh para configurar uma malha que abrange vários clusters do GKE, consulte Adicionar clusters do GKE ao Anthos Service Mesh. Para avaliar a Entrada de vários clusters e o Anthos Service Mesh com os critérios definidos anteriormente, use a lista a seguir, numerada em ordem de importância relativa:

  1. Solução gerenciada pelo Google. Tanto a Entrada de vários clusters quanto o Mesh Service Mesh são produtos totalmente gerenciados. Não é preciso provisionar esses produtos porque o Google os gerencia para você.
  2. Interfaces para interagir com a arquitetura. O Anthos Service Mesh usa o Istio na essência. A API Anthos Service Mesh é compatível com a configuração declarativa com base no modelo de recurso do Kubernetes.
  3. Exponha serviços fora do ambiente do GKE. Os gateways de entrada do Multi Service Ingress e do Anthos Service Mesh permitem expor suas cargas de trabalho fora dos clusters do GKE.
  4. Comunicação entre clusters. O Anthos Service Mesh configura canais de comunicação seguros diretamente entre os pods, independentemente do cluster em que eles estão sendo executados. Essa configuração permite que você evite gastar mais esforços para provisionar e configurar esses canais de comunicação. O Anthos Service Mesh usa o conceito de frotas e semelhança de serviços para estender a descoberta de serviços do GKE para vários clusters. Portanto, não é necessário modificar suas cargas de trabalho para descobrir cargas de trabalho em execução em outros clusters na malha.
  5. Gerenciamento de tráfego. O Anthos Service Mesh fornece recursos avançados de gerenciamento de tráfego que podem ser usados para controlar como o tráfego de entrada é protegido e roteado para cargas de trabalho. Por exemplo, o Anthos Service Mesh é compatível com todos osRecursos de gerenciamento de tráfego do Istio , como:injeção de falhas , solicitartempos limite enovas tentativas ,disjuntores ,espelhamento de tráfego ,mudança de tráfego. Também é possível usar esses recursos de gerenciamento de tráfego para simplificar a migração para um novo ambiente do GKE. Por exemplo, é possível transferir gradualmente o tráfego do ambiente antigo para o novo.
  6. Provisionar e configure outras ferramentas. Para usar o Ingress de vários clusters, você precisa atender aos pré-requisitos da descoberta de serviços de vários clusters, mas não precisa instalar outras ferramentas nos clusters do GKE. Para usar o Anthos Service Mesh, você precisa instalá-lo nos clusters.

Traffic Director

O Traffic Director é um plano de controle gerenciado para rede de aplicativos. Ele permite provisionar e configurar topologias de malha de serviço avançadas, com recursos avançados de gerenciamento e observabilidade de tráfego. Para mais informações sobre o Traffic Director, consulte Visão geral do Traffic Director e os recursos do Traffic Director. Para provisionar e configurar uma malha de serviço que abrange vários clusters do GKE, use um vários clusters ou vários ambientes Configuração do Traffic Director. Para avaliar o Traffic Director com base nos critérios que você estabeleceu anteriormente, use a lista a seguir, numerada em ordem de importância relativa:

  1. Solução gerenciada pelo Google. O Traffic Director é um produto totalmente gerenciado. Você não precisa provisionar esses produtos, porque o Google os gerencia para você.
  2. Interfaces para interagir com a arquitetura. É possível configurar o Traffic Director usando o Console do Google Cloud, a Google Cloud CLI, a API Traffic Director ou ferramentas como o Terraform. O Traffic Director é compatível com um modelo de configuração imperativo e é criado com base em produtos e tecnologias de código aberto, como o xDS. e gRPC.
  3. Exponha serviços fora do ambiente do GKE. O Traffic Director provisiona e configura balanceadores de carga para lidar com o tráfego de entrada de fora da rede de serviço.
  4. Comunicação entre clusters. O plano de controle do Traffic Director oferece APIs que permitem agrupar endpoints (como pods do GKE em vários clusters) em back-ends de serviço. Esses back-ends podem ser roteados de outros clientes na malha. O Traffic Director não está diretamente integrado à descoberta de serviços do GKE, mas é possível automatizar a integração usando um controlador de código aberto, como gke-autoneg-controller. Também é possível usar a Descoberta de serviços de vários clusters para estender a descoberta de serviços do GKE para vários clusters.
  5. Gerenciamento de tráfego. O Traffic Director fornece recursos avançados de gerenciamento de tráfego que podem ser usados para simplificar a migração para um novo ambiente do GKE e melhorar a confiabilidade da arquitetura. Para informações sobre como configurar recursos comoroteamento de tráfego refinado ,divisão de tráfego com base no peso ,espelhamento de tráfego ,balanceamento de carga ajustado , consulteComo configurar o gerenciamento de tráfego avançado.
  6. Provisionar e configure outras ferramentas. O Traffic Director não é executado nos clusters do GKE. Para informações sobre como provisionar e configurar o Traffic Director, consulte Como se preparar para a configuração do Traffic Director. Para configurar os pods secundários que o Traffic Director precisa para incluir as cargas de trabalho na rede de serviço, consulte Como implantar o Traffic Director com o Envoy nos pods do GKE.

Atualizações de registro DNS do Kubernetes e autogerenciados

Se você não quiser instalar software adicional no cluster e não precisar dos recursos fornecidos por uma malha de serviço, escolha o Kubernetes e a opção de atualizações de registro DNS autogerenciado.

É possível configurar a descoberta e a conectividade entre clusters usando essa opção, mas recomendamos que você escolha uma das outras opções descritas neste documento. O esforço necessário para operar uma solução autogerenciada supera muito os benefícios que podem ser concedidos. Considere também as seguintes limitações importantes:

Quando você cria um Serviço detype: LoadBalancer ou umEntrada objeto em um cluster do GKE, o GKE cria automaticamenteBalanceadores de carga de rede eBalanceadores de carga HTTP(S) para expor esse serviço usando o endereço IP do balanceador de carga. É possível usar os endereços IP dos balanceadores de carga para se comunicar com os serviços. No entanto, recomendamos evitar os endereços IP, mapeando esses endereços IP para registros DNS usando o Cloud DNS ou para Endpoints do Diretório de serviços que pode consultar usando o DNS e que você configurou seus clientes para usar esses registros DNS. É possível implantar várias instâncias do Serviço e mapear todos os endereços IP do balanceador de carga resultantes para o registro DNS relacionado ou o endpoint do Diretório de serviços.

Para desativar uma instância de um serviço, primeiro remova o endereço IP do balanceador de carga relacionado do registro DNS relevante ou do endpoint do diretório de serviços. Em seguida, garanta que o cache DNS dos clientes seja atualizado e, em seguida, desative o serviço.

É possível configurar suas cargas de trabalho para que possam se comunicar entre si em diferentes clusters do GKE. Para fazer isso, primeiro exponha os serviços fora do cluster usandoBalanceadores de carga TCP/UDP internos ou Balanceadores de carga HTTP(S) internos , Em seguida, você mapeia os endereços IP dos balanceadores de carga para registros DNS ou endpoints do Diretório de serviços. Por fim, você cria Serviços de type: ExternalName que apontam para esses registros DNS ou endpoints do Diretório de serviços em cada cluster.

Opcionalmente, é possível usar um controlador do Ingress extra para compartilhar um único balanceador de carga e um registro do Cloud DNS ou um endpoint do Diretório de serviços com várias cargas de trabalho. Por exemplo, se você provisionar um controlador de entrada em um cluster, poderá configurá-lo para redirecionar solicitações recebidas ao balanceador de carga que o GKE cria para esse controlador de entrada em vários serviços. Usar um controlador extra do Ingress permite reduzir o número de registros DNS ou endpoints do Diretório de serviços que você precisa gerenciar.

Para avaliar o Kubernetes e as atualizações de registro DNS autogerenciados em relação aos critérios que você estabeleceu anteriormente, use a lista a seguir, numerada em ordem de importância relativa:

  1. Solução gerenciada pelo Google. Você gerencia automaticamente os objetos do Kubernetes que fazem parte dessa solução. O Cloud DNS, o diretório de serviços e o balanceamento de carga são serviços gerenciados pelo Google.
  2. Interfaces para interagir com a arquitetura. O GKE usa o Kubernetes no centro e é compatível com modelos imperativos e declarativos de configuração.
  3. Exponha serviços fora do ambiente do GKE. É possível usar registros DNS, endpoints do diretório de serviços e balanceadores de carga para expor serviços a clientes fora dos clusters do GKE.
  4. Comunicação entre clusters. Os serviços de type: ExternalName permitem definir endpoints que apontam para serviços implantados no outro cluster do GKE. Essa configuração permite que os serviços se comuniquem uns com os outros como se fossem implantados no mesmo cluster.
  5. Gerenciamento de tráfego. A solução não oferece recursos adicionais de gerenciamento de tráfego além dos já oferecidos pelo Kubernetes e GKE. Por exemplo, essa opção não é compatível com o particionamento de tráfego entre clusters diferentes.
  6. Provisione e configure ferramentas adicionais. Essa opção não requer que o software adicional seja provisionado e configurado nos clusters do GKE. Opcionalmente, você pode instalar um controlador Ingress.

Como selecionar uma arquitetura

Depois de atribuir um valor a cada critério de cada opção, calcule a pontuação total de cada opção. Para calcular a pontuação total de cada opção, adicione todas as classificações dessa opção com base nos critérios. Por exemplo, se um ambiente marcou 10 em um critério e 6 em outro critério, a pontuação total dessa opção será 16.

Também é possível atribuir pesos diferentes à pontuação de acordo com cada critério, para representar a importância de cada um para a avaliação. Por exemplo, se uma solução gerenciada pelo Google for mais importante do que o suporte de uma arquitetura de carga de trabalho distribuída na avaliação, você poderá definir multiplicadores para refletir que: um multiplicador de 1.0 para a solução gerenciada pelo Google e um multiplicador de 0,7 para a arquitetura de carga de trabalho distribuída. Depois, use esses multiplicadores para calcular a pontuação total de uma opção.

Depois de calcular a pontuação total de cada ambiente avaliado, organize os ambientes pela pontuação total em ordem decrescente. Em seguida, escolha a opção que tenha a maior pontuação como o ambiente de sua preferência.

Há várias maneiras de representar esses dados. Por exemplo, é possível visualizar os resultados com um gráfico adequado para representar dados multivariáveis, como um gráfico de radar.

Migrar dados do ambiente antigo para o novo

Para orientações sobre como migrar dados do seu ambiente antigo para o novo, consulte Como migrar o Kubernetes para o GKE,Migrar dados do ambiente antigo para o novo.

Implantar cargas de trabalho

Para orientações sobre como migrar dados do seu ambiente antigo para o novo, consulte Implantar suas cargas de trabalho.

Todas as arquiteturas propostas neste documento permitem migrar suas cargas de trabalho de um ambiente atual do GKE para um novo ambiente de vários clusters sem qualquer tempo de inatividade ou janela de transferência. Para migrar as cargas de trabalho sem inatividade, faça o seguinte:

  1. Integre temporariamente os clusters legados do GKE no novo ambiente do GKE com vários clusters.
  2. Implante instâncias das cargas de trabalho no novo ambiente de vários clusters.
  3. Migre gradualmente o tráfego do seu ambiente atual para migrar gradualmente suas cargas de trabalho para os novos clusters do GKE e, em seguida, desative os clusters legados do GKE.

Concluir a implantação

Depois de provisionar e configurar a plataforma e os ambientes de execução, conclua as atividades descritas em Como migrar o Kubernetes para o GKE, Como implantar as cargas de trabalho.

Como otimizar o ambiente

A otimização é a última fase da migração. Nesta fase, você torna seu ambiente mais eficiente do que antes. Para otimizar o ambiente, conclua várias iterações do seguinte loop repetível até que o ambiente atenda aos requisitos de otimização:

  1. Avaliação do ambiente, das equipes e do loop de otimização atuais.
  2. Estabelecimento dos seus requisitos e metas de otimização.
  3. Otimização do seu ambiente e das suas equipes.
  4. Ajuste do loop de otimização.

Para otimizar o ambiente do GKE, consulte Como migrar o Kubernetes para o GKE, Como otimizar o ambiente.

A seguir