Cloud Service Mesh mit von Google Cloud APIs unterstützten Features
In diesem Dokument werden die in Cloud Service Mesh verfügbaren Features zusammengefasst.
Ein Cloud Service Mesh besteht aus Ihren Anwendungen, einer xDS-kompatiblen Datenebene (dem Open-Source-Envoy-Proxy oder der proxylosen gRPC-Datenebene) und Cloud Service Mesh als Steuerungsebene.
In den folgenden Tabellen bedeutet der Wert – (nicht zutreffend), dass ein Feature nicht unterstützt wird, da es nicht mit der jeweiligen Cloud Service Mesh-Konfiguration kompatibel ist. Wenn kein Leerzeichen vorhanden ist, also entweder ein Häkchen oder „–“, wird die Funktion nicht unterstützt.
Einige dieser Funktionen sind nur in Verbindung mit den Load Balancing-APIs verfügbar. Es wird dringend empfohlen, die Service Routing APIs zu verwenden und keine neuen Bereitstellungen mit den Load Balancing-APIs zu erstellen.
Unterstützte xDS-Versionen
Cloud Service Mesh verwendet Open-Source-xDS-Steuerungsebenen-APIs, um Envoy und proxylose gRPC-Clients zu konfigurieren. Diese Clients handeln im Auftrag Ihres Anwendungscodes, um die Anwendungsnetzwerkfunktionen von Cloud Service Mesh bereitzustellen.
Version | Support |
---|---|
xDS v2 | allgemein verfügbar. Bestimmte Funktionen, darunter die Dienstsicherheit, sind nur mit xDS v3 verfügbar. xDS v2 wird ab dem 20. Juni 2024 nicht mehr unterstützt. |
xDS v3 | Allgemeine Verfügbarkeit |
Plattformen zum Ausführen von Mesh-Diensten
Sie können Anwendungen auf den folgenden Plattformen ausführen und in ein globales Service Mesh aufnehmen, das von Cloud Service Mesh konfiguriert wird.
Funktion | Unterstützt |
---|---|
Compute Engine-VM-Instanzen | ✔ |
GKE-Containerinstanzen (Google Kubernetes Engine) | ✔ |
Kubernetes auf Compute Engine-Containerinstanzen | ✔ |
Verwaltung von Diensten
Dienste in einem von Cloud Service Mesh konfigurierten Mesh-Netzwerk profitieren von folgenden Vorteilen:
Diensterkennung. Wenn eine Anwendung in Ihrem Mesh-Netzwerk eine andere Anwendung erreichen möchte, kann sie den Dienst über den Namen aufrufen.
Back-End-Autoscaling. Instanzen, die Ihren Anwendungscode ausführen, werden nach Bedarf dynamisch skaliert.
Automatische Endpunktregistrierung. Neu erstellte oder entfernte Instanzen werden automatisch mit Ihrem Dienst verknüpft.
Funktion | Unterstützt |
---|---|
Automatisierte Bereitstellung von Sidecar-Proxys für Compute Engine-VMs | ✔ |
Automatisiertes Einfügen von Sidecar-Proxys für GKE-Pods | ✔ |
Service Discovery anhand des Hostnamens | ✔ |
Instanz-Autoscaling anhand der CPU-Auslastung | ✔ |
Instanz-Autoscaling anhand von Trafficaufkommen/Bereitstellungskapazität (nur Compute Engine-VMs in MIGs) |
✔ |
Automatische Reparatur von Instanzen anhand von konfigurierbaren Systemdiagnosen | ✔ |
Automatische Endpunktregistrierung für Compute Engine-VMs | ✔ |
Automatische Endpunktregistrierung für GKE-Containerinstanzen/-Pods | ✔ |
API zum programmatischen Hinzufügen oder Entfernen von Endpunkten | ✔ |
Endpunkte für Traffic auf Datenebene
Mikrodienste verwenden die Datenebene, um Dienste innerhalb und außerhalb Ihres Mesh-Netzwerks zu erreichen. Mit Cloud Service Mesh können Sie die Anwendungslogik von der Netzwerklogik trennen, sodass Ihre Anwendung nur Anfragen an die Datenebene senden muss (z. B. den neben der Anwendung ausgeführten Sidecar-Proxy). Die Datenebene sendet dann Anfragen an den richtigen Endpunkt.
In der folgenden Tabelle werden Anwendungen, die im Mesh-Netzwerk sind, beschrieben, die die von Cloud Service Mesh verwaltete Datenebene für die Kommunikation mit anderen Diensten verwenden. Diese Anwendungen können Traffic an Dienste innerhalb und außerhalb des Mesh-Netzwerks senden.
Funktion | Unterstützt |
---|---|
VM-basierte Anwendungen im Mesh-Netzwerk | ✔ |
Containerbasierte Anwendungen im Mesh-Netzwerk | ✔ |
VM-basierte Anwendungen außerhalb des Mesh-Netzwerks | ✔ |
Containerbasierte Anwendungen außerhalb des Mesh-Netzwerks | ✔ |
In lokalen Rechenzentren ausgeführte Anwendungen | ✔ |
Anwendungen in Multi-Cloud-Umgebungen | ✔ |
Topologien der Datenebene
Im Service-Mesh-Modell verwenden Ihre Anwendungen eine Datenebene für die Kommunikation. Diese Datenebene besteht häufig aus Sidecar-Proxys, die neben Ihren Anwendungen bereitgestellt werden. Cloud Service Mesh ist äußerst flexibel und unterstützt Datenebenen-Topologien, die Ihren Dienstnetzwerkanforderungen entsprechen.
Funktion | Unterstützt |
---|---|
Sidecar-Proxys, die neben Anwendungen ausgeführt werden | ✔ |
Proxylose gRPC-Anwendungen | ✔ |
Mittlere Proxys zwischen zwei Anwendungen in einem Mesh-Netzwerk | ✔ |
Edge-Proxys an der Grenze Ihres Mesh-Netzwerks | ✔ |
Mesh-Netzwerk, das sich über mehrere GKE-Cluster und/oder Compute Engine-VMs in mehreren Regionen erstreckt | ✔ |
Programmatische, API-gestützte Konfiguration
Die gesamte Konfiguration wird über unsere vorkonfigurierte REST API und das Dashboard bereitgestellt, damit Sie Änderungen in großen Teams automatisieren und programmatisch verwalten können. Einige Features können nicht mit der Google Cloud Console konfiguriert werden.
Funktion | Unterstützt |
---|---|
REST APIs | ✔ |
Google Cloud Console | ✔ |
Google Cloud CLI | ✔ |
Cloud Deployment Manager | ✔ |
Terraform-Unterstützung | ✔ |
Sprachunterstützung mit proxylosen gRPC-Proxyanwendungen
Mit den folgenden Programmiersprachen können Sie proxylose gRPC-Anwendungen erstellen, die mit Cloud Service Mesh funktionieren. Die in verschiedenen Implementierungen und Versionen von gRPC unterstützten Funktionen des Service Mesh sind auf GitHub aufgeführt.
Sprache | Unterstützt |
---|---|
Java | ✔ |
Go | ✔ |
C++ | ✔ |
Python | ✔ |
Ruby | ✔ |
PHP | ✔ |
Knoten | ✔ |
Anfrageprotokolle
Anwendungen können die folgenden Anfrageprotokolle verwenden, wenn sie die von Cloud Service Mesh konfigurierte Datenebene für die Kommunikation nutzen.
Funktion | Unterstützt |
---|---|
HTTP | ✔ |
HTTPS | ✔ |
HTTP/2 | ✔ |
TCP | ✔ |
gRPC | ✔ |
Dienstsicherheit
Cloud Service Mesh unterstützt die Dienstsicherheit mit den folgenden Konfigurationen.
Funktion | Envoy | gRPC |
---|---|---|
TLS mit GKE-Pods | ✔ | ✔ |
mTLS mit GKE-Pods | ✔ | ✔ |
Zugriffssteuerung und Autorisierung | ✔ | ✔ |
Routing und Trafficverwaltung
Cloud Service Mesh unterstützt erweiterte Richtlinien zur Trafficverwaltung, mit denen Sie den Traffic steuern, aufteilen und gestalten können, während er durch Ihre Datenebene geleitet wird.
Einige Features für die erweiterte Trafficverwaltung sind für proxylose gRPC-Dienste nicht verfügbar. Für die TCP-Proxy-Zielressource sind keine der erweiterten Features zur Trafficverwaltung verfügbar.
Die folgenden Features werden nicht unterstützt, wenn Cloud Service Mesh TCP-Traffic (Nicht-HTTP(S)) verarbeitet.
Funktion | Wird mit Envoy-Proxy unterstützt, der für die Verarbeitung von HTTP(S)- oder gRPC-Traffic konfiguriert ist | Für proxylose gRPC-Dienste unterstützt |
---|---|---|
HTTP-/Layer 7-Anfragerouting anhand von Suffix-/Präfix-/vollständiger/Regex-Übereinstimmung bei: | ||
• Hostname | ✔ | ✔ |
• Pfad | ✔ | ✔ |
• Header | ✔ | ✔ |
• Methode | ✔ | – |
• Cookies | ✔ | ✔ |
• Anfrageparameter | ✔ | – |
Fault Injection | ✔ | ✔ |
Konfigurierbare Zeitüberschreitungen | ✔ | – Siehe Maximale Streamdauer. |
Neuversuche | ✔ | ✔ außer pro Wiederholungszeitlimit |
Weiterleitungen | ✔ | |
URI wird neu geschrieben | ✔ | |
Anfrage-/Antwort-Headertransformationen | ✔ | |
Trafficteilung | ✔ | ✔ |
Traffic-Spiegelung | ✔ | |
Ausreißererkennung | ✔ | ✔ |
Schutzschaltung | ✔ | ✔ Nur maxRequests |
Maximale Streamdauer | ✔ | ✔ |
Load-Balancing
Sie können erweiterte Load-Balancing-Methoden und -Algorithmen so konfigurieren, dass das Load-Balancing auf den Ebenen für Dienst, Back-End-Gruppe (Instanzgruppen oder Netzwerk-Endpunktgruppen) und einzelnes Back-End oder Endpunkt erfolgt. Weitere Informationen finden Sie unter Back-End-Dienste und Erweitertes Load-Balancing.
Funktion | Wird mit Envoy-Proxy unterstützt, der für die Verarbeitung von HTTP(S)-, TCP- oder gRPC-Traffic konfiguriert ist | Für proxylose gRPC-Dienste unterstützt |
---|---|---|
Auswahl des Back-Ends (Instanzgruppe oder Netzwerk-Endpunktgruppe) anhand der Region (nächstgelegene Region mit fehlerfreier Back-End-Kapazität bevorzugen) | ✔ | ✔ |
Auswahl des Back-Ends mit preisbasiertem Balancing-Modus (Anfragen pro Sekunde). | ✔ Nicht unterstützt bei TCP-Traffic (nicht HTTP(S)). |
✔ |
Auswahl des Back-Ends anhand des nutzungsbasierten Balancing-Modus (nur VMs in Compute Engine-Instanzgruppen) | ✔ | ✔ |
Konfigurierbare maximale Kapazität pro Back-End (nur Compute Engine und GKE) | ✔ | ✔ |
Auswahl des Back-Ends anhand von konfigurierbaren Load-Balancing-Richtlinien. Informationen zu den einzelnen integrierten Richtlinien finden Sie unter |
|
|
Ausfallsicherheit von Diensten
Cloud Service Mesh unterstützt Funktionen, mit denen Sie die Ausfallsicherheit Ihrer Dienste verbessern können. Sie können mit Cloud Service Mesh beispielsweise ein Blau/Grün-Bereitstellungsmuster, Canary-Tests oder Verbindungstrennungen (Envoy, gRPC) implementieren.
Funktion | Wird mit Envoy-Proxy unterstützt, der für die Verarbeitung von HTTP(S)-, TCP- oder gRPC-Traffic konfiguriert ist | Für proxylose gRPC-Dienste unterstützt |
---|---|---|
Auswahl von Diensten anhand gewichteter Trafficaufteilungen | ✔ | ✔ |
Schutzschaltung | ✔ | ✔ Nur maxRequests |
Verwaltung der Dienst- und Backend-Kapazität
Cloud Service Mesh berücksichtigt die Dienst- und Back-End-Kapazität, um eine optimale Verteilung des Traffics auf die Back-Ends Ihrer Dienste sicherzustellen. Cloud Service Mesh ist in die Google Cloud-Infrastruktur eingebunden, sodass Kapazitätsdaten automatisch erfasst werden. Sie können die Kapazität auch manuell festlegen und konfigurieren.
Funktion | Unterstützt |
---|---|
Automatische Erfassung, basierend auf der CPU, der Back-End-Kapazität und -Auslastung für VM-Instanzen in einer verwalteten Instanzgruppe (MIG). | ✔ |
Manuelle Festlegung der Kapazität und von Überschreibungen für VM- und Containerinstanzen in MIGs und Netzwerk-Endpunktgruppen (NEGs) anhand der Anforderungsrate. | ✔ |
Manueller Ausgleich von Kapazitäten. | ✔ |
Failover
Enterprise-Arbeitslasten sind im Allgemeinen auf Hochverfügbarkeitsbereitstellungen angewiesen, um die Betriebszeit des Dienstes zu gewährleisten. Cloud Service Mesh unterstützt diese Arten von Bereitstellungen durch die Aktivierung von Redundanz für mehrere Zonen und Regionen.
Funktion | Unterstützt |
---|---|
Automatischer Failover auf eine andere Zone in derselben Region mit fehlerfreier Back-End-Kapazität. | ✔ |
Automatischer Failover in die nächste Region mit fehlerfreier Back-End-Kapazität. | ✔ |
Systemdiagnosen
Cloud Service Mesh unterstützt die zentrale Systemdiagnose zur Bestimmung des Back-End-Zustands.
Referenzinformationen finden Sie unter Systemdiagnosen – Übersicht.
Funktion | Unterstützt |
---|---|
gRPC-Systemdiagnosen | ✔ |
HTTP-Systemdiagnosen | ✔ |
HTTPS-Systemdiagnosen | ✔ |
HTTP/2-Systemdiagnosen | ✔ |
TCP-Systemdiagnosen | ✔ |
Konfigurierbare Systemdiagnosen:
|
✔ |
Konfigurierbarer Anfragepfad (HTTP, HTTPS, HTTP/2) | ✔ |
Konfigurierbarer Anfragestring oder -pfad (TCP oder SSL) | ✔ |
Konfigurierbarer String für die erwartete Antwort | ✔ |
Sichtbarkeit
Beobachtbarkeitstools bieten Monitoring-, Debugging- und Leistungsinformationen, mit denen Sie Ihr Service Mesh besser verstehen können. Die folgenden Funktionen werden entweder standardmäßig bereitgestellt oder in Ihrer Datenebene konfiguriert. Ihr Anwendungscode muss keine speziellen Schritte ausführen, um diese Beobachtbarkeitsdaten zu generieren.
Das Dashboard für den Dienststatus ist für proxylose gRPC-Dienste verfügbar, aber Sie können Logging und Tracing auf Datenebene nicht konfigurieren. Cloud Service Mesh kann das Logging und Tracing einer gRPC-Anwendung nicht konfigurieren. Sie können Logging und Tracing aktivieren, indem Sie die Anleitungen in den Abschnitten zur Fehlerbehebung oder die auf Open-Source-Websites verfügbaren gRPC-Anleitungen befolgen. Für die Erfassung von Messwerten und das Tracing in Ihren proxylosen gRPC-Diensten können Sie zum Beispiel Opencensus verwenden.
Feature | Für Proxys unterstützt | Für proxylose gRPC-Dienste unterstützt |
---|---|---|
Dashboard für den Dienststatus | ✔ | ✔ |
Logging auf Datenebene | ✔ | ✔ |
Tracing auf Datenebene | ✔ | ✔ |
Sitzungsaffinität
Die Client-Server-Kommunikation umfasst häufig mehrere aufeinanderfolgende Anfragen. In einem solchen Fall ist es hilfreich, aufeinanderfolgende Clientanfragen an dasselbe Back-End oder denselben Server weiterzuleiten. Cloud Service Mesh bietet konfigurierbare Optionen, um Anfragen von einem bestimmten Client auf Best-Effort-Basis an dasselbe Back-End zu senden, solange das Back-End fehlerfrei ist und Kapazität hat. Weitere Informationen finden Sie in der Übersicht zu Back-End-Diensten.
Funktion | Für HTTP(S)-Proxys unterstützt | Für TCP-Proxys unterstützt | Für proxylose gRPC-Dienste unterstützt |
---|---|---|---|
IP-Adresse des Clients | ✔ | ✔ | |
HTTP-Cookie | ✔ | – | |
HTTP-Header | ✔ | – | ✔ |
Generiertes Cookie (setzt das Client-Cookie bei der ersten Anfrage) | ✔ | – |
Netzwerktopologien
Cloud Service Mesh unterstützt gängige Google Cloud-Netzwerktopologien.
Funktion | Unterstützt |
---|---|
Ein einzelnes Netzwerk in einem Google Cloud-Projekt | ✔ |
Mehrere Mesh-Netzwerke in einem Google Cloud-Projekt | ✔ |
Mehrere Gateways in einem Google Cloud-Projekt | ✔ |
Freigegebene VPC (ein einzelnes Netzwerk, das von mehreren Google Cloud-Projekten gemeinsam genutzt wird) | ✔ |
Eine ausführliche Erläuterung dazu, wie freigegebene VPC mit Cloud Service Mesh unterstützt werden, finden Sie unter Einschränkungen.
Compliance
Cloud Service Mesh ist mit den folgenden Standards konform.
Compliance-Zertifizierung | Unterstützt |
---|---|
HIPAA | ✔ |
ISO 27001, ISO 27017, ISO 27018 | ✔ |
SOC1, SOC2, SOC3 | ✔ |
PCI DSS | ✔ |
Nächste Schritte
- Weitere Informationen zum Cloud Service Mesh finden Sie in der Übersicht zum Cloud Service Mesh.
- Informationen zu Anwendungsfällen und Architekturmustern für proxylose gRPC-Dienste finden Sie unter Proxylose gRPC-Dienste – Übersicht.