Vista geral do Cloud Service Mesh
Este documento destina-se a administradores de rede e proprietários de serviços que querem familiarizar-se com a Cloud Service Mesh e as respetivas capacidades. Este é um documento antigo que se aplica a configurações que usam as APIs de equilíbrio de carga.
O Cloud Service Mesh é um plano de controlo gerido para a rede de aplicações. O Cloud Service Mesh permite-lhe fornecer serviços globais de elevada disponibilidade com capacidades de rede de aplicações avançadas, como gestão de tráfego e observabilidade.
À medida que o número de serviços e microsserviços na sua implementação aumenta, começa normalmente a deparar-se com desafios comuns de rede de aplicações, como os seguintes:
- Como posso tornar os meus serviços resilientes?
- Como posso direcionar tráfego para os meus serviços e como é que os serviços sabem e comunicam entre si?
- Como posso compreender o que acontece quando os meus serviços comunicam entre si?
- Como posso atualizar os meus serviços sem arriscar uma indisponibilidade?
- Como posso gerir a infraestrutura que torna a minha implementação possível?
O Cloud Service Mesh ajuda a resolver estes tipos de desafios numa implementação moderna baseada em serviços. O Cloud Service Mesh baseia-se numa infraestrutura gerida pela Google para que não tenha de gerir a sua própria infraestrutura. Google CloudConcentra-se no envio de código de aplicação que resolve os problemas da sua empresa, enquanto permite que o Cloud Service Mesh faça a gestão das complexidades de rede da aplicação.
Cloud Service Mesh
Um padrão comum para resolver desafios de rede de aplicações é usar uma malha de serviços. O Cloud Service Mesh suporta a malha de serviços e outros padrões de implementação que se adequam às suas necessidades.
Numa malha de serviços típica, o seguinte é verdadeiro:
- Implementa os seus serviços num cluster do Kubernetes.
- Cada um dos pods dos serviços tem um proxy dedicado (normalmente, o Envoy) em execução como um proxy sidecar.
- Cada proxy sidecar comunica com a infraestrutura de rede (um plano de controlo) que está instalado no seu cluster. O plano de controlo informa os proxies sidecar acerca dos serviços, dos pontos finais e das políticas na sua malha de serviços.
- Quando um Pod envia ou recebe um pedido, o pedido é encaminhado para o proxy sidecar do Pod. O proxy sidecar processa o pedido, por exemplo, enviando-o para o destino pretendido.
Nos diagramas neste documento e noutros documentos do Cloud Service Mesh, os ícones cor-de-rosa de seis lados representam os proxies. O plano de controlo está ligado a cada proxy e fornece informações que os proxies precisam para processar pedidos. As setas entre as caixas mostram os fluxos de tráfego. Por exemplo, o código da aplicação em Service A
envia um pedido. O proxy processa o pedido e encaminha-o para Service B.
Este modelo permite-lhe mover a lógica de rede para fora do código da sua aplicação. Pode concentrar-se em gerar valor para a empresa enquanto deixa que a sua infraestrutura cuide da rede de aplicações.
Em que é que o Cloud Service Mesh é diferente
A malha de serviços na nuvem funciona de forma semelhante a esse modelo, mas é diferente em aspetos importantes. Tudo começa com o facto de o Cloud Service Mesh ser um serviço gerido pela Google.Google CloudNão a instala, não é executada no seu cluster e não precisa de a manter.
No diagrama seguinte, o Cloud Service Mesh é o plano de controlo. Existem quatro serviços neste cluster do Kubernetes, cada um com proxies sidecar que estão ligados ao Cloud Service Mesh. O Cloud Service Mesh fornece as informações de que os proxies precisam para encaminhar pedidos. Por exemplo, o código da aplicação num Pod que
pertence a Service A envia um pedido. O proxy sidecar em execução juntamente com este pod processa o pedido e encaminha-o para um pod pertencente a Service B.
Além da malha de serviço
O Cloud Service Mesh suporta mais tipos de implementações do que uma service mesh típica.
Kubernetes com vários clusters
Com o Cloud Service Mesh, tem acesso a redes de aplicações que funcionam em clusters do Kubernetes. No diagrama seguinte, o Cloud Service Mesh fornece o plano de controlo para clusters do Kubernetes em us-central1 e europe-west1.
Os pedidos podem ser encaminhados 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 sua malha de serviços pode estender-se a vários clusters do Kubernetes em várias Google Cloud regiões. Os serviços num cluster podem comunicar com os serviços noutro cluster. Pode até ter serviços que consistam em Pods em vários clusters.
Com o balanceamento de carga global baseado na proximidade do Cloud Service Mesh, os pedidos
destinados a Service B vão para o pod mais próximo que pode atender o pedido. Também
tem uma comutação por falha integrada. Se um pod estiver inativo, o pedido
é automaticamente comutado por falha para outro pod que possa publicar o pedido, mesmo que
este pod esteja num cluster do Kubernetes diferente.
Máquinas virtuais
O Kubernetes está a tornar-se cada vez mais popular, mas muitas cargas de trabalho são implementadas em instâncias de máquinas virtuais (VM). O Cloud Service Mesh também resolve a rede de aplicações para estas cargas de trabalho. As suas cargas de trabalho baseadas em VMs interagem com as cargas de trabalho baseadas no Kubernetes.
No diagrama seguinte, o tráfego entra na sua implementação através do Application Load Balancer externo. É encaminhado para Service A no cluster do Kubernetes
em asia-southeast1 e para Service D numa VM em europe-west1.
A Google oferece um mecanismo simples para configurar cargas de trabalho baseadas em VMs com a malha de serviços do Google Cloud. Só tem de adicionar uma flag ao modelo de instância de VM do Compute Engine, e a Google trata da configuração da infraestrutura. Esta configuração inclui a instalação e a configuração dos proxies que oferecem capacidades de rede de aplicações.
gRPC sem proxy
O gRPC é uma framework de RPC de código aberto com muitas funcionalidades que pode usar para escrever microsserviços de alto desempenho. Com a malha de serviços na nuvem, pode trazer capacidades de rede de aplicações (como a deteção de serviços, o equilíbrio de carga e a gestão de tráfego) para as suas aplicações gRPC. Para mais informações, consulte o artigo Cloud Service Mesh e gRPC: serviços sem proxy para a sua service mesh.
No diagrama seguinte, as aplicações gRPC encaminham o tráfego para serviços baseados em clusters do Kubernetes numa região e para serviços executados em VMs em diferentes regiões. Dois dos serviços incluem proxies sidecar e os outros são sem proxy.
O Cloud Service Mesh suporta serviços gRPC sem proxy. Estes serviços usam uma versão recente da biblioteca gRPC de código aberto que suporta as APIs xDS. As suas aplicações gRPC podem ligar-se à Cloud Service Mesh usando as mesmas APIs xDS que o Envoy usa.
Depois de as aplicações estarem ligadas, a biblioteca gRPC trata das funções de rede das aplicações, como a deteção de serviços, o equilíbrio de carga e a gestão de tráfego. Estas funções ocorrem nativamente no gRPC, pelo que não são necessários proxies de serviço. É por isso que são denominadas aplicações gRPC sem proxy.
Entrada e gateways
Em muitos exemplos de utilização, tem de [processar o tráfego que tem origem em clientes que não estão configurados pelo Cloud Service Mesh. Por exemplo, pode ter de encaminhar o tráfego da Internet pública para os seus microsserviços. Também pode configurar um equilibrador de carga como um proxy inverso que processa o tráfego de um cliente antes de o enviar para um destino.
No diagrama seguinte, um Application Load Balancer externo permite a entrada para clientes externos, com o tráfego encaminhado para serviços num cluster do Kubernetes. Um balanceador de carga de aplicações interno encaminha o tráfego interno para o serviço em execução na VM.
O Cloud Service Mesh funciona com o Cloud Load Balancing para oferecer uma experiência de entrada gerida. Configura um balanceador de carga externo ou interno e, em seguida, configura esse balanceador de carga para enviar tráfego para os seus microsserviços. No diagrama anterior, os clientes da Internet pública acedem aos seus serviços através do Application Load Balancer externo. Os clientes, como os microsserviços que residem na sua rede de nuvem virtual privada (VPC), usam um Application Load Balancer interno para alcançar os seus serviços.
Para alguns exemplos de utilização, pode querer configurar a Cloud Service Mesh para configurar um gateway. Essencialmente, um gateway é um proxy inverso, normalmente o Envoy em execução numa ou mais VMs, que escuta pedidos de entrada, processa-os e envia-os para um destino. O destino pode estar em qualquer Google Cloud região ou cluster do Google Kubernetes Engine (GKE). Pode até ser um destino fora deGoogle Cloud que seja acessível a partir de Google Cloud através da conetividade híbrida. Para mais informações sobre quando usar um gateway, consulte o artigo Tráfego de entrada para a sua malha.
No diagrama seguinte, uma VM na região europe-west1 executa um proxy que
funciona como uma gateway para três serviços que não estão a executar proxies. O tráfego
de um balanceador de carga de aplicações externo e de um balanceador de carga de aplicações interno é encaminhado para o gateway
e, em seguida, para os três serviços.
Vários ambientes
Quer tenha serviços no Google Cloud, nas instalações, noutras nuvens ou em todos estes, os desafios fundamentais de rede de aplicações permanecem os mesmos. Como direciona tráfego para estes serviços? Como é que estes serviços comunicam entre si?
No diagrama seguinte, a malha de serviços na nuvem encaminha o tráfego dos serviços
executados em Google Cloud para Service G, executados noutra nuvem pública,
e para Service E e Service F, ambos executados num centro de dados no local.
O Service A, o Service B e o Service C usam o Envoy como um proxy complementar, enquanto o
Service D é um serviço gRPC sem proxy.
Quando usa a Cloud Service Mesh, pode enviar pedidos para destinos fora do Google Cloud. Isto permite-lhe usar o Cloud Interconnect ou o Cloud VPN para encaminhar de forma privada o tráfego de serviços no interior Google Cloud para serviços ou gateways noutros ambientes.
Configurar o Cloud Service Mesh
A configuração do Cloud Service Mesh consiste em dois passos. Depois de concluir o processo de configuração, a sua infraestrutura processa a rede de aplicações e o Cloud Service Mesh mantém tudo atualizado com base nas alterações à sua implementação.
Implemente as suas aplicações
Primeiro, implementa o código da aplicação em contentores ou VMs. A Google fornece mecanismos que lhe permitem adicionar infraestrutura de rede de aplicações (normalmente, proxies Envoy) às suas instâncias de VMs e pods. Esta infraestrutura está configurada para comunicar com a Cloud Service Mesh e saber mais sobre os seus serviços.
Configure o Cloud Service Mesh
Em seguida, configure os serviços globais e defina como o tráfego deve ser processado. Para configurar o Cloud Service Mesh, pode usar a Google Cloud consola (para algumas funcionalidades e configurações), a Google Cloud CLI, a API Traffic Director ou outras ferramentas, como o Terraform.
Depois de concluir estes passos, o Cloud Service Mesh está pronto para configurar a infraestrutura de rede da sua aplicação.
A infraestrutura processa o trabalho em rede da aplicação
Quando uma aplicação envia um pedido para my-service, a sua infraestrutura de rede de aplicações (por exemplo, um proxy sidecar do Envoy) processa o pedido
de acordo com as informações recebidas do Cloud Service Mesh. Isto permite que um pedido de my-service seja encaminhado sem problemas para uma instância da aplicação capaz de receber o pedido.
Monitorização e atualizações contínuas
O Cloud Service Mesh monitoriza as instâncias de aplicações que constituem os seus serviços. Esta monitorização permite que o Cloud Service Mesh descubra que um serviço está em bom estado ou que a capacidade de um serviço mudou, por exemplo, quando é criado um novo pod do Kubernetes. Com base nestas informações, o Cloud Service Mesh atualiza continuamente a infraestrutura de rede da sua aplicação.
Funcionalidades
As funcionalidades do Cloud Service Mesh oferecem capacidades de rede de aplicações aos seus microsserviços. Alguns destaques são abordados nesta secção.
Plano de controlo totalmente gerido, verificação do estado de funcionamento e equilíbrio de carga
Quer dedicar o seu tempo a gerar valor para a empresa e não a gerir a infraestrutura. O Cloud Service Mesh é uma solução totalmente gerida, pelo que não tem de instalar, configurar nem atualizar a infraestrutura. Beneficia da mesma infraestrutura que a Google usa para a verificação de funcionamento e o equilíbrio de carga global.
Criado com produtos de código aberto
O Cloud Service Mesh usa o mesmo plano de controlo (APIs xDS) que projetos de código aberto populares, como o Envoy e o Istio, usam. Para ver as versões da API suportadas, consulte as APIs do plano de controlo xDS.
A infraestrutura que oferece capacidades de rede de aplicações, seja o Envoy ou o gRPC, dependendo do seu exemplo de utilização, também é de código aberto, pelo que não tem de se preocupar com a dependência de infraestrutura proprietária.
Evolua
Desde soluções de rede de aplicações únicas a implementações de malhas de serviços massivas com milhares de serviços, a Cloud Service Mesh foi criada para satisfazer os seus requisitos de escalabilidade.
Descoberta de serviços e acompanhamento dos seus pontos finais e back-ends
Quando a sua aplicação envia um pedido para my-service, a sua infraestrutura processa o pedido de forma integrada e envia-o para o destino correto. A sua aplicação não precisa de saber nada sobre endereços IP, protocolos ou outras complexidades de rede.
Balanceamento de carga global e comutação por falha
O Cloud Service Mesh usa o balanceamento de carga global da Google e a verificação de funcionamento para equilibrar de forma ideal o tráfego com base na localização do cliente e do back-end, na proximidade do back-end, no funcionamento e na capacidade. Melhora a disponibilidade do serviço fazendo com que o tráfego mude automaticamente para back-ends em bom estado com capacidade. Pode personalizar o equilíbrio de carga para distribuir o tráfego de forma a dar resposta adequada às necessidades da sua empresa.
Gestão de tráfego
A gestão avançada do tráfego, incluindo o encaminhamento e a manipulação de pedidos (com base no nome do anfitrião, no caminho, nos cabeçalhos, nos cookies e muito mais), permite-lhe determinar como o tráfego flui entre os seus serviços. Também pode aplicar ações como novas tentativas, redirecionamentos e divisão de tráfego baseada em ponderação para implementações de teste. Os padrões avançados, como a injeção de falhas, a replicação de tráfego e a deteção de valores atípicos, permitem exemplos de utilização de DevOps que melhoram a sua capacidade de recuperação.
Observabilidade
A sua infraestrutura de rede de aplicações recolhe informações de telemetria, como métricas, registos e rastreios, que podem ser agregadas centralmente no Google Cloud Observability. Depois de recolher estas informações, pode obter estatísticas e criar alertas para que, se algo correr mal, receba uma notificação.
VPC Service Controls
Pode usar os VPC Service Controls para fornecer segurança adicional aos recursos e serviços da sua aplicação. Pode adicionar projetos a perímetros de serviço que protegem recursos e serviços (como a Cloud Service Mesh) de pedidos que têm origem fora do perímetro. Para saber mais acerca do VPC Service Controls, consulte a vista geral do VPC Service Controls.
Para saber mais sobre a utilização do Cloud Service Mesh com os VPC Service Controls, consulte a página Produtos suportados.
O que se segue?
Este é um documento antigo que se aplica principalmente às APIs de equilíbrio de carga. Recomendamos vivamente que não configure a Cloud Service Mesh através das APIs de balanceamento de carga.
Para implementar o Cloud Service Mesh:
- Para o Compute Engine com VMs, use as APIs de encaminhamento de serviços.
- Para o Google Kubernetes Engine com pods, use as APIs Gateway.
Para encontrar exemplos de utilização e padrões de arquitetura para serviços gRPC sem proxy, consulte a vista geral dos serviços gRPC sem proxy.
Para saber como a gestão de tráfego lhe dá controlo sobre a forma como o tráfego é processado, consulte a vista geral da gestão avançada de tráfego.
Para saber como a malha de serviços na nuvem suporta ambientes que se estendem para além do Google Cloud, consulte os seguintes documentos: