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. Esta página descreve como configurar o Cloud Service Mesh com as APIs Gateway do Kubernetes. Essas APIs foram projetadas para simplificar e melhorar sua experiência geral de configuração da malha.

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

  • As APIs Gateway oferecem uma interface única e consistente para gerenciar o tráfego de entrada (norte-sul) e da 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 de gateway permitem projetar e gerenciar regras de roteamento complexas.
  • Com as APIs do gateway, os desenvolvedores podem se concentrar na definição de regras e políticas de roteamento de alto nível para o microsserviço sem precisar de conhecimento detalhado da implementação da malha de serviço subjacente.
  • A API foi projetada para ser extensível, permitindo melhorias futuras e suporte a novos protocolos e casos de uso.
  • As APIs do gateway têm um forte apoio da comunidade e são compatíveis com um ecossistema crescente de provedores e ferramentas de malha de serviço.

O trabalho da iniciativa GAMMA para compatibilidade com casos de uso de malha de serviço faz parte do canal padrão desde a v1.1.0 e é considerado GA.

A especificação propõe que um proprietário de 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 das funções "front-end" e "back-end" do Kubernetes Service, conforme definido em GEP-1324: malha de serviço na API Gateway, em que a função "front-end" é usada como um parentRef e a função "back-end" de Service é usada como um backendRef. A implementação em conformidade usa o nome Service para corresponder ao tráfego e os endpoints backendRef para os endereços IP canônicos.

API Gateway para malha

A API Gateway, um projeto do Kubernetes, se concentra no roteamento das camadas 4 e 7 no Kubernetes. Ela substitui as APIs Entrada, Load Balancing e Service Mesh. 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 do protocolo, como HTTPRoute e GRPCRoute, permitem roteamento avançado de entrada e 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 leste/oeste no mesmo cluster. O GAMMA tem como objetivo 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. O 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.

O GAMMA aproveita os pontos de extensibilidade atuais na especificação da API Gateway, sem exigir mudanças na API ou novos recursos. Isso é feito estendendo as definições de recursos de rota (GRPCRoute ou HTTPRoute na API Gateway) 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 do HTTPRoute

A HTTPRoute faz referência a um Service como 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 a HTTPRoute está anexada ao front-end do echo-service. Todo o tráfego enviado para echo-service por um cliente é encaminhado de acordo com a 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 escolhem 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 GRPCRoute

Assim como o exemplo de HTTPRoute, essa GRPCRoute é configurada para casos de uso de malha de serviço. Todo o 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 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 e injeções de arquivo secundário, como o Envoy, quando o prefixo xds:/// é descartado.

Diagrama de malha de cluster único

A seguir