Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Unterstützte Features, die Istio APIs verwenden (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 und dem
Unterschiede zwischen den einzelnen Implementierungen. Beachten Sie, dass dies keine Optionen sind,
auswählen. Die ISTIOD-Implementierung ist nur für bestehende Nutzer verfügbar.
Für Neuinstallationen 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 Methode
gcloud beta container fleet mesh debug-Befehle, wie in
Fehlerbehebung.
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 -Funktionen in der Google Cloud Console sind jedoch
an GKE Enterprise-Abonnenten. Informationen zu den verfügbaren
für Abonnenten und Nichtabonnenten, siehe
Unterschiede zwischen der GKE Enterprise- und Cloud Service Mesh-UI
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 DNS-Standarddomain .cluster.local.
Seit dem 14. November 2023 werden Neuinstallationen von Managed Cloud Service Mesh auf dem
rapid-Releasekanal ruft JWKS nur mit Envoys ab. 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 finden Sie in der
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
Implementierung der Steuerungsebene identifizieren
– 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. Frühere Nutzer des verwalteten Anthos Service Mesh sind
automatisch auf Organisationsebene auf die Zulassungsliste gesetzt.
Wenden Sie sich an den Google Cloud-Support, um Zugriff anzufordern.
oder um den Status der 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.
Wie wird die Implementierung der Steuerungsebene bestimmt?
Wenn Sie ein verwaltetes Cloud Service Mesh zum ersten Mal in einer Flotte bereitstellen,
um zu ermitteln, welche
Implementierung der Steuerungsebene 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 das verwaltete Cloud Service Mesh aufgenommen werden, erhalten das
Implementierung der TRAFFIC_DIRECTOR-Steuerungsebene mit bestimmten Ausnahmen:
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 einer dieser Nutzer sind, 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 einen Dienst erhalten,
Announcement.)
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 ein clusterinternes Cloud Service Mesh enthält
Steuerungsebene, wenn Sie das
verwaltete Cloud Service Mesh bereitstellen,
die Implementierung der ISTIOD-Steuerungsebene abrufen.
Wenn ein Cluster in Ihrer Flotte
GKE Sandbox
Wenn Sie das verwaltete Cloud Service Mesh bereitstellen, erhalten Sie das ISTIOD
Implementierung der Steuerungsebene.
Von der verwaltete Steuerungsebene unterstützte Features
Installieren, aktualisieren und Rollback ausführen
Umgebungen außerhalb von Google Cloud (GKE Enterprise lokal,
GKE Enterprise in anderen öffentlichen Clouds, Amazon EKS, Microsoft AKS,
oder anderen Kubernetes-Clustern)
Eine multiprimäre Konfiguration bedeutet, dass die Konfiguration repliziert werden muss
in allen Clustern.
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 Image-Typ „distroless“. Sie können sie nicht ändern.
Beachten Sie, dass distroless-Images nur minimale Binärdateien haben, sodass Sie die üblichen
wie bash oder curl, 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. Siehe zum Beispiel
Cloud Service Mesh-Logs erfassen
Integration in benutzerdefinierte Zertifizierungsstellen
Sicherheitsfunktionen
Zusätzlich zu den Istio-Sicherheitsfunktionen
unterstützt Cloud Service Mesh
bietet noch mehr Funktionen, mit denen Sie Ihre Anwendungen schützen können.
Obwohl TCP ein unterstütztes Protokoll für Netzwerke und TCP ist,
erfasst, aber nicht gemeldet. Messwerte werden nur angezeigt für
HTTP-Dienste in der Google Cloud Console.
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.
† IPv6 ist als Dual-Stack-Netzwerkfunktion in der Vorabversion verfügbar. In
Proxylose gRPC- und Dualstack-Features werden nur in gRPC 1.66.1 oder höher unterstützt.
in C++ und Python oder gRPC Node.js v1.12. Wenn Sie versuchen, Dual-Stack-Funktionen mit der Version
Bei gRPC, das Dual-Stack nicht unterstützt, verwenden die Clients nur die erste
die von Traffic Director gesendet wurde.
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-10-19 (UTC)."],[],[]]
