Übersicht

Cloud Service Mesh bietet Dienstnetzwerkfunktionen für Ihre Anwendungen, einschließlich erweiterter Trafficverwaltung, Beobachtbarkeit und Sicherheit. Das Konfigurieren und Betreiben eines Service Mesh ist jedoch eine komplexe Aufgabe. Auf dieser Seite wird beschrieben, wie Sie Cloud Service Mesh mit den Kubernetes Gateway APIs konfigurieren. Die APIs wurden entwickelt, um die Mesh-Konfiguration insgesamt zu vereinfachen und zu verbessern.

Mit den Kubernetes Gateway APIs für Mesh können Sie Cloud Service Mesh für sowohl proxylose gRPC- als auch Envoy-Proxy-Bereitstellungen. Das Modell „Gateway API for Mesh“ bietet mehrere entscheidende Vorteile:

  • Gateway APIs bieten eine einzige, einheitliche Oberfläche für die Verwaltung von Traffic für den Ingress (Nord-Süd) und den Service Mesh (Ost-West) in Ihrem Kubernetes-Cluster.
  • Service Meshes ermöglichen erweiterte Traffic-Routing-Muster. Gateway APIs ermöglichen um komplexe Routingregeln zu entwerfen und zu verwalten.
  • Mit Gateway APIs können Entwickler sich darauf konzentrieren, Routingregeln und ‑richtlinien auf hoher Ebene für ihren Mikrodienst zu definieren, ohne fundiertes Wissen über die zugrunde liegende Service Mesh-Implementierung zu benötigen.
  • Die API ist erweiterbar und ermöglicht zukünftige Verbesserungen und Unterstützung für neue Protokolle und Anwendungsfälle.
  • Gateway-APIs werden von der Community stark unterstützt und von einem wachsenden Ökosystem von Service Mesh-Anbietern und ‑Tools unterstützt.

Die GAMMA-Initiative zur Unterstützung von Service Mesh-Use-Cases ist seit Version 1.1.0 Teil des Standardkanals und gilt als GA.

Die spec schlägt vor, dass ein Anwendungsinhaber Trafficregeln für ein Mesh konfigurieren soll -Dienst durch Konfigurieren eines Route resource (auch als xRoute bezeichnet) mit einer Kubernetes-Service-Ressource als parentRef. Der Ansatz hängt davon ab, „Frontend“ von Kubernetes Service und "Backend" Rollen wie in den GEP-1324: Service Mesh in der Gateway API, Dabei ist das "frontend" Rolle wird als parentRef und das "Back-End" verwendet Rolle von Service wird als backendRef verwendet. Die konforme Implementierung verwendet die Name von Service, um Traffic und backendRef Endpunkte für die kanonische IP-Adresse abzugleichen Adressen.

Gateway API für Mesh

Gateway API, ein Kubernetes konzentriert sich auf das Layer-4- und Layer-4-und-7-Routing in Kubernetes. Sie folgt den Ingress-, Load Balancing- und Service Mesh APIs. Sie sind vielseitig, beschreibend und rollenorientiert und ihre Konfigurationen befinden sich hauptsächlich in der Routingschicht. Mit protokollspezifischen Ressourcen wie HTTPRoute und GRPCRoute können Sie erweitertes Ingress- und Mesh-Routing nutzen.

Die GAMMA-Initiative (Gateway API for Service Mesh) definiert, wie die Gateway API auch für dienstinternen oder East/West-Traffic innerhalb desselben Clusters verwendet werden kann. GAMMA zielt darauf ab, zu ermitteln, wie mit der Gateway API ein Service Mesh mit minimalen Änderungen an der Gateway API konfiguriert werden kann, wobei die rollenorientierte Natur beibehalten wird. GAMMA betont auch, wie wichtig es ist, die Einheitlichkeit zwischen Service-Mesh-Implementierungen der Gateway API, unabhängig von zugrunde liegender Technologie oder Proxy.

GAMMA nutzt die vorhandenen Erweiterbarkeitspunkte in der Gateway API-Spezifikation, wobei Folgendes erforderlich ist: keine API-Änderungen oder neue Ressourcen. Dazu wird die Routenressource erweitert, Definitionen (GRPCRoute oder HTTPRoute im Feld Gateway API), um den Anwendungsfall des Service Mesh zu signalisieren, indem Sie die Routenressourcen mit Dienstressourcen, wie in Gateway API für Service Mesh.

Das folgende Beispiel veranschaulicht den Anwendungsfall für ein Mesh bei der Verwendung von 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

HTTPRoute-Diagramm

Die HTTPRoute verweist als ihr parentRef auf eine Service, was signalisiert, dass die Die HTTPRoute-Route ist für den Anwendungsfall eines Service Mesh konfiguriert. Im vorherigen Beispiel wird der Dienst „echo-service“ als parentRef angegeben. Das bedeutet, dass die HTTPRoute an das Frontend von „echo-service“ angehängt ist. Jeglicher Traffic, der gesendet wird an Echo-Dienst eines Clients wird gemäß der HTTPRoute-Echoroute weitergeleitet.

GRPCRoute ist eine weitere Kubernetes Gateway API-Ressource, mit der gRPC-Traffic an Kubernetes-Dienste weitergeleitet wird. Nutzer verwenden GRPCRoute statt HTTPRoute verwenden, wenn gRPC-Traffic gezielt weitergeleitet und von Vorteil wie gRPC-Methode und Dienstabgleich.

Das folgende Beispiel veranschaulicht die Verwendung von 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

GRPCRoute-Diagramm

Genau wie das HTTPRoute-Beispiel ist diese GRPCRoute für Anwendungsfälle von Service Mesh konfiguriert. Alle Zugriffe, die an xds:///echo-service.default.svc.cluster.local:8080 gesendet wurden von einem proxylosen gRPC-Client gemäß der GRPCRoute-Echo-Route weitergeleitet wird. Die Routingregeln in diesem Beispiel stimmen mit einer gRPC-Methode überein und leiten den Traffic an eine bestimmte backendRef weiter. GRPC-Routen können auch zum Weiterleiten von Anfragen von Clients, die per Proxy mit Sidecar-Einschleusungen weitergeleitet werden, wie Envoy, wenn das Präfix xds:/// wird verworfen.

Diagramm: Single-Cluster-Mesh

Nächste Schritte