Como migrar contêineres para o Google Cloud: como migrar do OpenShift para o GKE Enterprise

Neste documento, ajudamos a planejar, projetar e implementar a migração do OpenShift para o GKE Enterprise. Se feita incorretamente, a migração das cargas de trabalho de um ambiente para outro pode ser uma tarefa desafiadora. Portanto, planeje e execute a migração com cuidado.

Este documento faz parte de uma série de várias partes sobre a migração para o Google Cloud. Se você tiver interesse em uma visão geral da série, consulte Migração para o Google Cloud: como escolher seu 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 é adequado para quem planeja migrar o OpenShift que está em execução em um ambiente de hospedagem local/privado ou em outro provedor de nuvem para o GKE Enterprise. É útil, além disso, se estiver considerando a oportunidade de migrar e quiser saber como funciona esse processo. O ambiente de destino pode ser um dos seguintes:

  • Um ambiente hospedado inteiramente no Google Cloud.
  • Um ambiente híbrido em que você mantém parte da carga de trabalho no local ou em um ambiente de hospedagem privado e migra o restante para o Google Cloud.

Para decidir qual ambiente atende às suas necessidades, considere seus requisitos. Por exemplo, você pode se concentrar em aumentar o valor da sua empresa em vez de se preocupar com a infraestrutura migrando para um ambiente de nuvem pública e terceirizando algumas responsabilidades para o Google. Você se beneficia de um modelo de consumo flexível para otimizar os gastos e o uso de recursos. Se você tiver algum requisito, como manter algumas cargas de trabalho fora do Google Cloud, considere um ambiente híbrido. Por exemplo, se for necessário manter parte das cargas de trabalho no ambiente atual para atender às políticas e regulamentos referentes à localização dos dados. Também é possível implementar uma estratégia de migração para melhorar e mover, em que você moderniza suas cargas de trabalho e então migra para o Google Cloud.

Independentemente do tipo de ambiente de destino, o objetivo dessa migração é gerenciar as cargas de trabalho em execução nesse ambiente usando o GKE Enterprise. Ao adotar o GKE Enterprise, você tem acesso a uma variedade de serviços, incluindo:

  • Gerenciamento de vários clusters, para ajudar você e sua organização a gerenciar em um único lugar os clusters, a infraestrutura e as cargas de trabalho que estão em ambientes na nuvem e no local.
  • Config Sync e Controlador de Políticas para criar configurações e políticas comuns em toda a infraestrutura e aplicá-las no local e na a nuvem.
  • Anthos Service Mesh, para adotar uma malha de serviço totalmente gerenciada que simplifica os serviços operacionais, o gerenciamento de tráfego, a telemetria e a segurança das comunicações entre serviços.
  • Autorização binária, para garantir que os contêineres implantados nos ambientes sejam confiáveis.
  • Cloud Run for Anthos, para oferecer suporte às cargas de trabalho sem servidor no ambiente do GKE Enterprise.

Recomendamos que você avalie esses serviços no início do processo de migração, enquanto ela ainda é projetada. É mais fácil adotar esses serviços agora em vez de modificar seus processos e sua infraestrutura mais tarde. Você pode começar a usar esses serviços imediatamente ou quando estiver pronto para modernizar suas cargas de trabalho.

Nesta migração, siga o framework de migração definido em Migração para o Google Cloud: primeiros passos. O framework tem quatro fases:

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

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

Caminho de migração com quatro fases.

Este documento baseia-se nos conceitos abordados em Migração de contêineres para o Google Cloud: como migrar o Kubernetes para o GKE. Você encontrará links para esse documento, quando necessário.

Como avaliar e descobrir as cargas de trabalho

Na fase de avaliação, determine os requisitos e as dependências para migrar as cargas de trabalho do OpenShift para o GKE Enterprise:

  1. Crie um inventário abrangente dos seus processos e aplicativos;
  2. Catalogue seus processos e aplicativos de acordo com as propriedades e dependências deles;
  3. Treine e instrua suas equipes no Google Cloud;
  4. Crie experimentos e provas 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, mas fornecem informações específicas para avaliar as cargas de trabalho que você quer migrar do OpenShift para o GKE Enterprise.

Criar seus inventários

Para criar o inventário dos componentes do seu ambiente, considere o seguinte:

  • Modelo de gerenciamento de plataforma e prestação de serviços
  • Projetos do OpenShift
  • Processo de criação e implantação
  • Cargas de trabalho, requisitos e dependências
  • Configuração de clusters do OpenShift

Modelo de gerenciamento de plataforma e prestação de serviços

Para migrar cargas de trabalho do OpenShift para o GKE Enterprise, avalie o modelo de gerenciamento de plataforma e a prestação de serviço atual do seu ambiente do OpenShift. Esse modelo provavelmente reflete sua estrutura organizacional e suas necessidades. Se você perceber que o modelo atual não atende às necessidades da organização, use essa migração como uma oportunidade para melhorar o modelo.

Em primeiro lugar, colete informações sobre as equipes responsáveis pelos seguintes aspectos:

  • Desenvolvimento e implantação de aplicativos, incluindo todos os usuários do OpenShift, que, geralmente, são equipes de desenvolvimento ou de lançamento de carga de trabalho.
  • Gerenciamento da plataforma OpenShift, incluindo a criação de projetos do OpenShift, atribuição de papéis a usuários, configuração de contextos de segurança e de pipelines do CI/CD.
  • Gerenciamento de cluster e instalação do OpenShift, incluindo instalação, upgrade, escalonamento de cluster e gerenciamento de capacidade do OpenShift.
  • Gerenciamento de infraestrutura. Essas equipes gerenciam servidores físicos, armazenamento, rede, plataforma de virtualização e sistemas operacionais.

Um modelo de gerenciamento de plataforma e de prestação de serviços consiste nas seguintes equipes:

  • A equipe de desenvolvimento. Essa equipe desenvolve cargas de trabalho e as implanta no OpenShift. Ao lidar com ambientes de produção complexos, a equipe que implanta cargas de trabalho pode ser diferente da equipe de desenvolvimento. Para simplificar, consideramos essa equipe como parte da equipe de desenvolvimento. Em ambientes de autoatendimento, a equipe de desenvolvimento também tem a responsabilidade de criar projetos do OpenShift.
  • A equipe da plataforma. Essa equipe é responsável pelo gerenciamento da plataforma do OpenShift, normalmente chamados de administradores de cluster do OpenShift. Essa equipe configura modelos de projeto do OpenShift para diferentes equipes de desenvolvimento e, em ambientes mais gerenciados, cria projetos do OpenShift. Ela atribui, além disso, papéis e permissões, configura contextos de segurança e o controle de acesso baseado em papéis (RBAC, na sigla em inglês), bem como define cotas para recursos e objetos de computação e estabelece estratégias de compilação e implantação. Às vezes, elas são chamadas de equipe de DevOps ou equipe de middleware, se gerenciam configurações de middleware e de servidor de aplicativos para desenvolvedores. A equipe da plataforma e a equipe de infraestrutura também podem estar envolvidas em atividades de gerenciamento de cluster do OpenShift de nível inferior, como a instalação e o upgrade de softwares, o escalonamento de cluster e o gerenciamento de capacidade.
  • A equipe de infraestrutura. Essa equipe gerencia a infraestrutura subjacente compatível com o ambiente do OpenShift. Ela é responsável, por exemplo, por servidores, armazenamentos, redes, plataformas de virtualização e sistemas operacionais de base. É chamada às vezes de equipe de data center ou equipe de operações. Se o OpenShift for implantado em um ambiente de nuvem pública, essa equipe será responsável pelos serviços de infraestrutura como serviço (IaaS) que um provedor de nuvem pública oferece.

Também é importante avaliar se há clusters dedicados do OpenShift para diferentes ambientes. Por exemplo, pode haver ambientes diferentes para desenvolvimento, controle de qualidade e produção, ou para separar diferentes zonas de rede e segurança, como zonas internas e zonas desatualizadas.

Projetos do OpenShift

Um projeto do OpenShift é um namespace do Kubernetes com anotações adicionais que permite aos desenvolvedores gerenciar recursos longe de outras equipes e separar recursos logicamente. Para criar o inventário dos seus projetos do OpenShift, considere o seguinte para cada projeto:

  • Papéis de cluster e papéis locais. O OpenShift é compatível com os papéis locais de um projeto do OpenShift ou de todo o cluster. Avalie se você criou algum cluster ou papel local para projetar um mecanismo de controle de acesso eficaz no ambiente de destino.
  • Vinculações de papéis, tanto para papéis de cluster quanto para papéis locais. Os usuários e grupos recebem permissões para executar operações em projetos do OpenShift ao atribuí-los vinculações de papéis. Os papéis podem estar no nível do cluster ou no nível local. Muitas vezes, as vinculações de papéis locais estão ligadas a papéis de cluster predefinidos. Por exemplo, a vinculação de papel de administrador do projeto do OpenShift padrão pode estar vinculada ao papel de administrador de cluster padrão.
  • ResourceQuotas . Para restringir o consumo de recursos agregados, o OpenShift permite definir cotas no nível do projeto do OpenShift e cotas em vários projetos do OpenShift. Avalie como eles são mapeados no ResourceQuotas do Kubernetes e preencha uma lista de todos os ResourceQuotas provisionados e configurados no ambiente do OpenShift.

Como avaliar seu ambiente descreve como avaliar recursos do Kubernetes, como ServiceAccounts e PersistentVolumes.

Processos de criação e implantação

Depois de coletar informações sobre o modelo de gerenciamento de plataforma e prestação de serviços e sobre os projetos do OpenShift, avalie como está criando suas cargas de trabalho e implantando-as no ambiente.

No ambiente atual do OpenShift, é possível ter o mesmo processo de criação e implantação para todas as cargas de trabalho, ou pode haver diferentes processos de avaliação. Os artefatos do processo de criação de uma carga de trabalho em contêiner são imagens de contêiner. Em um ambiente do OpenShift, é possível criar imagens de contêiner, armazená-las e implantá-las de diferentes maneiras:

Depois de criar cada imagem de contêiner, armazene-as em no Container Registry que pode ser implantado posteriormente. Seu Container Registry pode ser hospedado no OpenShift ou fora do ambiente do OpenShift. Avalie esse aspecto, porque poderá ser necessário um sistema semelhante no seu ambiente de destino.

Cargas de trabalho, requisitos e dependências

Cada aplicativo do OpenShift contém os seguintes componentes:

Dependendo da finalidade do aplicativo, use objetos diferentes para definir o aplicativo em vez de usar os objetos Implantação ou DeploymentConfig:

  • Defina aplicativos em lote usando o Job ou o cron job.
  • Defina aplicativos com estado usando StatefulSets.
  • Se houver cargas de trabalho relacionadas a operações que precisam ser executadas em cada nó ou vinculadas a nós específicos, defina-as usando DaemonSets.

A tabela a seguir lista as especificações e os parâmetros mais importantes coletados dos recursos do OpenShift para migrar os aplicativos para o ambiente do GKE Enterprise de destino.

Manifesto do recurso do OpenShift de origem Especificações e parâmetros mais importantes
Implantação, DeploymentConfig, StatefulSet, Job, cron job Imagem e repositório do contêiner, porta do contêiner, número de réplicas do pod, ConfigMaps, Secrets, PersistentVolumeClaimos, solicitações e limites de recursos, estratégia de atualização, nome do serviço StatefulSet e programação do cron job
ImageStream Imagem de contêiner, política de extração de imagem, repositório de imagens de contêiner
Escalonador automático de pod horizontal Critérios de escalonamento automático
Serviço Nome do host usado para se conectar ao aplicativo de dentro do cluster, endereço IP e porta em que o serviço está exposto, endpoints criados para recursos externos
Rota Nome do host e caminho do recurso usado para se conectar ao aplicativo de fora do cluster, regras de roteamento, criptografia, informações da cadeia de certificados

Como avaliar seu ambiente descreve como avaliar recursos do Kubernetes, como:

O OpenShift 4 introduziu o Framework do operador. Se estiver usando essa versão do OpenShift, poderá ter implantado alguns aplicativos usando Operadores instalados. Nesse caso, você recebe a lista dos operadores instalados e coleta informações para cada um deles sobre as instâncias do operador que foram implantadas. Essas instâncias são recursos personalizados definidos pelo operador que implantam alguns dos recursos do Kubernetes listados anteriormente.

Além de avaliar esses recursos, verifique:

  • Requisitos de conectividade de rede do aplicativo. Por exemplo, seus serviços ou pods precisam ser expostos a uma rede específica? Eles precisam alcançar sistemas de back-end específicos?
  • Restrições para executar cargas de trabalho em um local específico. Por exemplo, uma carga de trabalho ou conjunto de dados precisa permanecer no local para atender aos requisitos, como latência na comunicação com outras cargas de trabalho, políticas relacionadas à localização de dados e proximidade com os usuários?

Configuração de clusters do OpenShift

Em seguida, avalie os clusters do OpenShift. Para concluir esta tarefa, colete as seguintes informações:

  • Versão do OpenShift. As principais versões do OpenShift no escopo deste documento são OpenShift 3 e OpenShift 4. Versões diferentes do OpenShift podem apresentar outros recursos. Avalie qual versão do OpenShift está sendo executada para saber se está usando algum recurso específico da versão do OpenShift.
  • Provedor de identidade usado na autenticação. Para a autenticação, é possível usar o servidor OAuth integrado e um ou mais provedores de identidade.
  • Restrições de contexto de segurança. Avalie as restrições de contexto de segurança do OpenShift definidas nos clusters, a configuração deles e a quais usuários, grupos e contas de serviço eles estão atribuídos.
  • Isolamento e política de rede. Avalie o NetworkPolicies, como você configurou o isolamento de rede do pod e qual modo de SDN do OpenShift configurou nos clusters.

  • Monitoramento. Avalie os atuais requisitos de monitoramento e como você provisionou e configurou seu sistema atual de monitoramento para decidir como projetar e implementar uma solução de monitoramento no ambiente de destino. Essa avaliação pode ajudar a determinar se é preciso usar uma nova solução de monitoramento ou se você pode continuar a usar a solução atual. Várias versões do OpenShift incluem uma pilha de monitoramento baseada no Prometheus para monitorar os componentes do sistema, que também pode ser usada no monitoramento do aplicativo. Ao projetar sua solução de destino, considere:

    • a solução de monitoramento atualmente usada no ambiente do OpenShift, por exemplo, um Prometheus hospedado pelo OpenShift, uma pilha independente do Prometheus ou Grafana, Zabbix, InfuxData ou Nagios;
    • como as métricas são produzidas e coletadas, por exemplo, um mecanismo de pull ou push;
    • dependências de componentes implantados nos clusters do OpenShift;
    • o local do sistema de monitoramento, por exemplo, ele está implantado em um ambiente de nuvem ou no local;
    • as métricas atualmente coletadas para suas cargas de trabalho;
    • todos os alertas sobre métricas configuradas no sistema de monitoramento atual.

  • Geração de registros. Avalie seus requisitos atuais de geração de registros e como você provisionou e configurou seu sistema de geração de registros atual para decidir como projetar e implementar uma solução de geração de registros no ambiente de destino. Essa avaliação pode ajudar a determinar se é preciso usar uma nova solução de geração de registros ou se você pode continuar a usar a solução atual. Muitas versões do OpenShift vêm com uma solução de geração de registros com base em uma pilha Elasticsearch, Fluentd e Kibana (EfK), que é usada para coletar registros dos componentes do sistema. Essa solução também pode ser usada na geração de registros do aplicativo. Ao projetar sua solução de destino, considere:

    • o sistema de geração de registros usado atualmente no ambiente do OpenShift, por exemplo, uma pilha EFK hospedada pelo OpenShift, uma pilha EFK independente ou o Splunk;
    • dependências de componentes implantados nos clusters do OpenShift;
    • a arquitetura e a capacidade dos componentes de armazenamento de registros;
    • o local do sistema de geração de registros, por exemplo, ele está implantado em um ambiente de nuvem ou no local;
    • as políticas e a configuração de retenção de registros.

Como avaliar seu ambiente descreve como avaliar:

  • o número de clusters;
  • o número e tipo de nós por cluster
  • considerações adicionais sobre geração de registros, monitoramento e rastreamento;
  • recursos personalizados do Kubernetes.

Concluir a avaliação

Depois de compilar os inventários relacionados aos processos e às cargas de trabalho do OpenShift, conclua as outras atividades da fase de avaliação em Migração para o Google Cloud: como avaliar e descobrir suas cargas de trabalho.

Como planejar e construir sua base

Na fase de planejamento e compilação, provisione e configure a infraestrutura e os serviços compatíveis com suas cargas de trabalho:

  1. Crie uma hierarquia de recursos.
  2. Configurar o gerenciamento de identidade e acesso.
  3. Configurar o faturamento.
  4. Configurar a conectividade de rede.
  5. Aumente sua segurança.
  6. Configure o monitoramento e os alertas.

Nesta seção, fornecemos informações específicas para criar sua base no GKE Enterprise, com base nas informações em Migração para o Google Cloud: como criar sua base.

Antes de criar uma base no Google Cloud, leia a visão geral técnica do GKE Enterprise para entender como o GKE Enterprise funciona e quais componentes do GKE Enterprise podem ser necessários. Dependendo dos requisitos de carga de trabalho e localidade de dados coletados na fase de avaliação, você implanta as cargas de trabalho no GKE no VMware, em clusters do GKE no Google Cloud ou no GKE na AWS. Seus clusters podem ser distribuídos entre diferentes ambientes. Para mais informações sobre como criar uma base para o GKE no Google Cloud, consulte Como planejar e criar sua base.

Para criar uma base para o GKE no VMware, leia sobre os principais conceitos e considere o seguinte ao instalar o GKE no VMware:

Para criar uma base para o GKE na AWS, leia sobre os principais conceitos, como GKE na arquitetura da AWS e no GKE no armazenamento da AWS. Considere o seguinte ao instalar o GKE na AWS:

Como implantar suas cargas de trabalho

Na fase de implantação, você implanta suas cargas de trabalho no GKE Enterprise:

  1. Provisione e configure a plataforma e os ambientes de execução.
  2. Migre dados do ambiente antigo para o novo.
  3. Implante suas cargas de trabalho.

As seções a seguir fornecem informações específicas sobre como implantar cargas de trabalho no GKE Enterprise, com base nas informações em Migração para o Google Cloud: como transferir grandes conjuntos de dados, Migração para o Google Cloud: como implantar suas cargas de trabalho e Migração para o Google Cloud: como migrar de implantações manuais para implantações automatizadas em contêineres.

Provisionar e configurar a plataforma e os ambientes de execução

Antes de implantar qualquer carga de trabalho, você provisiona e configura os clusters do GKE Enterprise necessários.

É possível provisionar clusters do GKE no Google Cloud, no cluster do GKE no VMware ou nos clusters da AWS. Por exemplo, se você tem uma carga de trabalho que precisa ser implantada no local, é necessário provisionar um ou mais clusters do GKE no VMware. Se as cargas de trabalho não tiverem requisitos de localidade, provisione clusters do GKE no Google Cloud. Em ambos os casos, é possível gerenciar e monitorar os clusters com o GKE Enterprise. Se você tiver requisitos de várias nuvens, provisione o GKE nos clusters da AWS com outros clusters do GKE Enterprise.

Primeiro, defina o número e o tipo de clusters do GKE Enterprise necessários. Esses requisitos dependem em grande parte das informações coletadas na fase de avaliação, como o modelo de serviço que você quer implementar e como isolar diferentes ambientes. Se várias equipes de desenvolvimento estiverem compartilhando seus clusters do OpenShift, será necessário implementar um modelo multilocatário no GKE Enterprise:

  • Use diversos namespaces do Kubernetes. A equipe da plataforma cria um namespace do Kubernetes para cada projeto do OpenShift e implementa um modelo multilocatário de cluster. Esse modelo é parecido com o que você provavelmente adotou no ambiente do OpenShift. Portanto, pode exigir vários clusters do GKE Enterprise semelhantes ao número de clusters do OpenShift. Se necessário, é possível ainda assim ter clusters dedicados para diferentes ambientes.
  • Use diferentes clusters do GKE Enterprise. A equipe de infraestrutura fornece um cluster do GKE Enterprise para cada equipe de desenvolvimento, e a equipe de plataforma gerencia cada um desses clusters. Esse modelo poderá exigir mais clusters do GKE Enterprise do que o número de clusters do OpenShift, porque fornece maior flexibilidade e isolamento para seu desenvolvimento.
  • Use diversos projetos do Google Cloud. A equipe de infraestrutura cria um projeto do Google Cloud para cada equipe de desenvolvimento e provisiona clusters do GKE Enterprise dentro desse projeto do Google Cloud. A equipe de plataforma gerencia esses clusters. Esse modelo pode exigir mais clusters do GKE Enterprise do que o número de clusters do OpenShift, já que oferece o máximo de flexibilidade e isolamento para suas equipes de desenvolvimento.

Depois de decidir o número de clusters necessários e em qual ambiente eles serão provisionados, defina o tamanho do cluster, a configuração e os tipos de nó. Em seguida, provisione os clusters e pools de nós, de acordo com os requisitos de carga de trabalho coletados durante a fase de avaliação. Por exemplo, suas cargas de trabalho podem exigir determinadas garantias de desempenho e escalonabilidade, além de outros requisitos, como a necessidade de GPUs e TPUs.

Para mais informações sobre como provisionar e configurar clusters, consulte:

Depois de criar os clusters e antes de implantar qualquer carga de trabalho, configure os seguintes componentes para atender aos requisitos coletados na fase de avaliação dos projetos do OpenShift e dos clusters:

Com o Config Sync, é possível definir centralmente a configuração dos seguintes recursos em um repositório comum compatível com o Git e aplicar essa configuração a todos os clusters, tanto no local quanto na nuvem:

Para instalar, consulte Instalar o Config Sync. Para instalar, consulte Instalar o Controlador de Políticas.

Migrar dados do ambiente antigo

Agora é possível migrar dados do seu ambiente de origem para o ambiente de destino.

Se os aplicativos com estado do OpenShift hospedam dados em volumes permanentes do Kubernetes, há diferentes estratégias para migrar dados para o ambiente de destino. A escolha da estratégia adequada depende de vários fatores, como os provedores de armazenamento de back-end de origem e de destino e os locais de implantação:

  • Baseie-se nos recursos de clonagem, exportação e importação de volume do seu provedor de armazenamento. Se estiver usando Volumes do VMware vSphere no ambiente local e migrando para o GKE no VMware, clone os PersistentVolumes subjacentes aos discos virtuais VMDK e ative-os como volumes no ambiente de destino. Se estiver migrando para o GKE, importe os discos virtuais como discos permanentes do Compute Engine e use-os como volumes permanentes.
  • Faça o backup dos dados do ambiente de origem usando ferramentas do sistema operacional ou do banco de dados. Hospede esses dados em um local temporário que possa ser acessado dos dois ambientes e, em seguida, restaure os dados no ambiente de destino.
  • Use uma ferramenta de cópia remota, como rsync, para copiar dados do ambiente de origem para o ambiente de destino.
  • Use uma solução de backup independente de armazenamento, como o Velero, com integração restic.

Para mais informações, consulte Migração para o Google Cloud: como transferir grandes conjuntos de dados.

Para mais informações sobre como migrar dados e estratégias para gerenciar o armazenamento no GKE, consulte Migrar dados do ambiente antigo para o novo ambiente e os documentos do GKE sobre configuração de armazenamento.

Com o GKE no VMware, é possível escolher entre diferentes opções para integração com sistemas de armazenamento externo, como pelo armazenamento VMware vSphere, plug-ins de volume em árvore do Kubernetes e drivers do Container Storage Interface (CSI, na sigla em inglês). Sua escolha depende do sistema de armazenamento externo que você deve integrar, dos modos de acesso compatíveis e do provisionamento de volume dinâmico.

O GKE na AWS implanta automaticamente o driver CSI do Amazon Elastic Block Store (EBS) e um StorageClass padrão que faz backup de PersistentVolumeClaims usando os volumes EBS e um StorageClasses para outros tipos de volumes de EBS. Também é possível instalar outros drivers CSI e StorageClasses personalizados. Se você tem um volume do EBS que quer importar no GKE na AWS, pode criar um PersistentVolume a partir dele.

Implantar suas cargas de trabalho

Depois de provisionar o cluster do GKE Enterprise e migrar os dados, você vai criar e implantar suas cargas de trabalho. Você tem diferentes opções, desde implantações manuais a totalmente automatizadas.

Se for necessário usar operadores para implantar cargas de trabalho que usam esse método de implantação no ambiente do OpenShift, instale o operador antes de implantar a carga de trabalho. É possível verificar a disponibilidade dos operadores necessários nas seguintes fontes:

Implantar manualmente

Se você estiver implantando manualmente suas cargas de trabalho no ambiente do OpenShift, poderá adaptar esse processo de implantação manual ao novo ambiente do GKE Enterprise. Por exemplo, é possível transferir manualmente os manifestos dos recursos do OpenShift que você avaliou em cargas de trabalho, requisitos e dependências para os manifestos de recursos correspondentes do GKE Enterprise.

A tabela a seguir estende a tabela na seção cargas de trabalho, requisitos e dependências deste documento e adiciona informações sobre os recursos do GKE Enterprise de destino em que você pode usá-los.

Manifesto do recurso do OpenShift de origem Especificações e parâmetros mais importantes Manifesto do recurso do GKE Enterprise de destino
Implantação, DeploymentConfig, StatefulSet, Job, cron job Imagem e repositório do contêiner, porta do contêiner, número de réplicas do pod, ConfigMaps, Secrets, PersistentVolumeClaims, solicitações e limites de recursos, estratégia de atualização, nome do serviço StatefulSet e programação do cron job Implantação, StatefulSet, Job, cron job
ImageStream Imagem de contêiner, política de extração de imagem, repositório de imagens de contêiner Implantação
Escalonador automático de pod horizontal Critérios de escalonamento automático Escalonador automático de pod horizontal
Serviço Nome do host usado para se conectar ao aplicativo de dentro do cluster, endereço IP e porta em que o serviço está exposto, endpoints criados para recursos externos Serviço
Rota Nome do host e caminho do recurso usados para se conectar ao aplicativo de fora do cluster e às regras de roteamento Entrada

Projetar e implementar um processo de implantação automatizado

Para criar e implantar automaticamente suas cargas de trabalho, crie e implemente processos de compilação e implantação, ou adapte os atuais para oferecer suporte ao novo ambiente. Se você precisar implantar cargas de trabalho em um ambiente híbrido, os processos de implantação precisarão ser compatíveis com o GKE no Google Cloud e no GKE no VMware.

Para implementar os processos de compilação e implantação, use o Cloud Build. Se quiser automatizar os processos de compilação e implantação, poderá configurar o gatilho de compilação ou os gatilhos de aplicativos do GitHub, ou definir implantações automatizadas do Console do Google Cloud. Se estiver usando restrições do controlador de políticas, verifique os descritores do Kubernetes e do GKE Enterprise com relação às políticas nos jobs do Cloud Build para fornecer feedback aos desenvolvedores.

Caso seja necessário executar jobs de compilação ou armazenar o código-fonte no local, use o GitLab. Ele oferece repositórios de código-fonte, uma plataforma de colaboração, recursos de CI/CD e um registro de imagem de contêiner. É possível implantar o GitLab nos clusters do GKE Enterprise diretamente do Cloud Marketplace ou usar uma das outras opções de instalação disponíveis.

Se estiver usando um dos recursos do OpenShift para criar ou implantar automaticamente as cargas de trabalho, poderá adotar uma das seguintes estratégias, com base no seu processo atual:

  • Pipelines do Jenkins. Se estiver usando pipelines do Jenkins para automatizar o processo de compilação e implantação, poderá fazer a portabilidade do pipeline para o Cloud Build, usar o ambiente atual do Jenkins ou implantar o Jenkins no Google Cloud.
  • Compilações e implantações a partir de um Dockerfile e os artefatos necessários. Use o Cloud Build para criar imagens de contêiner com um Dockerfile ou um arquivo de configuração de compilação. Use o GitLab para executar suas versões em um cluster local.
  • Compilações de origem para imagem. No Cloud Build, é preciso implementar uma etapa preliminar para criar os artefatos exigidos pela imagem de contêiner resultante. Se o job da origem para imagem criar um aplicativo Python e produzir uma imagem de contêiner, será necessário configurar uma etapa de compilação personalizada para criar o aplicativo Python e então criar a imagem do contêiner. Essa abordagem também requer o fornecimento de um Dockerfile. Se não quiser fornecer um, use o Cloud Native Buildpacks ou o Jib para aplicativos Java.
  • Compilações personalizadas. É possível criar builders personalizados do Cloud Build, como está fazendo agora no OpenShift. Se os builders personalizados não estiverem usando nenhum recurso específico do OpenShift, você poderá usá-los da forma como estão no Cloud Build.

Independentemente da abordagem escolhida para criar as imagens de contêiner, é necessário armazená-las em um repositório de imagens de contêiner. Você tem as seguintes opções:

Independentemente de sua escolha para armazenar imagens de contêiner, é necessário provisionar e configurar as credenciais para que seus clusters acessem o repositório de imagens de contêiner.

Se precisar enviar notificações sobre o status das suas compilações e das imagens de contêiner para usuários ou serviços de terceiros, use o Cloud Functions para responder a eventos produzidos pelo Cloud Build e Container Registry.

Resumo do mapeamento de recursos do OpenShift para o GKE Enterprise

A tabela a seguir é um resumo de como mapear os recursos do GKE Enterprise para os usados no OpenShift.

OpenShift GKE Enterprise
Projetos do OpenShift
  • Namespaces do Kubernetes gerenciados centralmente pelo Config Sync
  • Autorização RBAC do Kubernetes gerenciada centralmente pelo Config Sync
  • Cotas de recursos do Kubernetes gerenciadas centralmente pelo Config Sync
SDN do OpenShift e isolamento de rede
  • Políticas de segurança de rede do Calico gerenciadas centralmente pelo Config Sync
Restrições de contexto de segurança do OpenShift
  • Restrições do Controlador de Políticas
Pipelines do OpenShift
  • Cloud Build
  • Integração do Jenkins usando o plug-in do Jenkins do Google Cloud
  • GitLab
Origem para imagem do OpenShift
  • Cloud Native Buildpacks
  • Jib
Integração de identidade
  • Cloud Identity
  • Google Cloud Directory Sync
  • Integração do OIDC no GKE no VMware

Como otimizar o ambiente

A otimização é a última fase da migração. Nesta fase, você torna seu ambiente mais eficiente do que antes. Além disso, é nela que você executa várias iterações de um loop repetível até que o ambiente atenda aos requisitos de otimização. Estas são as etapas do loop repetível:

  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.

As seções a seguir baseiam-se na Migração para o Google Cloud: como otimizar seu ambiente.

Avaliar o ambiente, as equipes e o ciclo de otimização atuais

Embora a primeira avaliação esteja centrada na migração do seu ambiente para o GKE Enterprise, essa avaliação é personalizada para a fase de otimização.

Estabelecer seus requisitos de otimização

Com relação aos requisitos de otimização do GKE no Google Cloud, revise os requisitos de otimização estabelecidos em Como otimizar seu ambiente.

Revise os seguintes requisitos de otimização para seu ambiente do GKE Enterprise:

Concluir a otimização

Depois de preencher a lista de requisitos de otimização, conclua as demais atividades da fase de otimização em Migração para o Google Cloud: como otimizar seu ambiente.

Como encontrar ajuda

O Google Cloud oferece várias opções e recursos para você encontrar a ajuda e o suporte necessários para usar os serviços do Google Cloud da melhor maneira possível:

Há mais recursos para ajudar a migrar cargas de trabalho para o Google Cloud no Centro de migração do Google Cloud.

Para mais informações sobre esses recursos, consulte a seção Como encontrar ajuda em Migração para o Google Cloud: primeiros passos.

A seguir