Unterstützte Features mit Istio-APIs (verwaltete Steuerungsebene)

Auf dieser Seite werden die unterstützten Features und Einschränkungen für Cloud Service Mesh mit TRAFFIC_DIRECTOR oder ISTIOD als Steuerungsebene sowie die Unterschiede zwischen den einzelnen Implementierungen beschrieben. Diese Optionen können Sie nicht auswählen. Die ISTIOD-Implementierung ist nur für bestehende Nutzer verfügbar. Bei neuen Installationen wird nach Möglichkeit die TRAFFIC_DIRECTOR-Implementierung verwendet.

Eine Liste der Istio- und Google Cloud -APIs, die vom verwalteten Cloud Service Mesh mit TRAFFIC_DIRECTOR unterstützt werden, finden Sie unter API-Unterstützung im verwalteten Cloud Service Mesh.

Eine Liste der von Cloud Service Mesh unterstützten Features für eine clusterinterne Steuerungsebene finden Sie unter Istio-APIs verwenden (clusterinterne istiod-Steuerungsebene).

Wenn Sie sich nicht sicher sind, welche Cloud Service Mesh-Steuerungsebene Sie verwenden, können Sie Ihre Implementierung der Steuerungsebene anhand der Anleitung unter Implementierung der Steuerungsebene identifizieren prüfen.

Beschränkungen

Es gelten folgende Einschränkungen:

  • GKE-Cluster müssen sich in einer der unterstützten Regionen befinden.
  • Die GKE-Version muss eine unterstützte Version sein.
  • Nur die unter Umgebungen aufgeführten Plattformen werden unterstützt.
  • Pods, die mit hostNetwork: true ausgeführt werden, werden nicht unterstützt.
  • Verwaltetes Cloud Service Mesh darf nicht in einem Cluster bereitgestellt werden, der auch eine clusterinterne Bereitstellung von OSS Istio oder eine clusterinterne Cloud Service Mesh-Steuerungsebene hat.
  • Das Ändern von Release-Versionen wird nicht unterstützt.
  • Migrationen von verwaltetem Cloud Service Mesh mit asmcli zu Cloud Service Mesh mit Fleet API werden nicht unterstützt. Ebenso wird die Bereitstellung von verwaltetem Cloud Service Mesh mit der Fleet API von --management manual bis --management automatic nicht unterstützt.
  • Migrationen von Cloud Service Mesh innerhalb von Clustern werden nur mit der Strategie Canary-Clustermigration unterstützt.
  • Migrationen und Upgrades werden nur von clusterinternen Cloud Service Mesh-Versionen unterstützt, die in der Tabelle Unterstützte Versionen aufgeführt sind und Mesh CA oder Certificate Authority Service verwenden. Installationen mit Istio CA (ehemals Citadel) müssen zuerst zu Mesh CA migriert werden.
  • Die Skalierungslimits werden in diesem Leitfaden beschrieben.
  • Nur die Multi-Primary-Bereitstellungsoption für Multi-Cluster wird unterstützt, die Primary-Remote-Bereitstellungsoption für Multi-Cluster nicht.
  • istioctl ps wird nicht unterstützt. Stattdessen können Sie die gcloud beta container fleet mesh debug-Befehle verwenden, wie unter Fehlerbehebung beschrieben.

  • Nicht unterstützte APIs:

    • WasmPlugin API

    • IstioOperator API

    • Kubernetes Ingress API

  • Ausführliche Informationen zur Unterstützung auf Feldebene und zu Einschränkungen für alle Istio APIs finden Sie unter Cloud Service Mesh API-Unterstützung.

  • Sie können die verwaltete Steuerungsebene ohne GKE Enterprise-Abo verwenden. Bestimmte UI-Elemente und Features in der Google Cloud Console sind jedoch nur für GKE Enterprise-Abonnenten verfügbar. Informationen dazu, welche Features Abonnenten und Nicht-Abonnenten zur Verfügung stehen, finden Sie unter Unterschiede zwischen GKE Enterprise und Cloud Service Mesh in der Benutzeroberfläche.

  • Während des Bereitstellungsprozesses für eine verwaltete Steuerungsebene werden Istio-CRDs, die dem ausgewählten Kanal entsprechen, im angegebenen Cluster installiert. Wenn im Cluster bereits Istio-CRDs vorhanden sind, werden diese überschrieben.

  • Managed Cloud Service Mesh unterstützt nur die Standard-DNS-Domain .cluster.local.

  • Bei neuen Installationen von verwaltetem Cloud Service Mesh werden JWKS nur über Envoys abgerufen, es sei denn, die Flotte enthält andere Cluster, für die dieses Verhalten nicht aktiviert ist. Dies entspricht der Istio-Option PILOT_JWT_ENABLE_REMOTE_JWKS=envoy. Im Vergleich zu Installationen ohne die Bedingung VPCSC_GA_SUPPORTED (siehe unten) ist für die Konfigurationen ServiceEntry und DestinationRule möglicherweise eine zusätzliche Konfiguration erforderlich. Ein Beispiel finden Sie unter requestauthn-with-se.yaml.tmpl. Sie können feststellen, ob der aktuelle Betriebsmodus PILOT_JWT_ENABLE_REMOTE_JWKS=envoy entspricht, indem Sie prüfen, ob VPC Service Controls für die Steuerungsebene unterstützt werden (d. h. die Bedingung VPCSC_GA_SUPPORTED wird angezeigt).

  • Die verwaltete Datenebene wird nur für Arbeitslasten ohne zusätzliche Sidecars (außer dem Cloud Service Mesh-Sidecar) unterstützt.

Unterschiede der Steuerungsebene

Es gibt Unterschiede bei den unterstützten Funktionen zwischen den Implementierungen der Steuerungsebene ISTIOD und TRAFFIC_DIRECTOR. Informationen dazu, welche Implementierung Sie verwenden, finden Sie unter Implementierung der Steuerungsebene identifizieren.

  •  – gibt an, dass das Feature verfügbar und standardmäßig aktiviert ist.
  • † – gibt an, dass sich die Feature-APIs zwischen den verschiedenen Plattformen unterscheiden können.
  • * gibt an, dass das Feature für die Plattform unterstützt wird und, wie unter Optionale Features aktivieren oder in dem in der Feature-Tabelle verlinkten Leitfaden beschrieben, aktiviert werden kann.
  •  – gibt an, dass das Feature nicht verfügbar ist oder nicht unterstützt wird.

Die standardmäßigen und optionalen Features werden vom Google Cloud-Support vollständig unterstützt. Features, die nicht explizit in den Tabellen aufgeführt sind, erhalten bestmöglichen Support.

Was bestimmt die Implementierung der Steuerungsebene?

Wenn Sie verwaltetes Cloud Service Mesh zum ersten Mal in einer Flotte bereitstellen, bestimmen wir, welche Implementierung der Steuerungsebene verwendet werden soll. Dieselbe Implementierung wird für alle Cluster verwendet, die verwaltetes Cloud Service Mesh in dieser Flotte bereitstellen.

Neue Flotten, die in verwaltetes Cloud Service Mesh aufgenommen werden, erhalten die Steuerungsebenen-Implementierung TRAFFIC_DIRECTOR, mit bestimmten Ausnahmen:

  • Wenn Sie bereits ein verwaltetes Cloud Service Mesh verwenden, erhalten Sie die Implementierung der Steuerungsebene ISTIOD, wenn Sie eine neue Flotte in derselben Google Cloud-Organisation in das verwaltete Cloud Service Mesh einbinden, bis mindestens zum 30. Juni 2024. Wenn Sie einer dieser Nutzer sind, können Sie sich an den Support wenden, um dieses Verhalten anzupassen. Nutzer, deren bestehende Nutzung ohne Änderungen nicht mit der TRAFFIC_DIRECTOR-Implementierung kompatibel ist, erhalten bis zum 8. September 2024 weiterhin die ISTIOD-Implementierung. (Diese Nutzer haben eine Dienstmitteilung erhalten.)
  • Wenn ein GKE on Google Cloud -Cluster in Ihrer Flotte eine clusterinterne Cloud Service Mesh-Steuerungsebene enthält, wenn Sie verwaltetes Cloud Service Mesh bereitstellen, erhalten Sie die ISTIOD-Steuerungsebenenimplementierung.
  • Wenn ein Cluster in Ihrer Flotte GKE Sandbox verwendet, erhalten Sie bei der Bereitstellung des verwalteten Cloud Service Mesh die Steuerungsebenen-Implementierung ISTIOD.

Von der verwaltete Steuerungsebene unterstützte Features

Installieren, aktualisieren und Rollback ausführen

Funktion Verwaltet (TD) Verwaltet (istiod) verworfen
Installation auf GKE-Clustern mit der Fleet Feature API
Upgrades von ASM 1.9-Versionen mit Mesh CA
Direkte Upgrades (Überspringen von Versionen) von Cloud Service Mesh-Versionen vor 1.9 (siehe Hinweise zu indirekten Upgrades)
Direkte Upgrades von Istio OSS (siehe Hinweise für indirekte Upgrades)
Direkte Upgrades von Istio-on-GKE-Add-on (siehe Hinweise für indirekte Upgrades)
Optionale Features aktivieren

Umgebungen

Funktion Verwaltet (TD) Verwaltet (istiod) verworfen
GKE-Versionen, die derzeit in Release-Versionen verfügbar sind, in einer der unterstützten Regionen
GKE-Versionen, die derzeit in Release-Versionen verfügbar sind, in einer der unterstützten Regionen, GKE-Autopilot-Cluster
Umgebungen außerhalb von Google Cloud (GKE Enterprise lokal, GKE Enterprise in anderen öffentlichen Clouds, Amazon EKS, Microsoft AKS oder andere Kubernetes-Cluster)

Skalieren

Weitere Informationen finden Sie auf der Seite zu Skalierbarkeitslimits.

Plattformumgebung

Funktion Verwaltet (TD) Verwaltet (istiod) verworfen
Einzelnes Netzwerk
Multinetzwerk
Einzelprojekt
Mehrere Projekte mit freigegebene VPC

Multi-Cluster-Bereitstellung

Funktion Verwaltet (TD) Verwaltet (istiod) verworfen
Multiprimär
Primäre Fernbedienung
Multi-Cluster-Endpunkterkennung mit deklarativer API
Multi-Cluster-Endpunkterkennung mit Remote-Secrets
Multi-Cluster-Endpunkterkennung mit deklarativer API und einer einfachen Topologie

Hinweise zur Terminologie

  • Eine Konfiguration mit mehreren Primärinstanzen bedeutet, dass die Konfiguration in allen Clustern repliziert werden muss.
  • Eine primäre Remote-Konfiguration bedeutet, dass ein einzelner Cluster die Konfiguration enthält und als „Source of Truth“ gilt.
  • Cloud Service Mesh verwendet eine vereinfachte Definition von Netzwerken auf der Grundlage allgemeiner Konnektivität. Arbeitslastinstanzen befinden sich im selben Netzwerk, wenn sie ohne Gateway direkt kommunizieren können.
  • Eine einfache Topologie für die Multi-Cluster-Endpunkterkennung bedeutet, dass jeder Cluster in der Flotte entweder an der Endpunkterkennung teilnimmt oder nicht. Zu den nicht unterstützten komplexen Topologien gehören (a) die einseitige Endpunkterkennung (z.B. kann Cluster A Endpunkte in Cluster B erkennen, aber nicht umgekehrt) und (b) unzusammenhängende Endpunkterkennungsnetzwerke (z.B. können Cluster A und B die Endpunkte des jeweils anderen erkennen, Cluster C und D können die Endpunkte des jeweils anderen erkennen, aber A/B und C/D können die Endpunkte des jeweils anderen nicht erkennen).

Basis-Images

Funktion Verwaltet (TD) Verwaltet (istiod) verworfen
Distroless-Proxy-Image †

† Istio veröffentlicht die Proxy-Images default, debug und distroless. Für Cloud Service Mesh mit einer verwalteten Steuerungsebene (TRAFFIC_DIRECTOR): Direkt eingebundene Cluster verwenden standardmäßig distroless. Dies kann nicht geändert werden. Migrierte Cluster verwenden standardmäßig default-Images und können distroless mit MeshConfig oder Pod-Annotation aktivieren. Überschreibungen für andere Image-Typen (debug) werden nicht unterstützt.

Distroless-Images enthalten nur minimale Binärdateien. Sie können daher die üblichen Befehle wie „bash“ oder „curl“ nicht ausführen, da sie im Distroless-Image nicht vorhanden sind. Sie können jedoch sitzungsspezifische Container verwenden, um sie an einen laufenden Arbeitslast-Pod anzuhängen, um ihn zu prüfen und benutzerdefinierte Befehle auszuführen. Weitere Informationen finden Sie unter Cloud Service Mesh-Logs erfassen.

Sicherheit

VPC Service Controls

Funktion Verwaltet (TD) Verwaltet (istiod) verworfen
VPC Service Controls

Mechanismen zur Zertifikatsverteilung und Rotation

Funktion Verwaltet (TD) Verwaltet (istiod) verworfen
Verwaltung von Arbeitslastzertifikaten
Externe Zertifikatsverwaltung auf Ingress- und Egress-Gateways.

Unterstützung von Zertifizierungsstellen (CA)

Funktion Verwaltet (TD) Verwaltet (istiod) verworfen
Cloud Service Mesh-Zertifizierungsstelle
Certificate Authority Service
Istio CA
Integration in benutzerdefinierte Zertifizierungsstellen

Sicherheitsfunktionen

Zusätzlich zur Unterstützung der Istio-Sicherheitsfunktionen bietet Cloud Service Mesh noch mehr Funktionen zum Schutz Ihrer Anwendungen.

Funktion Verwaltet (TD) Verwaltet (istiod) verworfen
IAP-Einbindung
Endnutzerauthentifizierung
Probelaufmodus
Logging der Ablehnung
Audit-Richtlinien (nicht unterstützt)

Autorisierungsrichtlinie

Funktion Verwaltet (TD) Verwaltet (istiod) verworfen
Autorisierungs-v1beta1-Richtlinie
BENUTZERDEFINIERTE Autorisierungsrichtlinie

Peer-Authentifizierung

Funktion Verwaltet (TD) Verwaltet (istiod) verworfen
Auto-mTLS
mTLS-PERMISSIVE-Modus
mTLS-STRICT-Modus * *
mTLS-DISABLE-Modus †

† Die PeerAuthentication API unterstützt den DISABLE-Modus für die TRAFFIC_DIRECTOR-Implementierung der Steuerungsebene nicht. Sie können mTLS jedoch für bestimmte Dienste oder Ports mit der DestinationRule API deaktivieren. Weitere Informationen finden Sie unter mTLS deaktivieren und API-Unterstützung: PeerAuthentication.

Authentifizierung anfordern

Funktion Verwaltet (TD) Verwaltet (istiod) verworfen
JWT-Authentifizierung(Hinweis 1)
JWT-Anforderungsbasiertes Routing
JWT-Anforderung in Header kopieren

Hinweise:

  1. JWT von Drittanbietern ist standardmäßig aktiviert.
  2. Fügen Sie den vollständigen FQDN/Hostnamen in JWKSURI hinzu, während Sie die RequestAuthentication API definieren.
  3. Die verwaltete Steuerungsebene erzwingt, dass Envoy JWKS abruft, wenn ein JWKS-URI angegeben wird.
  4. Die AES-CBC-Algorithmen A128CBC-HS256, A192CBC-HS384 und A256CBC-HS512 sind in Inline-JWKS nicht zulässig, wenn die Implementierung der Steuerungsebene TRAFFIC_DIRECTOR verwendet wird.

Telemetrie

Messwerte

Funktion Verwaltet (TD) Verwaltet (istiod) verworfen
Cloud Monitoring (HTTP-In-Proxy-Messwerte)
Cloud Monitoring (TCP-In-Proxy-Messwerte)
Prometheus-Messwerte werden in Grafana exportiert (nur Envoy-Messwerte) * *
Exportieren von Prometheus-Messwerten in Kiali
Google Cloud Managed Service for Prometheus, ohne das Cloud Service Mesh-Dashboard * *
Istio Telemetry API †
Benutzerdefinierte Adapter/Back-Ends, In- oder Out-of-Process
Beliebige Telemetrie- und Logging-Back-Ends

† Die Steuerungsebene TRAFFIC_DIRECTOR unterstützt einen Teil der Istio Telemetry API, die zum Konfigurieren von Zugriffslogs und Trace verwendet wird.

Logging von Proxyanfragen

Funktion Verwaltet (TD) Verwaltet (istiod) verworfen
Traffic-Logs
Zugriffslogs * *

Tracing

Funktion Verwaltet (TD) Verwaltet (istiod) verworfen
Cloud Trace * *
Jaeger-Tracing (ermöglicht die Verwendung des vom Kunden verwalteten Jaeger) Kompatibel
Zipkin-Tracing (ermöglicht die Verwendung des vom Kunden verwalteten Zipkin) Kompatibel

Netzwerk

Mechanismen zum Abfangen und Umleiten von Traffic

Funktion Verwaltet (TD) Verwaltet (istiod) verworfen
Verwendung von iptables mit init-Containern über CAP_NET_ADMIN †
Istio Container Network Interface (CNI)
Whitebox-Sidecar
Abfangmodus konfigurieren

† Wir empfehlen dringend, Container Network Interface (CNI) anstelle von init-Containern zu verwenden.

Protokollunterstützung

Funktion Verwaltet (TD) Verwaltet (istiod) verworfen
IPv4
HTTP/1.1
HTTP/2
TCP-Byte-Streams (Hinweis 1)
gRPC
IPv6 †

Hinweise:

  1. Obwohl TCP ein unterstütztes Protokoll für das Netzwerk ist und TCP-Messwerte erfasst werden, werden sie nicht gemeldet. Messwerte werden nur für HTTP-Dienste in der Google Cloud Console angezeigt.
  2. Dienste, die mit Layer-7-Funktionen für die folgenden Protokolle konfiguriert wurden, werden nicht unterstützt: WebSocket, MongoDB, Redis, MySQL, Kafka, Cassandra, RabbitMQ, Cloud SQL. Unter Umständen können Sie das Protokoll mithilfe der TCP-Bytestream-Unterstützung nutzen. Wenn der TCP-Bytestream das Protokoll nicht unterstützt (z. B. wenn Kafka eine Weiterleitungsadresse in einer protokollspezifischen Antwort sendet und diese Weiterleitung nicht mit der Routinglogik von Cloud Service Mesh kompatibel ist), wird das Protokoll nicht unterstützt. Gateway-Ports können zwar mit den Protokollen Mongo, MySQL und Redis erstellt werden, das Mesh-Netzwerk behandelt den resultierenden Traffic jedoch als Standard-TCP und bietet keine protokollspezifische Verarbeitung.
  3. † In proxylosem gRPC werden IPv6-Dual-Stack-Features nur in gRPC 1.66.1 oder höher in C++ und Python, gRPC Go v1.71 und gRPC Node.js v1.12 unterstützt. Wenn Sie versuchen, Dual-Stack-Features mit einer gRPC-Version zu konfigurieren, die Dual-Stack nicht unterstützt, verwenden die Clients nur die erste von Traffic Director gesendete Adresse.

Envoy-Bereitstellungen

Funktion Verwaltet (TD) Verwaltet (istiod) verworfen
Sidecar-Dateien
Ingress-Gateway
Ausgehender Traffic direkt von Sidecars
Ausgehender Traffic über Egress-Gateways * *

CRD-Support

Funktion Verwaltet (TD) Verwaltet (istiod) verworfen
Sidecar-Ressource
Diensteintragsressource
Prozentwert, Fehlerinjektion, Pfadabgleich, Weiterleitungen, Wiederholungsversuche, Umschreibungen, Zeitüberschreitung, Wiederholungsversuch, Header-Bearbeitung und CORS-Routingregeln
`WasmPlugin` API
Istio-Operator

Load-Balancer für das Istio-Ingress-Gateway

Funktion Verwaltet (TD) Verwaltet (istiod) verworfen
Externer Load Balancer eines Drittanbieters
Google Cloud Interner Load Balancer * *

Service Mesh-Cloud-Gateway

Funktion Verwaltet (TD) Verwaltet (istiod) verworfen
Service Mesh-Cloud-Gateway

Kubernetes Gateway API

Funktion Verwaltet (TD) Verwaltet (istiod) verworfen
Kubernetes Gateway API

Load Balancing-Richtlinien

Funktion Verwaltet (TD) Verwaltet (istiod) verworfen
Round-Robin
Mindestverbindungen
Zufällig
Passthrough
Konsistente Hashfunktion
Ort
GCPTrafficDistributionPolicy
GCPBackendPolicy

Load-Balancing-Modi

Funktion Verwaltet (TD) Verwaltet (istiod) verworfen
RATE
AUSLASTUNG
CUSTOM_METRICS
AKTIV

Weitere Informationen zu Balancing-Modi finden Sie unter Backend-Dienste – Übersicht.

Diensteintrag

Funktion Verwaltet (TD) Verwaltet (istiod) verworfen
ServiceEntry v1beta1 †

† Die TRAFFIC_DIRECTOR-Steuerungsebene unterstützt einen Teil der ServiceEntry-Felder. Eine vollständige Liste der unterstützten Felder, nicht unterstützten Felder und Konfigurationseinschränkungen finden Sie unter API-Unterstützung: ServiceEntry.

Zielregel

Funktion Verwaltet (TD) Verwaltet (istiod) verworfen
DestinationRule v1beta1 †

† Für die Implementierung der TRAFFIC_DIRECTOR-Steuerungsebene muss sich die Zielregel, die Teilmengen definiert, im selben Namespace und Cluster wie der Kubernetes-Dienst oder ServiceEntry befinden. Eine vollständige Liste der unterstützten Felder, nicht unterstützten Felder und Konfigurationseinschränkungen finden Sie unter API-Unterstützung: DestinationRule.

Sidecar

Funktion Verwaltet (TD) Verwaltet (istiod) verworfen
Sidecar v1beta1 †

† Die TRAFFIC_DIRECTOR-Steuerungsebene unterstützt einen Teil der Sidecar-Felder. Eine vollständige Liste der unterstützten Felder, nicht unterstützten Felder und Konfigurationseinschränkungen finden Sie unter API-Unterstützung: Sidecar.

DNS-Proxy

Funktion Verwaltet (TD) Verwaltet (istiod) verworfen
Namensauflösung von Service über Cluster hinweg †
Namensauflösung von ServiceEntry in einem Cluster †
Namensauflösung von Headless Service
Automatische Adresszuweisung †

† Sidecar-Version 1.21.5-asm.39 oder höher ist erforderlich.

EnvoyFilter

Funktion Verwaltet (TD) Verwaltet (istiod) verworfen
EnvoyFilter v1alpha3 †

† Informationen zu unterstützten Feldern und konfigurierbaren Erweiterungen finden Sie auf der Seite zur Erweiterbarkeit der Datenebene.

MeshConfig

Funktion Verwaltet (TD) Verwaltet (istiod) verworfen
DiscoverySelectors
clusterLocal
LocalityLB †
ExtensionProviders
CACert
ImageType – Distroless †
OutboundTrafficPolicy
defaultProviders.accessLogging
defaultProviders.tracing
defaultConfig.tracing.stackdriver
accessLogFile †
accessLogFormat †
accessLogEncoding †

† Ausführliche Informationen zum Konfigurationsverhalten finden Sie unter Distroless-Proxy-Image.
† Weitere Informationen zum Konfigurationsverhalten und zu Einschränkungen finden Sie unter Standortbasiertes Load Balancing konfigurieren.
† Weitere Informationen zum Konfigurationsverhalten und zu Einschränkungen finden Sie unter Format und Codierung des Envoy-Zugriffslogs anpassen.

ProxyConfig

Funktion Verwaltet (TD) Verwaltet (istiod) verworfen
HTTP/1.0-Unterstützung (ISTIO_META_NETWORK)
Image-Auswahl (Distroless- oder Basis-Image)
Nativer Kubernetes-Sidecar (ENABLE_NATIVE_SIDECARS)

Regionen

GKE-Cluster müssen sich in einer der folgenden Regionen oder in einer beliebigen Zone innerhalb der folgenden Regionen befinden.

Region Standort
africa-south1 Johannesburg
asia-east1 Taiwan
asia-east2 Hongkong
asia-northeast1 Tokio, Japan
asia-northeast2 Osaka, Japan
asia-northeast3 Südkorea
asia-south1 Mumbai, Indien
asia-south2 Delhi, Indien
asia-southeast1 Singapur
asia-southeast2 Jakarta
australia-southeast1 Sydney, Australien
australia-southeast2 Melbourne, Australien
europe-central2 Polen
europe-north1 Finnland
europe-north2 Stockholm
europe-southwest1 Spanien
europe-west1 Belgien
europe-west2 England
europe-west3 Frankfurt, Deutschland
europe-west4 Niederlande
europe-west6 Schweiz
europe-west8 Mailand, Italien
europe-west9 Frankreich
europe-west10 Berlin, Deutschland
europe-west12 Turin, Italien
me-central1 Doha
me-central2 Dammam, Saudi-Arabien
me-west1 Tel Aviv
northamerica-northeast1 Montreal, Kanada
northamerica-northeast2 Toronto, Kanada
northamerica-south1 Mexiko
southamerica-east1 Brasilien
southamerica-west1 Chile
us-central1 Iowa
us-east1 South Carolina
us-east4 Northern Virginia
us-east5 Ohio
us-south1 Dallas
us-west1 Oregon
us-west2 Los Angeles
us-west3 Salt Lake City
us-west4 Las Vegas

Benutzeroberfläche

Funktion Verwaltet (TD) Verwaltet (istiod) verworfen
Cloud Service Mesh-Dashboards in der Google Cloud Console
Cloud Monitoring
Cloud Logging

Tools

Funktion Verwaltet (TD) Verwaltet (istiod) verworfen
gcloud beta container fleet mesh debug tool