Ü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. Diese APIs sollen die Mesh-Konfiguration insgesamt vereinfachen und 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 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-Channels und gilt als allgemein verfügbar.
Die Spezifikation
schlägt vor, dass ein Anwendungsbesitzer 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, ein Kubernetes
Projekt, konzentriert sich auf das Routing auf Layer 4 und 7 in Kubernetes. Sie ersetzt die Ingress-, Load-Balancing- und Service Mesh-APIs. Sie ist vielseitig, beschreibend und rollenorientiert konzipiert. Die Konfigurationen befinden sich hauptsächlich auf 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, 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 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. Dies geschieht durch die Erweiterung der Routenressourcendefinitionen (GRPCRoute oder HTTPRoute in der Gateway API), 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 gezielt weiterleiten und Funktionen nutzen möchten, die speziell für gRPC entwickelt wurden, 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 proxylosen Clients mit Sidecar-Injections wie Envoy weiterzuleiten, wenn das Präfix xds:/// entfernt wird.
