Visão geral da malha de serviço do GKE do Cloud Service Mesh

Essa configuração é compatível com clientes do pré-lançamento, mas não é recomendada para novos usuários do Cloud Service Mesh. Para mais informações, consulte a visão geral do Cloud Service Mesh.

Este documento é para usuários do Google Kubernetes Engine que querem implantar uma malha de serviço do Cloud Service Mesh usando a API Kubernetes Gateway.

É possível configurar o Cloud Service Mesh para GKE usando as APIs Kubernetes Gateway, permitindo comunicações de serviço a serviço, gerenciamento de tráfego, balanceamento de carga global e aplicação de política de segurança para casos de uso de malha de serviço.

APIs do Kubernetes e do Google Cloud

É possível configurar uma malha de serviço do Cloud Service Mesh usando duas APIs diferentes:

Neste documento e nos guias de configuração associados, fornecemos instruções sobre como usar a API Kubernetes Gateway para configurar uma malha de serviço do Cloud Service Mesh.

Recomendamos que você use as APIs do gateway do Kubernetes no Google Kubernetes Engine e não use as duas APIs para configurar o roteamento na mesma malha de serviço no GKE.

A API de roteamento de serviços usa os mesmos nomes dos recursos das APIs Kubernetes Gateway, o que facilita o uso das duas APIs. Os recursos do Kubernetes configurados são funcionalmente equivalentes aos recursos do Google Cloud representados pela API de roteamento de serviço do Cloud Service Mesh.

As seções a seguir descrevem os recursos e a arquitetura usados pela integração do Cloud Service Mesh com as APIs Kubernetes Gateway.

API Gateway

A API Gateway é um conjunto de recursos que modelam a rede de serviços no Kubernetes. A API Gateway do Kubernetes é um projeto de código aberto que se concentra em oferecer suporte a casos de uso de entrada e balanceador de carga, fornecendo uma API de roteamento genérica. A API de roteamento genérico tem muitas implementações. As definições de recursos personalizados (CRDs) do Cloud Service Mesh são adicionadas como uma extensão à API Gateway de código aberto. As CRDs são compatíveis com casos de uso de malha de serviço e usam a mesma API de roteamento genérica introduzida pela API Gateway.

A API Gateway é organizada hierarquicamente, com um recurso pai de gateway e o GatewayClass associado a que você anexa rotas. O GKE inclui um recurso TDMesh que é um peering do recurso Gateway. É possível anexar os mesmos tipos de Route ao recurso TDMesh. É no recurso TDMesh que você anexa rotas e políticas para malhas de serviço.

API Gateway, recurso de gateway, recurso de malha e rotas
API Gateway, recurso Gateway, recurso de malha e rotas (clique para ampliar)

Frota

Uma frota consiste em um ou mais clusters do GKE agrupados logicamente. Uma frota permite gerenciar recursos e aplicar políticas de maneira consistente em vários clusters. Ao usar uma frota, é possível gerenciar uma malha de serviço do Cloud Service Mesh que abrange vários clusters.

Arquitetura

O Cloud Service Mesh oferece suporte à API Gateway no GKE ao programar os planos de dados dos clusters para implementar os comportamentos de rede especificados nos recursos da API Gateway. O Cloud Service Mesh em si é um plano de controle gerenciado pelo Google que não processa nenhum tráfego do plano de dados. Os proxies do Envoy em execução como arquivos secundários para suas cargas de trabalho ou clientes gRPC sem proxy processam o tráfego no plano de dados. O Cloud Service Mesh configura proxies Envoy e clientes gRPC sem proxy usando a API xDSv3.

O Cloud Service Mesh oferece uma solução de plano de controle gerenciada e disponível globalmente que é mais robusta e escalonável do que a execução de controladores no cluster. Como é uma solução global, o Cloud Service Mesh pode fazer o balanceamento de carga do tráfego entre cargas de trabalho distribuídas em vários clusters do GKE. Na ilustração a seguir, o Cloud Service Mesh gerencia o tráfego para serviços em três clusters que estão em uma única frota usando recursos da API Gateway.

Uma malha de serviço de vários clusters do Cloud Service Mesh configurada com a API Gateway
Uma malha de serviço de vários clusters do Cloud Service Mesh configurada usando a API Gateway (clique para ampliar)

Você designa um cluster na sua frota como o cluster de configuração. O cluster de configuração é onde os recursos da API Gateway são armazenados. O Cloud Service Mesh monitora apenas os recursos que estão no cluster de configuração e ignora os que estão em outros clusters na frota. Consulte Projeto do cluster de configuração na documentação do GKE para ver informações mais detalhadas sobre esse cluster.

Com os serviços de vários clusters do GKE, os recursos da API Gateway no cluster de configuração podem referenciar serviços do Kubernetes em qualquer cluster em uma frota. Consulte Serviços de vários clusters para ver mais informações sobre a descoberta de serviços multicluster.

Recursos

O Cloud Service Mesh oferece suporte a proxies Envoy e a gRPC sem proxy no plano de dados de uma malha de serviço. Os dois clientes recebem a configuração do Cloud Service Mesh para uma determinada malha de serviço, especificando o nome e o número do projeto correspondente do recurso TDMesh na respectiva configuração de inicialização. Os guias de configuração do Cloud Service Mesh com as APIs Kubernetes Gateway fornecem configurações de plano de dados de demonstração com Envoy e gRPC sem proxy.

RecursoTDMesh

O recurso TDMesh é um recurso personalizado do Cloud Service Mesh. É uma extensão das APIs de gateway de código aberto para oferecer suporte aos casos de uso de malha de serviço do Cloud Service Mesh. Usando o recurso TDMesh, você cria uma instância de malha de serviço na sua frota. As rotas anexadas ao recurso TDMesh especificam os comportamentos de roteamento de serviço a serviço na malha de serviço.

Route recursos

Um subconjunto dos recursos da rota da API Gateway pode ser anexado a um recurso TDMesh para especificar o roteamento no nível de serviço na malha de serviço. O Cloud Service Mesh é compatível com os seguintes recursos Route:

  • HTTPRoute
  • TCPRoute
  • TDGRPCRoute (recurso personalizado do Cloud Service Mesh)

Por exemplo, é possível criar um HTTPRoute para especificar que as solicitações HTTP destinadas ao host payments.svc.internal sejam roteadas para o serviço service-payments do Kubernetes. Quando você anexa o recurso HTTPRoute a um recurso TDMesh em que as instâncias de plano de dados estão inscritas, as solicitações HTTP enviadas por cargas de trabalho na malha são roteadas adequadamente.

Essa versão aumenta os recursos genéricos de Route na API Gateway com um novo tipo de rota, TDGRPCRoute. O novo tipo de rota oferece uma experiência de alto nível para rotear solicitações gRPC, por meio da correspondência de gRPC primitivos nativos, como definições de método e serviço.

Como usar os recursos da API Gateway no GKE para configurar o Cloud Service Mesh
Como usar os recursos da API Gateway no GKE para configurar o Cloud Service Mesh (clique para ampliar)

Limitações

  • O Cloud Service Mesh configura os comportamentos padrão a seguir para todos os serviços do Kubernetes na malha de serviço. Não é possível alterar esses comportamentos.
    • As verificações de integridade TCP são configuradas nas portas de serviço referenciadas por qualquer recurso Route da API Gateway.
    • Um tempo limite padrão de 30 segundos é configurado para todas as solicitações de entrada para serviços.
    • A afinidade da sessão está desativada.
  • O injetor automático do Envoy é compatível apenas com uma malha por frota.
  • Os recursos de segurança do Cloud Service Mesh não podem ser ativados usando a API Gateway.
  • Configure os recursos TDMesh e Route no GKE usando apenas a API Gateway. Não é possível usar o Console do Google Cloud, a CLI gcloud ou as APIs REST.
  • Todos os clusters precisam estar em um projeto. Uma malha de serviço que se estende por clusters em vários projetos não é compatível.
  • Não é possível configurar ou visualizar uma malha de serviço do GKE usando o Console do Google Cloud.
  • A observabilidade do plano de controle com o Cloud Logging e o Cloud Monitoring não é compatível.

A seguir