Übersicht

Cloud Service Mesh bietet Dienstnetzwerkfunktionen für Ihr einschließlich erweiterter Traffic-Verwaltung, Beobachtbarkeit und Sicherheit. Das Konfigurieren und Betreiben eines Service Mesh ist jedoch eine komplexe Aufgabe. Diese Seite beschreibt das Konfigurieren des Cloud Service Mesh mit Kubernetes Gateway APIs Diese APIs wurden entwickelt, um Ihr gesamtes Mesh-Netzwerk zu vereinfachen und zu verbessern. Konfiguration.

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, konsistente Schnittstelle zur Verwaltung beider (North-south) und Service Mesh (east-west)-Traffic innerhalb Ihrer Kubernetes-Umgebung Cluster.
  • Service Meshes ermöglichen erweiterte Traffic-Routingmuster. Gateway APIs ermöglichen um komplexe Routingregeln zu entwerfen und zu verwalten.
  • Mit Gateway APIs können sich Entwickler auf das Definieren von Routingregeln auf hoher Ebene konzentrieren und Richtlinien auf ihren Mikrodienst anwenden, ohne eines zugrunde liegenden Service Mesh.
  • Die API ist erweiterbar, sodass zukünftige Verbesserungen und Unterstützung für neue Protokolle und Anwendungsfälle.
  • Gateway APIs stützen sich auf die Community und werden von Service-Mesh-Anbieter und -Tools.

Die GAMMA-Initiative arbeitet für Support-Mesh-Anwendungsfälle gehören seit jeher zum Standardkanal Version 1.1.0 und gilt als allgemein verfügbar.

Die Spezifikation 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, wobei 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. Es ist mit Ingress erfolgreich, Load Balancing und Service Mesh APIs. Vielseitig, anschaulich, und rollenzentriert sind, befinden sich die Konfigurationen hauptsächlich auf der Routingebene. Protokollspezifische Ressourcen wie HTTPRoute und GRPCRoute ermöglichen erweiterte Funktionen. Ingress- und Mesh-Routing.

Die GAMMA-Initiative (Gateway API) für Service Mesh) definiert, wie die Gateway API auch für dienstübergreifende Dienste verwendet werden kann. oder Ost-/Westverkehr innerhalb desselben Clusters. Ziel von GAMMA ist es, festzulegen, wie die Gateway API genutzt werden kann, um ein Service Mesh mit minimalen Änderungen an der Gateway API konfigurieren, während Die Aufrechterhaltung der rollenorientierten die Natur. GAMMA betont auch, wie wichtig es ist, die Einheitlichkeit zwischen Service-Mesh-Implementierungen der Gateway API, unabhängig von zugrunde liegende 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 beispielsweise die Routenressourcen mit Dienstressourcen, wie in Gateway API für Service Mesh.

Das folgende Beispiel veranschaulicht den Anwendungsfall eines Mesh-Netzwerks bei 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 Der Dienst "echo-service" wird als parentRef angegeben, was bedeutet, dass HTTPRoute wird an das Front-End von echo-service angehängt. Jeglicher Traffic, der gesendet wird an Echo-Dienst eines Clients wird entsprechend der HTTPRoute-Echoroute weitergeleitet.

GRPCRoute ist eine weitere Kubernetes Gateway API-Ressource, die für das Routing von gRPC-Traffic zu Kubernetes-Diensten. Nutzer verwenden GRPCRoute statt HTTPRoute verwenden, wenn gRPC-Traffic spezifisch weitergeleitet und von 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

GRPC-Routendiagramm

Genau wie das HTTPRoute-Beispiel ist diese GRPC-Route für ein Service Mesh konfiguriert. Anwendungsfälle. 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 Übereinstimmung mit einer gRPC-Methode und leiten den Traffic an eine bestimmte backendRef. GRPC-Routen können auch zum Weiterleiten von Anfragen von Proxy-Clients mit Sidecar-Einschleusungen wie Envoy, wenn das Präfix xds:/// wird verworfen.

Diagramm: Single-Cluster-Mesh

Nächste Schritte