Selecionar um ambiente de execução do contêiner gerenciado

Last reviewed 2024-08-30 UTC

Este documento ajuda você a avaliar os requisitos do aplicativo e escolher entre o Cloud Run e o Autopilot do Google Kubernetes Engine (GKE), com base em considerações técnicas e organizacionais. Este documento é destinado a arquitetos de nuvem que precisam escolher um ambiente de execução de contêiner de destino do Google Cloud para as cargas de trabalho. Ele pressupõe que você conhece o Kubernetes e o Google Cloude que tem algum conhecimento sobre ambientes de execução sem servidor na nuvem, como o Cloud Run, as funções do Cloud Run ou o AWS Lambda.

Google Cloud oferece várias opções de ambiente de execução com uma variedade de recursos. O diagrama a seguir mostra a variedade de ofertas gerenciadas do Google Cloud:

As ofertas doGoogle Cloud , da mais gerenciada para a menos gerenciada.

O diagrama mostra estes elementos:

  • Ambientes de execução mais gerenciados (o foco deste guia):

    Essas opções são gerenciadas pelo Google, sem gerenciamento de infraestrutura de computação subjacente pelo usuário.

  • Ambientes de execução menos gerenciados:

    • GKE Standard, que é otimizado para cargas de trabalho empresariais e oferece escalonabilidade de cluster único de até 65.000 nós.
    • Compute Engine, que inclui a família de máquinas virtuais A3 otimizada para aceleradores para cargas de trabalho de machine learning (ML) e computação de alto desempenho (HPC).

    Essas opções exigem algum grau de gerenciamento de infraestrutura no nível do usuário, como as máquinas virtuais (VMs) que estão por trás dos recursos de computação. As VMs no GKE Standard são os nós do cluster do Kubernetes. As VMs no Compute Engine são a principal oferta da plataforma, que pode ser personalizada de acordo com seus requisitos.

Este guia ajuda você a escolher entre os ambientes de execução mais gerenciados, o Cloud Run e o Autopilot do GKE. Para uma visão mais ampla dos ambientes de execução do Google Cloud , consulte o guia Google Cloud Opções de hospedagem de aplicativos.

Visão geral dos ambientes

Nesta seção, apresentamos uma visão geral dos recursos do Cloud Run e do Autopilot do GKE. O Cloud Run e o Autopilot do GKE são totalmente integrados ao Google Cloud, então há muitas semelhanças entre os dois. As duas plataformas oferecem várias opções de balanceamento de carga com os serviços de balanceamento de carga altamente confiáveis e escalonáveis do Google. Ambos também são compatíveis com redes VPC, Identity-Aware Proxy (IAP) e Google Cloud Armor para quando uma rede privada mais granular é um requisito. As duas plataformas cobram apenas pelos recursos exatos que você usa nos aplicativos.

Do ponto de vista da entrega de software, como ambientes de execução de contêiner, o Cloud Run e o GKE Autopilot são compatíveis com serviços que compõem o ecossistema de contêineres do Google Cloud . Esses serviços incluem o Cloud Build, o Artifact Registry, a autorização binária e a entrega contínua com o Cloud Deploy, para ajudar a garantir que os aplicativos sejam implantados com segurança e confiabilidade na produção. Isso significa que você e suas equipes são responsáveis pelas decisões de criação e implantação.

Devido à semelhança entre as duas plataformas, talvez você queira aproveitar os pontos fortes de cada uma adotando uma abordagem flexível para o local de implantação dos aplicativos, conforme detalhado no guia Usar o GKE e o Cloud Run juntos. As seções a seguir descrevem aspectos exclusivos do Cloud Run e do Autopilot.

Cloud Run

O Cloud Run é uma plataforma de computação gerenciada sem servidor que permite executar aplicativos diretamente na infraestrutura escalonável do Google. O Cloud Run oferece automação e escalonamento para dois tipos principais de aplicativos:

  • Serviços do Cloud Run: para códigos que respondem a solicitações da Web.
  • Jobs do Cloud Run: para códigos que executam uma ou mais tarefas em segundo plano e são encerrados quando o trabalho é concluído.

Com esses dois modelos de implantação, o Cloud Run pode oferecer suporte a uma ampla gama de arquiteturas de aplicativos, além de permitir as práticas recomendadas e deixar que os desenvolvedores se concentrem no código.

O Cloud Run também é compatível com a implantação de código do aplicativo das seguintes fontes:

  • Funções leves individuais
  • Aplicativos completos do código-fonte
  • Aplicativos conteinerizados

O Cloud Run incorpora um recurso de criação e implantação que oferece suporte a FaaS e à capacidade de criar a partir da origem, além do recurso de ambiente de execução de contêiner pré-criado. Ao usar o Cloud Run dessa forma, as etapas de criação e implantação da imagem do contêiner do aplicativo que será executada são totalmente automáticas e não exigem uma configuração personalizada.

Autopilot do GKE

O Autopilot do GKE é o modo de operação de cluster padrão e recomendado no GKE. Com o Autopilot, é possível executar aplicativos no Kubernetes sem a sobrecarga de gerenciar a infraestrutura. Quando você usa o Autopilot, o Google gerencia os principais aspectos da configuração do cluster, incluindo o provisionamento e o escalonamento de nós, a postura de segurança padrão e outras configurações pré-definidas. Com o Autopilot gerenciando os recursos de nós, você paga apenas pelos recursos solicitados pelas cargas de trabalho. O Autopilot monitora e otimiza continuamente os recursos de infraestrutura para garantir o melhor ajuste, além de fornecer um SLA para suas cargas de trabalho.

O Autopilot do GKE é compatível com cargas de trabalho que podem não ser adequadas para o Cloud Run. Por exemplo, o GKE Autopilot geralmente é compatível com cargas de trabalho de longa duração ou com estado.

Escolher um ambiente de execução

Em geral, se as características da carga de trabalho forem adequadas para uma plataforma gerenciada, o ambiente de execução sem servidor do Cloud Run é ideal. O uso do Cloud Run pode resultar em menos infraestrutura para gerenciar, menos configuração autogerenciada e, portanto, menor sobrecarga operacional. A menos que você queira ou precise especificamente do Kubernetes, recomendamos que considere primeiro o ambiente sem servidor como seu ambiente de execução de destino. Embora o Kubernetes forneça a poderosa abstração de uma plataforma aberta, o uso dele adiciona complexidade. Se você não precisa do Kubernetes, recomendamos que considere se o aplicativo é adequado para a computação sem servidor. Se houver critérios que tornem sua carga de trabalho menos adequada para o modelo sem servidor, recomendamos o uso do Autopilot.

As seções a seguir fornecem mais detalhes sobre alguns dos critérios que podem ajudar você a responder a essas perguntas, principalmente se a carga de trabalho é adequada para o modelo sem servidor. Considerando as semelhanças entre o Autopilot e o Cloud Run descritas nas seções anteriores, a migração entre as plataformas é uma tarefa simples quando não há bloqueios técnicos ou de outro tipo. Para conhecer as opções de migração em mais detalhes, consulte Migrar do Cloud Run para o GKE e Migrar do Kubernetes para o Cloud Run.

Ao escolher um ambiente de execução para sua carga de trabalho, é preciso considerar aspectos técnicos e organizacionais. As considerações técnicas são características do aplicativo ou do ambiente de execução do Google Cloud. As considerações organizacionais são características não técnicas da sua organização ou equipe que podem influenciar sua decisão.

Considerações técnicas

Algumas das considerações técnicas que vão influenciar sua escolha de plataforma são as seguintes:

  • Controle e configurabilidade: granularidade do controle do ambiente de execução.
  • Gerenciamento e roteamento de tráfego de rede: configurabilidade de interações na rede.
  • Escalonabilidade horizontal e vertical: suporte para aumentar e reduzir a capacidade de forma dinâmica.
  • Suporte para aplicativos com estado: recursos para armazenar o estado persistente.
  • Arquitetura de CPU: suporte para diferentes tipos de CPU.
  • Descarregamento de acelerador (GPUs e TPUs): capacidade de descarregar a computação para hardware dedicado.
  • Alta capacidade de memória, CPU e outros recursos: nível de vários recursos consumidos.
  • Dependência explícita do Kubernetes: requisitos para o uso da API Kubernetes.
  • RBAC complexo para multilocação: suporte para compartilhamento de recursos em pool.
  • Tempo máximo de limite de tempo da tarefa do contêiner: duração da execução de aplicativos ou componentes de longa duração.

As seções a seguir detalham essas considerações técnicas para ajudar você a escolher um ambiente de execução.

Controle e capacidade de configuração

Em comparação com o Cloud Run, o Autopilot do GKE oferece um controle mais granular do ambiente de execução para suas cargas de trabalho. No contexto de um pod, o Kubernetes fornece muitas primitivas configuráveis que podem ser ajustadas para atender aos requisitos do aplicativo. As opções de configuração incluem nível de privilégio, parâmetros de qualidade de serviço, gerenciadores personalizados para eventos de ciclo de vida do contêiner e compartilhamento de namespace de processo entre vários contêineres.

O Cloud Run é compatível diretamente com um subconjunto da superfície da API Pod do Kubernetes, que é descrito no YAML de referência para o objeto de serviço do Cloud Run e no YAML de referência para o objeto de job do Cloud Run. Esses guias de referência podem ajudar você a avaliar as duas plataformas de acordo com os requisitos do aplicativo.

O contrato de contêiner para o ambiente de execução do Cloud Run é relativamente simples e se adapta à maioria das cargas de trabalho de exibição. No entanto, o contrato especifica alguns requisitos que precisam ser atendidos. Se o aplicativo ou as dependências dele não atenderem a esses requisitos ou se você precisar de um controle mais preciso sobre o ambiente de execução, o Autopilot pode ser mais adequado.

Se você quiser reduzir o tempo gasto com configuração e administração, escolha o Cloud Run como seu ambiente de execução. O Cloud Run tem menos opções de configuração do que o Autopilot, o que ajuda a maximizar a produtividade do desenvolvedor e reduzir a sobrecarga operacional.

Gerenciamento e roteamento de tráfego de rede

O Cloud Run e o Autopilot do GKE se integram ao Google Cloud Load Balancing. No entanto, o GKE Autopilot também oferece um conjunto avançado e eficiente de primitivos para configurar o ambiente de rede para comunicações entre serviços. As opções de configuração incluem permissões granulares e segregação na camada de rede usando namespaces e políticas de rede, remapeamento de portas e descoberta de serviços de DNS integrada no cluster. O GKE Autopilot também é compatível com a API Gateway, que é altamente configurável e flexível. Essa funcionalidade oferece um controle avançado sobre como o tráfego é roteado para os serviços no cluster e entre eles.

Como o Autopilot é altamente configurável, ele pode ser a melhor opção se você tiver vários serviços com um alto grau de codependência de rede ou requisitos complexos sobre como o tráfego é roteado entre os componentes do aplicativo. Um exemplo desse padrão é um aplicativo distribuído que é decomposto em vários microsserviços com padrões complexos de interdependência. Nesses cenários, as opções de configuração de rede do Autopilot podem ajudar você a gerenciar e controlar as interações entre os serviços.

Escalonabilidade horizontal e vertical

O Cloud Run e o Autopilot do GKE são compatíveis com o escalonamento horizontal manual e automático para serviços e jobs. O escalonamento horizontal aumenta a capacidade de processamento quando necessário e a remove quando não é mais necessária. Para uma carga de trabalho típica, o Cloud Run geralmente pode ser escalonar horizontalmente com mais rapidez do que o Autopilot do GKE para responder a picos no número de solicitações por segundo. Por exemplo, a demonstração em vídeo "What's New in Computação sem servidor?" mostra o Cloud Run escalonando de zero para mais de 10.000 instâncias em aproximadamente 10 segundos. Para aumentar a velocidade do escalonamento horizontal no Kubernetes (com um custo extra), o Autopilot permite provisionar capacidade de computação extra.

Se o aplicativo não puder ser escalonado adicionando mais instâncias para aumentar o nível de recursos disponíveis, talvez ele seja mais adequado para o Autopilot. O Autopilot é compatível com o escalonamento vertical para variar dinamicamente a quantidade de capacidade de processamento disponível sem aumentar o número de instâncias em execução do aplicativo.

O Cloud Run pode reduzir automaticamente as réplicas dos aplicativos para zero enquanto eles não estão sendo usados, o que é útil para determinados casos de uso com foco especial na otimização de custos. Devido às características de como os aplicativos podem ser reduzidos a zero, há várias etapas de otimização que podem ser seguidas para minimizar o tempo entre a chegada de uma solicitação e o momento em que o aplicativo está em execução e pode processar a solicitação.

Suporte para aplicativos com estado

O Autopilot oferece suporte completo ao volume do Kubernetes, com o apoio de discos permanentes que permitem executar uma ampla variedade de implantações com estado, incluindo bancos de dados autogerenciados. O Cloud Run e o Autopilot do GKE permitem que você se conecte a outros serviços, como o Filestore e os buckets do Cloud Storage. Ambos também incluem a capacidade de montar buckets de repositório de objetos no sistema de arquivos com o Cloud Storage FUSE.

O Cloud Run usa um sistema de arquivos na memória, que pode não ser uma boa opção para aplicativos que exigem um sistema de arquivos local permanente. Além disso, o sistema de arquivos local na memória é compartilhado com a memória do aplicativo. Portanto, o sistema de arquivos temporário e o uso da memória do aplicativo e do contêiner contribuem para esgotar o limite de memória. É possível evitar esse problema se usar um volume na memória dedicado com um limite de tamanho.

Um contêiner de serviço ou job do Cloud Run tem um tempo limite de tarefa máximo. Um contêiner em execução em um pod em um cluster do Autopilot pode ser reprogramado, sujeito a todas as restrições configuradas com orçamentos de interrupção de pods (PDBs, na sigla em inglês). No entanto, os pods podem ser executados por até sete dias quando estão protegidos contra remoção causada por upgrades automáticos de nós ou eventos de redução de escala vertical. Normalmente, o tempo limite da tarefa é mais provável de ser uma consideração para cargas de trabalho em lote no Cloud Run. Para cargas de trabalho de longa duração e tarefas em lote que não podem ser concluídas dentro da duração máxima da tarefa, o Autopilot pode ser a melhor opção.

arquitetura de CPU

Todas as plataformas de computação do Google Cloud são compatíveis com a arquitetura de CPU x86. O Cloud Run não é compatível com processadores de arquitetura Arm, mas o Autopilot é compatível com nós gerenciados que têm suporte da arquitetura Arm. Se a carga de trabalho exigir a arquitetura Arm, use o Autopilot.

Descarga do acelerador

O Autopilot oferece suporte ao uso de GPUs e ao uso de TPUs, incluindo a capacidade de consumir recursos reservados. O Cloud Run oferece suporte ao uso de GPUs com algumas limitações.

Requisitos altos de memória, CPU e outros recursos

Em comparação com os limites de solicitação de recursos do GKE Autopilot, os recursos máximos de CPU e memória que podem ser consumidos por um único serviço ou job do Cloud Run (uma única instância) são limitados. Dependendo das características das cargas de trabalho, o Cloud Run pode ter outros limites que restringem os recursos disponíveis. Por exemplo, o tempo limite de inicialização e o número máximo de conexões de saída podem ser limitados com o Cloud Run. Com o Autopilot, alguns limites podem não se aplicar ou podem ter valores permitidos mais altos.

Dependência explícita do Kubernetes

Alguns aplicativos, bibliotecas ou frameworks podem ter uma dependência explícita do Kubernetes. A dependência do Kubernetes pode ser resultado de um dos seguintes:

  1. Os requisitos do aplicativo (por exemplo, o aplicativo chama APIs do Kubernetes ou usa recursos personalizados do Kubernetes).
  2. Os requisitos das ferramentas usadas para configurar ou implantar o aplicativo (como o Helm).
  3. Os requisitos de suporte de um criador ou fornecedor terceirizado.

Nesses cenários, o Autopilot é o ambiente de execução de destino, porque o Cloud Run não é compatível com o Kubernetes.

RBAC complexo para multilocação

Se a organização tiver estruturas organizacionais ou requisitos de multilocação particularmente complexos, use o Autopilot para aproveitar o controle de acesso baseado em papéis (RBAC, na sigla em inglês) do Kubernetes. Para uma opção mais simples, use os recursos de segurança e segregação integrados ao Cloud Run.

Considerações organizacionais

Veja a seguir algumas das considerações organizacionais que vão influenciar sua escolha de ambiente:

  • Estratégia técnica ampla: a direção técnica da sua organização.
  • Aproveitar o ecossistema do Kubernetes: interesse em aproveitar a comunidade de OSS.
  • Ferramentas internas atuais: uso de determinadas ferramentas.
  • Perfis da equipe de desenvolvimento: habilidades e experiência do desenvolvedor.
  • Suporte operacional: recursos e foco das equipes de operações.

As seções a seguir detalham essas considerações organizacionais para ajudar você a escolher um ambiente.

Estratégia técnica ampla

As organizações ou equipes podem ter estratégias acordadas para preferir determinadas tecnologias em detrimento de outras. Por exemplo, se uma equipe tiver um acordo para padronizar, sempre que possível, o uso de tecnologias sem servidor ou do Kubernetes, esse acordo poderá influenciar ou até mesmo ditar um ambiente de execução de destino.

Se uma determinada carga de trabalho não for adequada para o ambiente de execução especificado na estratégia, você poderá fazer uma ou mais das seguintes ações, com as ressalvas que as acompanham:

  • Refazer a arquitetura da carga de trabalho. No entanto, se a carga de trabalho não for adequada, isso poderá resultar em desempenho, custo, segurança ou outras características não ideais.
  • Registre a carga de trabalho como uma exceção à direção estratégica. No entanto, se as exceções forem usadas em excesso, isso poderá resultar em um portfólio de tecnologia discrepante.
  • Reconsidere a estratégia. No entanto, isso pode resultar em sobrecarga de políticas que pode impedir ou bloquear o progresso.

Como aproveitar o ecossistema do Kubernetes

Como parte da estratégia técnica ampla descrita anteriormente, as organizações ou equipes podem decidir selecionar o Kubernetes como a plataforma de escolha devido ao ecossistema significativo e crescente. Essa escolha é diferente de selecionar o Kubernetes devido a dependências técnicas de aplicativos, conforme descrito na seção anterior Dependência explícita do Kubernetes. A consideração de usar o ecossistema do Kubernetes enfatiza uma comunidade ativa, ferramentas avançadas de terceiros e padrões e portabilidade fortes. Aproveitar o ecossistema do Kubernetes pode acelerar o desenvolvimento e reduzir o tempo de lançamento no mercado.

Ferramentas internas atuais

Em alguns casos, pode ser vantajoso usar ecossistemas de ferramentas existentes na sua organização ou equipe (para qualquer um dos ambientes). Por exemplo, se você estiver usando o Kubernetes, poderá continuar usando ferramentas de implantação como ArgoCD, ferramentas de segurança e política como Gatekeeper e gerenciamento de pacotes como Helm. As ferramentas atuais podem incluir regras estabelecidas para automação de conformidade organizacional e outras funcionalidades que podem ser caras ou exigir um longo tempo de lead para serem implementadas em um ambiente de destino alternativo.

Perfis de equipes de desenvolvimento

Uma equipe de aplicativos ou cargas de trabalho pode ter experiência anterior com o Kubernetes, o que pode acelerar a velocidade e a capacidade da equipe de entregar no Autopilot. Pode levar algum tempo para que uma equipe se torne proficiente em um novo ambiente de execução. Dependendo do modelo operacional, isso pode reduzir a confiabilidade da plataforma durante o período de capacitação.

Para uma equipe em crescimento, a capacidade de contratação pode influenciar a escolha da plataforma por uma organização. Em alguns mercados, as habilidades do Kubernetes podem ser escassas e, portanto, exigir um prêmio de contratação. Escolher um ambiente como o Cloud Run pode ajudar a simplificar o processo de contratação e permitir um crescimento mais rápido da equipe dentro do seu orçamento.

Suporte operacional

Ao escolher um ambiente de execução, considere a experiência e as habilidades das equipes de SRE, DevOps e plataformas, além de outras equipes operacionais. As capacidades das equipes operacionais de dar suporte eficaz ao ambiente de produção são cruciais do ponto de vista da confiabilidade. Também é fundamental que as equipes operacionais possam oferecer suporte a ambientes de pré-produção para garantir que a velocidade do desenvolvedor não seja impedida por inatividade, dependência de processos manuais ou mecanismos de implantação complicados.

Se você usa o Kubernetes, uma equipe central de operações ou engenharia de plataforma pode lidar com upgrades do Autopilot do Kubernetes. Embora os upgrades sejam automáticos, a equipe operacional geralmente os monitora de perto para garantir o mínimo de interrupções nas cargas de trabalho. Algumas organizações optam por fazer upgrade manual das versões do plano de controle. O GKE também inclui recursos para otimizar e simplificar o gerenciamento de aplicativos em vários clusters.

Ao contrário do Autopilot, o Cloud Run não exige sobrecarga de gerenciamento contínuo ou upgrades do plano de controle. Ao usar o Cloud Run, é possível simplificar os processos de operações. Ao selecionar um único ambiente de execução, é possível simplificar ainda mais os processos de operações. Se você optar por usar vários ambientes de execução, precisará garantir que a equipe tenha capacidade, recursos e interesse para dar suporte a esses ambientes de execução.

Seleção

Para iniciar o processo de seleção, converse com as várias partes interessadas. Para cada aplicativo, monte um grupo de trabalho composto por desenvolvedores, equipe operacional, representantes de qualquer grupo central de governança de tecnologia, usuários e consumidores internos de aplicativos, segurança, equipes de otimização financeira da nuvem e outros papéis ou grupos na sua organização que possam ser relevantes. Você pode distribuir uma pesquisa de coleta de informações para reunir as características do aplicativo e compartilhar os resultados antes da sessão. Recomendamos que você selecione um pequeno grupo de trabalho que inclua apenas as partes interessadas necessárias. Talvez nem todos os representantes sejam necessários para todas as sessões de trabalho.

Também pode ser útil incluir representantes de outras equipes ou grupos que tenham experiência na criação e execução de aplicativos no Autopilot ou no Cloud Run, ou em ambos. Use as considerações técnicas e organizacionais deste documento para orientar sua conversa e avaliar a adequação do aplicativo para cada uma das plataformas em potencial.

Recomendamos que você agende uma verificação após alguns meses para confirmar ou revisar a decisão com base nos resultados da implantação do aplicativo no novo ambiente.

A seguir

Colaboradores

Autor: Henry Bell | Arquiteto de soluções do Cloud

Outros colaboradores: