Cloud Service Mesh – Übersicht
Dieses Dokument richtet sich an Netzwerkadministratoren und Dienstinhaber, die sich mit Cloud Service Mesh und seinen Funktionen vertraut zu machen. Dies ist ein älteres Dokument, das für Konfigurationen mit Load-Balancing-APIs gilt.
Cloud Service Mesh ist eine verwaltete Steuerungsebene für das Anwendungsnetzwerk. Mit Cloud Service Mesh können Sie globale, hochverfügbare Dienste erweiterte Anwendungsnetzwerkfunktionen wie Traffic-Verwaltung und Beobachtbarkeit.
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 stützt sich auf von Google Cloud verwaltetes damit Sie Ihre Infrastruktur nicht selbst 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 Bereitstellungen 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ächst liegenden 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 einen nahtlosen Mechanismus 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 Netzwerkfunktionen für Anwendungen (z. B. Diensterkennung, Load-Balancing und Trafficverwaltung) zu Ihren gRPC-Anwendungen. 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 eine Verbindung zu Cloud Service Mesh herstellen Dabei werden dieselben xDS-APIs wie bei Envoy verwendet.
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 finden nativ in gRPC statt. Proxys sind nicht erforderlich und werden deshalb als proxyloses gRPC bezeichnet. Anwendungen.
Eingehender Traffic und Gateways
In vielen Anwendungsfällen müssen Sie die nicht von der Cloud Service Mesh. 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 aktiviert ein externer Application Load Balancer eingehenden Traffic für externe Dabei wird der Traffic an Dienste in einem Kubernetes-Cluster weitergeleitet. 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 einen verwalteten Traffic für eingehenden Traffic generieren. Dazu richten Sie einfach einen externen oder internen Load-Balancer ein und konfigurieren diesen so, dass Traffic an die Mikrodienste gesendet wird. In Im obigen Diagramm erreichen öffentliche Internet-Clients Ihre Dienste über die externen Application Load Balancer. Kunden wie die sich in Ihrem VPC-Netzwerk (Virtual Private Cloud) befinden, ein internen Application Load Balancer, um Ihre Dienste zu erreichen.
Für einige Anwendungsfälle kann es sinnvoll sein, das Cloud Service Mesh einzurichten, um ein gateway 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. Verkehrslage
von einem externen und einem internen Application Load Balancer an das Gateway
und dann zu den drei Diensten.
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 und 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.
Wenn Sie Cloud Service Mesh verwenden, können Sie Anfragen an Ziele außerhalb von Google Cloud 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. Nachdem Sie die Einrichtungsprozess übernimmt Ihre Infrastruktur Anwendungsnetzwerke und Cloud Service Mesh hält alle Änderungen an Ihrem Bereitstellung.
Anwendungen bereitstellen
Als Erstes stellen Sie Ihren Anwendungscode für Container oder VMs bereit. Google bietet Mechanismen, mit denen Sie eine Netzwerkinfrastruktur für Anwendungen hinzufügen können. (in der Regel Envoy-Proxys) zu Ihren VM-Instanzen und Pods. 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. Zum Konfigurieren des Cloud Service Mesh können Sie die Google Cloud Console (für einige Features und Konfigurationen), die Google Cloud CLI, die Traffic Director API oder andere wie Terraform.
Nachdem Sie diese Schritte abgeschlossen haben, kann das Cloud Service Mesh zum Konfigurieren Ihres die Netzwerkinfrastruktur von Anwendungen.
Infrastruktur verwaltet Anwendungsnetzwerke
Wenn eine Anwendung eine Anfrage an my-service sendet, ist das Anwendungsnetzwerk
verarbeitet die Infrastruktur (z. B. ein Envoy-Sidecar-Proxy) die Anfrage
laut den vom Cloud Service Mesh erhaltenen Informationen. 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, die Ihre Dienstleistungen. Durch dieses Monitoring kann Cloud Service Mesh erkennen, dass ein Dienst fehlerfrei ist oder die Kapazität eines Dienstes sich geändert hat, z. B. wenn ein neuer Kubernetes-Pod erstellt. Anhand dieser Informationen aktualisiert Cloud Service Mesh kontinuierlich die Infrastruktur Ihres Anwendungsnetzwerks.
Features
Die Features von Cloud Service Mesh bieten Anwendungsnetzwerkfunktionen zu Ihren Mikrodiensten hinzufügen. 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, sodass Sie die Infrastruktur nicht installieren, konfigurieren oder aktualisieren müssen. Dabei profitieren Sie von derselben Infrastruktur, die Google für Systemdiagnosen und globales Load-Balancing nutzt.
Open-Source-Produkte als Grundlage
Cloud Service Mesh verwendet dieselbe Steuerungsebene (xDS-APIs) beliebte Open-Source-Projekte wie Envoy und Istio verwenden. So rufen Sie die unterstützten API-Versionen auf: Siehe xDS-Steuerungsebenen-APIs
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. Ihr
Anwendung nichts über die
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. Sie verbessern die Verfügbarkeit Ihrer Dienste, indem Sie den Traffic automatisch zulassen Failover auf fehlerfreie Back-Ends mit Kapazität. Sie können das Load-Balancing anpassen. um den Traffic entsprechend Ihren Geschäftsanforderungen zu verteilen.
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 unter auf der Seite Unterstützte Produkte.
Nächste Schritte
Dies ist ein veraltetes Dokument, das sich hauptsächlich auf die Load-Balancing-APIs bezieht. Wir empfehlen dringend, Cloud Service Mesh nicht mit die Load-Balancing-APIs.
So stellen Sie das Cloud Service Mesh bereit:
- Verwenden Sie für 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.
Erfahren Sie, wie Cloud Service Mesh Umgebungen unterstützt, die über Google Cloud erhalten Sie in den folgenden Dokumenten: