Visão geral do Cloud Service Mesh
Este documento é para administradores de rede e proprietários de serviços que desejam conhecer melhor o Cloud Service Mesh e os recursos dele. Isso é um documento legado que se aplica à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 fornecer serviços globais altamente disponíveis com recursos avançados de rede de aplicativos, como gerenciamento de tráfego e observabilidade.
À medida que o número de serviços e microsserviços na sua implantação aumenta, você geralmente começa a enfrentar desafios comuns da rede de aplicativos, como estes:
- Como faço para tornar meus serviços resilientes?
- Como obtenho tráfego para meus serviços e como os serviços sabem e se comunicam uns com os outros?
- Como posso entender o que está acontecendo quando meus serviços se comunicam entre si?
- Como atualizo meus serviços sem correr riscos de falha temporária?
- 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 um ambiente implantação baseada em serviço. O Cloud Service Mesh depende dos serviços gerenciados do Google Cloud, para que você não precise gerenciar sua própria infraestrutura. Você concentre-se no código do aplicativo de envio que resolve os problemas da sua empresa e, ao mesmo tempo, permitindo que o Cloud Service Mesh gerencie as complexidades de rede do aplicativo.
Cloud Service Mesh
Um padrão comum para resolver desafios de rede de aplicativos é usar uma malha de serviço. O Cloud Service Mesh oferece suporte a malha de serviço e outros os padrões de implantação adequados às suas necessidades.
Em uma malha de serviço típica, as seguintes condições são verdadeiras:
- Implante seus 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) que é instalado 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 solicitações. 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 que você mova a lógica de rede para fora do seu aplicativo o código-fonte. Você pode focar em agregar valor aos negócios e, ao mesmo tempo, permitir que sua infraestrutura cuide da rede do aplicativo.
Diferenças do Cloud Service Mesh
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 é uma serviço gerenciado pelo Google 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 que
os proxies necessários para encaminhar 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
A 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 redes de aplicativos que funcionam
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.
Sua malha de serviço pode se estender por vários clusters do Kubernetes em várias regiões do Google Cloud. Os serviços em um cluster podem conversar com serviços em outro cluster. É possível ter serviços que consistem em pods em vários clusters.
Com o balanceamento de carga global baseado em proximidade do Cloud Service Mesh, as solicitações
destinados a Service B vão para o pod mais próximo que possa 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á se tornando cada vez mais popular, mas muitas cargas de trabalho são implantadas em instâncias de máquina virtual (VM). O Cloud Service Mesh também resolve a rede de aplicativos para essas cargas de trabalho. As cargas de trabalho baseadas em VM interagem com as cargas de trabalho baseadas 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 fornece um mecanismo contínuo para configurar cargas de trabalho baseadas em VM com do Cloud Service Mesh. Você só adiciona uma sinalização ao modelo de instância da VM do Compute Engine, e o Google lida com a 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 a 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 à malha de serviços do Cloud usando as mesmas APIs xDS que o Envoy usa.
Depois que os aplicativos são conectados, a biblioteca do gRPC cuida das funções de rede de aplicativos, como descoberta de serviços, balanceamento de carga e gerenciamento de tráfego. Essas funções ocorrem nativamente no gRPC. Portanto, proxies não são necessários, por isso são chamados de gRPC sem proxy. aplicativos conteinerizados.
Entrada e gateways
Em muitos casos de uso, é preciso [lidar com o tráfego originado de clientes que não são configurados pela Cloud Service Mesh: Por exemplo, talvez seja necessário encaminhar tráfego de 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 funciona 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, talvez você queira configurar o Cloud Service Mesh para configurar uma 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 em um cluster do Google Kubernetes Engine (GKE). É possível até mesmo um destino fora do Google Cloud que pode ser acessado pelo Google Cloud usando 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 no Google Cloud para Service G, em outra nuvem pública,
e para Service E e Service F, ambos 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 alterações da implantação.
Implantar seus aplicativos
Primeiro, implante o código do aplicativo em contêineres ou VMs. O Google oferece que permitem adicionar infraestrutura de rede de aplicativos (geralmente proxies Envoy) às instâncias de VM e pods. Essa infraestrutura é configurado para falar com o Cloud Service Mesh e aprender sobre seus 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, use o console do Google Cloud (por alguns recursos e configurações), a Google Cloud CLI, a API Traffic Director ou outros de código aberto, 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 serviços. Esse monitoramento permite que o Cloud Service Mesh descubra que um serviço está íntegra ou que a capacidade de um serviço foi alterada, por exemplo, quando um novo O pod do Kubernetes é criado. Com base nessas informações, o Cloud Service Mesh atualiza continuamente a infraestrutura de rede de aplicativos.
Recursos
Os recursos do Cloud Service Mesh fornecem de rede de aplicativos aos 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 passar seu tempo fornecendo valor comercial, não gerenciando a 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) projetos conhecidos de código aberto, como o Envoy O Istio (em inglês). Para acessar as versões de API compatíveis, consulte as APIs do plano de controle xDS.
A infraestrutura que fornece redes de aplicativos recursos: Envoy ou gRPC dependendo do seu caso de uso, também são de código aberto, então você não precisa se preocupar em relação a uma infraestrutura reservada.
Escala
De soluções de rede de aplicativos únicas a malha de serviço massiva com milhares de serviços, o Cloud Service Mesh foi criado para atender às suas 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 saber nada sobre
endereços IP, protocolos ou outras complexidades de rede.
Balanceamento de carga e failover globais
O Cloud Service Mesh usa o balanceamento de carga global e a verificação de integridade do Google 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 manipulação de solicitações (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 para 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 do aplicativo coleta informações de telemetria, como métricas, registros e traces, que podem ser agregados de forma centralizada Observabilidade do Google Cloud. 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
É possível usar o VPC Service Controls para fornecer segurança adicional aos recursos e serviços do seu aplicativo. É possível adicionar projetos a perímetros de serviço que protegem recursos e serviços (como o Cloud Service Mesh) contra solicitações que fora dele. Para saber mais sobre o VPC Service Controls, consulte a visão geral sobre ele.
Para saber mais sobre como usar o Cloud Service Mesh com o VPC Service Controls, consulte a página Produtos com suporte.
A seguir
Este é um documento legado que se aplica principalmente às APIs de balanceamento de carga. É altamente recomendável não configurar o Cloud Service Mesh usando as APIs de balanceamento de carga.
Para implantar o Cloud Service Mesh:
- Para o Compute Engine com VMs, use as APIs de roteamento de serviço.
- Para o 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 fornece controle sobre como o tráfego é tratado, consulte a Visão geral do gerenciamento de tráfego avançado.
Para saber como o Cloud Service Mesh é compatível com ambientes que se estendem além do Google Cloud, consulte os seguintes documentos: