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

Neste documento, ajudamos você a avaliar os requisitos do seu aplicativo e escolher entre o Cloud Run e o Google Kubernetes Engine (GKE) Autopilot, com base em considerações técnicas e organizacionais. Este documento é para arquitetos de nuvem que precisam escolher um Google Cloud ambiente de execução de contêiner de destino para suas cargas de trabalho. Ele pressupõe que você esteja familiarizado com o Kubernetes e o Google Cloude que tenha algum conhecimento de ambientes de execução sem servidor em 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 diversos recursos. O diagrama a seguir mostra a variedade de Google Cloud soluções gerenciadas:

Soluções de marcador de posição 4 da mais 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 usuário da infraestrutura de computação subjacente.

  • Ambientes de execução menos gerenciados:

    • GKE Standard, que é otimizado para cargas de trabalho empresariais e oferece escalonabilidade de cluster único para até 65.000 nós.
    • Compute Engine, que inclui a família de máquinas virtuais A3 (em inglês) 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) subjacentes aos 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 central da plataforma, que podem ser personalizadas para atender aos seus requisitos.

Este guia ajuda 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 Google Cloud ambientes de execução, consulte o guia Google Cloud Opções de hospedagem do aplicativo.

Visão geral dos ambientes

Nesta seção, você terá uma visão geral dos recursos do Cloud Run e do Autopilot do GKE. O Cloud Run e o Autopilot do GKE estão totalmente integrados ao Google Cloud, então há muita em comum entre eles. As duas plataformas são compatíveis com 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 são compatíveis com redes VPC, Identity-Aware Proxy (IAP) e Google Cloud Armor para quando uma rede privada mais granular é um requisito. Ambas as plataformas cobram apenas pelos recursos exatos usados nos aplicativos.

Do ponto de vista da entrega de software, como ambientes de execução de contêiner, o Cloud Run e o Autopilot do GKE têm o suporte dos serviços que compõem o Google Cloud ecossistema de contêineres. Esses serviços incluem Cloud Build, Artifact Registry, autorização binária e entrega contínua com o Cloud Deploy, para ajudar a garantir que seus aplicativos sejam implantados de maneira segura e confiável 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, convém aproveitar os pontos fortes de cada uma adotando uma abordagem flexível para a 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 fornece 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 sai quando o trabalho é concluído.

Com esses dois modelos de implantação, o Cloud Run é compatível com uma ampla variedade de arquiteturas de aplicativos, permitindo as práticas recomendadas e permitindo que os desenvolvedores se concentrem no código.

O Cloud Run também é compatível com a implantação do 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, junto com o recurso de ambiente 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 de cluster no GKE. Com o Autopilot, é possível executar aplicativos no Kubernetes sem a sobrecarga do gerenciamento da infraestrutura. Quando você usa 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 predefinidas. Com o gerenciamento de recursos do nó no Autopilot, você paga apenas pelos recursos solicitados pelas cargas de trabalho. O Autopilot monitora e otimiza continuamente os recursos da infraestrutura para garantir o melhor ajuste, além de fornecer um SLA para suas cargas de trabalho.

O Autopilot do GKE dá suporte a cargas de trabalho que talvez não sejam adequadas para o Cloud Run. Por exemplo, o GKE Autopilot 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 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 considerar o ambiente sem servidor primeiro como o ambiente de execução de destino. O Kubernetes fornece a abstração poderosa de uma plataforma aberta, mas usá-lo aumenta a complexidade. Se você não precisa do Kubernetes, recomendamos considerar se o aplicativo é adequado para a execução sem servidor. Se houver critérios que tornam sua carga de trabalho menos adequada para a execução sem servidor, recomendamos o uso do Autopilot.

As seções a seguir fornecem mais detalhes sobre alguns dos critérios que podem ajudar a responder a essas perguntas, especialmente a questão de se a carga de trabalho é adequada para ambientes 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á obstáculos técnicos ou de outros tipos. Para explorar 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 levar em conta considerações técnicas e organizacionais. As considerações técnicas são características do seu aplicativo ou do Google Cloud ambiente de execução. Considerações organizacionais são características não técnicas da organização ou equipe que podem influenciar sua decisão.

Considerações técnicas

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

  • Controle e configuração: granularidade de controle do ambiente de execução.
  • Gerenciamento e roteamento de tráfego de rede: configuração das interações na rede.
  • Escalonabilidade horizontal e vertical: suporte à capacidade de crescimento e redução dinâmicos.
  • Suporte para aplicativos com estado: recursos para armazenar o estado persistente.
  • Arquitetura de CPU: suporte a diferentes tipos de CPU.
  • Descarregamento do acelerador (GPUs e TPUs): capacidade de descarregar a computação para um hardware dedicado.
  • Memória alta, CPU e outras capacidades de recursos: nível de vários recursos consumidos.
  • Dependência explícita no Kubernetes: requisitos para o uso da API Kubernetes.
  • RBAC complexo para multilocação: suporte para compartilhamento de recursos em pool.
  • 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 GKE Autopilot fornece 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 seu 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 aceita diretamente um subconjunto da superfície da API Kubernetes Pod, descrita no YAML de referência para o objeto de serviço do Cloud Run e no YAML de referência para o objeto do job do Cloud Run. Estes guias de referência podem ajudar você a avaliar as duas plataformas 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 cumpridos. Se o aplicativo ou as dependências dele não atenderem a esses requisitos ou se você precisar de um maior grau de controle sobre o ambiente de execução, o Autopilot pode ser mais adequado.

Para reduzir o tempo gasto na configuração e na administração, escolha o Cloud Run como o 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 o overhead 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 avançado de primitivos para configurar o ambiente de rede para comunicações de serviço a 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ços DNS integrados no cluster. O Autopilot do GKE também é compatível com a API Gateway, altamente configurável e flexível. Essa funcionalidade fornece um controle poderoso sobre a maneira como o tráfego é roteado 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 os serviços.

Escalonabilidade horizontal e vertical

O Cloud Run e o GKE Autopilot oferecem suporte a escalonamento horizontal manual e automático para serviços e jobs. O escalonamento horizontal fornece maior capacidade de processamento quando necessário e remove essa capacidade quando ela não é necessária. Para uma carga de trabalho típica, o Cloud Run geralmente pode ser escalonado mais rapidamente do que o Autopilot do GKE para responder a picos no número de solicitações por segundo. Por exemplo, na demonstração em vídeo "O que há de novo na computação sem servidor?". mostra o escalonamento do Cloud Run de 0 para mais de 10.000 instâncias em aproximadamente 10 segundos. Para aumentar a velocidade do escalonamento horizontal no Kubernetes (por algum custo extra), o Autopilot permite provisionar capacidade extra de computação.

Se o aplicativo não puder escalonar adicionando mais instâncias para aumentar o nível de recursos disponíveis, ele pode ser uma opção melhor para o Autopilot. O Autopilot oferece suporte ao 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 escalonar automaticamente seus aplicativos para zero réplicas enquanto elas não estão sendo usadas, o que é útil para determinados casos de uso com um foco especial na otimização de custos. Devido às características de redução dos aplicativos 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á funcionando e pode processá-la.

Suporte a aplicativos com estado

O Autopilot oferece suporte completo ao volume do Kubernetes, com o suporte de discos permanentes que permitem executar uma ampla variedade de implantações com estado, incluindo bancos de dados autogerenciados. O Cloud Run e o GKE Autopilot permitem que você se conecte a outros serviços, como o Filestore e buckets 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, o que pode não ser adequado para aplicativos que exigem um sistema de arquivos local persistente. Além disso, o sistema de arquivos na memória local é compartilhado com a memória do aplicativo. Portanto, o sistema de arquivos temporário e o uso de memória do aplicativo e do contêiner contribuem para o esgotamento do limite de memória. Para evitar esse problema, use um volume dedicado na memória com um limite de tamanho.

Um serviço do Cloud Run ou um contêiner de job 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 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 do nó ou eventos de redução de escala. Normalmente, é mais provável que o tempo limite da tarefa seja 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 Google Cloud as plataformas de computação oferecem suporte à arquitetura de CPU x86. O Cloud Run não oferece suporte a processadores de arquitetura do ARM, mas o Autopilot oferece suporte a nós gerenciados apoiados pela arquitetura do ARM. Caso sua carga de trabalho exija a arquitetura Arm, será necessário usar o Autopilot.

Descarregamento do acelerador

O Autopilot é compatível com o uso de GPUs e de TPUs, incluindo a capacidade de consumir recursos reservados. O Cloud Run é compatível com 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 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 maiores.

Dependência explícita no 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, chamar APIs do Kubernetes ou usar 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 aceita Kubernetes.

RBAC complexo para multilocação

Se a organização tiver estruturas ou requisitos organizacionais particularmente complexos para multilocação, 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 influenciarão 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 OSS.
  • Ferramentas internas atuais: uso estabelecido de determinadas ferramentas.
  • Perfis da equipe de desenvolvimento: experiências e conjuntos de habilidades dos desenvolvedores.
  • 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.

ampla estratégia técnica

As organizações ou equipes podem ter acordado de estratégias para priorizar determinadas tecnologias em detrimento de outras. Por exemplo, se uma equipe tiver um acordo para padronizar sempre que possível no ambiente sem servidor ou no Kubernetes, esse contrato pode 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 ações a seguir, com as ressalvas:

  • Rearquitetar a 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 pode resultar em um portfólio tecnológico diferente.
  • Reconsidere a estratégia. No entanto, isso pode resultar em uma sobrecarga de política que pode impedir ou bloquear o progresso.

Como aproveitar o ecossistema do Kubernetes

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

Ferramentas internas atuais

Em alguns casos, pode ser vantajoso usar os ecossistemas de ferramentas atuais em 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 o ArgoCD, ferramentas de segurança e políticas como o Gatekeeper e o gerenciamento de pacotes como Helm. As ferramentas existentes 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 implementar em um ambiente de destino alternativo.

Perfis da equipe de desenvolvimento

Uma equipe de carga de trabalho ou aplicativo pode ter experiência anterior com o Kubernetes, o que pode acelerar a velocidade e a capacidade de entrega da equipe no Autopilot. Pode levar tempo para uma equipe se tornar proficiente com um novo ambiente de execução. Dependendo do modelo operacional, isso pode levar a uma menor confiabilidade da plataforma durante o período de qualificaçã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 no Kubernetes podem ser escassas e, portanto, comandam um aumento na contratação. Escolher um ambiente como o Cloud Run pode ajudar você a simplificar o processo de contratação e permitir um crescimento mais rápido da equipe dentro do orçamento.

Suporte operacional

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

Se você usa o Kubernetes, uma equipe de engenharia de plataforma ou operações centrais pode processar os upgrades do Kubernetes no Autopilot. Os upgrades são automáticos, mas a equipe operacional normalmente os monitora de perto para garantir interrupções mínimas nas 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 otimizar e simplificar o gerenciamento de aplicativos em vários clusters.

Ao contrário do Autopilot, o Cloud Run não exige sobrecarga contínua de gerenciamento 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, você simplifica ainda mais os processos operacionais. Se você usar vários ambientes de execução, precisará garantir que a equipe tenha a capacidade, os recursos e o interesse para oferecer suporte a eles.

Seleção

Para iniciar o processo de seleção, converse com as várias partes interessadas. Para cada aplicativo, monte um grupo de trabalho formado por desenvolvedores, funcionários operacionais, representantes de qualquer grupo de governança de tecnologia central, consumidores e usuários internos de aplicativos, segurança, equipes de otimização financeira na nuvem e outras funções ou grupos dentro da organização que possam ser relevantes. É possível 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. 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, 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 possíveis plataformas.

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: