Ü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. Das Gateway API for Mesh-Modell bietet mehrere wichtige Vorteile:
- Gateway APIs bieten eine einheitliche, konsistente Schnittstelle für die Verwaltung von Ingress-Traffic (North-South) und Service Mesh-Traffic (East-West) in Ihrem Kubernetes-Cluster.
- Service Meshs ermöglichen erweiterte Traffic-Routing-Muster. 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 detaillierte Kenntnisse der zugrunde liegenden 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 einer starken Community unterstützt und von einem wachsenden Ökosystem von Service Mesh-Anbietern und -Tools verwendet.
Die Arbeit der 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.
Die Spezifikation
schlägt vor, dass ein Anwendungsinhaber Traffic-Regeln für einen Mesh-
Dienst konfiguriert, indem er eine Route resource (manchmal auch als xRoute)
mit einer Kubernetes-Service-Ressource als parentRef konfiguriert. Der Ansatz hängt von
den Rollen „Frontend“ und „Backend“ von
Service ab, wie in
GEP-1324: Service Mesh in Gateway API definiert. Dabei wird die Rolle „Frontend“ als parentRef und die Rolle „Backend“ von
Service als backendRef verwendet. Die konforme Implementierung verwendet den Namen Service, um Traffic abzugleichen, und backendRef-Endpunkte für die kanonischen IP-Adressen.
Gateway API für Mesh
Die Gateway API ist ein Kubernetes-
Projekt, das sich auf das Routing auf Layer 4 und 7 in Kubernetes konzentriert. Sie ersetzt die Ingress-, Load-Balancing- und Service Mesh-APIs. Sie ist vielseitig, beschreibend und rollenorientiert konzipiert. Die Konfigurationen 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 Traffic zwischen Diensten oder East/West-Traffic innerhalb desselben Clusters verwendet werden kann. Ziel von GAMMA ist es, festzulegen, 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 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, ohne dass API-Änderungen oder neue Ressourcen erforderlich sind. Dazu werden die Routenressourcendefinitionen (GRPCRoute oder HTTPRoute in der Gateway API) erweitert, um den Service Mesh-Anwendungsfall zu signalisieren, insbesondere durch die Verknüpfung der Routenressourcen mit 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 einen Service als parentRef, was signalisiert, dass die HTTPRoute-Route für den Service Mesh-Anwendungsfall konfiguriert ist. Im vorherigen Beispiel ist 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 echo-service gesendet wird, wird gemäß der HTTPRoute echo-route weitergeleitet.
GRPCRoute ist eine weitere Kubernetes Gateway API-Ressource, die verwendet wird, um gRPC-Traffic an Kubernetes-Dienste weiterzuleiten. Nutzer verwenden GRPCRoute anstelle von HTTPRoute, wenn sie gRPC-Traffic speziell weiterleiten und Funktionen nutzen möchten, die auf gRPC zugeschnitten sind, z. B. gRPC-Methoden- 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
Wie im 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 Proxy-Clients mit Sidecar-Injections wie Envoy weiterzuleiten, wenn das Präfix xds:/// entfernt wird.
