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 a Execução na nuvem 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 sua 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 do Kubernetes familiares, 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. Aqui está 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 implementar 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 tráfego entre o Cloud Run e o GKE, pode expor pontos finais externos atravé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 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.