Ü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 die Konfiguration von Cloud Service Mesh mit den Kubernetes Gateway APIs beschrieben. 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 (Nord-Süd) und Service Mesh-Traffic (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 sich Entwickler auf die Definition von allgemeinen Routingregeln und Richtlinien für ihren Mikrodienst konzentrieren, ohne dass sie über umfassende Kenntnisse der zugrunde liegenden Service Mesh-Implementierung verfügen müssen.
- Die API ist erweiterbar, sodass zukünftige Verbesserungen und die Unterstützung neuer Protokolle und Anwendungsfälle möglich sind.
- Gateway APIs werden von einer starken Community unterstützt und von einem wachsenden Ökosystem von Service Mesh-Anbietern und -Tools unterstützt.
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 Anwendungsinhaber Trafficregeln für einen Mesh-Dienst konfigurieren sollte, indem er eine Route resource (manchmal auch als xRoute bezeichnet) 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. Die konforme Implementierung verwendet den Namen Service, um Traffic abzugleichen, und die Endpunkte backendRef für die kanonischen IP-Adressen.
Gateway API für Mesh
Die Gateway API, ein Kubernetes-Projekt, konzentriert sich auf das Layer-4- und Layer-7-Routing in Kubernetes. Sie ist der Nachfolger von Ingress-, Load Balancing- und Service Mesh-APIs. Die Konfigurationen sind vielseitig, beschreibend und rollenbasiert 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 Ost-West-Traffic innerhalb desselben Clusters verwendet werden kann. GAMMA soll festlegen, wie die Gateway API verwendet wird, um ein Service Mesh mit minimalen Änderungen an der Gateway API zu konfigurieren, während die rollenorientierte Natur beibehalten wird. GAMMA betont auch, wie wichtig es ist, die Konsistenz zwischen verschiedenen Service Mesh-Implementierungen der Gateway API zu fördern, 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. Dazu werden die Routenressourcen mit Service-Ressourcen verknüpft, wie unter 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. Das bedeutet, 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 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 zum Weiterleiten von gRPC-Traffic an Kubernetes-Dienste verwendet wird. Nutzer verwenden GRPCRoute anstelle von HTTPRoute, wenn sie gRPC-Traffic gezielt 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
Genau 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 entsprechen einer gRPC-Methode und leiten den Traffic an einen bestimmten backendRef weiter. GRPCRoutes können auch verwendet werden, um Anfragen von Proxy-Clients mit Sidecar-Injektionen wie Envoy weiterzuleiten, wenn das Präfix xds:/// weggelassen wird.
