Cloud Service Mesh – Übersicht
Dieses Dokument richtet sich an Netzwerkadministratoren und Dienstinhaber, die sich mit Cloud Service Mesh und seinen Funktionen vertraut machen möchten. Dieses Dokument bezieht sich auf Konfigurationen, bei denen die Load Balancing APIs verwendet werden.
Cloud Service Mesh ist eine verwaltete Steuerungsebene für das Anwendungsnetzwerk. Mit Cloud Service Mesh können Sie globale, hochverfügbare Dienste mit erweiterten Funktionen für das Anwendungsnetzwerk wie Trafficverwaltung und -beobachtbarkeit bereitstellen.
Bei wachsender Anzahl der Dienste und Mikrodienste in einer Bereitstellung ergeben sich in der Regel bestimmte Fragen in Bezug auf das Anwendungsnetzwerk:
- Wie kann ich die Stabilität meiner Dienste verbessern?
- Wie kann ich Traffic zu meinen Diensten ausführen und wie können die Dienste miteinander kommunizieren?
- Wie kann ich nachvollziehen, was passiert, wenn meine Dienste miteinander kommunizieren?
- Wie aktualisiere ich meine Dienste, ohne einen Ausfall zu riskieren?
- Wie verwalte ich die Infrastruktur, die meine Bereitstellung ermöglicht?
Cloud Service Mesh bietet eine Unterstützung für diese Fragestellungen in einem modernen, dienstbasierten Deployment. Cloud Service Mesh basiert auf der von Google Cloud verwalteten Infrastruktur, sodass Sie keine eigene Infrastruktur verwalten müssen. Sie können so Ihren Schwerpunkt auf die Bereitstellung des Anwendungscodes für Ihre geschäftlichen Problemstellungen legen, während Cloud Service Mesh die Komplexität der Anwendungsnetzwerke steuert.
Cloud Service Mesh
Eine gängige Methode zur Behebung von Problemen des Anwendungsnetzwerks ist die Verwendung eines Service Mesh. Cloud Service Mesh unterstützt Service Mesh und andere Bereitstellungsmuster, die Ihren Anforderungen entsprechen.
In einem typischen Service Mesh gilt Folgendes:
- Sie stellen Ihre Dienste in einem Kubernetes-Cluster bereit.
- Jeder Pod der Dienste hat einen dedizierten Proxy (in der Regel Envoy), der als Sidecar-Proxy ausgeführt wird.
- Jeder Sidecar-Proxy kommuniziert mit der Netzwerkinfrastruktur (die Steuerungsebene), die in Ihrem Cluster installiert ist. Die Steuerungsebene gibt an die Sidecar-Proxys Informationen zu Diensten, Endpunkten und Richtlinien in Ihrem Service Mesh weiter.
- Wenn ein Pod eine Anfrage sendet oder empfängt, wird die Anfrage an den Sidecar-Proxy des Pods weitergeleitet. Der Sidecar-Proxy verarbeitet dann die Anfrage, z. B. durch Senden an das vorgesehene Ziel.
In den Diagrammen in diesem Dokument und anderen Cloud Service Mesh-Dokumenten stellen die sechsseitigen rosa Symbole die Proxys dar. Die Steuerungsebene ist mit jedem Proxy verbunden und stellt die Informationen bereit, die die Proxys zur Verarbeitung von Anfragen benötigen. Pfeile zwischen Feldern zeigen den Traffic-Fluss an. Mit dem Anwendungscode in Service A wird beispielsweise eine Anfrage gesendet. Der Proxy verarbeitet diese Anfrage und leitet sie an Service B weiter.
Mit diesem Modell lässt sich die Netzwerklogik aus Ihrem Anwendungscode herausnehmen. Sie können sich so auf die Unterstützung des Geschäftsbetriebs konzentrieren, während die Infrastruktur für das Deployment eines funktionsfähigen Anwendungsnetzwerks sorgt.
Unterschiede zu Cloud Service Mesh
Cloud Service Mesh funktioniert ähnlich wie dieses Modell, unterscheidet sich aber in wichtigen Punkten. Der Hauptunterschied besteht darin, dass Cloud Service Mesh ein von Google Cloud verwalteter Dienst ist. Sie installieren ihn nicht, er wird nicht in Ihrem Cluster ausgeführt und muss nicht verwaltet werden.
Im folgenden Diagramm stellt Cloud Service Mesh die Steuerungsebene dar. In diesem Kubernetes-Cluster gibt es vier Dienste jeweils mit Sidecar-Proxys, die mit Cloud Service Mesh verbunden sind. Cloud Service Mesh stellt die Informationen bereit, die die Proxys zum Weiterleiten von Anfragen benötigen. Beispielsweise sendet der Anwendungscode auf einem Pod, der zu Service A gehört, eine Anfrage. Der neben diesem Pod ausgeführte Sidecar-Proxy verarbeitet die Anfrage und leitet sie an einen Pod weiter, der zu Service B gehört.
Jenseits eines Service Mesh
Cloud Service Mesh unterstützt mehr Deployment-Typen als ein typisches Service Mesh.
Multi-Cluster-Kubernetes
Mit Cloud Service Mesh können Sie ein Anwendungsnetzwerk nutzen, das auch zwischen Kubernetes-Clustern funktioniert. Im folgenden Diagramm stellt Cloud Service Mesh die Steuerungsebene für Kubernetes-Cluster in us-central1 und europe-west1 bereit.
Anfragen können zwischen den drei Diensten in us-central1, den beiden Diensten in europe-west1 und zwischen den Diensten in den beiden Clustern weitergeleitet werden.
Ihr Service Mesh kann sich über mehrere Kubernetes-Cluster in mehreren Google Cloud-Regionen erstrecken. Dienste in einem Cluster haben die Möglichkeit, mit Diensten in einem anderen Cluster zu kommunizieren. Sie können auch Dienste verwenden, die aus Pods in mehreren Clustern bestehen.
Mit dem auf Nachbarschaft ausgerichteten globalen Load Balancing von Cloud Service Mesh werden Anfragen für Service B an den nächstgelegenen Pod weitergeleitet, der die Anfrage verarbeiten kann. Außerdem profitieren Sie von einem nahtlosen Failover: Wenn ein Pod ausfällt, wird für die Anfrage automatisch ein Failover zu einem anderen Pod ausgeführt, der die Anfrage verarbeiten kann, auch wenn sich dieser Pod in einem anderen Kubernetes-Cluster befindet.
Virtuelle Maschinen
Kubernetes wird zwar immer beliebter, doch werden viele Arbeitslasten auf VM-Instanzen (virtuelle Maschinen) bereitgestellt. Cloud Service Mesh kann auch für diese Arbeitslasten als Steuerungsebene des Anwendungsnetzwerks dienen. Ihre VM-basierten Arbeitslasten lassen sich damit problemlos mit Ihren Kubernetes-basierten Arbeitslasten verknüpfen.
Im folgenden Diagramm gelangt der Traffic über den externen Application Load Balancer in Ihre Bereitstellung. Der Traffic wird zu Service A im Kubernetes-Cluster in asia-southeast1 und zu Service D auf einer VM in europe-west1 weitergeleitet.
Google bietet ein automatisiertes Verfahren zum Einrichten VM-basierter Arbeitslasten mit Cloud Service Mesh. Sie fügen der Compute Engine-VM-Instanzvorlage lediglich ein Flag hinzu und Google kümmert sich um die Einrichtung der Infrastruktur. Zu dieser Einrichtung gehören auch die Installation und die Konfiguration der Proxys, die Funktionen für das Anwendungsnetzwerk bereitstellen.
Proxylose gRPC-Dienste
gRPC ist ein Open-Source-RPC-Framework mit großem Funktionsumfang, mit dem Sie leistungsstarke Mikrodienste programmieren können. Mit Cloud Service Mesh können Sie Funktionen für das Anwendungsnetzwerk wie Diensterkennung, Load Balancing und Trafficverwaltung in gRPC-Anwendungen einbinden. Weitere Informationen finden Sie unter Cloud Service Mesh und gRPC – proxylose Dienste für Ihr Service Mesh.
Im folgenden Diagramm wird dargestellt, wie gRPC-Anwendungen Traffic an Dienste in Kubernetes-Clustern in einer Region sowie an Dienste weiterleiten, die auf VMs in verschiedenen Regionen ausgeführt werden. Zwei der Dienste nutzen Sidecar-Proxys, alle anderen werden ohne Proxy ausgeführt.
Cloud Service Mesh unterstützt proxylose gRPC-Dienste. Diese Dienste verwenden eine aktuelle Version der Open-Source-gRPC-Bibliothek, die die xDS APIs unterstützt. Ihre gRPC-Anwendungen können über dieselben xDS APIs, die Envoy verwendet, eine Verbindung zu Cloud Service Mesh herstellen.
Nachdem Ihre Anwendungen verbunden wurden, stellt die gRPC-Bibliothek die Funktionalität des Anwendungsnetzwerks bereit, z. B. für Diensterkennung, Load-Balancing und Trafficverwaltung. Diese Funktionen werden nativ in gRPC ausgeführt, sodass keine Dienstproxys erforderlich sind. Sie werden deshalb als proxylose gRPC-Anwendungen bezeichnet.
Eingehender Traffic und Gateways
Für viele Anwendungsfälle muss [Traffic von Clients verarbeitet werden, die nicht von Cloud Service Mesh konfiguriert sind. Beispielsweise kann der eingehende öffentliche Internettraffic zu Ihren Mikrodiensten weitergeleitet werden. Sie haben auch die Möglichkeit, einen Load-Balancer als Reverse-Proxy zu konfigurieren, der den Traffic von einem Client verarbeitet, bevor er an ein Ziel gesendet wird.
Im folgenden Diagramm ermöglicht ein externer Application Load Balancer eingehenden Traffic an externe Clients, wobei der Traffic an Dienste in einem Kubernetes-Cluster weitergeleitet wird. Ein interner Application Load Balancer leitet internen Traffic an den auf der VM ausgeführten Dienst weiter.
Cloud Service Mesh arbeitet mit Cloud Load Balancing zusammen, um eine verwaltete Umgebung für eingehenden Traffic bereitzustellen. Dazu richten Sie einfach einen externen oder internen Load-Balancer ein und konfigurieren diesen so, dass Traffic an die Mikrodienste gesendet wird. Im obigen Diagramm erreichen öffentliche Internetclients Ihre Dienste über den externen Application Load Balancer. Clients wie etwa Mikrodienste, die sich in Ihrem VPC-Netzwerk (Virtual Private Cloud) befinden, verwenden einen internen Application Load Balancer, um Ihre Dienste zu erreichen.
Für einige Anwendungsfälle sollten Sie Cloud Service Mesh einrichten, um damit ein Gateway zu konfigurieren. Ein Gateway ist im Wesentlichen ein Reverse-Proxy, der in der Regel Envoy auf einer oder mehreren VMs ausführt, womit eingehende Anfragen überwacht, verarbeitet und an ein Ziel gesendet werden. Das Ziel kann sich in einer beliebigen Google Cloud-Region oder in einem GKE-Cluster (Google Kubernetes Engine) befinden. Es kann aber auch ein Ziel außerhalb von Google Cloud sein, das über Hybridkonnektivität in Google Cloud erreichbar ist. Weitere Informationen dazu, wann Sie ein Gateway verwenden sollten, finden Sie unter Eingehender Traffic für Ihr Mesh.
Im folgenden Diagramm wird dargestellt, wie eine VM in der Region europe-west1 einen Proxy ausführt, der als Gateway für drei Dienste dient, die keine Proxys ausführen. Traffic von einem externen Application Load Balancer und einem internen Application Load Balancer wird an das Gateway und dann an die drei Dienste weitergeleitet.
Mehrere Umgebungen
Ob Sie nun Dienste in Google Cloud, lokal und/oder in anderen Clouds bereitstellen: Die grundlegenden Problemstellungen für Anwendungsnetzwerke sind jeweils die gleichen. Wie wird Traffic an diese Dienste geleitet? Und wie kommunizieren diese Dienste miteinander?
Das folgende Diagramm zeigt, wie Cloud Service Mesh den Traffic von Diensten, die in Google Cloud ausgeführt werden, zu Service G in einer anderen öffentlichen Cloud und zu Service E sowie zu Service F in einem lokalen Rechenzentrum weiterleitet.
Service A, Service B und Service C verwenden Envoy als Sidecar-Proxy, während Service D ein proxyloser gRPC-Dienst ist.
Mit Cloud Service Mesh können Sie Anfragen an Ziele außerhalb von Google Cloud senden. Damit haben Sie die Möglichkeit, mithilfe von Cloud Interconnect oder Cloud VPN Traffic von Diensten innerhalb von Google Cloud privat an Dienste oder Gateways in anderen Umgebungen weiterzuleiten.
Cloud Service Mesh einrichten
Die Einrichtung von Cloud Service Mesh umfasst zwei Schritte. Nach Abschluss der Einrichtung wird das Anwendungsnetzwerk von der Infrastruktur verwaltet. Cloud Service Mesh sorgt dafür, dass Änderungen des Deployments immer aktuell übernommen werden.
Anwendungen bereitstellen
Als Erstes stellen Sie Ihren Anwendungscode für Container oder VMs bereit. Google bietet die Verfahren, mit denen Sie Ihren VM-Instanzen und Pods die Infrastruktur für ein Anwendungsnetzwerk (in der Regel Envoy-Proxys) hinzufügen können. Diese Infrastruktur ist so eingerichtet, dass sie mit Cloud Service Mesh kommuniziert und damit Informationen über Ihre Dienste erfasst.
Cloud Service Mesh konfigurieren
Als Nächstes konfigurieren Sie Ihre globalen Dienste und legen dabei fest, wie der Traffic verarbeitet werden soll. Sie können Cloud Service Mesh unter Verwendung der Google Cloud Console (für einige Features und Konfigurationen), der Google Cloud CLI, der Traffic Director API oder anderer Tools wie Terraform konfigurieren.
Nach Ausführung dieser Schritte lässt sich mit Cloud Service Mesh die Infrastruktur Ihres Anwendungsnetzwerks konfigurieren.
Infrastruktur verwaltet Anwendungsnetzwerke
Wenn eine Anwendung eine Anfrage an my-service sendet, wird die Anfrage von der Infrastruktur Ihres Anwendungsnetzwerks (z. B. von einem Envoy-Sidecar-Proxy) gemäß den Informationen von Cloud Service Mesh verarbeitet. Dadurch lässt sich eine Anfrage für my-service nahtlos an eine Anwendungsinstanz weiterleiten, die in der Lage ist, die Anfrage zu empfangen.
Monitoring und kontinuierliche Updates
Cloud Service Mesh überwacht die Anwendungsinstanzen, aus denen Ihre Dienste bestehen. So kann Cloud Service Mesh feststellen, ob ein Dienst fehlerfrei ausgeführt wird oder ob sich die Kapazität eines Dienstes geändert hat, z. B. wenn ein neuer Kubernetes-Pod erstellt wurde. Anhand dieser Informationen aktualisiert Cloud Service Mesh kontinuierlich die Infrastruktur Ihres Anwendungsnetzwerks.
Features
Die Funktionen von Cloud Service Mesh bieten Ihren Mikrodiensten eine Funktionalität für Anwendungsnetzwerke. Im folgenden Abschnitt werden einige wichtige Features erläutert.
Vollständig verwaltete Steuerungsebene, Systemdiagnose und Load-Balancing
Sie möchten sich auf die Unterstützung des Geschäftsbetriebs konzentrieren und nicht die Infrastruktur verwalten müssen. Cloud Service Mesh ist eine vollständig verwaltete Lösung. Sie müssen also keine eigene Infrastruktur installieren, konfigurieren oder aktualisieren. Dabei profitieren Sie von derselben Infrastruktur, die Google für Systemdiagnosen und globales Load-Balancing nutzt.
Open-Source-Produkte als Grundlage
Cloud Service Mesh nutzt die gleiche Steuerungsebene (xDS APIs), die beliebte Open-Source-Projekte wie Envoy und Istio verwenden. Informationen zu den unterstützten API-Versionen finden Sie unter APIs der xDS-Steuerungsebene.
Die Infrastruktur für Anwendungsnetzwerkfunktionen – je nach Anwendungsfall entweder Envoy oder gRPC – ist Open Source-basiert. Sie laufen also nicht Gefahr, den Beschränkungen einer firmeneigenen Infrastruktur ausgesetzt zu sein.
Skalieren
Von einmaligen Lösungen für Anwendungsnetzwerke bis zu umfangreichen Service Mesh-Deployments mit Tausenden von Diensten ist Cloud Service Mesh optimal für Ihre Skalierungsanforderungen ausgelegt.
Diensterkennung und Tracking von Endpunkten sowie von Back-Ends
Wenn Ihre Anwendung eine Anfrage an my-service sendet, verarbeitet die Infrastruktur die Anfrage nahtlos und sendet sie an das richtige Ziel. Ihre Anwendung benötigt dafür keine Informationen über IP-Adressen, Protokolle oder andere Netzwerkkomplexitäten.
Globales Load-Balancing und Failover
Cloud Service Mesh nutzt das globale Load Balancing und die Systemdiagnosefunktion von Google, um Traffic optimal anhand von Client- und Back-End-Standort, Back-End-Nähe, Systemdiagnose und Kapazität zu verteilen. Damit wird auch die Dienstverfügbarkeit verbessert, da für Traffic automatisch ein Failover an fehlerfreie Back-Ends mit Kapazität ausgeführt wird. Sie können das Load Balancing anpassen, um den Traffic so zu verteilen, dass er Ihren geschäftlichen Anforderungen entspricht.
Trafficverwaltung
Mit erweiterter Trafficverwaltung einschließlich Routing- und Anfragebearbeitung (anhand von Hostname, Pfad, Headern, Cookies usw.) können Sie festlegen, wie Traffic zwischen Ihren Diensten geleitet wird. Außerdem haben Sie die Möglichkeit, Aktionen wie wiederholte Versuche, Weiterleitungen und gewichtete Trafficaufteilung für Canary-Deployments anzuwenden. Erweiterte Methoden wie Fehlerinjektion, Trafficspiegelung und Ausreißererkennung ermöglichen DevOps-Anwendungsfälle, mit denen die Ausfallsicherheit erhöht wird.
Beobachtbarkeit
Die Netzwerkinfrastruktur Ihrer Anwendung erfasst Telemetrieinformationen wie Messwerte, Logs und Traces, die zentral in Google Cloud Observability zusammengefasst werden können. Nachdem diese Informationen gesammelt wurden, können Sie Einblicke gewinnen und Benachrichtigungen erstellen, damit Sie informiert werden, wenn etwas schief läuft.
VPC Service Controls
Mit VPC Service Controls können Sie die Sicherheit der Ressourcen und Dienste Ihrer Anwendung erhöhen. Sie können Projekte zu Dienstperimetern hinzufügen, die Ressourcen und Dienste (z. B. Cloud Service Mesh) vor Anfragen schützen, die ihren Ursprung außerhalb des Perimeters haben. Weitere Informationen zu VPC Service Controls finden Sie in der Übersicht zu VPC Service Controls.
Weitere Informationen zur Verwendung von Cloud Service Mesh mit VPC Service Controls finden Sie auf der Seite Unterstützte Produkte.
Nächste Schritte
Dieses Dokument bezieht sich hauptsächlich auf die Load Balancing APIs. Wir empfehlen dringend, Cloud Service Mesh nicht mit den Load Balancing APIs zu konfigurieren.
So stellen Sie Cloud Service Mesh bereit:
- Verwenden Sie für die Compute Engine mit VMs die Dienstrouting-APIs.
- Verwenden Sie für die Google Kubernetes Engine mit Pods die Gateway APIs.
Informationen zu Anwendungsfällen und Architekturmustern für proxylose gRPC-Dienste finden Sie in der Proxylose gRPC-Dienste – Übersicht.
Informationen zur Handhabung der Trafficverwaltung finden Sie unter Erweiterte Trafficverwaltung – Übersicht.
In den folgenden Dokumenten erfahren Sie, wie Cloud Service Mesh Umgebungen außerhalb von Google Cloud unterstützt: