Visão geral

O Cloud Service Mesh oferece recursos de rede de serviços aos aplicativos, incluindo gerenciamento avançado de tráfego, observabilidade e segurança. No entanto, configurar e operar uma malha de serviço é uma tarefa complexa. Nesta página, descrevemos como configurar o Cloud Service Mesh com as APIs Gateway do Kubernetes. Estas APIs foram projetadas para simplificar e melhorar sua experiência geral de configuração da malha.

As APIs de gateway do Kubernetes para Mesh permitem configurar o Cloud Service Mesh para implantações de proxy gRPC e Envoy sem proxy. O modelo da API Gateway para Mesh oferece vários benefícios importantes:

  • As APIs Gateway fornecem uma interface única e consistente para gerenciar o tráfego de entrada (norte-sul) e de malha de serviço (leste-oeste) no cluster do Kubernetes.
  • As malhas de serviço permitem padrões avançados de roteamento de tráfego. As APIs Gateway permitem projetar e gerenciar regras de rota complexas.
  • Com as APIs Gateway, os desenvolvedores podem se concentrar em definir regras de rota e políticas de alto nível para o microsserviço, sem precisar de conhecimento profundo da implementação da malha de serviço subjacente.
  • A API foi projetada para ser extensível, permitindo melhorias futuras e suporte para novos protocolos e casos de uso.
  • As APIs Gateway têm um forte apoio da comunidade e são compatíveis com um ecossistema cada vez maior de provedores e ferramentas de malha de serviço.

O trabalho da iniciativa GAMMA para dar suporte a casos de uso de malha de serviço faz parte do canal Standard desde a v1.1.0 e é considerado GA.

A especificação propõe que o proprietário de um aplicativo configure regras de tráfego para um serviço de malha configurando um Route resource (às vezes chamado de xRoute) com um recurso Service do Kubernetes como parentRef. A abordagem depende dos papéis de "front-end" e "back-end" do Service do Kubernetes, conforme definido em GEP-1324: malha de serviço na API Gateway, em que o papel de "front-end" é usado como um parentRef e o papel de "back-end" do Service é usado como um backendRef. A implementação compatível usa o nome Service para corresponder ao tráfego e aos endpoints backendRef para os endereços IP canônicos.

API Gateway para Mesh

A API Gateway, um projeto do Kubernetes, se concentra no roteamento das camadas 4 e 7 no Kubernetes. Ela sucede as APIs Entrada, Balanceamento de Carga e Malha de Serviço. Projetado para ser versátil, descritivo e focado em funções, as configurações dele estão principalmente na camada de roteamento. Recursos específicos de protocolo, como HTTPRoute e GRPCRoute, permitem roteamento avançado de entrada e de malha.

A Iniciativa GAMMA (API Gateway para malha de serviço) define como a API Gateway também pode ser usada para tráfego entre serviços ou tráfego leste/oeste no mesmo cluster. O objetivo do GAMMA é estabelecer como usar a API Gateway para configurar uma malha de serviço com modificações mínimas na API Gateway, mantendo a natureza orientada a papéis dela. A GAMMA também enfatiza a importância de promover a consistência entre várias implementações de malha de serviço da API Gateway, independentemente da tecnologia ou do proxy subjacente.

A GAMMA aproveita os pontos de extensibilidade atuais na especificação da API Gateway, sem exigir mudanças na API ou novos recursos. Para isso, as definições de recursos de rota (GRPCRoute ou HTTPRoute na API Gateway) são estendidas para sinalizar o caso de uso da malha de serviço, especificamente associando os recursos de rota aos recursos de serviço, conforme descrito em API Gateway para malha de serviço.

O exemplo a seguir ilustra o caso de uso de malha no uso de HTTPRoute:

apiVersion:  gateway.networking.k8s.io
kind: HTTPRoute
metadata:
  name: echo-route
spec:
  parentRefs:
  - kind: Service
    group: ""
    name: echo-service
  rules:
  - backendRefs:
    - name: echo-v1
      port: 80
      weight: 9
  - backendRefs:
    - name: echo-v2
      port: 80
      weight: 1

Diagrama de HTTPRoute

O HTTPRoute faz referência a um Service como o parentRef, o que indica que a rota HTTPRoute está configurada para o caso de uso da malha de serviço. No exemplo anterior, o serviço echo-service é especificado como parentRef, o que significa que o HTTPRoute está anexado ao front-end do echo-service. Qualquer tráfego enviado para echo-service por um cliente é roteado de acordo com o HTTPRoute echo-route.

GRPCRoute é outro recurso da API Kubernetes Gateway, usado para rotear o tráfego gRPC para serviços do Kubernetes. Os usuários optam por usar GRPCRoute em vez de HTTPRoute quando querem rotear especificamente o tráfego gRPC e aproveitar recursos personalizados para gRPC, como correspondência de método e serviço gRPC.

O exemplo a seguir ilustra o uso de GRPCRoute:

apiVersion:  gateway.networking.k8s.io
kind: GRPCRoute
metadata:
  name: echo-route
spec:
  parentRefs:
  - kind: Service
    group: ""
    name: echo-service
  rules:
   - matches:
    - method:
        service:echo_basic.grpcecho.GrpcEcho
        method: Echo
    backendRefs:
    - name: grpc-infra-backend-v1
      port: 8080
  - matches:
    - method:
        service:echo_basic.grpcecho.GrpcEcho
        method: EchoTwo
    backendRefs:
    - name: grpc-infra-backend-v2
      port: 8080

Diagrama de GRPCRoute

Assim como o exemplo de HTTPRoute, esse GRPCRoute é configurado para casos de uso de malha de serviço. Qualquer tráfego enviado para xds:///echo-service.default.svc.cluster.local:8080 por um cliente gRPC sem proxy é roteado de acordo com a rota de eco do GRPCRoute. As regras de rota neste exemplo correspondem a um método gRPC e roteiam o tráfego para um backendRef específico. As GRPCRoutes também podem ser usadas para rotear solicitações de clientes com proxy com injeções de sidecar, como o Envoy, quando o prefixo xds:/// é descartado.

Diagrama de malha de cluster único

A seguir