Google Cloud oferece duas plataformas principais para executar aplicações contentorizadas: o GKE para executar contentores em clusters do Kubernetes e o Cloud Run para executar contentores diretamente na Google Cloud infraestrutura. Mas quando deve usar uma ou outra? Pode usar ambas? Esta página oferece uma comparação das duas plataformas e das respetivas vantagens, e ajuda a descobrir se uma estratégia de plataforma única ou híbrida é adequada para si.
Esta página foi concebida para administradores de infraestrutura e operadores de aplicações que executam um conjunto diversificado de cargas de trabalho em contentores e querem tirar partido das vantagens do Google Kubernetes Engine (GKE) e do Cloud Run para implementar aplicações naGoogle Cloud plataforma.
Antes de ler esta página, certifique-se de que conhece:
Cargas de trabalho sem estado e com estado
Porquê usar o GKE e o Cloud Run em conjunto?
O GKE e o Cloud Run oferecem diferentes vantagens para executar aplicações em contentores e destinam-se a diferentes níveis de complexidade da carga de trabalho. No entanto, não tem de escolher entre as duas plataformas. Pode tirar partido simultaneamente dos pontos fortes do GKE e do Cloud Run migrando as suas cargas de trabalho entre as duas plataformas conforme necessário. Uma estratégia híbrida como esta pode permitir-lhe otimizar os custos, o desempenho e os custos administrativos.
Seguem-se algumas vantagens da utilização de ambos os tempos de execução para implementar as suas cargas de trabalho:
O GKE e o Cloud Run oferecem um nível relativamente elevado de portabilidade:
Ambas as plataformas usam imagens de contentores padrão como artefactos de implementação. Pode usar a mesma imagem para a sua aplicação em qualquer uma das plataformas sem modificações, o que permite uma migração perfeita das cargas de trabalho entre o GKE e o Cloud Run. Não precisa de atualizar a configuração de integração contínua para migrar entre o GKE e o Cloud Run, desde que as imagens de contentores estejam armazenadas no Artifact Registry.
O GKE e a Execução na nuvem usam um modelo de API declarativo. A API Cloud Run Admin v1 foi concebida para ser compatível com a API Kubernetes. Isto significa que pode usar conceitos familiares do Kubernetes, como implementações, serviços e escaladores automáticos de pods horizontais, para gerir o seu serviço do Cloud Run. Esta semelhança facilita a tradução das configurações entre as duas plataformas.
Os recursos são representados em ficheiros YAML com a mesma estrutura declarativa e padrão e, por isso, podem ser facilmente migrados entre tempos de execução. Segue-se um exemplo que compara os ficheiros YAML de uma implementação do Kubernetes e um serviço do Cloud Run.
O GKE e o Cloud Run integram-se perfeitamente com o Cloud Logging e o Cloud Monitoring, oferecendo-lhe uma vista centralizada na Google Cloud consola para observar as métricas da aplicação independentemente da respetiva plataforma. Também pode usar a monitorização dos objetivos ao nível do serviço (SLO) em ambas as plataformas e ver uma apresentação unificada dos SLOs no painel de controlo do Cloud Monitoring.
Pode implementar a entrega contínua nos recursos do GKE ou nos serviços do Cloud Run através do Cloud Deploy. Em alternativa, se preferir, implemente simultaneamente a sua aplicação no GKE e no Cloud Run através da implementação paralela.
Pode facilitar a gestão avançada do tráfego através da utilização de balanceadores de carga externos e internos para serviços no GKE e no Cloud Run. Isto inclui a capacidade de expor pontos finais externos para que possa implementar e executar diferentes URLs para a mesma aplicação em ambas as plataformas. Também pode dividir o tráfego para o mesmo serviço no GKE e no Cloud Run, o que permite uma migração perfeita de uma plataforma para outra.
Google Cloud oferece ferramentas de segurança para melhorar a sua postura de segurança quando usa ambos os tempos de execução. A análise de SO permite-lhe analisar contentores quanto a vulnerabilidades antes da implementação em qualquer uma das plataformas. Uma política de autorização binária central pode aplicar a integração com o plano de controlo do GKE e do Cloud Run para permitir ou bloquear a implementação de imagens com base nas políticas que definir. Com os VPC Service Controls, as equipas de segurança podem definir controlos de perímetro detalhados nos seus recursos do GKE e do Cloud Run.
Compare o GKE e o Cloud Run
Para tirar partido das melhores funcionalidades do GKE e do Cloud Run, e saber quando mover cargas de trabalho entre eles, é importante compreender como os dois serviços diferem entre si.
| Funcionalidade | GKE | Cloud Run |
|---|---|---|
| Implementação e gestão | Faça a gestão dos clusters do Kubernetes, incluindo a configuração de nós, a rede, o dimensionamento e as atualizações. Google Cloud gerem a infraestrutura subjacente e fornecem ferramentas para simplificar as operações de cluster, mas continua a ser responsável pelos aspetos essenciais do Kubernetes. |
Execute contentores diretamente na infraestrutura escalável do Google Cloud. Só tem de fornecer o código fonte ou uma imagem de contentor, e o Cloud Run pode criar o contentor por si. Não tem de criar um cluster nem aprovisionar e gerir infraestrutura. |
| Controlo e flexibilidade | Controlo total sobre o cluster do Kubernetes. Pode criar personalizações avançadas de configurações de nós, políticas de rede, definições de segurança e suplementos. |
Controlo limitado sobre a infraestrutura subjacente. Pode configurar as variáveis de ambiente, a simultaneidade e as ligações de rede, mas não pode personalizar a infraestrutura ou o ambiente subjacente. Ideal para simplicidade e velocidade. |
| Tipos de aplicações | Suporta aplicações sem estado e com estado, e é ideal para aplicações complexas com necessidades de recursos específicas. | Mais adequados para serviços sem estado, baseados em pedidos ou eventos, serviços Web e funções. |
| Modelo de preços | Pagamento por cluster por hora, independentemente do modo de funcionamento (padrão ou automático), do tamanho ou da topologia do cluster. | Pagamento por utilização, arredondado para os 100 milissegundos mais próximos. |
Exemplo de utilização
Considere que é administrador de uma plataforma de uma empresa de retalho que está a criar uma grande plataforma de comércio eletrónico. Tem as seguintes cargas de trabalho contentorizadas para implementar:
Website e app para dispositivos móveis de front-end: uma aplicação Web sem estado que processa a navegação, a pesquisa e o pagamento de produtos.
Gestão do inventário de produtos: um serviço com estado que gere a disponibilidade e as atualizações dos produtos.
Motor de recomendações: um microsserviço complexo que gera recomendações de produtos personalizadas para cada utilizador.
Tarefas de processamento em lote: inclui tarefas periódicas, como atualizar catálogos de produtos e analisar o comportamento dos utilizadores.
Estas cargas de trabalho representam uma combinação de serviços sem estado e com estado, pelo que decide tirar partido do GKE e da Execução na nuvem para um desempenho ideal. Segue-se uma forma de implementar uma abordagem híbrida para as suas cargas de trabalho.
Depois de ler os critérios de adequação das cargas de trabalho do Cloud Run, decide usar o Cloud Run para o Website e a app para dispositivos móveis, bem como os trabalhos de processamento em lote. A implementação destes serviços no Cloud Run tem as seguintes vantagens:
O escalamento automático à medida que os picos de tráfego e os grandes trabalhos em lote são processados sem intervenção manual.
Relação custo-eficácia com um modelo de pagamento por utilização. Só paga quando os utilizadores estão a navegar ou a fazer o checkout, e quando os recursos são usados durante a execução de tarefas em lote.
Implementações mais rápidas, uma vez que as atualizações estão disponíveis instantaneamente, o que melhora a experiência do utilizador.
Integração fácil com outros Google Cloud serviços. Por exemplo, para o processamento orientado por eventos, pode usar as funções do Cloud Run para iniciar tarefas de processamento em lote no Cloud Run e ativar fluxos de trabalho perfeitos.
A gestão do inventário de produtos é um serviço com estado que requer um controlo detalhado e, potencialmente, soluções de armazenamento personalizadas. Decide usar o GKE para implementar este serviço, uma vez que oferece armazenamento persistente e permite anexar volumes para a persistência e a fiabilidade dos dados dos produtos.
O motor de recomendações é um microsserviço complexo que beneficia do GKE. Com o GKE, pode gerir dependências complexas e exercer um controlo detalhado sobre a atribuição e o escalonamento de recursos.
O GKE é mais adequado para arquiteturas de microsserviços complexas, aplicações com estado, cargas de trabalho que requerem configurações de infraestrutura ou de rede personalizadas e cenários em que o controlo detalhado sobre o Kubernetes é essencial. O Cloud Run é mais adequado para apps orientadas por eventos. É ideal para serviços Web sem estado, APIs, trabalhos em lote e outras cargas de trabalho que beneficiam de preços de pagamento por utilização.
O exemplo anterior demonstra como a combinação do GKE e do Cloud Run pode oferecer uma solução poderosa e flexível para a sua plataforma de comércio eletrónico. Tira partido das vantagens de ambas as plataformas: eficiência sem servidor para cargas de trabalho sem estado e controlo do Kubernetes para microsserviços complexos e componentes com estado.
Para uma vista unificada dos componentes distintos implementados com uma abordagem híbrida e para ver como funcionam em conjunto como uma aplicação coesa, pode usar o App Hub. Para mais informações, consulte o artigo Recursos suportados do App Hub.
Considerações
O GKE e o Cloud Run complementam-se, respondendo a diferentes necessidades num panorama de aplicações complexo.
Seguem-se algumas considerações ao adotar uma abordagem híbrida para a implementação de cargas de trabalho:
Execute microsserviços sem estado no Cloud Run para rentabilidade e escalabilidade.
Implemente aplicações com estado complexas que requerem uma personalização detalhada no GKE.
Se usar uma rede privada no Google Cloud, para aceder a recursos no seu cluster do GKE a partir do serviço do Cloud Run, pode enviar um pedido a uma rede da nuvem virtual privada (VPC) através da saída da VPC direta. Para aceder aos serviços Kubernetes no cluster do GKE, o serviço Cloud Run tem de estar ligado à rede VPC do cluster e o serviço Kubernetes tem de usar um Network Load Balancer de encaminhamento interno.
Para migrar o tráfego entre o Cloud Run e o GKE, pode expor pontos finais externos atrás de um balanceador de carga de aplicações externo global. Quando implementa este equilibrador de carga à frente dos serviços em ambos os tempos de execução, pode implementar a mesma aplicação no Cloud Run e no GKE, o que lhe permite mudar gradualmente o tráfego de uma plataforma para a outra.
Para expor serviços do Cloud Run na nuvem virtual privada atrás de IPs privados, use um balanceador de carga interno.
Lembre-se de que, se as suas cargas de trabalho já estiverem no Cloud Run, pode sempre migrar para o GKE conforme necessário.
Quando não usar o GKE e o Cloud Run em conjunto
Embora o GKE e o Cloud Run ofereçam uma abordagem apelativa para muitas cargas de trabalho em contentores, existem situações em que a utilização conjunta pode não ser a mais adequada. Seguem-se alguns exemplos de situações em que pode decidir não adotar uma abordagem híbrida:
Microsserviços fortemente acoplados: se os seus microsserviços forem altamente dependentes uns dos outros e exigirem uma comunicação frequente e de baixa latência, a gestão dos mesmos em plataformas separadas pode introduzir complexidades. As chamadas de rede frequentes entre plataformas podem adicionar sobrecarga e potenciais gargalos, o que afeta o desempenho.
Aplicações antigas com dependências personalizadas: se a sua aplicação depender de bibliotecas, frameworks ou configurações específicas não suportadas pelo Cloud Run, a sua utilização para partes da aplicação pode exigir uma refatoração ou soluções alternativas significativas. Isto pode anular as vantagens sem servidor e introduzir custos gerais de manutenção específicos da plataforma.
Restrições orçamentais com cargas de trabalho previsíveis: se a sua carga de trabalho tiver requisitos de recursos consistentes e tiver um orçamento limitado, o modelo de pagamento por nó do GKE pode ser mais rentável do que a faturação de pagamento por utilização do Cloud Run. Se tiver cargas de trabalho previsíveis, pode não usar totalmente as vantagens do escalamento automático do Cloud Run, o que torna o custo fixo do GKE mais atrativo.
Em última análise, a melhor abordagem depende das suas necessidades e prioridades específicas. Avalie cuidadosamente os requisitos da sua aplicação, as restrições de recursos e a experiência da equipa antes de decidir por uma arquitetura híbrida do GKE e do Cloud Run.
O que se segue?
Saiba como converter o seu serviço do Cloud Run numa implementação do Kubernetes em Migre do Cloud Run para o GKE.
Empacote a sua implementação do Kubernetes num contentor compatível com o Cloud Run seguindo o artigo Migre do Kubernetes para o Cloud Run.