Unterstützte Features mit Istio-APIs (verwaltete Steuerungsebene)
Auf dieser Seite werden die unterstützten Funktionen 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 Neuinstallationen wird nach Möglichkeit die TRAFFIC_DIRECTOR-Implementierung verwendet.
Eine Liste der von Managed Cloud Service Mesh mit TRAFFIC_DIRECTOR unterstützten Istio- und Google Cloud APIs finden Sie unter API-Unterstützung in Managed 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 nicht sicher sind, welche Cloud Service Mesh-Steuerungsebene Sie verwenden, können Sie die Implementierung der Steuerungsebene anhand der Anleitung unter Implementierung der Steuerungsebene ermitteln 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: trueausgeführt werden, werden nicht unterstützt. - Managed Cloud Service Mesh darf nicht in einem Cluster bereitgestellt werden, in dem auch eine clusterinterne Bereitstellung von OSS Istio oder eine clusterinterne Cloud Service Mesh-Steuerungsebene vorhanden ist.
- Das Ändern von Release-Versionen wird nicht unterstützt.
- Migrationen von verwaltetem Cloud Service Mesh mit
asmclizu 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 manualbis--management automaticnicht unterstützt. - Migrationen von Cloud Service Mesh innerhalb von Clustern werden nur mit der Canary-Clustermigration unterstützt.
- Migrationen und Upgrades werden nur von Clusterversionen von Cloud Service Mesh 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 Limits für die Skalierung sind 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 pswird nicht unterstützt. Stattdessen können Sie diegcloud beta container fleet mesh debug-Befehle verwenden, wie unter Fehlerbehebung beschrieben.Nicht unterstützte APIs:
WasmPluginAPIIstioOperatorAPIKubernetes IngressAPI
Ausführliche Informationen zur Unterstützung und zu Einschränkungen auf Feldebene 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 Funktionen 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.
Das verwaltete Cloud Service Mesh unterstützt nur die Standard-DNS-Domain
.cluster.local.Bei Neuinstallationen von verwaltetem Cloud Service Mesh werden JWKS nur über Envoys abgerufen, sofern die Flotte keine anderen Cluster enthält, 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 möglicherweise eine zusätzliche Konfiguration fürServiceEntry- undDestinationRule-Konfigurationen erforderlich. Ein Beispiel finden Sie unterrequestauthn-with-se.yaml.tmpl. Sie können feststellen, ob der aktuelle BetriebsmodusPILOT_JWT_ENABLE_REMOTE_JWKS=envoyentspricht, 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 ermitteln.
- – gibt an, dass das Feature verfügbar und standardmäßig aktiviert ist.
- † – weist darauf hin, dass sich die Feature-APIs auf verschiedenen Plattformen unterscheiden können.
- * – gibt an, dass das Feature für die Plattform unterstützt wird und, wie unter Optionale Funktionen 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 Funktionen 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, wird festgelegt, welche Steuerungsebene verwendet werden soll. Dieselbe Implementierung wird für alle Cluster verwendet, in denen verwaltetes Cloud Service Mesh in dieser Flotte bereitgestellt wird.
Neue Flotten, die in verwaltetes Cloud Service Mesh eingebunden werden, erhalten die TRAFFIC_DIRECTOR-Steuerungsebenenimplementierung, mit bestimmten Ausnahmen:
- Wenn Sie bereits ein Nutzer der verwalteten Cloud Service Mesh sind, erhalten Sie die
ISTIOD-Steuerungsebenenimplementierung, wenn Sie bis mindestens 30. Juni 2024 eine neue Flotte in derselben Google Cloud-Organisation in die verwaltete Cloud Service Mesh einbinden. 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 derTRAFFIC_DIRECTOR-Implementierung kompatibel ist, erhalten bis zum 8. September 2024 weiterhin dieISTIOD-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 in einem Cluster in Ihrer Flotte GKE Sandbox verwendet wird, erhalten Sie beim Bereitstellen von verwaltetem Cloud Service Mesh die
ISTIOD-Steuerungsebene.
Von der verwaltete Steuerungsebene unterstützte Features
Installieren, aktualisieren und Rollback ausführen
| Funktion | Verwaltet (TD) | Verwaltet (istiod) ist veraltet |
|---|---|---|
| Installation auf GKE-Clustern mit der Fleet Feature API | ||
| Upgrades von ASM 1.9-Versionen mit Mesh CA | ||
| Direkte (Skip-Level-)Upgrades 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) ist veraltet |
|---|---|---|
| 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 (lokale GKE Enterprise, GKE Enterprise in anderen öffentlichen Clouds, Amazon EKS, Microsoft AKS oder andere Kubernetes-Cluster) |
Skalieren
Seite zu Skalierbarkeitslimits
Plattformumgebung
| Funktion | Verwaltet (TD) | Verwaltet (istiod) ist veraltet |
|---|---|---|
| Einzelnes Netzwerk | ||
| Multinetzwerk | ||
| Einzelprojekt | ||
| Mehrere Projekte mit freigegebene VPC |
Multi-Cluster-Bereitstellung
| Funktion | Verwaltet (TD) | Verwaltet (istiod) ist veraltet |
|---|---|---|
| Multiprimär | ||
| Primäre Fernbedienung | ||
| Multi-Cluster Endpoint Discovery mit declarative API | ||
| Endpunkterkennung für mehrere Cluster mit Remote-Secrets | ||
| Multi-Cluster-Endpunkterkennung mit deklarativer API und einer einfachen Topologie |
Hinweise zur Terminologie
- Bei einer Konfiguration mit mehreren Primärclustern muss die Konfiguration in allen Clustern repliziert werden.
- Bei einer primären Remote-Konfiguration enthält ein einzelner Cluster die Konfiguration und gilt als „Source of Truth“.
- 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. Komplexe Topologien, die nicht unterstützt werden, umfassen (a) die unidirektionale Endpunkterkennung (z.B. Cluster A kann Endpunkte in Cluster B erkennen, aber nicht umgekehrt) und (b) disjunkte Endpunkterkennungsnetzwerke (z.B. Cluster A und B können 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) ist veraltet |
|---|---|---|
| Distroless-Proxy-Image | † |
† Istio veröffentlicht Proxy-Images für default, debug und distroless. Für Cloud Service Mesh mit einer verwalteten (TRAFFIC_DIRECTOR) Steuerungsebene: Direkt eingebundene Cluster verwenden standardmäßig distroless und können nicht geändert werden. In migrierten Clustern werden standardmäßig default-Images verwendet. Sie können distroless mit MeshConfig oder einer Pod-Annotation aktivieren. Überschreibungen für andere Bildtypen (debug) werden nicht unterstützt.
Distroless-Images enthalten nur minimale Binärdateien. Daher können Sie 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 eine Verbindung zu einem laufenden Arbeitslast-Pod herzustellen, um ihn zu untersuchen und benutzerdefinierte Befehle auszuführen. Ein Beispiel finden Sie unter Cloud Service Mesh-Logs erfassen.
Sicherheit
VPC Service Controls
| Funktion | Verwaltet (TD) | Verwaltet (istiod) ist veraltet |
|---|---|---|
| VPC Service Controls |
Mechanismen zur Zertifikatsverteilung und ‑rotation
| Funktion | Verwaltet (TD) | Verwaltet (istiod) ist veraltet |
|---|---|---|
| Verwaltung von Arbeitslastzertifikaten | ||
| Externe Zertifikatsverwaltung auf Ingress- und Egress-Gateways. |
Unterstützung von Zertifizierungsstellen (CA)
| Funktion | Verwaltet (TD) | Verwaltet (istiod) ist veraltet |
|---|---|---|
| Cloud Service Mesh-Zertifizierungsstelle | ||
| Certificate Authority Service | ||
| Istio CA | ||
| Integration in benutzerdefinierte Zertifizierungsstellen |
Sicherheitsfunktionen
Cloud Service Mesh unterstützt nicht nur Istio-Sicherheitsfunktionen, sondern bietet auch weitere Funktionen zum Schutz Ihrer Anwendungen.
| Funktion | Verwaltet (TD) | Verwaltet (istiod) ist veraltet |
|---|---|---|
| IAP-Einbindung | ||
| Endnutzerauthentifizierung | ||
| Probelaufmodus | ||
| Logging der Ablehnung | ||
| Audit-Richtlinien (nicht unterstützt) |
Autorisierungsrichtlinie
| Funktion | Verwaltet (TD) | Verwaltet (istiod) ist veraltet |
|---|---|---|
| Autorisierungs-v1beta1-Richtlinie | ||
| BENUTZERDEFINIERTE Autorisierungsrichtlinie |
Peer-Authentifizierung
| Funktion | Verwaltet (TD) | Verwaltet (istiod) ist veraltet |
|---|---|---|
| Auto-mTLS | ||
| mTLS-PERMISSIVE-Modus | ||
| mTLS-STRICT-Modus | * | * |
| mTLS-DISABLE-Modus |
Hinweis:Die PeerAuthentication API unterstützt den DISABLE-Modus für die Implementierung der TRAFFIC_DIRECTOR-Steuerungsebene nicht. Sie können mTLS für bestimmte Arbeitslasten jedoch mit der DestinationRule API als Workaround deaktivieren. Weitere Informationen finden Sie unter mTLS für Managed CSM deaktivieren.
Authentifizierung anfordern
| Funktion | Verwaltet (TD) | Verwaltet (istiod) ist veraltet |
|---|---|---|
| JWT-Authentifizierung(Hinweis 1) | ||
| JWT-Anforderungsbasiertes Routing | ||
| JWT-Anspruch in Header kopieren |
Hinweise:
- JWT von Drittanbietern ist standardmäßig aktiviert.
- Fügen Sie den vollständigen FQDN/Hostnamen in JWKSURI ein, wenn Sie die RequestAuthentication API definieren.
- Bei der verwalteten Steuerungsebene wird Envoy gezwungen, JWKS abzurufen, wenn ein JWKS-URI angegeben wird.
- Die AES-CBC-Algorithmen A128CBC-HS256, A192CBC-HS384 und A256CBC-HS512 sind in Inline-JWKS nicht zulässig, wenn die
TRAFFIC_DIRECTOR-Steuerungsebene verwendet wird.
Telemetrie
Messwerte
| Funktion | Verwaltet (TD) | Verwaltet (istiod) ist veraltet |
|---|---|---|
| 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 TRAFFIC_DIRECTOR-Steuerungsebene unterstützt eine Teilmenge der Istio-Telemetrie-API, die zum Konfigurieren von Zugriffsprotokollen und Traces verwendet wird.
Proxyanfrage-Logging
| Funktion | Verwaltet (TD) | Verwaltet (istiod) ist veraltet |
|---|---|---|
| Traffic-Logs | ||
| Zugriffslogs | * | * |
Tracing
| Funktion | Verwaltet (TD) | Verwaltet (istiod) ist veraltet |
|---|---|---|
| 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) ist veraltet |
|---|---|---|
Verwendung von iptables mit init-Containern über CAP_NET_ADMIN |
† | |
| Istio Container Network Interface (CNI) | ||
| Whitebox-Sidecar |
† Wir empfehlen dringend, Container Network Interface (CNI) anstelle von init-Containern zu verwenden.
Protokollunterstützung
| Funktion | Verwaltet (TD) | Verwaltet (istiod) ist veraltet |
|---|---|---|
| IPv4 | ||
| HTTP/1.1 | ||
| HTTP/2 | ||
| TCP-Byte-Streams (Hinweis 1) | ||
| gRPC | ||
| IPv6 | † |
Hinweise:
- 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.
- 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. Obwohl Gateway-Ports mit dem Mongo-, MySQL- und Redis-Protokoll erstellt werden können, behandelt das Mesh den resultierenden Traffic als Standard-TCP, ohne protokollspezifische Verarbeitung.
- † Bei proxylosen gRPC-Bereitstellungen werden IPv6-Dual-Stack-Funktionen 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-Funktionen mit einer Version von gRPC 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) ist veraltet |
|---|---|---|
| Sidecar-Dateien | ||
| Ingress-Gateway | ||
| Ausgehender Traffic direkt von Sidecars | ||
| Ausgehender Traffic über Egress-Gateways | * | * |
CRD-Support
| Funktion | Verwaltet (TD) | Verwaltet (istiod) ist veraltet |
|---|---|---|
| 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) ist veraltet |
|---|---|---|
| Externer Load Balancer von Drittanbietern | ||
| Google Cloud Interner Load Balancer | * | * |
Service Mesh-Cloud-Gateway
| Funktion | Verwaltet (TD) | Verwaltet (istiod) ist veraltet |
|---|---|---|
| Service Mesh-Cloud-Gateway |
Kubernetes Gateway API
| Funktion | Verwaltet (TD) | Verwaltet (istiod) ist veraltet |
|---|---|---|
| Kubernetes Gateway API |
Load Balancing-Richtlinien
| Funktion | Verwaltet (TD) | Verwaltet (istiod) ist veraltet |
|---|---|---|
| Round-Robin | ||
| Mindestverbindungen | ||
| Zufällig | ||
| Passthrough | ||
| Konsistenter Hash | ||
| Ort | ||
| GCPTrafficDistributionPolicy | ||
| GCPBackendPolicy |
Load-Balancing-Modi
| Funktion | Verwaltet (TD) | Verwaltet (istiod) ist veraltet |
|---|---|---|
| PREIS | ||
| NUTZUNG | ||
| CUSTOM_METRICS | ||
| AKTIV |
Weitere Informationen zu Balancing-Modi finden Sie in der Übersicht zu Back-End-Diensten.
Diensteintrag
| Funktion | Verwaltet (TD) | Verwaltet (istiod) ist veraltet |
|---|---|---|
| ServiceEntry v1beta1 | † |
† Die TRAFFIC_DIRECTOR-Implementierung der Steuerungsebene unterstützt nur 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) ist veraltet |
|---|---|---|
| DestinationRule v1beta1 | † |
† Für die Implementierung der TRAFFIC_DIRECTOR-Steuerungsebene muss sich die Zielregel, in der Teilmengen definiert werden, im selben Namespace und Cluster wie der Kubernetes-Dienst oder ServiceEntry befinden. Eine vollständige Liste der unterstützten und nicht unterstützten Felder sowie der Konfigurationseinschränkungen finden Sie unter API-Unterstützung: DestinationRule.
Sidecar
| Funktion | Verwaltet (TD) | Verwaltet (istiod) ist veraltet |
|---|---|---|
| Sidecar v1beta1 | † |
† Die TRAFFIC_DIRECTOR-Implementierung der Steuerungsebene unterstützt nur einen Teil der Sidecar-Felder. Eine vollständige Liste der unterstützten und nicht unterstützten Felder sowie der Konfigurationseinschränkungen finden Sie unter API-Unterstützung: Sidecar.
DNS-Proxy
| Funktion | Verwaltet (TD) | Verwaltet (istiod) ist veraltet |
|---|---|---|
Namensauflösung von Service über Cluster hinweg |
† | |
Namensauflösung von ServiceEntry in einem Cluster |
† | |
Namensauflösung von Headless Service |
||
| Automatische Adresszuweisung | † |
† 1.21.5-asm.39 oder eine höhere Version des Sidecars ist erforderlich.
EnvoyFilter
| Funktion | Verwaltet (TD) | Verwaltet (istiod) ist veraltet |
|---|---|---|
| EnvoyFilter v1alpha3 | † |
† Informationen zu unterstützten Feldern und konfigurierbaren Erweiterungen finden Sie auf der Seite zur Datenebene.
MeshConfig
| Funktion | Verwaltet (TD) | Verwaltet (istiod) ist veraltet |
|---|---|---|
| DiscoverySelectors | ||
| clusterLocal | ||
| LocalityLB | † | |
| ExtensionProviders | ||
| CACert | ||
| ImageType – distroless | † | |
| OutboundTrafficPolicy | ||
| defaultProviders.accessLogging | ||
| defaultProviders.tracing | ||
| defaultConfig.tracing.stackdriver | ||
| accessLogFile | † | |
| accessLogFormat | † | |
| accessLogEncoding | † |
† Weitere Informationen zum Konfigurationsverhalten finden Sie unter Distroless-Proxy-Image.
† Weitere Informationen zum Konfigurationsverhalten und zu Einschränkungen finden Sie unter Locality Load Balancing konfigurieren.
† Ausführliche Informationen zum Konfigurationsverhalten und zu Einschränkungen finden Sie unter Envoy-Zugriffslogformat und ‑codierung anpassen.
ProxyConfig
| Funktion | Verwaltet (TD) | Verwaltet (istiod) ist veraltet |
|---|---|---|
| HTTP/1.0-Unterstützung (ISTIO_META_NETWORK) | ||
| Bildauswahl (Distroless- oder Basis-Image) | ||
| Kubernetes-nativer 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) ist veraltet |
|---|---|---|
| Cloud Service Mesh-Dashboards in der Google Cloud Console | ||
| Cloud Monitoring | ||
| Cloud Logging |
Tools
| Funktion | Verwaltet (TD) | Verwaltet (istiod) ist veraltet |
|---|---|---|
gcloud beta container fleet mesh debug tool |