Übersicht
Cloud Service Mesh bietet Dienstnetzwerkfunktionen für Ihre Anwendungen, einschließlich erweiterter Trafficverwaltung, Beobachtbarkeit und Sicherheit. Die Konfiguration und der Betrieb 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 sowohl für proxylose gRPC- als auch für Envoy-Proxy-Bereitstellungen konfigurieren. Die Gateway API für das Mesh-Modell bietet mehrere wichtige Vorteile:
- Gateway APIs bieten eine einzige, einheitliche Oberfläche für die Verwaltung von Traffic für den Ingress (Nord-Süd) und für das Service Mesh (Ost-West) in Ihrem Kubernetes-Cluster.
- Service Meshes ermöglichen erweiterte Traffic-Routing-Muster. Mit Gateway APIs können Sie komplexe Routingregeln entwerfen und 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 sowie die Unterstützung neuer 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.
In der Spezifikation wird vorgeschlagen, dass ein Anwendungsinhaber Traffic-Regeln für einen Mesh-Dienst konfigurieren sollte, indem er eine Route resource (manchmal auch xRoute genannt) mit einer Kubernetes-Service-Ressource als parentRef konfiguriert. Der Ansatz hängt von den „Frontend“- und „Backend“-Rollen von Kubernetes Service ab, wie in GEP-1324: Service Mesh in Gateway API definiert. Dabei wird die „Frontend“-Rolle als parentRef und die „Backend“-Rolle von Service als backendRef verwendet. Bei der konformen Implementierung wird der Name Service verwendet, um den Traffic mit den backendRef-Endpunkten für die kanonischen IP-Adressen abzugleichen.
Gateway API für Mesh
Die Gateway API ist ein Kubernetes-Projekt, das sich auf das Routing der Schicht 4 und 7 innerhalb von Kubernetes konzentriert. 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.
Protokollspezifische Ressourcen wie HTTPRoute und GRPCRoute ermöglichen erweitertes Ingress- und Mesh-Routing.
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 die Wichtigkeit, für Konsistenz zwischen verschiedenen Service Mesh-Implementierungen der Gateway API zu sorgen, unabhängig von der zugrunde liegenden Technologie oder dem Proxy.
GAMMA nutzt vorhandene Erweiterungspunkte in der Gateway API-Spezifikation, sodass keine API-Änderungen oder neuen Ressourcen erforderlich sind. Dazu werden die Definitionen der Routenressourcen (GRPCRoute oder HTTPRoute in der Gateway API) erweitert, um den Service Mesh-Anwendungsfall zu signalisieren. Insbesondere werden die Routenressourcen mit Dienstressourcen verknüpft, wie in der Gateway API für Service Mesh beschrieben.
Das folgende Beispiel veranschaulicht den Mesh-Anwendungsfall 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
Die HTTPRoute verweist auf eine Service als parentRef, was bedeutet, dass die HTTPRoute für den Anwendungsfall eines Service Mesh konfiguriert ist. 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. Der gesamte Traffic, der von einem Client an den Echo-Dienst gesendet wird, wird gemäß der HTTPRoute-Echo-Route weitergeleitet.
GRPCRoute ist eine weitere Kubernetes Gateway API-Ressource, mit der gRPC-Traffic an Kubernetes-Dienste weitergeleitet wird. Nutzer verwenden GRPCRoute anstelle von HTTPRoute, wenn sie gRPC-Traffic speziell weiterleiten und gRPC-spezifische Funktionen wie den gRPC-Methoden- und Dienstabgleich nutzen möchten.
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
Genau wie das HTTPRoute-Beispiel ist diese GRPCRoute für Anwendungsfälle von Service Mesh konfiguriert. Der gesamte Traffic, der von einem proxylosen gRPC-Client an xds:///echo-service.default.svc.cluster.local:8080 gesendet wird, wird gemäß der GRPCRoute-Echo-Route weitergeleitet. Die Routingregeln in diesem Beispiel stimmen mit einer gRPC-Methode überein und leiten den Traffic an eine bestimmte backendRef weiter. GRPCRoutes können auch verwendet werden, um Anfragen von Proxy-Clients mit Sidecar-Injections wie Envoy weiterzuleiten, wenn das Präfix xds:/// entfernt wird.
