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. Estas APIs foram projetadas para simplificar e melhorar sua experiência geral de configuração da malha.

As APIs Kubernetes Gateway para Mesh permitem configurar a Cloud Service Mesh para implantações de proxy gRPC e Envoy sem proxy. A API Gateway para modelo de mesh 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 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 roteamento complexas.
  • Com as APIs Gateway, os desenvolvedores podem se concentrar em definir regras de roteamento de alto nível e políticas para o microsserviço sem precisar de conhecimento profundo da implementação da malha de serviço.
  • A API foi projetada para ser extensível, permitindo melhorias futuras e suporte a novos protocolos e casos de uso.
  • As APIs de gateway têm um forte suporte 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 apoiar casos de uso de mesh de serviço faz parte do Canal Padrão desde a v1.1.0 e é considerado GA.

A especificação propõe que o proprietário do aplicativo configure regras de tráfego para um serviço de rede mesh configurando um Route resource (às vezes chamado de xRoute) com um recurso Service do Kubernetes como parentRef. A abordagem depende dos papéis "frontend" e "back-end" do Service do Kubernetes, conforme definido em GEP-1324: malha de serviço na API Gateway, em que o papel "frontend" é usado como parentRef e o papel "back-end" do Service é usado como backendRef. A implementação em conformidade usa o nome Service para corresponder ao tráfego e aos endpoints backendRef dos 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. Ele sucede as APIs Entrada, Load Balancing e Service Mesh. Projetado para ser versátil, descritivo e focado em função, as configurações dele estão principalmente na camada de roteamento. Recursos específicos do protocolo, como HTTPRoute e GRPCRoute, permitem o roteamento avançado de entrada e mesh.

A Iniciativa GAMMA (API Gateway para malha de serviço) define como a API Gateway também pode ser usada para tráfego interserviço ou 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. 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.

A GAMMA aproveita os pontos de extensibilidade existentes 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 na API Gateway para malha de serviço.

O exemplo a seguir ilustra o caso de uso da 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

O 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 o HTTPRoute está anexado ao front-end de echo-service. Todo tráfego enviado para echo-service por um cliente é roteado de acordo com a rota HTTPRoute echo-route.

A GRPCRoute é outro recurso da API Kubernetes Gateway, que é 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 do gRPC e aproveitar os recursos adaptados para o gRPC, como a correspondência de método e serviço do gRPC.

O exemplo a seguir ilustra o uso da 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 da GRPCRoute

Assim como no exemplo de HTTPRoute, essa GRPCRoute é configurada 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 GRPCRoute. As regras de roteamento neste exemplo correspondem a um método gRPC e roteiam o tráfego para uma backendRef específica. 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