Este documento ajuda a avaliar os requisitos da sua aplicação e a escolher entre o Cloud Run e o Google Kubernetes Engine (GKE) Autopilot, com base em considerações técnicas e organizacionais. Este documento destina-se a arquitetos de nuvem que precisam de escolher um ambiente de tempo de execução do contentor de destino para as respetivas cargas de trabalho. Google Cloud Parte do princípio de que tem familiaridade com o Kubernetes e Google Cloud, e que tem algum conhecimento de ambientes de tempo 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 tempo de execução com uma variedade de capacidades. O diagrama seguinte mostra o intervalo de ofertas geridas: Google Cloud
O diagrama mostra o seguinte:
Ambientes de tempo de execução mais geridos (o foco deste guia):
- Cloud Run, que inclui funções do Cloud Run.
- GKE Autopilot.
Estas opções são geridas pela Google, sem gestão de utilizadores da infraestrutura de computação subjacente.
Ambientes de tempo de execução menos geridos:
- GKE Standard, que está otimizado para cargas de trabalho empresariais e oferece escalabilidade de cluster único até 65 000 nós.
- Compute Engine, que inclui a família A3 de máquinas virtuais otimizadas para aceleradores para cargas de trabalho de aprendizagem automática (AA) e computação de elevado desempenho (HPC).
Estas opções requerem algum grau de gestão da infraestrutura ao nível do utilizador, como as máquinas virtuais (VMs) que suportam as capacidades 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 personalizar de acordo com os seus requisitos.
Este guia ajuda a escolher entre os ambientes de tempo de execução mais geridos, o Cloud Run e o GKE Autopilot. Para uma vista mais ampla dos Google Cloud ambientes de tempo de execução, consulte o guia Google Cloud Opções de alojamento de aplicações.
Vista geral dos ambientes
Esta secção oferece uma vista geral das capacidades do Cloud Run e do GKE Autopilot. O Cloud Run e o GKE Autopilot estão ambos estreitamente integrados no Google Cloud, pelo que existe muita comunidade entre os dois. Ambas as plataformas suportam várias opções de equilíbrio de carga com os serviços de equilíbrio de carga altamente fiáveis e escaláveis da Google. Ambos também suportam redes VPC, Identity-Aware Proxy (IAP), e Google Cloud Armor para quando uma rede privada mais detalhada é um requisito. Ambas as plataformas cobram apenas os recursos exatos que usa para as suas aplicações.
Do ponto de vista da entrega de software, como ambientes de tempo de execução de contentores, o Cloud Run e o GKE Autopilot são suportados por serviços que compõem o Google Cloud ecossistema de contentores. Estes serviços incluem o Cloud Build, Artifact Registry, Binary Authorization> e a entrega contínua com o Cloud Deploy, para ajudar a garantir que as suas aplicações são implementadas de forma segura e fiável na produção. Isto significa que as decisões de compilação e implementação são da sua responsabilidade e das suas equipas.
Devido à semelhança entre as duas plataformas, é recomendável tirar partido dos pontos fortes de cada uma adotando uma abordagem flexível quanto à implementação das suas aplicações, conforme detalhado no guia Use o GKE e o Cloud Run em conjunto. As secções seguintes descrevem aspetos únicos do Cloud Run e do Autopilot.
Cloud Run
O Cloud Run é uma plataforma de computação gerida sem servidor que lhe permite executar as suas aplicações diretamente na infraestrutura escalável da Google. O Cloud Run oferece automatização e escalabilidade para dois tipos principais de aplicações:
- Serviços do Cloud Run: Para código que responde a pedidos Web.
- Tarefas do Cloud Run: Para código que executa uma ou mais tarefas em segundo plano e, em seguida, termina quando o trabalho está concluído.
Com estes dois modelos de implementação, o Cloud Run pode suportar uma vasta gama de arquiteturas de aplicações, ao mesmo tempo que permite as práticas recomendadas e deixa os programadores focados no código.
O Cloud Run também suporta a implementação de código de aplicação a partir das seguintes origens:
- Funções individuais simples
- Aplicações completas a partir do código-fonte
- Aplicações contentorizadas
O Cloud Run incorpora uma capacidade de compilação e implementação que suporta FaaS e a capacidade de compilar a partir da origem, juntamente com a capacidade de tempo de execução de contentores pré-criados. Quando usa o Cloud Run desta forma, os passos de compilação e implementação da imagem do contentor da aplicação que vai ser executada são totalmente automáticos e não requerem nenhuma configuração personalizada da sua parte.
GKE Autopilot
O GKE Autopilot é o modo de funcionamento do cluster predefinido e recomendado no GKE. O Autopilot permite-lhe executar aplicações no Kubernetes sem a sobrecarga da gestão da infraestrutura. Quando usa o Autopilot, a Google gere os principais aspetos subjacentes da configuração do cluster, incluindo o aprovisionamento e o dimensionamento de nós, a postura de segurança predefinida e outras definições pré-configuradas. Com o Autopilot a gerir os recursos dos nós, paga apenas pelos recursos pedidos pelas suas cargas de trabalho. O Autopilot monitoriza e otimiza continuamente a atribuição de recursos da infraestrutura para garantir a melhor adequação, ao mesmo tempo que oferece um ANS para as suas cargas de trabalho.
O GKE Autopilot suporta cargas de trabalho que podem não ser adequadas para o Cloud Run. Por exemplo, o GKE Autopilot suporta normalmente cargas de trabalho de longa duração ou com estado.
Escolha um ambiente de execução
Em geral, se as caraterísticas da sua carga de trabalho forem adequadas para uma plataforma gerida, o ambiente de tempo de execução sem servidor do Cloud Run é ideal. A utilização do Cloud Run pode resultar numa menor infraestrutura para gerir, numa menor configuração autogerida e, por conseguinte, numa menor sobrecarga operacional. A menos que queira ou precise especificamente do Kubernetes, recomendamos que considere primeiro a opção sem servidor como o ambiente de tempo de execução de destino. Embora o Kubernetes ofereça a poderosa abstração de uma plataforma aberta, a sua utilização adiciona complexidade. Se não precisar do Kubernetes, recomendamos que considere se a sua aplicação é adequada para uma arquitetura sem servidor. Se existirem critérios que tornem a sua carga de trabalho menos adequada para a arquitetura sem servidor, recomendamos que use o Autopilot.
As secções seguintes fornecem mais detalhes sobre alguns dos critérios que podem ajudar a responder a estas perguntas, particularmente à questão de saber se a carga de trabalho é adequada para a arquitetura sem servidor. Dada a semelhança entre o Autopilot e o Cloud Run descrita nas secções anteriores, a migração entre as plataformas é uma tarefa simples quando não existem bloqueios técnicos ou de outro tipo. Para explorar as opções de migração com mais detalhe, consulte os artigos Migre do Cloud Run para o GKE e Migre do Kubernetes para o Cloud Run.
Quando escolhe um ambiente de tempo de execução para a sua carga de trabalho, tem de ter em conta as considerações técnicas e organizacionais. As considerações técnicas são caraterísticas da sua aplicação ou do Google Cloud ambiente de tempo de execução. As considerações organizacionais são características não técnicas da sua organização ou equipa que podem influenciar a sua decisão.
Considerações técnicas
Algumas das considerações técnicas que vão influenciar a sua escolha da plataforma são as seguintes:
- Controlo e configurabilidade: granularidade do controlo do ambiente de execução.
- Gestão e encaminhamento do tráfego de rede: configurabilidade das interações através da rede.
- Escalabilidade horizontal e vertical: suporte para o aumento e a diminuição dinâmicos da capacidade.
- Suporte para aplicações com estado: capacidades para armazenar o estado persistente.
- Arquitetura da CPU: compatibilidade com diferentes tipos de CPUs.
- Transferência de aceleradores (GPUs e TPUs): capacidade de transferir a computação para hardware dedicado.
- Memória, CPU e capacidade de outros recursos elevadas: nível de vários recursos consumidos.
- Dependência explícita do Kubernetes: requisitos para a utilização da API Kubernetes.
- RBAC complexo para multi-inquilino: suporte para partilha de recursos agrupados.
- Tempo limite máximo da tarefa do contentor: duração da execução de aplicações ou componentes de longa duração.
As secções seguintes detalham estas considerações técnicas para ajudar a escolher um ambiente de tempo de execução.
Controlo e configurabilidade
Em comparação com o Cloud Run, o GKE Autopilot oferece um controlo mais detalhado do ambiente de execução para as suas cargas de trabalho. No contexto de um Pod, o Kubernetes oferece muitas primitivas configuráveis que pode ajustar para cumprir os requisitos da sua aplicação. As opções de configuração incluem: nível de privilégio, parâmetros de qualidade do serviço, controladores personalizados para eventos do ciclo de vida do contentor, e partilha do espaço de nomes do processo entre vários contentores.
O Cloud Run suporta diretamente um subconjunto da superfície da API Kubernetes Pod, 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 tarefa do Cloud Run. Estes guias de referência podem ajudar a avaliar as duas plataformas juntamente com os requisitos da sua candidatura.
O contrato de contentor para o ambiente de execução do Cloud Run é relativamente simples e adequa-se à maioria das cargas de trabalho de publicação. No entanto, o contrato especifica alguns requisitos que têm de ser cumpridos. Se a sua aplicação ou as respetivas dependências não conseguirem cumprir esses requisitos, ou se precisar de um maior grau de controlo sobre o ambiente de execução, o Autopilot pode ser mais adequado.
Se quiser reduzir o tempo gasto na configuração e administração, pondere escolher o Cloud Run como o seu ambiente de tempo de execução. O Cloud Run tem menos opções de configuração do que o Autopilot, pelo que pode ajudar a maximizar a produtividade dos programadores e reduzir os custos operacionais.
Encaminhamento e gestão do tráfego de rede
O Cloud Run e o GKE Autopilot integram-se com o Google Cloud Load Balancing. No entanto, o GKE Autopilot também oferece um conjunto de primitivas avançado e eficaz para configurar o ambiente de rede para comunicações entre serviços. As opções de configuração incluem autorizações detalhadas e segregação na camada de rede através da utilização de namespaces e políticas de rede, remapping de portas e deteção de serviços DNS incorporada no cluster. O GKE Autopilot também suporta a API Gateway altamente configurável e flexível. Esta funcionalidade oferece um controlo poderoso sobre a forma como o tráfego é encaminhado para e entre os serviços no cluster.
Uma vez que o Autopilot é altamente configurável, pode ser a melhor opção se tiver vários serviços com um elevado grau de interdependência de rede ou requisitos complexos sobre como o tráfego é encaminhado entre os componentes da sua aplicação. Um exemplo deste padrão é uma aplicação distribuída que é decomposta em numerosos microsserviços que têm padrões complexos de interdependência. Nestes cenários, as opções de configuração de rede do Autopilot podem ajudar a gerir e controlar as interações entre serviços.
Escalabilidade horizontal e vertical
O Cloud Run e o GKE Autopilot suportam o escalonamento horizontal manual e automático para serviços e trabalhos. O escalamento horizontal oferece uma maior capacidade de processamento quando necessário e remove a capacidade de processamento adicional quando não é necessária. Para uma carga de trabalho típica, o Cloud Run pode normalmente aumentar a escala mais rapidamente do que o GKE Autopilot para responder a picos no número de pedidos por segundo. Por exemplo, a demonstração em vídeo "What's New in Serverless Compute?" mostra o escalamento do Cloud Run de zero para mais de 10 000 instâncias em aproximadamente 10 segundos. Para aumentar a velocidade do escalamento horizontal no Kubernetes (com algum custo adicional), o Autopilot permite-lhe aprovisionar capacidade de computação adicional.
Se a sua aplicação não conseguir dimensionar adicionando mais instâncias para aumentar o nível de recursos disponíveis, o Autopilot pode ser mais adequado. O Autopilot suporta a escalabilidade vertical para variar dinamicamente a quantidade de capacidade de processamento disponível sem aumentar o número de instâncias em execução da aplicação.
O Cloud Run pode dimensionar automaticamente as suas aplicações para zero réplicas quando não estão a ser usadas, o que é útil para determinados exemplos de utilização que se focam especialmente na otimização de custos. Devido às características de como as suas aplicações podem ser dimensionadas para zero, existem vários passos de otimização que pode seguir para minimizar o tempo entre a chegada de um pedido e o tempo em que a sua aplicação está em funcionamento e é capaz de processar o pedido.
Suporte para aplicações com estado
O Autopilot oferece suporte completo para volumes do Kubernetes, com o apoio de discos persistentes que lhe permitem executar uma vasta gama de implementações com estado, incluindo bases de dados autogeridas. O Cloud Run e o GKE Autopilot permitem-lhe estabelecer ligação a outros serviços, como o Filestore e os contentores do Cloud Storage. Ambos incluem também a capacidade de montar contentores de armazenamento de objetos no sistema de ficheiros com o Cloud Storage FUSE.
O Cloud Run usa um sistema de ficheiros na memória, que pode não ser adequado para aplicações que requerem um sistema de ficheiros local persistente. Além disso, o sistema de ficheiros local na memória é partilhado com a memória da sua aplicação. Por conseguinte, tanto o sistema de ficheiros efémero como a utilização de memória da aplicação e do contentor contribuem para esgotar o limite de memória. Pode evitar este problema se usar um volume dedicado na memória com um limite de tamanho.
Um serviço ou um contentor de tarefas do Cloud Run tem um limite de tempo da tarefa máximo. Um contentor em execução num pod num cluster do Autopilot pode ser reagendado, sujeito a quaisquer restrições configuradas com orçamentos de interrupção de pods (PDBs). No entanto, os pods podem ser executados durante um máximo de sete dias quando estão protegidos contra a remoção causada por atualizações automáticas de nós ou eventos de redução de escala. Normalmente, o limite de tempo da tarefa é mais provável de ser uma consideração para fluxos de trabalho em lote no Cloud Run. Para cargas de trabalho de longa duração e para 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 Google Cloud plataformas de computação suportam a arquitetura de CPU x86. O Cloud Run não suporta processadores de arquitetura Arm, mas o Autopilot suporta nós geridos baseados na arquitetura Arm. Se a sua carga de trabalho exigir a arquitetura Arm, tem de usar o Autopilot.
Descarga do acelerador
O Autopilot suporta a utilização de GPUs e a utilização de TPUs, incluindo a capacidade de consumir recursos reservados. O Cloud Run suporta a utilização de GPUs com algumas limitações.
Requisitos elevados de memória, CPU e outros recursos
Em comparação com os limites de pedidos de recursos do GKE Autopilot, os recursos máximos de CPU e memória que podem ser consumidos por um único serviço ou tarefa do Cloud Run (uma única instância) são limitados. Consoante as 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 arranque e o número máximo de ligaçõ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 elevados.
Dependência explícita do Kubernetes
Algumas aplicações, bibliotecas ou frameworks podem ter uma dependência explícita do Kubernetes. A dependência do Kubernetes pode ser o resultado de um dos seguintes aspetos:
- Os requisitos da aplicação (por exemplo, a aplicação chama APIs Kubernetes ou usa recursos personalizados do Kubernetes).
- Os requisitos das ferramentas usadas para configurar ou implementar a aplicação (como o Helm).
- Os requisitos de apoio técnico de um criador ou um fornecedor externo.
Nestes cenários, o Autopilot é o ambiente de tempo de execução de destino porque o Cloud Run não suporta o Kubernetes.
RBAC complexo para multi-tenancy
Se a sua organização tiver estruturas organizacionais particularmente complexas ou requisitos de multi-tenancy, use o Autopilot para poder tirar partido do controlo de acesso baseado em funções (RBAC) do Kubernetes. Para uma opção mais simples, pode usar as capacidades de segurança e segregação integradas no Cloud Run.
Considerações organizacionais
Seguem-se algumas considerações organizacionais que vão influenciar a sua escolha do ambiente:
- Estratégia técnica abrangente: a orientação técnica da sua organização.
- Tirar partido do ecossistema Kubernetes: interesse em tirar partido da comunidade de software de código aberto (OSS).
- Ferramentas internas existentes: utilização de determinadas ferramentas.
- Perfis da equipa de desenvolvimento: competências e experiência dos programadores.
- Apoio técnico operacional: capacidades e foco das equipas de operações.
As secções seguintes detalham estas considerações organizacionais para ajudar a escolher um ambiente.
Estratégia técnica abrangente
As organizações ou as equipas podem ter estratégias acordadas para preferir determinadas tecnologias em detrimento de outras. Por exemplo, se uma equipa tiver um contrato para padronizar, sempre que possível, o uso de serverless ou Kubernetes, esse contrato pode influenciar ou até mesmo determinar um ambiente de tempo de execução de destino.
Se uma determinada carga de trabalho não for adequada para o ambiente de tempo de execução especificado na estratégia, pode decidir fazer uma ou mais das seguintes ações, com as ressalvas que se seguem:
- Reestruture a carga de trabalho. No entanto, se a carga de trabalho não for adequada, pode resultar num desempenho, custo, segurança ou outras características não ideais.
- Registe a carga de trabalho como uma exceção à direção estratégica. No entanto, se as exceções forem usadas em excesso, pode resultar num portefólio de tecnologia dispar.
- Reconsidere a estratégia. No entanto, fazê-lo pode resultar em sobrecarga de políticas que podem impedir ou bloquear o progresso.
Tirar partido do ecossistema do Kubernetes
No âmbito da estratégia técnica abrangente descrita anteriormente, as organizações ou as equipas podem decidir selecionar o Kubernetes como a respetiva plataforma de eleição devido ao ecossistema significativo e em crescimento. Esta escolha é diferente da seleção do Kubernetes devido a dependências técnicas da aplicação, conforme descrito na secção anterior Dependência explícita do Kubernetes. A ponderação da utilização do ecossistema Kubernetes enfatiza uma comunidade ativa, ferramentas de terceiros avançadas e normas e portabilidade fortes. Tirar partido do ecossistema do Kubernetes pode acelerar a velocidade de desenvolvimento e reduzir o tempo de lançamento no mercado.
Ferramentas internas existentes
Em alguns casos, pode ser vantajoso usar ecossistemas de ferramentas existentes na sua organização ou equipa (para qualquer um dos ambientes). Por exemplo, se estiver a usar o Kubernetes, pode optar por continuar a usar ferramentas de implementação como o ArgoCD, ferramentas de segurança e políticas como o Gatekeeper e gestão de pacotes como o Helm. As ferramentas existentes podem incluir regras estabelecidas para a automatização da conformidade organizacional e outras funcionalidades que podem ser dispendiosas ou exigir um longo prazo de execução para implementação num ambiente de destino alternativo.
Perfis da equipa de desenvolvimento
Uma equipa de aplicações ou cargas de trabalho pode ter experiência anterior com o Kubernetes, o que pode acelerar a velocidade e a capacidade da equipa para oferecer resultados no Autopilot. Uma equipa pode demorar algum tempo a adquirir proficiência num novo ambiente de execução. Consoante o modelo de funcionamento, fazê-lo pode potencialmente resultar numa menor fiabilidade da plataforma durante o período de melhoria de competências.
Para uma equipa em crescimento, a capacidade de contratação pode influenciar a escolha da plataforma por parte de uma organização. Em alguns mercados, as competências de Kubernetes podem ser escassas e, por isso, ter 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 equipa dentro do seu orçamento.
Apoio técnico operacional
Quando escolher um ambiente de tempo de execução, tenha em conta a experiência e as capacidades das suas equipas de SRE, DevOps e plataformas, bem como de outro pessoal operacional. As capacidades das equipas operacionais para apoiar eficazmente o ambiente de produção são cruciais do ponto de vista da fiabilidade. Também é fundamental que as equipas operacionais possam suportar ambientes de pré-produção para garantir que a velocidade dos programadores não é impedida por tempo de inatividade, dependência de processos manuais ou mecanismos de implementação complexos.
Se usar o Kubernetes, uma equipa central de operações ou engenharia de plataformas pode tratar das atualizações do Kubernetes do Autopilot. Embora as atualizações sejam automáticas, normalmente, a equipa operacional monitoriza-as atentamente para garantir que as suas cargas de trabalho sofrem o mínimo de interrupções possível. Algumas organizações optam por atualizar manualmente as versões do plano de controlo. O GKE Enterprise também inclui capacidades para simplificar e otimizar a gestão de aplicações em vários clusters.
Ao contrário do Autopilot, o Cloud Run não requer atualizações nem sobrecarga de gestão contínuas do plano de controlo. Ao usar o Cloud Run, pode simplificar os processos de operações. Ao selecionar um único ambiente de tempo de execução, pode simplificar ainda mais os processos de operações. Se optar por usar vários ambientes de tempo de execução, tem de garantir que a equipa tem a capacidade, as competências e o interesse para suportar esses ambientes de tempo de execução.
Seleção
Para iniciar o processo de seleção, fale com os vários intervenientes. Para cada aplicação, reúna um grupo de trabalho composto por programadores, pessoal operacional, representantes de qualquer grupo central de governação tecnológica, utilizadores e consumidores internos da aplicação, equipas de segurança, de otimização financeira na nuvem e outras funções ou grupos na sua organização que possam ser relevantes. Pode optar por distribuir um inquérito de recolha de informações para reunir as características da candidatura e partilhar os resultados antes da sessão. Recomendamos que selecione um pequeno grupo de trabalho que inclua apenas as partes interessadas necessárias. Pode não ser necessário ter todos os representantes presentes em todas as sessões de trabalho.
Também pode ser útil incluir representantes de outras equipas ou grupos com experiência na criação e execução de aplicações no Autopilot ou no Cloud Run, ou em ambos. Use as considerações técnicas e organizacionais deste documento para orientar a sua conversa e avaliar a adequação da sua aplicação a cada uma das potenciais plataformas.
Recomendamos que agende uma reunião de acompanhamento após alguns meses para confirmar ou rever a decisão com base nos resultados da implementação da sua aplicação no novo ambiente.
O que se segue?
- Saiba mais sobre estes ambientes de tempo de execução com o Início rápido do GKE Autopilot e o laboratório do Cloud Run.
- Leia mais sobre a migração da Execução na nuvem para o GKE e de Kubernetes para a Execução na nuvem.
- Para ver mais arquiteturas de referência, diagramas e práticas recomendadas, explore o Centro de arquitetura na nuvem.
Colaboradores
Autor: Henry Bell | Arquiteto de soluções na nuvem
Outros colaboradores:
- Marco Ferrari | Arquiteto de soluções na nuvem
- Gari Singh | Outbound Product Manager
- Maridi (Raju) Makaraju | Supportability Tech Lead
- Parag Doshi | Key Enterprise Architect
- Daniel Stamer | Customer Engineer, Digital Natives
- Steren Giannini | Group Product Manager
- Victor Szalvay | Senior Product Manager
- William Denniss | Group Product Manager