Migre da AWS para Google Cloud: migre do Amazon EKS para o GKE

Last reviewed 2024-08-02 UTC

Google Cloud oferece ferramentas, produtos, orientações e serviços profissionais para migrar do Amazon Elastic Kubernetes Service (Amazon EKS) para o Google Kubernetes Engine (GKE). Este documento ajuda a conceber, implementar e validar um plano de migração do Amazon EKS para o GKE. Este documento também fornece orientações se estiver a avaliar a oportunidade de migrar e quiser explorar como pode ser a migração. Além de ser executado no Amazon Elastic Compute Cloud (Amazon EC2), o Amazon EKS tem algumas outras opções de implementação, como o Amazon EKS em saídas da AWS e o Amazon EKS em qualquer lugar. Este documento foca-se no Amazon EKS no EC2.

Este documento faz parte de uma série de vários artigos sobre a migração da AWS para a Google Cloud , que inclui os seguintes documentos:

O GKE é um serviço Kubernetes gerido pela Google que pode usar para implementar e operar aplicações em contentores em grande escala através da infraestrutura da Google, e oferece funcionalidades que ajudam a gerir o seu ambiente Kubernetes, como:

  • Duas edições: GKE Standard e GKE Enterprise. Com o GKE Standard, tem acesso a um nível padrão de funcionalidades essenciais. Com o GKE Enterprise, tem acesso a todas as capacidades do GKE. Para mais informações, consulte o artigo Edições do GKE.
  • Dois modos de funcionamento: padrão e automático. Com o Standard, gere a infraestrutura subjacente e a configuração de cada nó no seu cluster do GKE. Com o Autopilot, o GKE gere a infraestrutura subjacente, como a configuração de nós, o dimensionamento automático, as atualizações automáticas, a segurança de base e a configuração de rede. Para mais informações sobre os modos de funcionamento do GKE, consulte o artigo Escolha um modo de funcionamento do GKE.
  • Contrato de nível de serviço exclusivo da indústria para pods quando usar o Autopilot em várias zonas.
  • Criação e eliminação automáticas de node pools com o aprovisionamento automático de nós.
  • Redes multicluster geridas pela Google para ajudar a conceber e implementar arquiteturas distribuídas de alta disponibilidade para as suas cargas de trabalho.

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

Para esta migração para Google Cloud, recomendamos que siga a estrutura de migração descrita no artigo Migrar para Google Cloud: introdução.

O diagrama seguinte ilustra o caminho do seu percurso de migração.

Caminho de migração com quatro fases.

Pode migrar do ambiente de origem para o ambiente de destino Google Cloud numa série de iterações. Por exemplo, pode migrar algumas cargas de trabalho primeiro e outras mais tarde. Para cada iteração de migração separada, segue as fases da estrutura de migração geral:

  1. Avalie e descubra as suas cargas de trabalho e dados.
  2. Planeie e crie uma base em Google Cloud.
  3. Migre as suas cargas de trabalho e dados para o Google Cloud.
  4. Otimize o seu Google Cloud ambiente.

Para mais informações sobre as fases desta estrutura, consulte o artigo Migre para Google Cloud: comece.

Para criar um plano de migração eficaz, recomendamos que valide cada passo do plano e se certifique de que tem uma estratégia de reversão. Para ajudar a validar o seu plano de migração, consulte o artigo Migre para Google Cloud: práticas recomendadas para validar um plano de migração.

Avalie o ambiente de origem

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

A fase de avaliação é fundamental para o sucesso da sua migração. Tem de adquirir conhecimentos profundos sobre as cargas de trabalho que quer migrar, os respetivos requisitos, as respetivas dependências e o seu ambiente atual. Tem de compreender o seu ponto de partida para planear e executar com êxito uma Google Cloud migração.

A fase de avaliação consiste nas seguintes tarefas:

  1. Crie um inventário abrangente das suas cargas de trabalho.
  2. Catalogue as suas cargas de trabalho de acordo com as respetivas propriedades e dependências.
  3. Forme e eduque as suas equipas sobre Google Cloud.
  4. Crie experiências e provas de conceito em Google Cloud.
  5. Calcular o custo total de propriedade (TCO) do ambiente de destino.
  6. Escolha a estratégia de migração para as suas cargas de trabalho.
  7. Escolha as ferramentas de migração.
  8. Defina o plano de migração e a linha cronológica.
  9. Valide o seu plano de migração.

Para mais informações sobre a fase de avaliação e estas tarefas, consulte o artigo Migre para Google Cloud: avalie e descubra as suas cargas de trabalho. As secções seguintes baseiam-se nas informações desse documento.

Crie os seus inventários

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

  1. O inventário dos seus clusters.
  2. O inventário das suas cargas de trabalho implementadas nesses clusters.

Depois de criar estes inventários:

  1. Avalie os processos de implementação e operacionais do seu ambiente de origem.
  2. Avalie os serviços de apoio técnico e as dependências externas.

Crie o inventário dos seus clusters

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

  • Número e tipo de nós. Quando sabe quantos nós e as características de cada nó que tem no seu ambiente atual, pode dimensionar os clusters quando se mudar para o GKE. Os nós no novo ambiente podem ser executados numa arquitetura de hardware ou geração diferente dos que usa no seu ambiente. O desempenho de cada arquitetura e geração é diferente, pelo que o número de nós de que precisa no novo ambiente pode ser diferente do seu ambiente. Avalie qualquer tipo de hardware que esteja a usar nos seus nós, como dispositivos de armazenamento de alto desempenho, GPUs e TPUs. Avalie a imagem do sistema operativo que está a usar nos seus nós.
  • Cluster interno ou externo. Avalie a que atores, internos ou externos ao seu ambiente, cada cluster está exposto. Para suportar os seus exemplos de utilização, esta avaliação inclui as cargas de trabalho executadas no cluster e as interfaces que interagem com os seus clusters.
  • Multi-tenancy. Se estiver a gerir clusters multi-inquilinos no seu ambiente, avalie se funciona no novo ambiente Google Cloud. Agora é um bom momento para avaliar como melhorar os seus clusters multi-inquilino, porque a sua estratégia de multi-inquilino influencia a forma como cria a sua base no Google Cloud.
  • Versão do Kubernetes. Recolha informações sobre a versão do Kubernetes dos seus clusters para avaliar se existe uma incompatibilidade entre essas versões e as disponíveis no GKE. Se estiver a executar uma versão do Kubernetes mais antiga ou lançada recentemente, pode estar a usar funcionalidades que não estão disponíveis no GKE. As funcionalidades podem estar descontinuadas ou a versão do Kubernetes que as envia ainda não está disponível no GKE.
  • Ciclo de atualização do Kubernetes. Para manter um ambiente fiável, compreenda como está a processar as atualizações do Kubernetes e como o seu ciclo de atualização se relaciona com as atualizações do GKE.
  • Pools de nós. Se estiver a usar qualquer forma de agrupamento de nós, é recomendável considerar como estes agrupamentos são mapeados para o conceito de pools de nós no GKE, uma vez que os seus critérios de agrupamento podem não ser adequados para o GKE.
  • Inicialização do nó. Avalie como inicializa cada nó antes de o marcar como disponível para executar as suas cargas de trabalho, para que possa portar esses procedimentos de inicialização para o GKE.
  • Configuração de rede. Avalie a configuração de rede dos seus clusters, a respetiva atribuição de endereços IP, como configurou os respetivos plug-ins de rede, como configurou os respetivos servidores DNS e fornecedores de serviços DNS, se configurou alguma forma de NAT ou SNAT para estes clusters e se fazem parte de um ambiente de vários clusters.
  • Conformidade: avalie todos os requisitos regulamentares e de conformidade que os seus clusters têm de cumprir e se está a cumprir estes requisitos.
  • Quotas e limites. Avalie como configurou as quotas e os limites para os seus clusters. Por exemplo, quantos pods cada nó pode executar? Quantos nós pode ter um cluster?
  • Etiquetas. Avalie todos os metadados que aplicou a clusters, conjuntos de nós e nós, e como os está a usar. Por exemplo, pode estar a gerar relatórios com atribuição de custos detalhada baseada em etiquetas.

Os seguintes itens que avalia no seu inventário focam-se na segurança da sua infraestrutura e clusters do Kubernetes:

  • Espaços de nomes. Se usar namespaces do Kubernetes nos seus clusters para separar logicamente os recursos, avalie que recursos estão em cada namespace e compreenda por que motivo criou esta separação. Por exemplo, pode estar a usar espaços de nomes como parte da sua estratégia de multi-tenancy. Pode ter cargas de trabalho implementadas em espaços de nomes reservados para componentes do sistema Kubernetes e pode não ter tanto controlo no GKE.
  • Controlo de acesso baseado em funções (CABF). Se usar a autorização RBAC nos seus clusters, liste uma descrição de todos os ClusterRoles e ClusterRoleBindings que configurou nos seus clusters.
  • Políticas de rede. Liste todas as políticas de rede que configurou nos seus clusters e compreenda como funcionam as políticas de rede no GKE.
  • Contextos de segurança do pod. Capture informações sobre os contextos de segurança dos pods que configurou nos seus clusters e saiba como funcionam no GKE.
  • Contas de serviço. Se algum processo no seu cluster estiver a interagir com o servidor da API Kubernetes, capture informações sobre as contas de serviço que estão a usar.

Quando cria o inventário dos seus clusters do Kubernetes, pode verificar que alguns dos clusters têm de ser desativados como parte da migração. Certifique-se de que o seu plano de migração inclui a desativação destes recursos.

Crie o inventário das suas cargas de trabalho do Kubernetes

Depois de concluir o inventário de clusters do Kubernetes e avaliar a segurança do seu ambiente, crie o inventário das cargas de trabalho implementadas nesses clusters. Quando avaliar as suas cargas de trabalho, recolha informações sobre os seguintes aspetos:

  • Agrupamentos e controladores. Para dimensionar os clusters no seu novo ambiente, avalie quantas instâncias de cada carga de trabalho implementou e se está a usar quotas de recursos e limites de consumo de recursos de computação. Recolha informações sobre as cargas de trabalho que estão a ser executadas nos nós do plano de controlo de cada cluster e os controladores que cada carga de trabalho usa. Por exemplo, quantas implementações está a usar? Quantos DaemonSets está a usar?
  • Jobs e CronJobs. Os seus clusters e cargas de trabalho podem ter de executar trabalhos ou CronJobs como parte dos respetivos procedimentos de inicialização ou operação. Avalie quantas instâncias de Jobs e CronJobs implementou, bem como as responsabilidades e os critérios de conclusão de cada instância.
  • Kubernetes Autoscalers. Para migrar as suas políticas de escala automática para o novo ambiente, saiba como a escala automática horizontal de pods e a escala automática vertical de pods funcionam no GKE.
  • Cargas de trabalho sem estado e com estado. As cargas de trabalho sem estado não armazenam dados nem estado no cluster ou no armazenamento persistente. As aplicações com estado guardam dados para utilização posterior. Para cada carga de trabalho, avalie que componentes são sem estado e quais são com estado, porque a migração de cargas de trabalho com estado é normalmente mais difícil do que a migração de cargas de trabalho sem estado.
  • Funcionalidades do Kubernetes. A partir do inventário de clusters, sabe qual é a versão do Kubernetes que cada cluster executa. Reveja as notas de lançamento de cada versão do Kubernetes para saber que funcionalidades são fornecidas e que funcionalidades são descontinuadas. Em seguida, avalie as suas cargas de trabalho em função das funcionalidades do Kubernetes de que precisa. O objetivo desta tarefa é saber se está a usar funcionalidades descontinuadas ou funcionalidades que ainda não estão disponíveis no GKE. Se encontrar funcionalidades indisponíveis, migre das funcionalidades descontinuadas e adote as novas quando estiverem disponíveis no GKE.
  • Armazenamento. Para cargas de trabalho com estado, avalie se usam PersistenceVolumeClaims. Indique todos os requisitos de armazenamento, como o tamanho e o modo de acesso, e como estes PersistenceVolumeClaims são mapeados para PersistenceVolumes. Para ter em conta o crescimento futuro, avalie se precisa de expandir qualquer PersistenceVolumeClaim.
  • Configuração e injeção de segredos. Para evitar a reconstrução dos artefactos implementáveis sempre que houver uma alteração na configuração do seu ambiente, injete a configuração e os segredos nos pods através de ConfigMaps e Secrets. Para cada carga de trabalho, avalie os ConfigMaps e os segredos que essa carga de trabalho está a usar e como está a preencher esses objetos.
  • Dependências. As suas cargas de trabalho provavelmente não funcionam isoladamente. Podem ter dependências, quer internas ao cluster, quer de sistemas externos. Para cada carga de trabalho, capture as dependências e, se as suas cargas de trabalho tiverem alguma tolerância para quando as dependências não estão disponíveis. Por exemplo, as dependências comuns incluem sistemas de ficheiros distribuídos, bases de dados, plataformas de distribuição de segredos, sistemas de gestão de identidades e acessos, mecanismos de deteção de serviços e quaisquer outros sistemas externos.
  • Serviços do Kubernetes. Para expor as suas cargas de trabalho a clientes internos e externos, use os Serviços. Para cada serviço, tem de saber o respetivo tipo. Para serviços expostos externamente, avalie a forma como esse serviço interage com o resto da sua infraestrutura. Por exemplo, como é que a sua infraestrutura suporta os serviços LoadBalancer, objetos Gateway, e objetos Ingress? Que controladores de entrada implementou nos seus clusters?
  • Malha de serviços. Se estiver a usar uma malha de serviços no seu ambiente, avalie a forma como está configurada. Também tem de saber quantos clusters abrange, que serviços fazem parte da malha e como modifica a topologia da malha.
  • Taints e tolerations e afinidade e antiafinidade. Para cada agrupamento e nó, avalie se configurou alguma contaminação de nós, tolerâncias de agrupamentos ou afinidades para personalizar o agendamento de agrupamentos nos seus clusters do Kubernetes. Estas propriedades também podem dar-lhe estatísticas sobre possíveis configurações não homogéneas de nós ou pods e podem significar que os pods, os nós ou ambos têm de ser avaliados com especial atenção e cuidado. Por exemplo, se configurou um conjunto específico de pods para serem agendados apenas em determinados nós no seu cluster do Kubernetes, pode significar que os pods precisam de recursos especializados que só estão disponíveis nesses nós.
  • Autenticação: avalie como as suas cargas de trabalho se autenticam em relação aos recursos no seu cluster e em relação aos recursos externos.

Avalie os serviços de apoio técnico e as dependências externas

Depois de avaliar os clusters e as respetivas cargas de trabalho, avalie os restantes serviços e aspetos de apoio na sua infraestrutura, como os seguintes:

  • StorageClasses e PersistentVolumes. Avalie como a sua infraestrutura está a suportar PersistentVolumeClaims listando StorageClasses para aprovisionamento dinâmico e PersistentVolumes PersistentVolumes. Para cada PersistentVolume, considere o seguinte: capacidade, modo de volume, modo de acesso, classe, política de recuperação, opções de montagem e afinidade de nós.
  • VolumeSnapshots e VolumeSnapshotContents. Para cada PersistentVolume, avalie se configurou algum VolumeSnapshot e se precisa de migrar algum VolumeSnapshotContent existente.
  • Controladores da interface de armazenamento de contentores (CSI). Se forem implementados nos seus clusters, avalie se estes controladores são compatíveis com o GKE e se precisa de adaptar a configuração dos seus volumes para funcionar com controladores CSI compatíveis com o GKE.
  • Armazenamento de dados. Se depender de sistemas externos para aprovisionar PersistentVolumes, faculte uma forma de as cargas de trabalho no seu ambiente do GKE usarem esses sistemas. A localidade dos dados tem um impacto no desempenho das cargas de trabalho com estado, porque a latência entre os seus sistemas externos e o seu ambiente do GKE é proporcional à distância entre eles. Para cada sistema de armazenamento de dados externo, considere o respetivo tipo, como volumes de blocos, armazenamento de ficheiros ou armazenamento de objetos, e todos os requisitos de desempenho e disponibilidade que tem de satisfazer.
  • Recursos personalizados e suplementos do Kubernetes. Recolha informações sobre quaisquer recursos personalizados do Kubernetes e quaisquer suplementos do Kubernetes que possa ter implementado nos seus clusters, uma vez que podem não funcionar no GKE ou pode ter de os modificar. Por exemplo, se um recurso personalizado interagir com um sistema externo, avalie se isso é aplicável ao seu ambiente. Google Cloud
  • Cópia de segurança. Avalie como está a fazer uma cópia de segurança da configuração dos seus clusters e dados de carga de trabalho com estado no ambiente de origem.

Avalie os seus processos de implementação e operacionais

É importante ter uma compreensão clara do funcionamento dos processos de implementação e operacionais. Estes processos são uma parte fundamental das práticas que preparam e mantêm o seu ambiente de produção e as cargas de trabalho que são executadas nesse ambiente.

Os seus processos de implementação e operacionais podem criar os artefactos de que as suas cargas de trabalho precisam para funcionar. Por conseguinte, deve recolher informações sobre cada tipo de artefacto. Por exemplo, um artefacto pode ser um pacote do sistema operativo, um pacote de implementação de aplicações, uma imagem do sistema operativo, uma imagem de contentor ou outra coisa.

Além do tipo de artefacto, considere como conclui as seguintes tarefas:

  • Desenvolva as suas cargas de trabalho. Avalie os processos que as equipas de desenvolvimento têm em vigor para criar as suas cargas de trabalho. Por exemplo, como é que as suas equipas de desenvolvimento estão a conceber, programar e testar as suas cargas de trabalho?
  • Gere os artefactos que implementa no seu ambiente de origem. Para implementar as suas cargas de trabalho no ambiente de origem, pode gerar artefactos implementáveis, como imagens de contentores ou imagens de sistemas operativos, ou pode personalizar artefactos existentes, como imagens de sistemas operativos de terceiros, instalando e configurando software. A recolha de informações sobre como está a gerar estes artefactos ajuda a garantir que os artefactos gerados são adequados para implementação noGoogle Cloud.

  • Armazenar os artefactos. Se produzir artefactos que armazena num registo de artefactos no seu ambiente de origem, tem de disponibilizar os artefactos no seu ambiente de destino. Google Cloud Pode fazê-lo através de estratégias como as seguintes:

    • Estabeleça um canal de comunicação entre os ambientes: torne os artefactos no ambiente de origem acessíveis a partir do ambiente de destinoGoogle Cloud .
    • Refatore o processo de criação de artefactos: conclua uma refatoração menor do seu ambiente de origem para que possa armazenar artefactos no ambiente de origem e no ambiente de destino. Esta abordagem suporta a sua migração através da criação de infraestrutura, como um repositório de artefactos, antes de ter de implementar processos de compilação de artefactos no ambiente de destino. Google CloudPode implementar esta abordagem diretamente ou basear-se na abordagem anterior de estabelecer primeiro um canal de comunicação.

    A disponibilidade de artefactos nos ambientes de origem e de destino permite-lhe concentrar-se na migração sem ter de implementar processos de criação de artefactos no ambiente de destino Google Cloud como parte da migração.

  • Leia e assine o código. Como parte dos processos de compilação de artefactos, pode estar a usar a análise de código para ajudar a proteger-se contra vulnerabilidades comuns e a exposição não intencional da rede, bem como a assinatura de código para ajudar a garantir que apenas o código fidedigno é executado nos seus ambientes.

  • Implemente artefactos no seu ambiente de origem. Depois de gerar artefactos implementáveis, pode implementá-los no seu ambiente de origem. Recomendamos que avalie cada processo de implementação. A avaliação ajuda a garantir que os seus processos de implementação são compatíveis com o Google Cloud. Também ajuda a compreender o esforço necessário para, eventualmente, refatorar os processos. Por exemplo, se os seus processos de implementação funcionarem apenas com o ambiente de origem, pode ter de refatorá-los para segmentar o ambiente de destino. Google Cloud

  • Injetar configuração de tempo de execução. Pode estar a injetar a configuração de tempo de execução para clusters, ambientes de tempo de execução ou implementações de cargas 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 ajudar a garantir que os processos de injeção de configuração de tempo de execução funcionam no Google Cloud, recomendamos que avalie como está a configurar as cargas de trabalho que são executadas no seu ambiente de origem.

  • Registo, monitorização e criação de perfis. Avalie os processos de registo, monitorização e criação de perfis que tem implementados para monitorizar o estado do ambiente de origem, as métricas de interesse e a forma como está a consumir os dados fornecidos por estes processos.

  • Autenticação. Avalie a forma como está a fazer a autenticação no seu ambiente de origem.

  • Aprovisione e configure os seus recursos. Para preparar o ambiente de origem, pode ter concebido e implementado processos que aprovisionam e configuram recursos. Por exemplo, pode estar a usar o Terraform juntamente com ferramentas de gestão de configuração para aprovisionar e configurar recursos no seu ambiente de origem.

Ferramentas para criar o inventário do seu ambiente de origem

Para criar o inventário dos seus clusters do Amazon EKS, recomendamos que use o Migration Center, a plataforma unificada daGoogle Cloudque ajuda a acelerar o seu percurso na nuvem ponto a ponto do seu ambiente atual para o Google Cloud. O centro de migração permite-lhe importar dados do Amazon EKS e de outros recursos da AWS. Em seguida, o Migration Center recomenda serviços relevantes Google Cloud para os quais pode migrar.

Refine o inventário dos seus clusters e cargas de trabalho do Amazon EKS

Os dados fornecidos pelo Migration Center podem não captar totalmente as dimensões que lhe interessam. Nesse caso, pode integrar esses dados com os resultados de outros mecanismos de recolha de dados que criar e que se baseiam em APIs AWS, ferramentas para programadores da AWS e a interface de linha de comandos da AWS.

Além dos dados que recebe do Migration Center, considere os seguintes pontos de dados para cada cluster do Amazon EKS que quer migrar:

  • Considere aspetos e funcionalidades específicos do Amazon EKS para cada cluster do Amazon EKS, incluindo o seguinte:
    • Clusters privados
    • Controlo de acesso ao ponto final do cluster
    • Encriptação secreta
    • Grupos de nós geridos e nós autogeridos
    • Etiquetas em recursos do Amazon EKS
    • AMIs personalizadas da Amazon no EKS
    • Utilização do Amazon EKS Fargate
    • Utilização do Amazon EKS Managed Prometheus
    • Configuração de autenticação do OpenID Connect
  • Avalie a forma como está a fazer a autenticação nos seus 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 seus clusters do Amazon EKS.

Planeie e crie a sua base

Na fase de planeamento e criação, aprovisiona e configura a infraestrutura para fazer o seguinte:

  • Suporte as suas cargas de trabalho no seu Google Cloud ambiente.
  • Ligue o ambiente de origem e o ambiente Google Cloud para concluir a migração.

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

  1. Crie uma hierarquia de recursos.
  2. Configure Google Cloud's Identity and Access Management (IAM).
  3. Configure a faturação
  4. Configure a conetividade de rede.
  5. Reforce a sua segurança.
  6. Configure o registo, a monitorização e os alertas.

Para mais informações sobre cada uma destas tarefas, consulte o artigo Migre para o Google Cloud: planeie e crie a sua base.

As secções seguintes integram as considerações em Migre para o Google Cloud: planeie e crie a sua base.

Planeie a multi-posse

Para criar uma hierarquia de recursos eficiente, considere como a sua empresa e as estruturas organizacionais se relacionam com Google Cloud. Por exemplo, se precisar de um ambiente multiinquilino no GKE, pode escolher entre as seguintes opções:

  • Criar um Google Cloud projeto para cada inquilino.
  • Partilhar um projeto entre diferentes inquilinos e aprovisionar vários clusters do GKE.
  • Usar namespaces do Kubernetes.

A sua escolha depende das necessidades de isolamento, complexidade e escalabilidade. Por exemplo, ter um projeto por inquilino isola os inquilinos uns dos outros, mas a hierarquia de recursos torna-se mais complexa de gerir devido ao elevado número de projetos. No entanto, embora a gestão dos espaços de nomes do Kubernetes seja relativamente mais fácil do que uma hierarquia de recursos complexa, esta opção não garante tanto isolamento. Por exemplo, o plano de controlo pode ser partilhado entre inquilinos. Para mais informações, consulte o artigo Multi-posse de clusters.

Configure a gestão de identidade e de acesso

O GKE suporta várias opções para gerir o acesso aos recursos no seu Google Cloud projeto e respetivos clusters através do RBAC. Para mais informações, consulte Controlo de acesso.

Configure a rede do GKE

A configuração de rede é um aspeto fundamental do seu ambiente. Antes de aprovisionar e configurar qualquer cluster, recomendamos que avalie o modelo de rede do GKE, as práticas recomendadas para a rede do GKE e como planear endereços IP ao migrar para o GKE.

Configure a monitorização e os alertas

Ter uma ideia clara do desempenho da sua infraestrutura e cargas de trabalho é fundamental para encontrar áreas de melhoria. O GKE tem integrações profundas com o Google Cloud Observability, pelo que recebe informações de registo, monitorização e criação de perfis sobre os seus clusters do GKE e cargas de trabalho nesses clusters.

Migre os seus dados e implemente cargas de trabalho

Na fase de implementação, faz o seguinte:

  1. Aprovisione e configure o seu ambiente do GKE.
  2. Configure os seus clusters do GKE.
  3. Refatore as suas cargas de trabalho.
  4. Refatore os processos de implementação e operacionais.
  5. Migre dados do seu ambiente de origem para o Google Cloud.
  6. Implemente as suas cargas de trabalho no seu ambiente do GKE.
  7. Valide as suas cargas de trabalho e o ambiente do GKE.
  8. Exponha cargas de trabalho em execução no GKE.
  9. Desviar o tráfego do ambiente de origem para o ambiente do GKE.
  10. Desative o ambiente de origem.

Aprovisione e configure o seu Google Cloud ambiente

Antes de mover qualquer carga de trabalho para o novo ambiente Google Cloud , tem de aprovisionar os clusters do GKE.

O GKE suporta a ativação de determinadas funcionalidades em clusters existentes, mas pode haver funcionalidades que só pode ativar no momento da criação do cluster. Para ajudar a evitar interrupções e simplificar a migração, recomendamos que ative as funcionalidades do cluster de que precisa no momento da criação do cluster. Caso contrário, pode ter de destruir e recriar os clusters se não for possível ativar as funcionalidades de cluster de que precisa depois de criar um cluster.

Após a fase de avaliação, já sabe como aprovisionar os clusters do GKE no seu novo ambiente Google Cloud para satisfazer as suas necessidades. Para aprovisionar os seus 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 escalabilidade de cada cluster.
  • O modo de funcionamento de cada cluster. O GKE oferece dois modos de funcionamento para clusters: GKE Autopilot e GKE Standard.
  • O número de clusters privados.
  • A escolha entre redes nativas da VPC ou baseadas em router.
  • As versões e os canais de lançamento do Kubernetes de que precisa nos seus clusters do GKE.
  • Os conjuntos de nós para agrupar logicamente os nós nos seus clusters do GKE e se precisa de criar automaticamente conjuntos de nós com o aprovisionamento automático de nós.
  • Os procedimentos de inicialização que pode transferir do seu ambiente para o ambiente do GKE e os novos procedimentos que pode implementar. Por exemplo, pode iniciar automaticamente nós do GKE implementando um ou vários procedimentos de inicialização, eventualmente privilegiados, para cada nó ou conjunto de nós nos seus clusters.
  • Os planos de escalabilidade para cada cluster.
  • As funcionalidades adicionais do GKE de que precisa, como o Cloud Service Mesh e os suplementos do GKE, como o Backup for GKE.

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

Gestão de frotas

Quando aprovisiona os seus clusters do GKE, pode perceber que precisa de um grande número deles para suportar todos os exemplos de utilização do seu ambiente. Por exemplo, pode ter de separar a produção dos ambientes de não produção ou separar os serviços entre equipas ou áreas geográficas. Para mais informações, consulte os exemplos de utilização de vários clusters.

À medida que o número de clusters aumenta, o seu ambiente do GKE pode tornar-se mais difícil de operar, uma vez que a gestão de um grande número de clusters apresenta desafios significativos de escalabilidade e operacionais. O GKE oferece ferramentas e funcionalidades para ajudar a gerir frotas, um agrupamento lógico de clusters do Kubernetes. Para mais informações, consulte o artigo Gestão de frotas.

Rede em vários clusters

Para ajudar a melhorar a fiabilidade do seu ambiente do GKE e distribuir as cargas de trabalho por vários clusters do GKE, pode usar:

  • Descoberta de serviços em vários clusters, um mecanismo de invocação e descoberta de serviços entre clusters. Os serviços são detetáveis e acessíveis em todos os clusters do GKE. Para mais informações, consulte o artigo Deteção 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 o artigo Implementar gateways de vários clusters.
  • Malha de vários clusters no Cloud Service Mesh gerido. Para mais informações, consulte o artigo Configure uma malha de vários clusters.

Para mais informações sobre a migração de um ambiente do GKE de cluster único para um ambiente do GKE de vários clusters, consulte o artigo Migre para a rede de vários clusters.

Configure os seus clusters do GKE

Depois de aprovisionar os clusters do GKE e antes de implementar qualquer carga de trabalho ou migrar dados, configura os espaços de nomes, o RBAC, as políticas de rede, as contas de serviço e outros objetos do Kubernetes e do GKE para cada cluster do GKE.

Para configurar objetos do Kubernetes e do GKE nos seus clusters do GKE, recomendamos que:

  1. Certifique-se de que tem as credenciais e as autorizações necessárias para aceder aos clusters no ambiente de origem e no ambiente do GKE.
  2. Avalie se os objetos nos clusters do Kubernetes do seu ambiente de origem são compatíveis com o GKE e como as implementações que suportam estes objetos diferem do ambiente de origem e do GKE.
  3. Refatore qualquer objeto incompatível para o tornar compatível com o GKE ou retire-o.
  4. Crie estes objetos nos seus clusters do GKE.
  5. Configure quaisquer objetos adicionais de que necessita nos seus clusters do GKE.

Config Sync

Para ajudar a adotar as práticas recomendadas de GitOps para gerir a configuração dos seus clusters do GKE à medida que o GKE é dimensionado, recomendamos que use o Config Sync, um serviço GitOps para implementar configurações a partir de uma fonte de verdade. Por exemplo, pode armazenar a configuração dos seus clusters do GKE num repositório Git e usar o Config Sync para aplicar essa configuração.

Para mais informações, consulte o artigo Arquitetura da sincronização de configurações.

Controlador de políticas

O Policy Controller ajuda a aplicar e impor políticas programáveis para ajudar a garantir que os seus clusters e cargas de trabalho do GKE são executados de forma segura e em conformidade. À medida que o seu ambiente do GKE é dimensionado, pode usar o Policy Controller para aplicar automaticamente políticas, pacotes de políticas e restrições a todos os seus clusters do GKE. Por exemplo, pode restringir os repositórios a partir dos quais as imagens de contentores podem ser extraídas ou pode exigir que cada espaço de nomes tenha, pelo menos, uma etiqueta para ajudar a garantir uma monitorização precisa do consumo de recursos.

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

Refatore as suas cargas de trabalho

Uma prática recomendada para conceber cargas de trabalho em contentores é evitar dependências da plataforma de orquestração de contentores. Isto pode nem sempre ser possível na prática devido aos requisitos e ao design das suas cargas de trabalho. Por exemplo, as suas cargas de trabalho podem depender de funcionalidades específicas do ambiente que só estão disponíveis no ambiente de origem, como suplementos, extensões e integrações.

Embora possa migrar a maioria das cargas de trabalho tal como estão para o GKE, pode ter de despender mais esforço para refatorizar as cargas de trabalho que dependem de funcionalidades específicas do ambiente, de modo a minimizar estas dependências e, eventualmente, mudar para alternativas disponíveis no GKE.

Para refatorar as suas cargas de trabalho antes de as migrar para o GKE, faça o seguinte:

  1. Reveja as funcionalidades específicas do ambiente de origem, como suplementos, extensões e integrações.
  2. Adote soluções alternativas adequadas do GKE.
  3. Refatore as suas cargas de trabalho.

Reveja as funcionalidades específicas do ambiente de origem

Se estiver a usar funcionalidades específicas do ambiente de origem e as suas cargas de trabalho dependerem destas funcionalidades, tem de:

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

Como parte desta revisão, recomendamos que faça o seguinte:

  • Considere se pode descontinuar alguma destas funcionalidades específicas do ambiente de origem.
  • Avalie a importância de uma funcionalidade específica do ambiente de origem para o sucesso da migração.

Adote soluções alternativas adequadas do GKE

Depois de rever as funcionalidades específicas do ambiente de origem e mapeá-las para soluções alternativas adequadas do GKE, adota estas soluções no seu ambiente do GKE. Para reduzir a complexidade da migração, recomendamos que faça o seguinte:

  • Evite adotar soluções alternativas do GKE para funcionalidades específicas do ambiente de origem que pretende descontinuar.
  • Concentre-se na adoção de soluções alternativas do GKE para as funcionalidades específicas do ambiente de origem mais críticas e planeie projetos de migração dedicados para o resto.

Refatore as suas cargas de trabalho

Embora a maioria das suas cargas de trabalho possa funcionar tal como está no GKE, pode ter de refatorar algumas delas, especialmente se dependerem de funcionalidades específicas do ambiente de origem para as quais adotou soluções alternativas do GKE.

Esta refatoração pode envolver:

  • Descritores de objetos do Kubernetes, como implementações e serviços expressos no formato YAML.
  • Descritores de imagens de contentores, como Dockerfiles e Containerfiles.
  • Código-fonte das cargas de trabalho.

Para simplificar o esforço de refatoração, recomendamos que se concentre na aplicação da menor quantidade de alterações necessárias para tornar as suas cargas de trabalho adequadas para o GKE e correções de erros críticos. Pode planear outras melhorias e alterações como parte de projetos futuros.

Refatore os processos de implementação e operacionais

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

  • Aprovisione e configure recursos no seu Google Cloud ambiente em vez de aprovisionar recursos no seu ambiente de origem.
  • Crie e configure cargas de trabalho e implemente-as no Google Cloud em vez de as implementar no seu ambiente de origem.

Recolheu informações sobre estes processos durante a fase de avaliação anteriormente neste processo.

O tipo de refatoração que tem de considerar para estes processos depende de como os concebeu e implementou. A refatoração também depende do estado final que quer para cada processo. Por exemplo, considere o seguinte:

  • Pode ter implementado estes processos no seu ambiente de origem e pretender criar e implementar processos semelhantes no Google Cloud. Por exemplo, pode refatorar estes processos para usar o Cloud Build, o Cloud Deploy e o Infrastructure Manager.
  • Pode ter implementado estes processos noutro ambiente de terceiros fora do seu ambiente de origem. Neste caso, tem de refatorar estes processos para segmentar o seu ambiente Google Cloud em vez do ambiente de origem.
  • Uma combinação das abordagens anteriores.

A refatoração dos processos de implementação e operacionais pode ser complexa e exigir um esforço significativo. Se tentar realizar estas tarefas como parte da migração da carga de trabalho, a migração da carga de trabalho pode tornar-se mais complexa e expô-lo a riscos. Depois de avaliar a implementação e os processos operacionais, é provável que compreenda o respetivo design e complexidade. Se estimar que precisa de um esforço substancial para refatorar a implementação e os processos operacionais, recomendamos que considere refatorar estes processos como parte de um projeto separado e dedicado.

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

Este documento centra-se nos processos de implementação que produzem os artefactos a implementar e implementam-nos no ambiente de tempo de execução de destino. A estratégia de refatoração depende muito da complexidade destes processos. A lista seguinte descreve uma possível estratégia de refatoração geral:

  1. Aprovisione repositórios de artefactos em Google Cloud. Por exemplo, pode usar o Artifact Registry para armazenar artefactos e criar dependências.
  2. Refatore os processos de compilação para armazenar artefactos no ambiente de origem e no Artifact Registry.
  3. Refatore os processos de implementação para implementar as cargas de trabalho no ambiente de destinoGoogle Cloud . Por exemplo, pode começar por implementar um pequeno subconjunto das suas cargas de trabalho no Google Cloud, usando artefactos armazenados no Artifact Registry. Em seguida, aumenta gradualmente o número de cargas de trabalho implementadas em Google Cloudaté que todas as cargas de trabalho a migrar sejam executadas emGoogle Cloud.
  4. Refatore os processos de compilação para armazenar artefactos apenas no Artifact Registry.
  5. Se necessário, migre versões anteriores dos artefactos para implementação a partir dos repositórios no ambiente de origem para o Artifact Registry. Por exemplo, pode copiar imagens de contentores para o Artifact Registry.
  6. Desative os repositórios no seu ambiente de origem quando já não precisar deles.

Para facilitar as reversões eventuais devido a problemas inesperados durante a migração, pode armazenar imagens de contentores nos seus repositórios de artefactos atuais enquanto a migração para o Google Container Registry estiver em curso. Google Cloud Google Cloud Por último, como parte da desativação do ambiente de origem, pode refatorar os processos de criação de imagens de contentores para armazenar artefactosGoogle Cloud apenas.

Embora possa não ser crucial para o sucesso de uma migração, pode ter de migrar as versões anteriores dos seus artefactos do ambiente de origem para os repositórios de artefactos no Google Cloud. Por exemplo, para suportar a reversão das suas cargas de trabalho para pontos arbitrários no tempo, pode ter de migrar versões anteriores dos seus artefactos para o Artifact Registry. Para mais informações, consulte Migre imagens de um registo de terceiros.

Se estiver a usar o Artifact Registry para armazenar os seus artefactos, recomendamos que configure controlos para ajudar a proteger os seus repositórios de artefactos, como o controlo de acesso, a prevenção de exfiltração de dados, a análise de vulnerabilidades e a autorização binária. Para mais informações, consulte o artigo Controle o acesso e proteja os artefactos.

Migre dados

O GKE suporta vários serviços de armazenamento de dados, como armazenamento em blocos, armazenamento em blocos não processados, armazenamento de ficheiros e armazenamento de objetos. Para mais informações, consulte o artigo Vista geral do armazenamento para clusters do GKE.

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

  1. Aprovisione e configure toda a infraestrutura de armazenamento necessária.
  2. Configure os aprovisionadores StorageClass nos seus clusters do GKE. Nem todos os aprovisionadores de StorageClass são compatíveis com todos os ambientes. Antes de implementar um aprovisionador de StorageClass, recomendamos que avalie a respetiva compatibilidade com o GKE e as respetivas dependências.
  3. Configure StorageClasses.
  4. Configure PersistentVolumes e PersistentVolumeClaims para armazenar os dados a migrar.
  5. Migre dados do seu ambiente de origem para estes PersistentVolumes. Os detalhes desta migração de dados dependem das características do ambiente de origem.

Para migrar dados do seu ambiente de origem para o ambiente de destino, recomendamos que crie um plano de migração de dados seguindo as orientações em Migre para Google Cloud: transfira grandes conjuntos de dados. Google Cloud

Migre dados do EKS para o GKE

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

  • Migre dados de volumes do Amazon EBS para recursos do GKE PersistentVolume.
  • Copiar dados de volumes do Amazon EBS para o Amazon S3 ou o Cloud Storage e, em seguida, migrar dados para recursos do GKE PersistentVolume.
Migre dados de volumes do Amazon EBS para PersistentVolumes do GKE

Pode migrar dados de volumes do Amazon EBS para recursos do GKE PersistentVolume através de uma das seguintes abordagens:

  • Copie diretamente dados de volumes do Amazon EBS para discos persistentes do Compute Engine:
    1. Aprovisione instâncias do Amazon EC2 e anexe os volumes do Amazon EBS que contêm os dados a migrar.
    2. Aprovisione instâncias do Compute Engine com discos persistentes vazios que tenham capacidade suficiente para armazenar os dados a migrar.
    3. Execute uma ferramenta de sincronização de dados, como o rsync, para copiar dados dos volumes do Amazon EBS para os discos persistentes do Compute Engine.
    4. Desassocie os discos persistentes das instâncias do Compute Engine.
    5. Desativar as instâncias do Compute Engine.
    6. Configure os discos persistentes como recursos do GKE PersistentVolume.
  • Migre instâncias do Amazon EC2 e volumes do Amazon EBS para o Compute Engine:
    1. Aprovisione instâncias do Amazon EC2 e anexe os volumes do Amazon EBS que contêm os dados a migrar.
    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. Desassocie os discos persistentes das instâncias do Compute Engine.
    4. Desativar as instâncias do Compute Engine.
    5. Configure os discos persistentes como recursos do GKE PersistentVolume.

Para mais informações sobre a migração de instâncias do Amazon EC2 para o Compute Engine, consulte o artigo Migre da AWS para o Google Cloud: migre do Amazon EC2 para o Compute Engine.

Para mais informações sobre a utilização de discos persistentes do Compute Engine como recursos do GKE PersistentVolume, consulte o artigo Usar discos persistentes pré-existentes como PersistentVolumes.

Copie dados de volumes do Amazon EBS para um suporte intermédio e migre para volumes persistentes do GKE

Em vez de migrar diretamente dos volumes do Amazon EBS para os recursos do GKE PersistentVolume, pode usar um suporte intermédio, como um armazenamento de objetos:

  1. Carregue dados de volumes do Amazon EBS para um suporte intermédio, como um contentor do Amazon S3 ou um contentor do Cloud Storage.
  2. Transfira os dados do suporte intermédio para os recursos do GKE PersistentVolume.

Em determinados cenários, a utilização de vários suportes pode simplificar a transferência de dados com base nas suas configurações de rede e de segurança. Por exemplo, pode carregar inicialmente os dados para um contentor do S3, copiá-los do contentor do S3 para um contentor do Cloud Storage e, finalmente, transferir os dados para os seus volumes persistentes. Independentemente da abordagem que escolher, para garantir uma transição tranquila e ter em atenção considerações importantes, recomendamos que reveja Migrar do 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 para si depende das suas necessidades e requisitos específicos, como as seguintes considerações:

  • A quantidade de dados que precisa de migrar.
    • Se tiver uma pequena quantidade de dados para migrar, como alguns ficheiros de dados, considere usar ferramentas como o rsync para copiar os dados diretamente para os discos persistentes do Compute Engine. Esta opção é relativamente rápida, mas pode não ser adequada para uma grande quantidade de dados.
    • Se tiver uma grande quantidade de dados para migrar, considere usar o Migrate to Virtual Machines para migrar os dados para o Compute Engine. Esta opção é mais complexa do que copiar diretamente os dados, mas é mais fiável e escalável.
  • O tipo de dados que tem de migrar.
  • A conetividade de rede entre os ambientes de origem e de destino.
    • Se não conseguir estabelecer uma conetividade de rede direta entre as instâncias do AWS EC2 e do Compute Engine, recomendamos que considere usar o Amazon S3 ou o Cloud Storage para armazenar os dados temporariamente enquanto os migra para o Compute Engine. Esta opção pode ser menos dispendiosa porque não tem de manter as instâncias do EC2 e do Compute Engine em execução em simultâneo.
  • A linha cronológica da sua migração.
    • Se tiver uma largura de banda de rede limitada ou uma grande quantidade de dados e não tiver um prazo apertado, também pode considerar usar um Transfer Appliance para mover os seus dados da AWS para o Google Cloud.

Independentemente da opção que escolher, é importante testar a migração antes de a publicar. Os testes ajudam a identificar potenciais problemas e a garantir que a migração é bem-sucedida.

Implemente as suas cargas de trabalho

Quando os processos de implementação estiverem prontos, implemente as suas cargas de trabalho no GKE. Para mais informações, consulte o artigo Vista geral da implementação de cargas de trabalho.

Para preparar as cargas de trabalho para implementação no GKE, recomendamos que analise os seus descritores do Kubernetes, porque alguns Google Cloud recursos que o GKE aprovisiona automaticamente para si são configuráveis através de etiquetas e anotações, em vez de ter de aprovisionar manualmente estes recursos. Por exemplo, pode aprovisionar um equilibrador de carga interno em vez de um externo adicionando uma anotação a um serviço LoadBalancer.

Valide as suas cargas de trabalho

Depois de implementar cargas de trabalho no seu ambiente do GKE, mas antes de expôr estas cargas de trabalho aos seus utilizadores, recomendamos que faça testes e validação extensivos. Estes testes podem ajudar a verificar se as suas cargas de trabalho estão a comportar-se conforme esperado. Por exemplo, pode:

  • Realize testes de integração, testes de carga, testes de conformidade, testes de fiabilidade e outros procedimentos de validação que ajudam a garantir que as suas cargas de trabalho estão a funcionar dentro dos parâmetros esperados e de acordo com as respetivas especificações.
  • Examine os registos, as métricas e os relatórios de erros no Google Cloud Observability para identificar potenciais problemas e detetar tendências para antecipar problemas antes que ocorram.

Para mais informações sobre a validação da carga de trabalho, consulte o artigo Testar a fiabilidade.

Exponha as suas cargas de trabalho

Depois de concluir os testes de validação das cargas de trabalho em execução no seu ambiente do GKE, exponha as cargas de trabalho para as tornar acessíveis.

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

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

Desvie o tráfego para o seu Google Cloud ambiente

Depois de verificar que as cargas de trabalho estão a ser executadas no seu ambiente do GKE e depois de as expor aos clientes, transfere o tráfego do ambiente de origem para o ambiente do GKE. Para ajudar a evitar migrações em grande escala e todos os riscos relacionados, recomendamos que transfira gradualmente o tráfego do seu ambiente de origem para o GKE.

Consoante a forma como concebeu o seu ambiente do GKE, tem várias opções para implementar um mecanismo de equilíbrio de carga que transfere gradualmente o tráfego do ambiente de origem para o ambiente de destino. Por exemplo, pode implementar uma política de resolução de DNS que resolva os registos de DNS de acordo com alguma política para resolver uma determinada percentagem de pedidos para endereços IP pertencentes ao seu ambiente do GKE. Em alternativa, pode implementar um mecanismo de equilíbrio de carga através de endereços IP virtuais e equilibradores de carga de rede.

Depois de começar a transferir gradualmente o tráfego para o seu ambiente do GKE, recomendamos que monitorize o comportamento das cargas de trabalho à medida que os respetivos carregamentos aumentam.

Por fim, faz uma mudança, que ocorre quando transfere todo o tráfego do ambiente de origem para o ambiente do GKE.

Para mais informações sobre o equilíbrio de carga, consulte o artigo Equilíbrio de carga no front-end.

Desative o ambiente de origem

Depois de as cargas de trabalho no seu ambiente do GKE estarem a processar pedidos corretamente, desativa o ambiente de origem.

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

  • Faça uma cópia de segurança de todos os dados para ajudar a restaurar os recursos no ambiente de origem.
  • Notifique os utilizadores 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 no seu ambiente de origem.
  2. Elimine os clusters no ambiente de origem.
  3. Elimine os recursos associados a estes clusters, como grupos de segurança, equilibradores de carga e redes virtuais.

Para evitar deixar recursos órfãos, a ordem em que desativa os recursos no ambiente de origem é importante. Por exemplo, determinados fornecedores exigem que desative os serviços Kubernetes que levam à criação de equilibradores de carga antes de poder desativar as redes virtuais que contêm esses equilibradores de carga.

Otimize o seu Google Cloud ambiente

A otimização é a última fase da migração. Nesta fase, itera nas tarefas de otimização até que o ambiente de destino cumpra os requisitos de otimização. Os passos de cada iteração são os seguintes:

  1. Avalie o seu ambiente, equipas e ciclo de otimização atuais.
  2. Estabeleça os seus requisitos e objetivos de otimização.
  3. Otimize o seu ambiente e as suas equipas.
  4. Ajuste o ciclo de otimização.

Repete esta sequência até atingir os seus objetivos de otimização.

Para mais informações sobre a otimização do seu Google Cloud ambiente, consulte Migrar para Google Cloud: otimize o seu ambiente e Google Cloud Framework bem arquitetado: otimização do desempenho.

As secções seguintes integram as considerações em Migrar para o Google Cloud: otimize o seu ambiente.

Estabeleça os seus requisitos de otimização

Os requisitos de otimização ajudam a restringir o âmbito da iteração de otimização atual. Para mais informações acerca dos requisitos e objetivos de otimização, consulte o artigo Estabeleça os requisitos e os objetivos de otimização.

Para estabelecer os requisitos de otimização do seu ambiente do GKE, comece por considerar os seguintes aspetos:

  • Segurança, privacidade e conformidade: ajudam a melhorar a postura de segurança do seu ambiente do GKE.
  • Fiabilidade: ajuda a melhorar a disponibilidade, a escalabilidade 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: ajudam a manter e operar o seu ambiente do GKE de forma eficiente.
  • Otimização do desempenho: ajuda a otimizar o desempenho das cargas de trabalho implementadas no seu ambiente do GKE.

Segurança, privacidade e conformidade

Fiabilidade

  • Melhore a fiabilidade dos seus clusters. Para ajudar a criar um cluster do GKE mais resiliente a interrupções zonais improváveis, prefira os clusters regionais aos zonais ou multizonais.

  • Cópia de segurança e restauro de cargas de trabalho. Configure um fluxo de trabalho de cópia de segurança e restauro de cargas de trabalho com a cópia de segurança do GKE.

Otimização de custos

Para mais informações sobre a otimização do custo do seu ambiente do GKE, consulte:

Eficiência operacional

Para ajudar a evitar problemas que afetam o seu ambiente de produção, recomendamos que:

  • Crie os seus clusters do GKE de forma que sejam fungíveis. Ao considerar os seus clusters como fungíveis e automatizar o respetivo aprovisionamento e configuração, pode simplificar e generalizar os processos operacionais para os manter e também simplificar as migrações futuras e as atualizações de clusters do GKE. Por exemplo, se precisar de atualizar um cluster do GKE fungível para uma nova versão do GKE, pode aprovisionar e configurar automaticamente um novo cluster atualizado, implementar automaticamente cargas de trabalho no novo cluster e desativar o cluster do GKE antigo e desatualizado.
  • Monitorize as métricas de interesse. Certifique-se de que todas as métricas de interesse sobre as suas cargas de trabalho e clusters são recolhidas corretamente. Além disso, verifique se todos os alertas relevantes que usam estas métricas como entradas estão implementados e a funcionar.

Para mais informações sobre a configuração da monitorização, do registo e da criação de perfis no seu ambiente do GKE, consulte:

Otimização do desempenho

Para mais informações, consulte o artigo Acerca da escalabilidade do GKE.

O que se segue?

Colaboradores

Autores: