Esta página é destinada a administradores de infraestrutura e operadores de aplicativos que executam um conjunto diversificado de cargas de trabalho conteinerizadas e querem aproveitar os pontos fortes do Google Kubernetes Engine (GKE) e do Cloud Run para implantar aplicativos no Google Cloud Platform. Uma estratégia híbrida permite otimizar custos, desempenho e despesas gerais de gerenciamento.
Antes de ler esta página, você precisa conhecer:
Cargas de trabalho sem estado e com estado
Por que usar o GKE e o Cloud Run juntos?
O GKE e o Cloud Run oferecem vantagens diferentes para a execução de aplicativos conteinerizados e atendem a diferentes níveis de complexidade da carga de trabalho. No entanto, você não precisa escolher entre as duas plataformas. É possível aproveitar os pontos fortes do GKE e do Cloud Run migrando as cargas de trabalho entre as duas plataformas conforme a necessidade.
Confira a seguir alguns benefícios de usar os dois ambientes de execução para implantar suas cargas de trabalho:
O GKE e o Cloud Run oferecem um nível relativamente alto de portabilidade:
As duas plataformas usam imagens de contêiner padrão como artefatos de implantação. É possível usar a mesma imagem para seu aplicativo em qualquer uma das plataformas sem nenhuma modificação, permitindo a migração perfeita de cargas de trabalho entre o GKE e o Cloud Run. Não é necessário atualizar configuração da integração contínua para migrar entre o GKE e o Cloud Run, desde que as imagens do contêiner sejam armazenadas no Artifact Registry.
O GKE e o Cloud Run usam um modelo de API declarativa. A API Cloud Run Admin v1 foi projetada para ser compatível com a API Kubernetes. Isso significa que é possível usar conceitos conhecidos do Kubernetes, como implantações, serviços e escalonadores automáticos horizontais de pods, para gerenciar o serviço do Cloud Run. Essa semelhança facilita a conversão de configurações entre as duas plataformas.
Os recursos são representados em arquivos YAML com a mesma estrutura declarativa e padrão e, portanto, podem ser facilmente migrados entre os ambientes de execução. Confira um exemplo que compara os arquivos YAML de uma implantação do Kubernetes e um serviço do Cloud Run.
Tanto o GKE quanto o Cloud Run se integram perfeitamente ao Cloud Logging eCloud Monitoring, proporcionando uma visualização centralizada no console do Google Cloud para observar as métricas do aplicativo independentemente da plataforma. Também é possível usar o monitoramento de objetivos de nível de serviço (SLO) em ambas as plataformas e exibir uma exibição unificada dos SLOs no painel do Cloud Monitoring.
É possível implementar a entrega contínua para recursos do GKE ou serviços do Cloud Run usando o Cloud Deploy. Se preferível, implantar simultaneamente o aplicativo no GKE e no Cloud Run usando a implantação paralela.
Facilite o gerenciamento de tráfego avançado usando balanceadores de carga externos e internos para serviços no GKE e no Cloud Run. Isso inclui a capacidade de expor endpoints externos para implantar e executar URLs diferentes do mesmo aplicativo nas duas plataformas. Também é possível dividir o tráfego para o mesmo serviço entre o GKE e o Cloud Run, permitindo uma migração perfeita de uma plataforma para outra.
O Google Cloud fornece ferramentas de segurança para melhorar sua postura de segurança ao usar os dois ambientes de execução. A verificação do SO permite que você verifique se há vulnerabilidades nos contêineres antes da implantação em qualquer uma das plataformas. Uma política central de autorização binária pode aplicar a integração com o plano de controle do GKE e do Cloud Run para permitir ou bloquear a implantação de imagens com base nas políticas que você definir. Com o VPC Service Controls, as equipes de segurança podem definir controles refinados de perímetro nos recursos do GKE e do Cloud Run.
Comparar o GKE e o Cloud Run
Para aproveitar os melhores recursos do GKE e do Cloud Run e saber quando mover as cargas de trabalho entre eles, é importante entender as diferenças entre os dois serviços.
| Recurso | GKE | Cloud Run |
|---|---|---|
| Implantação e gerenciamento | Gerencie os clusters do Kubernetes, incluindo configuração de nós, rede, escalonamento e upgrades. O Google Cloud gerencia a infraestrutura e fornece ferramentas para simplificar as operações do cluster, mas você ainda é responsável pelos aspectos principais do Kubernetes. |
Execute contêineres diretamente na infraestrutura escalonável do Google Cloud. Basta fornecer o código-fonte ou uma imagem do contêiner para que o Cloud Run crie o contêiner. Não é preciso criar um cluster ou provisionar e gerenciar a infraestrutura. |
| Controle e flexibilidade | Controle total sobre o cluster do Kubernetes. É possível criar personalizações avançadas de configurações de nó, políticas de rede, configurações de segurança e complementos. |
Controle limitado sobre a infraestrutura subjacente. É possível configurar variáveis de ambiente, simultaneidade e conexões de rede, mas não é possível personalizar a infraestrutura nem o ambiente. Ideal para simplicidade e velocidade. |
| Tipos de aplicativo | Oferece suporte a aplicativos sem estado e com estado e é ideal para aplicativos complexos com necessidades específicas de recursos. | Mais adequado para serviços, serviços da Web e funções sem estado, com base em solicitações ou eventos. |
| Modelo de preços | Pagamento por cluster por hora, independentemente do modo de operação (padrão ou Autopilot), do tamanho ou da topologia do cluster. | Pagamento pelo uso, arredondado para os 100 milissegundos mais próximos. |
Caso de uso
Considere que você é um administrador de plataforma de uma empresa de varejo que está criando uma grande plataforma de e-commerce. Você tem as seguintes cargas de trabalho conteinerizadas para implantar:
Site de front-end e app para dispositivos móveis: um aplicativo da Web sem estado que processa a navegação, a pesquisa e a finalização de compra dos produtos.
Gerenciamento de inventário de produtos: um serviço com estado que gerencia a disponibilidade e as atualizações de produtos.
Mecanismo de recomendação: um microsserviço complexo que gera recomendações de produtos personalizadas para cada usuário.
Jobs de processamento em lote: incluem tarefas periódicas, como atualização de catálogos de produtos e análise do comportamento do usuário.
Essas cargas de trabalho representam uma combinação de serviços sem estado e com estado. Portanto, você decide aproveitar o GKE e o Cloud Run para um desempenho ideal. Veja aqui uma maneira de implementar uma abordagem híbrida para suas cargas de trabalho.
Depois de ler os critérios de adequação das cargas de trabalho do Cloud Run, você decide usar o Cloud Run no site e no app para dispositivos móveis, além dos jobs de processamento em lote. A implantação desses serviços no Cloud Run tem os seguintes benefícios:
Escalonamento automático como picos de tráfego e grandes jobs em lote são tratados sem intervenção manual.
Economia com um modelo de pagamento conforme o uso. Você só paga quando os usuários estão navegando ou fazendo check-out e quando os recursos são usados durante a execução de jobs em lote.
Implantações mais rápidas, já que as atualizações são disponibilizadas instantaneamente, melhorando a experiência do usuário.
Fácil integração com outros serviços do Google Cloud. Por exemplo, para processamento orientado por eventos, é possível usar as funções do Cloud Run para iniciar jobs de processamento em lote no Cloud Run e ativar fluxos de trabalho contínuos.
O gerenciamento de inventário de produtos é um serviço com estado que requer controle refinado e soluções de armazenamento potencialmente personalizadas. Você decide usar o GKE para implantar esse serviço, já que ele oferece armazenamento permanente e permite anexar volumes para persistência e confiabilidade dos dados do produto.
O mecanismo de recomendação é um microsserviço complexo que se beneficia do GKE. Com o GKE, é possível gerenciar dependências complexas e exercer um controle refinado sobre a alocação e o escalonamento de recursos.
O GKE é mais adequado para arquiteturas complexas de microsserviços, aplicativos com estado, cargas de trabalho que exigem configurações personalizadas de infraestrutura ou rede e cenários em que o controle profundo sobre o Kubernetes é essencial. O Cloud Run é mais adequado para apps orientados a eventos. Ele é ideal para serviços da Web sem estado, APIs, jobs em lote e outras cargas de trabalho que se beneficiam do sistema de pagamento por uso.
O exemplo anterior demonstra como a combinação do GKE e do Cloud Run pode fornecer uma solução poderosa e flexível para sua plataforma de e-commerce. Você recebe os benefícios das duas plataformas, eficiência sem servidor para cargas de trabalho sem estado e controle do Kubernetes para microsserviços complexos e componentes com estado.
Considerações
O GKE e o Cloud Run se complementam, atendendo às diferentes necessidades em um cenário complexo de aplicativos.
Veja a seguir algumas considerações ao adotar uma abordagem híbrida para implantar cargas de trabalho:
Execute microsserviços sem estado no Cloud Run para ter eficiência de custo e escalonabilidade.
Implante aplicativos complexos com estado que exigem personalização profunda no GKE.
Se você usa uma rede privada no Google Cloud, para acessar recursos no cluster do GKE pelo serviço do Cloud Run, envie uma solicitação para uma rede de nuvem privada virtual (VPC). usando a saída de VPC direta. Para acessar os serviços do Kubernetes no GKE cluster, o serviço do Cloud Run precisa estar conectado ao rede VPC, e o serviço do Kubernetes precisa usar uma Balanceador de carga de rede de passagem interna.
Para migrar o tráfego entre o Cloud Run e o GKE, exponha os endpoints externos por trás de um balanceador de carga de aplicativo externo global. Ao implementar esse balanceador de carga na frente dos serviços nos dois ambientes de execução, é possível implantar o mesmo aplicativo no Cloud Run e no GKE, permitindo mudar gradualmente o tráfego de uma plataforma para a outro.
Para expor os serviços do Cloud Run na nuvem privada virtual atrás de IPs privados, use um balanceador de carga interno.
Se suas cargas de trabalho já estiverem no Cloud Run, será possível migrar para o GKE a qualquer momento, conforme necessário.
Quando não usar o GKE e o Cloud Run juntos
Embora o GKE e o Cloud Run ofereçam uma abordagem atraente para muitas cargas de trabalho conteinerizadas, há situações em que usá-los juntos pode não ser a melhor opção. Veja alguns exemplos de quando você pode decidir não adotar uma abordagem híbrida:
Microsserviços com acoplamento rígido: se os microsserviços forem muito dependentes uns dos outros e exigirem comunicação frequente e de baixa latência, o gerenciamento em plataformas separadas poderá gerar complexidades. Chamadas de rede frequentes entre plataformas podem adicionar sobrecarga e possíveis gargalos, afetando o desempenho.
Aplicativos legados com dependências personalizadas: se o aplicativo depende de bibliotecas, frameworks ou configurações específicas não compatíveis com o Cloud Run, o uso dele para partes do aplicativo pode exigir uma quantidade significativa de refatoração ou soluções alternativas. Isso pode negar os benefícios sem servidor e introduzir sobrecarga de manutenção específica da plataforma.
Restrições de orçamento com cargas de trabalho previsíveis: se a carga de trabalho tiver requisitos de recursos consistentes e você estiver com um orçamento apertado, o modelo de pagamento por nó do GKE poderá ser mais econômico do que o faturamento por uso do Cloud Run. Se você tiver cargas de trabalho previsíveis, talvez não use totalmente os benefícios de escalonamento automático do Cloud Run, tornando o custo fixo do GKE mais atraente.
A melhor abordagem depende, em última instância, de suas necessidades e prioridades específicas. Avalie cuidadosamente os requisitos, as restrições de recursos e a experiência da equipe do aplicativo antes de decidir sobre uma arquitetura híbrida do GKE e do Cloud Run.
A seguir
Saiba como converter o serviço do Cloud Run em uma implantação do Kubernetes em Migrar do Cloud Run para o GKE.
Empacote sua implantação do Kubernetes em um contêiner compatível com o Cloud Run seguindo o artigo Migrar do Kubernetes para o Cloud Run.