Vista geral

A Cloud Service Mesh oferece capacidades de rede de serviços às suas aplicações, incluindo gestão de tráfego avançada, observabilidade e segurança. No entanto, configurar e operar uma malha de serviço é uma tarefa complexa. Esta página descreve a configuração da Cloud Service Mesh com as APIs Gateway do Kubernetes. Estas APIs foram concebidas para simplificar e melhorar a sua experiência geral de configuração de malhas.

As APIs Kubernetes Gateway para a malha permitem-lhe configurar a Cloud Service Mesh para implementações de proxy Envoy e gRPC sem proxy. A API Gateway para o modelo de malha oferece várias vantagens importantes:

  • As APIs Gateway oferecem uma interface única e consistente para gerir o tráfego de entrada (norte-sul) e de malha de serviços (este-oeste) no cluster do Kubernetes.
  • As malhas de serviço permitem padrões de encaminhamento de tráfego avançados. As APIs de gateway permitem-lhe criar e gerir regras de encaminhamento complexas.
  • Com as APIs Gateway, os programadores podem concentrar-se na definição de regras de encaminhamento de alto nível e políticas para o respetivo microsserviço sem precisar de conhecimentos detalhados da implementação da malha de serviços subjacente.
  • A API foi concebida para ser extensível, o que permite melhorias futuras e suporte para novos protocolos e exemplos de utilização.
  • As APIs Gateway têm um forte apoio da comunidade e são suportadas por um ecossistema crescente de fornecedores e ferramentas de malha de serviços.

O trabalho da iniciativa GAMMA para apoiar exemplos de utilização da malha de serviços faz parte do canal padrão desde a versão 1.1.0 e é considerado GA.

A especificação propõe que o proprietário de uma aplicação configure regras de tráfego para um serviço de malha configurando um Route resource (por vezes, denominado xRoute) com um recurso Service do Kubernetes como parentRef. A abordagem depende das funções de "frontend" e "backend" do Kubernetes Service, conforme definido em GEP-1324: Service Mesh in Gateway API, onde a função de "frontend" é usada como parentRef e a função de "backend" de Service é usada como backendRef. A implementação em conformidade usa o nome Service para fazer corresponder o tráfego e os pontos finais backendRef aos endereços IP canónicos.

API Gateway para Mesh

A API Gateway, um projeto do Kubernetes, foca-se no encaminhamento das camadas 4 e 7 no Kubernetes. Sucede às APIs Ingress, Load Balancing e Service Mesh. Concebida para ser versátil, descritiva e centrada em funções, as suas configurações encontram-se principalmente na camada de encaminhamento. Os recursos específicos do protocolo, como HTTPRoute e GRPCRoute, permitem a entrada e o encaminhamento de malha avançados.

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

A GAMMA tira partido dos pontos de extensibilidade existentes na especificação da API Gateway, não exigindo alterações à API nem novos recursos. Isto é feito através da extensão das definições de recursos de rotas (GRPCRoute ou HTTPRoute na API Gateway) para sinalizar o exemplo de utilização da malha de serviços, especificamente associando os recursos de rotas a recursos de serviços, conforme descrito na API Gateway para malha de serviços.

O exemplo seguinte ilustra o exemplo de utilização da malha na utilização 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 HTTPRoute

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

GRPCRoute é outro recurso da API Kubernetes Gateway, que é usado para encaminhar o tráfego gRPC para serviços Kubernetes. Os utilizadores optam por usar GRPCRoute em vez de HTTPRoute quando querem encaminhar especificamente o tráfego gRPC e tirar partido de funcionalidades personalizadas para gRPC, como a correspondência de serviços e métodos gRPC.

O exemplo seguinte ilustra a utilização 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

Tal como no exemplo de HTTPRoute, esta GRPCRoute está configurada para exemplos de utilização de malha de serviço. Qualquer tráfego enviado para xds:///echo-service.default.svc.cluster.local:8080 por um cliente gRPC sem proxy é encaminhado de acordo com a rota de eco GRPCRoute. As regras de encaminhamento neste exemplo correspondem a um método gRPC e encaminham o tráfego para um backendRef específico. Também é possível usar GRPCRoutes para encaminhar pedidos de clientes com proxy com injeções de sidecar, como o Envoy, quando o prefixo xds:/// é ignorado.

Diagrama de malha de cluster único

O que se segue?