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ê esteja familiarizado com o Kubernetes e Google Cloud, e que tenha algum conhecimento de ambientes de execução sem servidor na nuvem como Cloud Run, funções do Cloud Run ou AWS Lambda.

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

OfertasGoogle Cloud do mais gerenciado ao menos gerenciado.

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 usuários da infraestrutura de computação subjacente.

  • Ambientes de execução menos gerenciados:

    • O GKE Standard, otimizado para cargas de trabalho empresariais e que oferece escalonabilidade de cluster único de até 65.000 nós.
    • O Compute Engine, que inclui a família A3 de máquinas virtuais otimizadas 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 sustentam os 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 de plataforma, que pode ser personalizada para atender aos 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

Esta seção oferece uma visão geral dos recursos do Cloud Run e do GKE Autopilot. O Cloud Run e o Autopilot do GKE são integrados de maneira eficiente no Google Cloud. Portanto, há muita semelhança entre os dois. As duas plataformas oferecem suporte a várias opções de balanceamento de carga com os serviços de balanceamento de carga altamente confiáveis e escalonáveis do Google. Os dois também oferecem suporte a redes VPC, Identity-Aware Proxy (IAP) e Google Cloud Armor para quando uma rede privada mais granular é necessária. 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êineres, o Cloud Run e o Autopilot do GKE são compatíveis com serviços que compõem o ecossistema de contêineres Google Cloud . Esses serviços incluem o Cloud Build, Artifact Registry, autorização binária e a entrega contínua com o Cloud Deploy, para ajudar a garantir que seus aplicativos sejam implantados na produção com segurança e confiabilidade. Isso significa que você e suas equipes são responsáveis pelas decisões de build e implantação.

Devido à semelhança entre as duas plataformas, talvez seja interessante aproveitar os pontos fortes de cada uma adotando uma abordagem flexível para a implantação de 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ódigo que responde a solicitações da Web.
  • Jobs do Cloud Run: para código que executa uma ou mais tarefas em segundo plano e é encerrado quando o trabalho é concluído.

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

O Cloud Run também permite implantar código de aplicativo das seguintes origens:

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

O Cloud Run incorpora uma capacidade de build e implantação que oferece suporte ao FaaS e à capacidade de criar do código-fonte, além da capacidade de runtime 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 configuração personalizada.

Autopilot do GKE

O GKE Autopilot é 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 gerenciamento da infraestrutura. Ao usar o Autopilot, o Google gerencia os principais aspectos da configuração do cluster, incluindo provisionamento e escalonamento de nós, postura de segurança padrão e outras configurações pré-configuradas. Com o Autopilot gerenciando recursos de nós, você paga apenas pelos recursos que são solicitados pelas cargas de trabalho. O Autopilot monitora e otimiza continuamente o provisionamento de recursos de infraestrutura para garantir a melhor adequação, além de oferecer um SLA para suas cargas de trabalho.

O Autopilot do GKE oferece suporte a cargas de trabalho que talvez não sejam 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 sua carga de trabalho forem adequadas para uma plataforma gerenciada, o ambiente de execução sem servidor do Cloud Run será 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 o ambiente sem servidor como seu ambiente de execução de destino. Embora o Kubernetes ofereça a abstração poderosa de uma plataforma aberta, usá-lo adiciona complexidade. Se você não precisa do Kubernetes, recomendamos que considere se o aplicativo é adequado para o ambiente sem servidor. Se houver critérios que tornem sua carga de trabalho menos adequada para o serverless, recomendamos usar o 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 ambiente sem servidor. Devido à semelhança entre o Autopilot e o Cloud Run, descrita 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 saber mais sobre as opções de migração, 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, você precisa 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:

  • Controle e capacidade de configuração: granularidade de controle do ambiente de execução.
  • Gerenciamento e roteamento de tráfego de rede: capacidade de configuração de interações na rede.
  • Escalonabilidade horizontal e vertical: suporte para capacidade de crescimento e redução dinâmicos.
  • Suporte a aplicativos com estado: recursos para armazenar estado persistente.
  • Arquitetura da CPU: compatibilidade com 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 uso da API do Kubernetes.
  • RBAC complexo para multilocação: suporte para compartilhamento de recursos agrupados.
  • Tempo máximo de espera 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 GKE Autopilot oferece um controle mais granular do ambiente de execução para suas cargas de trabalho. No contexto de um pod, o Kubernetes oferece muitos componentes essenciais configuráveis que podem ser ajustados 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, manipuladores personalizados para eventos do ciclo de vida do contêiner, e compartilhamento de namespace de processo entre vários contêineres.

O Cloud Run oferece suporte direto a um subconjunto da superfície da API de pods do Kubernetes, descrita 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 seu aplicativo.

O contrato de contêiner para o ambiente de execução do Cloud Run é relativamente simples e adequado para a maioria das cargas de trabalho de serviç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 refinado sobre o ambiente de execução, o Autopilot poderá ser mais adequado.

Se você quiser reduzir o tempo gasto na configuração e na administração, escolha o Cloud Run como ambiente de execução. O Cloud Run tem menos opções de configuração do que o Autopilot. Por isso, ele pode ajudar você a maximizar a produtividade do desenvolvedor e reduzir o overhead operacional.

Gerenciamento e roteamento de tráfego de rede

O Cloud Run e o Autopilot do GKE se integram ao Cloud Load Balancing do Google. No entanto, o GKE Autopilot também oferece um conjunto rico e poderoso de primitivos para configurar o ambiente de rede para comunicações de serviço para serviço. 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ço 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 controle avançado sobre como o tráfego é roteado para dentro e entre os serviços no cluster.

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 a gerenciar e controlar as interações entre serviços.

Escalonabilidade horizontal e vertical

O Cloud Run e o GKE Autopilot oferecem suporte ao 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 preciso. Para uma carga de trabalho típica, o Cloud Run geralmente pode escalonar horizontalmente mais rápido 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 Serverless Compute?" mostra o escalonamento do Cloud Run 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 adicional), o Autopilot permite provisionar capacidade extra de computação.

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 oferece suporte ao escalonamento vertical para variar dinamicamente a quantidade de poder de processamento disponível sem aumentar o número de instâncias em execução do aplicativo.

O Cloud Run pode reduzir automaticamente seus aplicativos a zero réplicas enquanto 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 seus aplicativos podem ser escalonados para zero, há várias etapas de otimização que você pode seguir para minimizar o tempo entre a chegada de uma solicitação e o momento em que seu aplicativo está funcionando e pode processar a solicitação.

Suporte para aplicativos com estado

O Autopilot oferece suporte completo a volumes do Kubernetes, com o apoio de discos permanentes que permitem executar uma ampla variedade de implantações com estado, incluindo bancos de dados autogerenciados. Com o Cloud Run e o Autopilot do GKE, é possível se conectar a outros serviços como buckets do Filestore e do Cloud Storage. Os dois também incluem a capacidade de montar buckets de armazenamento 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 adequado 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 efêmero e o uso de memória do aplicativo e do contêiner contribuem para o esgotamento do 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 reagendado, sujeito a restrições configuradas com orçamentos de interrupção de pods (PDBs). 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 relevante 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 da CPU

Todas as plataformas de computação 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 com suporte da arquitetura Arm. Se a carga de trabalho exigir a arquitetura do Arm, use o Autopilot.

Transferência de acelerador

O Autopilot aceita o uso de GPUs e o uso de TPUs, incluindo a capacidade de consumir recursos reservados. O Cloud Run aceita o 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 suas 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 Helm).
  3. Os requisitos de suporte de um criador de conteúdo 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 multitenancy particularmente complexos, use o Autopilot para aproveitar o controle de acesso baseado em papéis (RBAC) do Kubernetes. Para uma opção mais simples, use os recursos de segurança e segregação integrados ao Cloud Run.

Considerações organizacionais

Confira algumas 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: conjuntos de 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

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

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

  • 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 à orientação estratégica. No entanto, se as exceções forem usadas em excesso, isso poderá resultar em um portfólio de tecnologia disparatado.
  • Reconsidere a estratégia. No entanto, isso pode resultar em sobrecarga de política que pode impedir ou bloquear o progresso.

Como aproveitar o ecossistema do Kubernetes

Como parte da estratégia técnica abrangente descrita anteriormente, as organizações ou equipes podem decidir selecionar o Kubernetes como plataforma de escolha devido ao ecossistema significativo e crescente. Essa escolha é diferente da seleção do 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 sólidos. Aproveitar o ecossistema do Kubernetes pode acelerar o desenvolvimento e reduzir o tempo de lançamento.

Ferramentas internas atuais

Em alguns casos, pode ser vantajoso usar ecossistemas de ferramentas atuais na 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 o ArgoCD, ferramentas de segurança e política como o Gatekeeper e gerenciamento de pacotes como o 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 prazo de implementação para um ambiente de destino alternativo.

Perfis da equipe de desenvolvimento

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

Para uma equipe em crescimento, a capacidade de contratação pode influenciar a escolha de plataforma de 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 outros funcionários operacionais. A capacidade das equipes operacionais de oferecer suporte eficaz ao ambiente de produção é crucial do ponto de vista da confiabilidade. Também é fundamental que as equipes operacionais ofereçam suporte a ambientes de pré-produção para garantir que a velocidade do desenvolvedor não seja impedida por tempo de 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 gerenciar upgrades do Kubernetes Autopilot. Embora os upgrades sejam automáticos, a equipe operacional normalmente os monitora de perto para garantir o mínimo de interrupções nas suas cargas de trabalho. Algumas organizações optam por fazer upgrade manual das versões do plano de controle. O GKE Enterprise também inclui recursos para 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 nem upgrades do plano de controle. Ao usar o Cloud Run, é possível simplificar os processos operacionais. Ao selecionar um único ambiente de execução, você pode simplificar ainda mais os processos de operações. Se você optar por usar vários ambientes de execução, verifique se a equipe tem capacidade, recursos e interesse para oferecer suporte a esses ambientes.

Seleção

Para iniciar o processo de seleção, converse com as várias partes interessadas. Para cada aplicativo, reúna um grupo de trabalho com desenvolvedores, funcionários operacionais, representantes de qualquer grupo central de governança de tecnologia, usuários e consumidores internos de aplicativos, equipes de segurança e otimização financeira da nuvem e outras funções ou grupos relevantes na sua organização. Você pode enviar uma pesquisa para coletar informações sobre as características das inscrições e compartilhar os resultados antes da sessão. Recomendamos que você selecione um pequeno grupo de trabalho que inclua apenas os stakeholders necessários. Nem todos os representantes são necessários para todas as sessões de trabalho.

Também pode ser útil incluir representantes de outras equipes ou grupos com 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 possíveis.

Recomendamos que você agende um check-in 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: