Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Von Istio APIs unterstützte Features (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 nicht ausgewählt werden. 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 von Cloud Service Mesh unterstützten Features für eine clusterinterne Steuerungsebene finden Sie unter Istio APIs verwenden (istiod-Steuerungsebene in Clustern).
Wenn Sie sich nicht sicher sind, welche Cloud Service Mesh-Steuerungsebene Sie verwenden, können Sie die Implementierung der Steuerungsebene anhand der Anleitung unter Steuerungsebenenimplementierung 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.
Migrationen und Upgrades werden nur von Cloud Service Mesh-Versionen ab Cluster 1.9 unterstützt, die mit Mesh CA installiert sind. Installationen mit Istio CA (ehemals Citadel) müssen zuerst zu Mesh CA migriert werden.
Die Skalierung ist auf 1.000 Dienste und 5.000 Arbeitslasten pro Cluster beschränkt.
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:
EnvoyFilter API
WasmPlugin API
IstioOperator API
Kubernetes Ingress API
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 der Benutzeroberfläche von GKE Enterprise und Cloud Service Mesh.
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.
Verwaltetes Cloud Service Mesh unterstützt nur die Standard-DNS-Domain .cluster.local.
Seit dem 14. November 2023 werden für neue Installationen von verwaltetem Cloud Service Mesh im Rapid Release Channel JWKS nur noch mit Envoys abgerufen. Dies entspricht der Istio-Option PILOT_JWT_ENABLE_REMOTE_JWKS=envoy. Im Vergleich zu Installationen im regulären und stabilen Release-Kanal oder Installationen im schnellen Release-Kanal vor dem 14. November 2023 sind möglicherweise zusätzliche ServiceEntry- und DestinationRule-Konfigurationen erforderlich. Ein Beispiel ist requestauthn-with-se.yaml.tmpl.
Unterschiede auf Steuerungsebene
Es gibt Unterschiede bei den unterstützten Funktionen zwischen den ISTIOD- und TRAFFIC_DIRECTOR-Steuerungsebenen. Informationen dazu, welche Implementierung Sie verwenden, finden Sie unter Steuerungsebenenimplementierung ermitteln.
– gibt an, dass das Feature verfügbar und standardmäßig aktiviert ist.
† = gibt an, dass sich Funktions-APIs auf 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 die Funktion über die Zulassungsliste unterstützt wird. Bisherige Nutzer von verwaltetem Anthos Service Mesh werden automatisch auf Organisationsebene auf die Zulassungsliste gesetzt.
Wenden Sie sich an den Google Cloud-Support, um Zugriff zu beantragen oder den Status Ihrer Zulassungsliste zu prüfen.
– 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, legen wir fest, welche Steuerungsebenenimplementierung verwendet werden soll. Die gleiche Implementierung wird für alle Cluster verwendet, die in dieser Flotte verwaltetes Cloud Service Mesh bereitstellen.
Neue Flotten, die in verwaltetes Cloud Service Mesh aufgenommen werden, erhalten mit bestimmten Ausnahmen die TRAFFIC_DIRECTOR-Steuerungsebene.
Wenn Sie bereits Cloud Service Mesh verwaltet verwenden, erhalten Sie die ISTIOD-Steuerungsebene, wenn Sie bis mindestens 30. Juni 2024 eine neue Flotte in derselben Google Cloud-Organisation in Cloud Service Mesh verwaltet aufnehmen.
Wenn Sie zu diesen Nutzern gehören, können Sie sich an den Support wenden, um dieses Verhalten zu optimieren.
Nutzer, deren bisherige Nutzung nicht ohne Änderungen mit der TRAFFIC_DIRECTOR-Implementierung kompatibel ist, erhalten bis zum 8. September 2024 weiterhin die ISTIOD-Implementierung. (Diese Nutzer haben eine Servicemitteilung erhalten.)
Wenn bei der Bereitstellung eines verwalteten Cloud Service Mesh ein Cluster in Ihrer Flotte den Certificate Authority Service verwendet, erhalten Sie die ISTIOD-Steuerungsebene.
Wenn ein Cluster in Ihrer Flotte beim Bereitstellen von verwaltetem Cloud Service Mesh eine clusterinterne Cloud Service Mesh-Steuerungsebene enthält, wird die ISTIOD-Steuerungsebene implementiert.
Wenn in Ihrer Flotte ein Cluster die GKE Sandbox verwendet, 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
Umgebungen außerhalb von Google Cloud (lokale GKE Enterprise, GKE Enterprise in anderen öffentlichen Clouds, Amazon EKS, Microsoft AKS oder andere Kubernetes-Cluster)
Bei einer Multi-Primary-Konfiguration muss die Konfiguration in allen Clustern repliziert werden.
Eine Primary-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.
† Cloud Service Mesh mit einer verwalteten Steuerungsebene (TD) unterstützt nur den Imagetyp „distroless“. Sie können sie nicht ändern.
Beachten Sie, dass Distroless-Images nur minimale Binärdateien enthalten. 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 einen laufenden Workload-Pod anzuhängen, um ihn zu prüfen und benutzerdefinierte Befehle auszuführen. Weitere Informationen finden Sie beispielsweise unter Cloud Service Mesh-Protokolle erfassen.
Integration in benutzerdefinierte Zertifizierungsstellen
Sicherheitsfunktionen
Cloud Service Mesh unterstützt nicht nur die Sicherheitsfunktionen von Istio, sondern bietet auch weitere Funktionen, mit denen Sie Ihre Anwendungen schützen können.
TCP ist ein unterstütztes Protokoll für das Netzwerk und TCP-Messwerte werden erfasst, aber 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, 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.
† Die TRAFFIC_DIRECTOR-Steuerungsebene unterstützt die folgenden Felder und Werte in Feldern nicht:
Feld workloadSelector
Feld endpoints[].network
Feld endpoints[].locality
Feld endpoints[].weight
Feld endpoints[].serviceAccount
DNS_ROUND_ROBIN-Wert im Feld resolution
MESH_INTERNAL-Wert im Feld location
Unix-Domain-Socket-Adresse im Feld endpoints[].address
Feld subjectAltNames
Zielregel
Funktion
Verwaltet (TD)
Verwaltet (istiod)
DestinationRule v1beta1
†
† Die TRAFFIC_DIRECTOR-Steuerungsebene unterstützt die Felder trafficPolicy.loadBalancer.localityLbSetting und trafficPolicy.tunnel nicht.
Außerdem erfordert die Implementierung der TRAFFIC_DIRECTOR-Steuerungsebene, dass sich die Zielregel, die Teilmengen definiert, im selben Namespace und Cluster wie der Kubernetes-Dienst oder ServiceEntry befindet.
Sidecar
Funktion
Verwaltet (TD)
Verwaltet (istiod)
Sidecar v1beta1
†
† Die TRAFFIC_DIRECTOR-Steuerungsebene unterstützt die folgenden Felder und Werte in Feldern nicht:
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2024-12-04 (UTC)."],[],[]]
