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ê já conhece o Kubernetes e o Google Cloude que você tem algum conhecimento de ambientes de execução sem servidor na nuvem, como o Cloud Run, as funções do Cloud Run ou o AWS Lambda.

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

Google Cloud ofertas da mais gerenciada para a menos gerenciada.

O diagrama mostra estes elementos:

  • A maioria dos ambientes de execução gerenciados (o foco deste guia):

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

  • Ambientes de execução com a menor quantidade de gerenciamento:

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

    Essas opções exigem algum nível de gerenciamento de infraestrutura no nível do usuário, como as máquinas virtuais (VMs) que são a base 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 oferta de plataforma principal, 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

Esta seção apresenta uma visão geral dos recursos do Cloud Run e do Autopilot do GKE. O Cloud Run e o Autopilot do GKE são integrados ao Google Cloud. Por isso, há muitas semelhanças entre os dois. Ambas as 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. Eles também oferecem suporte a redes VPC, proxy Aware de identidade (IAP, na sigla em inglês) e Google Cloud Armor para quando uma rede privada mais granular é um requisito. Ambas as plataformas cobram apenas pelos recursos exatos que você usa nos seus apps.

Do ponto de vista da entrega de software, como ambientes de execução de contêineres, o Cloud Run e o GKE Autopilot são compatíveis com os 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 garantir que seus aplicativos sejam implantados de forma segura e confiável na produção. 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, você pode aproveitar os pontos fortes de cada uma delas adotando uma abordagem flexível para implantar seus 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 seus 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ódigo que executa uma ou mais tarefas em segundo plano e sai 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 a adoção de práticas recomendadas e permitir que os desenvolvedores se concentrem no código.

O Cloud Run também oferece suporte à implantação do código do aplicativo das seguintes fontes:

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

O Cloud Run incorpora um recurso de build e implantação que oferece suporte a FaaS e à capacidade de criar a partir da origem, além do recurso de tempo de execução de contêiner pré-criado. Quando você usa o Cloud Run dessa maneira, 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 padrão e recomendado para clusters no GKE. O Autopilot permite executar aplicativos no Kubernetes sem a sobrecarga de gerenciamento de infraestrutura. Quando você usa o Autopilot, o Google gerencia os principais aspectos subjacentes da configuração do cluster, incluindo provisionamento e dimensionamento de nós, postura de segurança padrão e outras configurações predefinidas. Com o Autopilot gerenciando os recursos de nó, você paga apenas pelos recursos que são 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 oferece suporte a cargas de trabalho que podem não ser adequadas para o Cloud Run. Por exemplo, o Autopilot do GKE geralmente oferece suporte a 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á o 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 você considere o ambiente de execução sem servidor como seu ambiente de execução de destino. Embora o Kubernetes ofereça a poderosa abstração de uma plataforma aberta, o uso dele aumenta a complexidade. Se você não precisar do Kubernetes, recomendamos que considere se o aplicativo é adequado para a opção sem servidor. Se houver critérios que tornem sua carga de trabalho menos adequada para a tecnologia serverless, recomendamos usar o Autopilot.

As seções a seguir fornecem mais detalhes sobre alguns dos critérios que podem ajudar a responder a essas perguntas, principalmente a questão de saber se a carga de trabalho é adequada para a computação sem servidor. Considerando a 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á nenhum problema técnico ou outro. 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, é preciso considerar considerações técnicas e organizacionais. Considerações técnicas são características do seu 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 configurável: granularidade de controle do ambiente de execução.
  • Gerenciamento e roteamento de tráfego de rede: capacidade de configuração de interações pela rede.
  • Escalonamento horizontal e vertical: suporte para o crescimento dinâmico e redução da capacidade.
  • Suporte a aplicativos com estado: recursos para armazenar estados persistentes.
  • Arquitetura da CPU: oferece suporte a diferentes tipos de CPU.
  • Deslocamento de aceleração (GPUs e TPUs): capacidade de transferir a computação para hardware dedicado.
  • Memória alta, CPU e outras capacidades de 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: oferece suporte ao compartilhamento de recursos agrupados.
  • Tempo limite máximo 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 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 API Pod do Kubernetes, que é descrito no YAML de referência do objeto de serviço do Cloud Run e no YAML de referência do objeto de job do Cloud Run. Esses guias de referência podem ajudar você a avaliar as duas plataformas com seus requisitos de aplicativo.

O contrato de contêiner para o ambiente de execução do Cloud Run é relativamente simples e atende à 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 grau maior de controle 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, então ele pode ajudar 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 balanceamento de carga do Google Cloud. No entanto, o GKE Autopilot também oferece um conjunto rico e poderoso de primitivas 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 porta e descoberta de serviço DNS integrada no cluster. O Autopilot do GKE também oferece suporte à API Gateway (link em inglês), que é altamente configurável e flexível. Essa funcionalidade oferece um controle poderoso sobre a forma como o tráfego é roteado para 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 que têm padrões complexos de interdependência. Nesses casos, as opções de configuração de rede do Autopilot podem ajudar a gerenciar e controlar as interações entre os serviços.

Escalonabilidade horizontal e vertical

O Cloud Run e o Autopilot do GKE oferecem suporte à escala horizontal manual e automática para serviços e jobs. O escalonamento horizontal aumenta a capacidade de processamento quando necessário e remove essa capacidade quando não é necessária. Para uma carga de trabalho típica, o Cloud Run geralmente pode ser escalonar horizontalmente mais rapidamente do que o Autopilot do GKE para responder a picos no número de solicitações por segundo. Como exemplo, a demonstração em vídeo "What's New in Serverless Compute?" mostra a escalação 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 extra), o Autopilot permite que você provisione capacidade de computação extra.

Se o aplicativo não puder ser dimensionado 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 dimensionamento 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 escalonar automaticamente seus aplicativos para zero de réplicas enquanto eles não estão sendo usados, o que é útil para determinados casos de uso que têm foco especial na otimização de custos. Devido às características de como os aplicativos podem ser dimensionados para zero, há várias etapas de otimização que podem ser realizadas para minimizar o tempo entre a chegada de uma solicitação e o momento em que o aplicativo está ativo e pode processar a solicitação.

Suporte a aplicativos com estado

O Autopilot oferece suporte completo ao Kubernetes Volume, com o suporte de discos persistentes que permitem executar uma ampla gama 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 os buckets do Filestore e do Cloud Storage. Eles 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 uma boa opção para aplicativos que exigem um sistema de arquivos local persistente. 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 usando um volume dedicado na memória com um limite de tamanho.

Um serviço ou contêiner de job do Cloud Run tem um tempo limite máximo de tarefa. Um contêiner em execução em um pod em um cluster do Autopilot pode ser reprogramado, sujeito a qualquer restrição configurada com orçamentos de interrupção de pod (PDBs, na sigla em inglês). No entanto, os pods podem ser executados por até sete dias quando são protegidos contra expulsão causada por upgrades automáticos de nó ou eventos de redução de escala. 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 da 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 oferece suporte a processadores de arquitetura Arm, mas o Autopilot oferece suporte a nós gerenciados com arquitetura Arm. Se a carga de trabalho exigir a arquitetura Arm, será necessário usar o Autopilot.

Desativação do acelerador

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

Requisitos de alta memória, CPU e outros recursos

Em comparação com os limites de solicitação de recursos do Autopilot do GKE, 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 ser aplicados ou podem ter valores permitidos mais altos.

Dependência explícita no Kubernetes

Alguns aplicativos, bibliotecas ou frameworks podem ter uma dependência explícita no Kubernetes. A dependência do Kubernetes pode ser o resultado de uma das seguintes situações:

  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 oferece suporte ao Kubernetes.

RBAC complexo para multilocação

Se a sua organização tiver estruturas organizacionais ou requisitos de multitenência 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 a seguir algumas considerações organizacionais que vão influenciar a escolha do 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 dos desenvolvedores.
  • Suporte operacional: os recursos e o 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 tem um acordo para padronizar onde possível em sem servidor ou Kubernetes, esse acordo pode influenciar ou até determinar 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:

  • 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.
  • Registrar a carga de trabalho como uma exceção à direção estratégica. No entanto, se as exceções forem usadas em excesso, isso pode resultar em um portfólio de tecnologia desigual.
  • 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 ampla descrita anteriormente, as organizações ou equipes podem decidir selecionar o Kubernetes como a plataforma de escolha devido ao ecosistema significativo e em crescimento. Essa escolha é diferente de selecionar o Kubernetes devido a dependências técnicas do aplicativo, conforme descrito na seção anterior Dependência explícita no Kubernetes. A consideração de usar o ecossistema do Kubernetes enfatiza uma comunidade ativa, ferramentas de terceiros ricas e padrões e portabilidade fortes. Aproveitar o ecossistema do Kubernetes pode acelerar a velocidade de desenvolvimento e reduzir o tempo de lançamento.

Ferramentas internas

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

Perfis de equipes de desenvolvimento

Uma equipe de aplicativo ou carga 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 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 da organização. Em alguns mercados, as habilidades do Kubernetes podem ser escassas e, portanto, exigem um prêmio de contratação. A escolha de 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 e de outros funcionários operacionais. Os recursos das equipes operacionais para oferecer suporte eficaz ao ambiente de produção são cruciais 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 prejudicada por inatividade, dependência de processos manuais ou mecanismos de implantação desajeitados.

Se você usa o Kubernetes, uma equipe central de operações ou de engenharia de plataforma pode gerenciar upgrades do Autopilot Kubernetes. Embora os upgrades sejam automáticos, a equipe operacional normalmente os monitora de perto para garantir o mínimo de interrupções nas cargas de trabalho. Algumas organizações escolhem atualizar manualmente as versões do plano de controle. O GKE Enterprise também inclui recursos para simplificar e agilizar o gerenciamento de aplicativos em vários clusters.

Ao contrário do Autopilot, o Cloud Run não exige sobrecarga de gerenciamento contínua nem upgrades do plano de controle. Ao usar o Cloud Run, você pode simplificar seus processos operacionais. Ao selecionar um único ambiente de execução, você pode simplificar ainda mais seus processos de operações. Se você optar por usar vários ambientes de execução, é necessário garantir que a equipe tenha a capacidade, as habilidades e o 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 aplicação, monte um grupo de trabalho que consista de desenvolvedores, equipe operacional, representantes de qualquer grupo central de governança de tecnologia, usuários e consumidores de aplicativos internos, segurança, equipes de otimização financeira em nuvem e outras funções ou grupos na sua organização que possam ser relevantes. Você pode circular 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 cada sessão 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 a conversa e avaliar a adequação do seu aplicativo para cada uma das plataformas em potencial.

Recomendamos que você agende um check-in após alguns meses para confirmar ou rever 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 em nuvem

Outros colaboradores: