Visão geral do Cloud Service Mesh
Este documento é destinado a administradores de redes e proprietários de serviços que querem se familiarizar com o Cloud Service Mesh e os recursos dele. Este é um documento legado dedicado às configurações que usam as APIs de balanceamento de carga.
O Cloud Service Mesh é um plano de controle gerenciado para redes de aplicativos. O Cloud Service Mesh permite oferecer serviços globais altamente disponíveis com recursos avançados de rede de aplicativos, como gerenciamento de tráfego e observabilidade.
À medida que aumenta o número de serviços e microsserviços na sua implantação, é comum você enfrentar desafios habituais da rede de aplicativos, como estes:
- Como faço para tornar meus serviços resilientes?
- Como conseguir tráfego para meus serviços e como os serviços reconhecem e se comunicam uns com os outros?
- Como saber o que acontece quando meus serviços se comunicam entre si?
- Como atualizo meus serviços sem correr riscos de interrupção?
- Como faço para gerenciar a infraestrutura que torna minha implantação possível?
O Cloud Service Mesh ajuda a resolver esses tipos de desafios em uma implantação moderna, baseada em serviços. O Cloud Service Mesh usa a infraestrutura gerenciada pelo Google Cloudpara que você não precise gerenciar sua própria infraestrutura. Você se dedica ao código do aplicativo de envio que resolve seus problemas empresariais, e o Cloud Service Mesh gerencia as complexidades da rede de aplicativos.
Cloud Service Mesh
Um padrão comum para resolver os desafios da rede de aplicativos é usar uma malha de serviço. O Cloud Service Mesh é compatível com a malha de serviço e outros padrões de implantação que atendem às suas necessidades.
Em uma malha de serviço típica, as seguintes condições são verdadeiras:
- Você implanta os serviços em um cluster do Kubernetes.
- Cada um dos pods de serviço tem um proxy dedicado (geralmente o Envoy) em execução como um proxy sidecar.
- Cada proxy sidecar se comunica com a infraestrutura de rede (um plano de controle) instalada no cluster. O plano de controle informa os proxies sidecar sobre serviços, endpoints e políticas na malha de serviço.
- Quando um pod envia ou recebe uma solicitação, a solicitação vai para o proxy sidecar do pod. O proxy sidecar processa a solicitação, por exemplo, enviando-a para o destino pretendido.
Nos diagramas deste documento e de outros documentos do Cloud Service Mesh, os ícones rosa
de seis lados representam os proxies. O plano de controle está conectado a cada proxy e
fornece as informações necessárias para que os proxies processem as solicitações. As setas
entre as caixas mostram os fluxos de tráfego. Por exemplo, o código do aplicativo em Service A
envia uma solicitação. O proxy processa a solicitação e a encaminha para Service B.
Esse modelo permite remover a lógica de rede do código do seu aplicativo. Você se dedica aos negócios enquanto a infraestrutura cuida da rede de aplicativos.
Como o Cloud Service Mesh é diferente
O Cloud Service Mesh funciona de modo semelhante ao modelo, mas é diferente de maneiras importantes. Tudo começa com o fato de que o Cloud Service Mesh é um serviço gerenciado peloGoogle Cloud. Você não o instala, ele não é executado no cluster e você não precisa mantê-lo.
No diagrama a seguir, o Cloud Service Mesh é o plano de controle. Há quatro
serviços neste cluster do Kubernetes, cada um com proxies sidecar
conectados ao Cloud Service Mesh. O Cloud Service Mesh fornece as informações
necessárias para os proxies encaminharem solicitações. Por exemplo, o código do aplicativo em um pod que
pertence a Service A envia uma solicitação. O proxy sidecar em execução ao lado desse
pod manipula a solicitação e a encaminha para um pod que pertence a Service B.
Além da malha de serviço
O Cloud Service Mesh é compatível com mais tipos de implantações do que uma malha de serviço típica.
Kubernetes de vários clusters
Com o Cloud Service Mesh, você tem uma rede de aplicativos que funciona nos
clusters do Kubernetes. No diagrama a seguir, o Cloud Service Mesh fornece o
plano de controle para clusters do Kubernetes em us-central1 e europe-west1.
As solicitações podem ser encaminhadas entre os três serviços em us-central1, entre os
dois serviços em europe-west1 e entre os serviços nos dois clusters.
A malha de serviço pode se estender por vários clusters do Kubernetes em diversas regiões doGoogle Cloud . Os serviços em um cluster podem conversar com serviços em outro cluster. É possível ter serviços com pods em vários clusters.
Com o balanceamento de carga global baseado em proximidade do Cloud Service Mesh, as solicitações
destinadas a Service B vão para o pod mais próximo que pode atender à solicitação. Você
também terá um failover perfeito: se um pod estiver inativo, a solicitação
fará o failover automaticamente para outro pod que possa servir na solicitação, mesmo se
esse pod estiver em um cluster diferente do Kubernetes.
Máquinas virtuais
O Kubernetes está ficando cada vez mais em alta, mas muitas cargas de trabalho são implantadas em instâncias de máquina virtual (VM, na sigla em inglês). O Cloud Service Mesh também resolve a rede de aplicativos para essas cargas de trabalho: há uma interoperabilidade entre as cargas de trabalho baseadas em VM e no Kubernetes.
No diagrama a seguir, o tráfego entra na implantação por meio do balanceador
de carga de aplicativo externo. Ele é roteado para Service A no cluster do Kubernetes
em asia-southeast1 e para Service D em uma VM em europe-west1.
O Google oferece um mecanismo perfeito para configurar cargas de trabalho baseadas em VM com o Cloud Service Mesh. Você adiciona uma flag ao modelo de instância da VM do Compute Engine, e o Google cuida da configuração da infraestrutura. Isso inclui a instalação e a configuração dos proxies que fornecem recursos de rede de aplicativos.
gRPC sem proxy
gRPC é um framework RPC de código aberto de recursos completos que pode ser usado para escrever microsserviços de alto desempenho. Com o Cloud Service Mesh, é possível trazer recursos de rede de aplicativos (como descoberta de serviços, balanceamento de carga e gerenciamento de tráfego) para aplicativos gRPC. Para mais informações, consulte Cloud Service Mesh e gRPC: serviços sem proxy para sua malha de serviço.
No diagrama a seguir, os aplicativos gRPC encaminham tráfego para serviços baseados em clusters do Kubernetes em uma região e para serviços em execução em VMs em regiões diferentes. Dois dos serviços incluem proxies sidecar, e os outros são sem proxy.
O Cloud Service Mesh é compatível com serviços gRPC sem proxy. Esses serviços usam uma versão recente da biblioteca gRPC de código aberto compatível com as APIs xDS. Os aplicativos gRPC podem se conectar ao Cloud Service Mesh usando as mesmas APIs xDS que o Envoy usa.
Depois de conectada, a biblioteca do gRPC cuida das funções da rede de aplicativos, como descoberta de serviços, balanceamento de carga e gerenciamento de tráfego. Essas funções acontecem nativamente no gRPC, de modo que os proxies de serviço não sejam obrigatórios. É por isso que eles são chamados de aplicativos gRPC sem proxy.
Entrada e gateways
Para muitos casos de uso, é preciso processar o tráfego proveniente de clientes que não estão configurados pelo Cloud Service Mesh. Por exemplo, talvez seja necessário encaminhar tráfego da internet pública para seus microsserviços. Você também pode configurar um balanceador de carga como um proxy reverso que processa o tráfego de um cliente antes de enviá-lo para um destino.
No diagrama a seguir, um balanceador de carga de aplicativo externo permite a entrada de clientes externos, com tráfego roteado para serviços em um cluster do Kubernetes. Um balanceador de carga de aplicativo interno encaminha o tráfego interno para o serviço em execução na VM.
A Cloud Service Mesh trabalha com o Cloud Load Balancing para fornecer uma experiência de entrada gerenciada. Basta configurar um balanceador de carga externo ou interno e em seguida, configurá-lo para enviar tráfego aos microsserviços. No diagrama anterior, os clientes públicos da Internet acessam seus serviços por meio do balanceador de carga de aplicativo externo. Os clientes, como microsserviços que residem na rede da nuvem privada virtual (VPC), usam um balanceador de carga de aplicativo interno para acessá-los.
Em alguns casos de uso, convém configurar o Cloud Service Mesh para configurar um gateway. Esse gateway é essencialmente um proxy reverso, geralmente Envoy em execução em uma ou mais VMs, que detecta solicitações de entrada, as manipula e as envia para um destino. O destino pode estar em qualquer região do Google Cloud ou cluster do Google Kubernetes Engine (GKE). O destino pode até ser fora do Google Cloud acessível por Google Cloud usando a conectividade híbrida. Para mais informações sobre quando usar um gateway, consulte Tráfego de entrada para sua malha.
No diagrama a seguir, uma VM na região europe-west1 executa um proxy que
atua como um gateway para três serviços que não estão executando proxies. O tráfego
de um balanceador de carga de aplicativo externo e um balanceador de carga de aplicativo interno é roteado para o gateway e, em seguida,
para os três serviços.
Vários ambientes
Não importa se você tem serviços no Google Cloud, no local, em outras nuvens ou em todas elas, os desafios fundamentais da rede de aplicativos permanecem os mesmos. Como você recebe tráfego para esses serviços? E como esses serviços se comunicam uns com os outros?
No diagrama a seguir, o Cloud Service Mesh encaminha o tráfego dos serviços
em execução em Google Cloud para Service G, em outra nuvem pública
e para Service E e Service F, sendo executados em um data center local.
Service A, Service B e Service C, usam o Envoy como um proxy sidecar, enquanto
Service D é um serviço gRPC sem proxy.
Ao usar o Cloud Service Mesh, é possível enviar solicitações para destinos fora do Google Cloud. Isso permite que você use o Cloud Interconnect ou o Cloud VPN para encaminhar de modo particular o tráfego de serviços dentro do Google Cloud para serviços ou gateways em outros ambientes.
Como configurar o Cloud Service Mesh
A configuração do Cloud Service Mesh consiste em duas etapas. Depois de concluir o processo de configuração, a infraestrutura gerencia a rede de aplicativos e o Cloud Service Mesh mantém tudo atualizado com base nas mudanças da implantação.
Implantar seus aplicativos
Primeiro, implante o código do aplicativo em contêineres ou VMs. O Google fornece mecanismos que permitem que você adicione a infraestrutura de rede de aplicativos (geralmente proxies do Envoy) às instâncias de VM e aos pods. Essa infraestrutura está configurada para se comunicar com o Cloud Service Mesh e saber mais sobre os serviços.
Configurar o Cloud Service Mesh
Em seguida, configure seus serviços globais e defina como o tráfego será tratado. Para configurar o Cloud Service Mesh, é possível usar o console do Google Cloud (para alguns recursos e configurações), a CLI do Google Cloud, a API Traffic Director ou outras ferramentas, como o Terraform.
Depois de concluir essas etapas, o Cloud Service Mesh estará pronto para configurar a infraestrutura de rede de aplicativos.
A infraestrutura lida com rede de aplicativos
Quando um aplicativo envia uma solicitação para my-service, a infraestrutura de rede de
aplicativos, por exemplo, um proxy sidecar do Envoy, processa a solicitação
de acordo com as informações recebidas do Cloud Service Mesh. Isso permite que uma solicitação
de my-service seja encaminhada facilmente para uma instância de aplicativos que possa
receber a solicitação.
Monitoramento e atualizações contínuas
O Cloud Service Mesh monitora as instâncias de aplicativos que constituem seus serviços. Isso permite que o Cloud Service Mesh descubra que um serviço está íntegro ou que a capacidade dele mudou, por exemplo, quando um novo pod do Kubernetes é criado. Com base nessas informações, o Cloud Service Mesh faz atualizações periódicas da infraestrutura de rede de aplicativos.
Recursos
As funcionalidades do Cloud Service Mesh oferecem recursos de rede de aplicativos a microsserviços. Alguns destaques são discutidos nesta seção.
Plano de controle totalmente gerenciado, verificação de integridade e balanceamento de carga
Você quer se dedicar aos seus negócios, não ao gerenciamento da infraestrutura. O Cloud Service Mesh é uma solução totalmente gerenciada. Assim, você não precisa instalar, configurar ou atualizar a infraestrutura. Você se beneficia da mesma infraestrutura que o Google usa para verificação de integridade e balanceamento de carga global.
Desenvolvidos com produtos de código aberto
O Cloud Service Mesh usa o mesmo plano de controle (APIs xDS) que projetos de código aberto conhecidos como Envoy e Istio usam. Para ver as versões compatíveis da API, consulte as APIs do plano de controle do xDS.
A infraestrutura que oferece os recursos de rede de aplicativos (Envoy ou gRPC, dependendo do caso de uso) também é de código aberto, assim você não se preocupa em depender de uma infraestrutura reservada.
Escala
De soluções de rede de aplicativos únicas a implantações de malha de serviço massivas com milhares de serviços, o Cloud Service Mesh foi criado para atender aos seus requisitos de escalonamento.
Descoberta de serviços e rastreamento de endpoints e back-ends
Quando o aplicativo envia uma solicitação para my-service, a infraestrutura
processa continuamente a solicitação e a envia para o destino correto. Seu
aplicativo não precisa ter nenhuma informação sobre endereços IP, protocolos ou
outras complexidades de rede.
Balanceamento de carga global e failover
O Cloud Service Mesh usa o balanceamento de carga global do Google e a verificação de integridade para equilibrar o tráfego de acordo com a proximidade, a integridade e a capacidade do back-end. Você melhora a disponibilidade do serviço fazendo o failover do tráfego automaticamente para back-ends íntegros com capacidade. É possível personalizar o balanceamento de carga para distribuir o tráfego e atender às suas necessidades de negócios.
Gerenciamento de tráfego
O gerenciamento avançado de tráfego, incluindo roteamento e solicitação de manipulação (com base no nome do host, caminho, cabeçalhos, cookies e muito mais), permite determinar o fluxo do tráfego entre os serviços. Também é possível aplicar ações, como novas tentativas, redirecionamentos e divisão de tráfego com base no peso, a implantações canário. Padrões avançados como injeção de falhas, espelhamento de tráfego e detecção de outliers permitem casos de uso de DevOps que melhoram sua resiliência.
Observabilidade
A infraestrutura de rede de aplicativos coleta informações de telemetria, como métricas, registros e traces, que podem ser agregadas de maneira centralizada no Google Cloud Observability. Depois que essas informações forem coletadas, é possível conseguir insights e criar alertas para que, caso algo dê errado, você receba uma notificação.
VPC Service Controls
Use o VPC Service Controls para reforçar a segurança de recursos e serviços do seu aplicativo. É possível adicionar projetos a perímetros de serviço para proteger recursos e serviços (como o Cloud Service Mesh) de solicitações que vêm de fora do perímetro. Para saber mais, consulte a Visão geral sobre o VPC Service Controls.
Para saber mais sobre como usar o Cloud Service Mesh com o VPC Service Controls, consulte a página Produtos compatíveis.
A seguir
Este é um documento legado dedicado às APIs de balanceamento de carga. Não recomendamos configurar o Cloud Service Mesh usando as APIs de balanceamento de carga.
Para implantar o Cloud Service Mesh:
- No Compute Engine com VMs, use as APIs de roteamento de serviço.
- No Google Kubernetes Engine com pods, use as APIs de gateway.
Para encontrar casos de uso e padrões de arquitetura para serviços do gRPC sem proxy, consulte a Visão geral dos serviços do gRPC sem proxy.
Para saber como o gerenciamento de tráfego permite controlar o tráfego processado, consulte a Visão geral do gerenciamento de tráfego avançado.
Para saber sobre outros ambientes compatíveis com o Cloud Service Mesh, além do Google Cloud, consulte os seguintes documentos: