Ü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 for 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 einheitliche Schnittstelle zum Verwalten von Ingress-Traffic (Nord-Süd) und Service-Mesh-Traffic (Ost-West) in Ihrem Kubernetes-Cluster.
- Service Meshes ermöglichen erweiterte Muster für das Traffic-Routing. Mit Gateway-APIs können Sie komplexe Routingregeln entwerfen und verwalten.
- Mit Gateway APIs können sich Entwickler auf die Definition von Routingregeln und Richtlinien auf hoher Ebene für ihren Mikrodienst konzentrieren, ohne dass sie detaillierte Kenntnisse der zugrunde liegenden Service Mesh-Implementierung benötigen.
- Die API ist so konzipiert, dass sie erweiterbar ist und zukünftige Verbesserungen sowie die Unterstützung neuer Protokolle und Anwendungsfälle ermöglicht.
- 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-Anwendungsfällen ist seit Version 1.1.0 Teil des Standard Channel und gilt als allgemein verfügbar.
In der Spezifikation wird vorgeschlagen, dass ein Anwendungsbesitzer Trafficregeln für einen Mesh-Dienst konfiguriert, indem er eine Route resource (manchmal auch als xRoute bezeichnet) mit einer Kubernetes-Service-Ressource als parentRef konfiguriert. Der Ansatz hängt von den Kubernetes-Rollen Service „Frontend“ und „Backend“ ab, die in GEP-1324: Service Mesh in Gateway API definiert sind. Dabei wird die Rolle „Frontend“ als parentRef und die Rolle „Backend“ von Service als backendRef verwendet. Die konforme Implementierung verwendet den Namen Service für den Abgleich von Traffic und backendRef-Endpunkte für die kanonischen IP-Adressen.
Gateway API für Mesh
Die Gateway API, ein Kubernetes-Projekt, konzentriert sich auf das Routing auf Layer 4 und 7 in Kubernetes. Sie löst die Ingress-, Load-Balancing- und Service Mesh-APIs ab. Die Konfigurationen sind vielseitig, beschreibend und rollenzentriert und befinden sich hauptsächlich in der Routing-Ebene.
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 den dienstübergreifenden oder East/West-Traffic innerhalb desselben Clusters verwendet werden kann. Ziel von GAMMA ist es, herauszufinden, wie die Gateway API verwendet werden kann, um ein Service Mesh mit minimalen Änderungen an der Gateway API zu konfigurieren und gleichzeitig die rollenorientierte Natur beizubehalten. GAMMA betont auch die Bedeutung der Förderung der Konsistenz zwischen verschiedenen Service-Mesh-Implementierungen der Gateway API, 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 Routenressourcendefinitionen (GRPCRoute oder HTTPRoute in der Gateway API) erweitert, um den Service Mesh-Anwendungsfall zu signalisieren. Dies geschieht insbesondere durch die Zuordnung der Routenressourcen zu Dienstressourcen, wie unter Gateway API for 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 Service als parentRef. Das signalisiert, dass die HTTPRoute-Route für den Service Mesh-Anwendungsfall 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 wird. 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, die zum Weiterleiten von gRPC-Traffic an Kubernetes-Dienste verwendet wird. Nutzer entscheiden sich für GRPCRoute anstelle von HTTPRoute, wenn sie speziell gRPC-Traffic weiterleiten und von Funktionen profitieren möchten, die auf gRPC zugeschnitten sind, z. B. dem Abgleich von gRPC-Methoden und ‑Diensten.
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
Wie das HTTPRoute-Beispiel ist diese GRPCRoute für Service Mesh-Anwendungsfälle 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 Routenregeln 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 Proxied-Clients mit Sidecar-Injections wie Envoy weiterzuleiten, wenn das Präfix xds:/// entfernt wird.
