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. Dies ist ein Legacy-Dokument, das für Konfigurationen mit Load-Balancing-APIs gilt.

Cloud Service Mesh ist eine verwaltete Steuerungsebene für Anwendungsnetzwerke. Mit Cloud Service Mesh können Sie globale, hochverfügbare Dienste mit erweiterten Anwendungsnetzwerkfunktionen 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?
Dienste müssen miteinander kommunizieren können.
Dienste müssen miteinander kommunizieren (zum Vergrößern klicken)

Mit Cloud Service Mesh können Sie diese Arten von Herausforderungen in einer modernen, dienstbasierten Bereitstellung meistern. Cloud Service Mesh basiert auf der von Google Cloud verwalteten Infrastruktur, sodass Sie keine eigene Infrastruktur verwalten müssen. Sie konzentrieren sich auf das Versenden von Anwendungscode, der Ihre geschäftlichen Probleme löst, und lassen Cloud Service Mesh die Komplexität der Anwendungsnetzwerke verwalten.

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.

Typisches Service Mesh.
Typisches Service Mesh (zum Vergrößern klicken)

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 können Sie Netzwerklogik aus Ihrem Anwendungscode heraus verschieben. 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 zwischen Cloud Service Mesh

Cloud Service Mesh funktioniert ähnlich wie dieses Modell, unterscheidet sich aber in wichtigen Punkten. Alles beginnt damit, 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 ist Cloud Service Mesh die Steuerungsebene. In diesem Kubernetes-Cluster gibt es vier Dienste mit jeweils 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.

Beispiel für ein Service Mesh mit Cloud Service Mesh.
Beispiel für ein Service Mesh mit Cloud Service Mesh (zum Vergrößern klicken)

Jenseits eines Service Mesh

Cloud Service Mesh unterstützt mehr Bereitstellungen als ein typisches Service Mesh.

Multi-Cluster-Kubernetes

Mit Cloud Service Mesh erhalten Sie Anwendungsnetzwerke, die in allen Kubernetes-Clustern funktionieren. 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.

Ein Beispiel für Multi-Cluster-Kubernetes mit Cloud Service Mesh.
Beispiel für Multi-Cluster-Kubernetes mit Cloud Service Mesh (zum Vergrößern klicken)

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 Entfernung basierenden globalen Load-Balancing von Cloud Service Mesh werden Anfragen, die für Service B bestimmt sind, an den nächsten Pod geleitet, 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 löst auch das Anwendungsnetzwerk für diese Arbeitslasten. Ihre VM-basierten Arbeitslasten interagieren mit Ihren Kubernetes-basierten Arbeitslasten.

Im folgenden Diagramm wird der Traffic über den externen Application Load Balancer in Ihre Bereitstellung eingespeist. Der Traffic wird zu Service A im Kubernetes-Cluster in asia-southeast1 und zu Service D auf einer VM in europe-west1 weitergeleitet.

Beispiel für VMs und Kubernetes mit Cloud Service Mesh
Beispiel für VMs und Kubernetes mit Cloud Service Mesh (zum Vergrößern klicken)

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 wie Diensterkennung, Load-Balancing und Trafficverwaltung in Ihre 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.

Ein Beispiel für proxylose gRPC-Anwendungen mit Cloud Service Mesh.
Beispiel für proxylose gRPC-Anwendungen mit Cloud Service Mesh (zum Vergrößern klicken)

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 mithilfe derselben xDS-APIs, die Envoy verwendet, eine Verbindung zu Cloud Service Mesh herstellen.

Nachdem die Anwendungen verbunden sind, übernimmt die gRPC-Bibliothek Anwendungsnetzwerkfunktionen wie Diensterkennung, Load-Balancing und Trafficverwaltung. Diese Funktionen werden nativ in gRPC ausgeführt, sodass keine Dienstproxys erforderlich sind. Daher werden sie als proxylose gRPC-Anwendungen bezeichnet.

Eingehender Traffic und Gateways

In vielen Anwendungsfällen müssen Sie den Traffic von Clients verarbeiten, 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 aktiviert ein externer Application Load Balancer eingehenden Traffic für externe Clients, wobei Traffic an Dienste in einem Kubernetes-Cluster weitergeleitet wird. Ein interner Application Load Balancer leitet den internen Traffic an den Dienst weiter, der auf der VM ausgeführt wird.

Cloud Service Mesh mit Cloud Load Balancing für eingehenden Traffic.
Cloud Service Mesh mit Cloud Load Balancing für eingehenden Traffic (zum Vergrößern klicken)

Cloud Service Mesh arbeitet mit Cloud Load Balancing zusammen, um eine verwaltete Umgebung für eingehenden Traffic zu bieten. 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 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 kann es sinnvoll sein, Cloud Service Mesh zum Konfigurieren eines Gateways einzurichten. 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 zur Verwendung eines Gateways 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. Der Traffic von einem externen und internen Application Load Balancer wird an das Gateway und dann an die drei Dienste weitergeleitet.

Cloud Service Mesh, das zum Konfigurieren eines Gateways verwendet wird.
Cloud Service Mesh zum Konfigurieren eines Gateways (zum Vergrößern klicken)

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?

Im folgenden Diagramm leitet Cloud Service Mesh den Traffic von Diensten, die in Google Cloud ausgeführt werden, an Service G, das in einer anderen öffentlichen Cloud ausgeführt wird, sowie an Service E und Service F weiter, die beide in einem lokalen Rechenzentrum ausgeführt werden. Service A, Service B und Service C verwenden Envoy als Sidecar-Proxy, während Service D ein proxyloser gRPC-Dienst ist.

Cloud Service Mesh, das für die umgebungsübergreifende Kommunikation verwendet wird.
Cloud Service Mesh für die umgebungsübergreifende Kommunikation (zum Vergrößern klicken)

Wenn Sie Cloud Service Mesh verwenden, 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. Nachdem Sie den Einrichtungsprozess abgeschlossen haben, verarbeitet Ihre Infrastruktur das Anwendungsnetzwerk und Cloud Service Mesh hält anhand von Änderungen an Ihrer Bereitstellung alles auf dem neuesten Stand.

Anwendungen bereitstellen

Als Erstes stellen Sie Ihren Anwendungscode für Container oder VMs bereit. Google bietet Mechanismen, mit denen Sie Ihren VM-Instanzen und Pods die Netzwerkinfrastruktur für Anwendungen (in der Regel Envoy-Proxys) hinzufügen können. Diese Infrastruktur ist so eingerichtet, dass sie mit Cloud Service Mesh kommuniziert und Informationen zu Ihren Diensten erhält.

Cloud Service Mesh konfigurieren

Als Nächstes konfigurieren Sie Ihre globalen Dienste und legen dabei fest, wie der Traffic verarbeitet werden soll. Zum Konfigurieren von Cloud Service Mesh können Sie die Google Cloud Console (für einige Funktionen und Konfigurationen), die Google Cloud CLI, die Traffic Director API oder andere Tools wie Terraform verwenden.

Nachdem Sie diese Schritte abgeschlossen haben, kann Cloud Service Mesh die Netzwerkinfrastruktur Ihrer Anwendung konfigurieren.

Infrastruktur verwaltet Anwendungsnetzwerke

Wenn eine Anwendung eine Anfrage an my-service sendet, verarbeitet die Netzwerkinfrastruktur Ihrer Anwendung (z. B. ein Envoy-Sidecar-Proxy) die Anfrage gemäß den von Cloud Service Mesh empfangenen 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, aus denen Ihre Dienste bestehen. Dieses Monitoring ermöglicht es Cloud Service Mesh, zu erkennen, ob ein Dienst fehlerfrei ist oder sich die Kapazität eines Dienstes geändert hat, z. B. wenn ein neuer Kubernetes-Pod erstellt wird. Anhand dieser Informationen aktualisiert Cloud Service Mesh kontinuierlich die Netzwerkinfrastruktur Ihrer Anwendung.

Features

Die Features von Cloud Service Mesh bieten Anwendungsnetzwerkfunktionen für Ihre Mikrodienste. 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 die gleiche Steuerungsebene (xDS APIs), die beliebte Open-Source-Projekte wie Envoy und Istio verwenden. Informationen zu unterstützten API-Versionen finden Sie unter APIs der xDS-Steuerungsebene.

Die Infrastruktur, die Anwendungsnetzwerkfunktionen bereitstellt – je nach Anwendungsfall entweder Envoy oder gRPC, ist ebenfalls Open Source, sodass Sie sich keine Gedanken darüber machen müssen, ob Sie an eine proprietäre Infrastruktur gebunden sind.

Skalieren

Von einmaligen Netzwerklösungen für Anwendungen bis hin zu riesigen Service-Mesh-Bereitstellungen mit Tausenden von Diensten – Cloud Service Mesh ist darauf ausgelegt, Ihre Skalierungsanforderungen zu erfüllen.

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 muss keine Kenntnisse über IP-Adressen, Protokolle oder andere Netzwerkkomplexitäten haben.

Globales Load-Balancing und Failover

Cloud Service Mesh nutzt das globale Load-Balancing und die Systemdiagnose von Google, um den Traffic basierend auf Client- und Back-End-Standort, Back-End-Nähe, Zustand und Kapazität optimal auszugleichen. Die Verfügbarkeit der Dienste wird dadurch verbessert, dass für den Traffic automatisch ein Failover an fehlerfreie Back-Ends mit Kapazitäten durchgeführt wird. Sie können das Load-Balancing anpassen, um den Traffic entsprechend Ihren Geschäftsanforderungen zu verteilen.

Trafficverwaltung

Mit der erweiterten Trafficverwaltung, einschließlich Routing und Anfragebearbeitung (basierend auf Hostnamen, Pfad, Headern, Cookies usw.), können Sie festlegen, wie Traffic zwischen Ihren Diensten fließt. 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

Ihre Netzwerkinfrastruktur Ihrer Anwendung erfasst Telemetriedaten 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 von außerhalb des Perimeters stammen. 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

Dies ist ein älteres Dokument, das sich hauptsächlich auf die Load-Balancing-APIs bezieht. Es wird dringend empfohlen, Cloud Service Mesh nicht mit den Load Balancing APIs zu konfigurieren.