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 Anwendungsnetzwerke. 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?
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 einem modernen, eine dienstbasierte Bereitstellung vornehmen. Cloud Service Mesh stützt sich auf von Google Cloud verwaltetes damit Sie Ihre Infrastruktur nicht selbst verwalten müssen. Ich sich auf den Versand von Anwendungscode konzentrieren, der Ihre geschäftlichen Probleme löst, und Cloud Service Mesh die Komplexität von Anwendungsnetzwerken zu 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 Bereitstellungsmustern, 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 haben die sechs rosafarbene Symbole mit Seitenrand stehen für die Proxys. 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 Ihrer Anwendung heraus verschieben Code. 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 . Alles beginnt damit, dass Cloud Service Mesh ein Von Google Cloud verwalteter Dienst. 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. Es gibt vier Dienste in diesem Kubernetes-Cluster, jeweils mit Sidecar-Proxys, die mit Cloud Service Mesh verbunden. Cloud Service Mesh stellt die Informationen bereit, müssen die Proxys Anfragen weiterleiten. 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 Kubernetes-Cluster. Im folgenden Diagramm stellt Cloud Service Mesh das Steuerungsebene für Kubernetes-Cluster in us-central1 und europe-west1. 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 umgebungsbasierten globalen Load-Balancing des Cloud Service Mesh können Anfragen für Service B bestimmt, an den nächsten Pod, 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 Anwendungsnetzwerke auch für diese Arbeitslasten geeignet. dass Ihre VM-basierten Arbeitslasten für Ihre Kubernetes-basierten Arbeitslasten.

Im folgenden Diagramm gelangt der Traffic über die externen Application Load Balancer. 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 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.

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 eine Verbindung zu Cloud Service Mesh herstellen Dabei werden dieselben xDS-APIs wie bei Envoy verwendet.

Nachdem die Anwendungen verbunden sind, kümmert sich die gRPC-Bibliothek um Anwendungsnetzwerkfunktionen wie Service Discovery, Load Balancing, und Traffic-Verwaltung. 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. Eine Der interne 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 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 zur Verwendung eines siehe Eingehender Traffic für das Mesh-Netzwerk.

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.

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 Traffic von Diensten weiter in Google Cloud zu Service G, in einer anderen öffentlichen Cloud, sowie an Service E und Service F, 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 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 einrichten, um mit dem Cloud Service Mesh zu sprechen und mehr über Ihre Dienste zu erfahren.

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, aus denen 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. Basierend auf diesen Informationen aktualisiert kontinuierlich Ihre Netzwerkinfrastruktur für Anwendungen.

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 die Bereitstellung von Anwendungsnetzwerken Funktionen – entweder Envoy oder gRPC ist je nach Anwendungsfall auch Open Source, sodass Sie sich keine Gedanken an eine proprietäre Infrastruktur gebunden zu sein.

Skalieren

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

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 von Google und Systemdiagnosen nutzen, basierend auf Client- und Back-End-Standort, Back-End-Nähe, Kapazität. 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

Erweiterte Trafficverwaltung, einschließlich Routing und Anfragebearbeitung (basierend auf nach Hostnamen, Pfad, Headern, Cookies und mehr) können Sie festlegen, die Traffic-Flüsse zwischen Ihren Diensten. 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 wie Metriken, Logs und Traces, die zentral in Google Cloud-Beobachtbarkeit. 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, ihren Ursprung außerhalb des Perimeters. 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.