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 a APIs de gateway. 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 o modelo de malha oferece vários benefícios importantes:

  • As APIs de gateway oferecem uma interface única e consistente para gerenciar tráfego (norte-sul) e malha de serviço (leste-oeste) no Kubernetes cluster.
  • As malhas de serviço permitem padrões avançados de roteamento de tráfego. As APIs de gateway permitem criar 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.

A iniciativa GAMMA trabalha para o suporte a casos de uso de malha de serviço faz parte do Canal Standard desde v1.1.0 e é considerado GA.

A especificação propõe que um proprietário de aplicativo deve configurar regras de tráfego para uma malha serviço 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 Ingress, 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. Os recursos específicos de protocolo, como HTTPRoute e GRPCRoute, ativam recursos avançados roteamento 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 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 e manter os papéis orientados pelo papel natureza. 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. Para isso, é preciso estender o recurso de rota (GRPCRoute ou HTTPRoute no API Gateway) para sinalizar o caso de uso da malha de serviço, especificamente associando os recursos de rota com os recursos de serviço, conforme descrito em 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 GRPCRoute

Assim como no exemplo de HTTPRoute, esse GRPCRoute é configurado para a em diferentes casos de uso de negócios. 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