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 Cloud Service Mesh 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. Bei Neuinstallationen wird die Cloud Service Mesh-Implementierung verwendet.

Liste der von Cloud Service Mesh unterstützten Features für einen Cluster im Cluster Steuerungsebene, siehe Istio APIs verwenden (Clusterinterne istiod-Steuerungsebene) Wenn Sie nicht sicher sind, welche Cloud Service Mesh-Steuerungsebene Sie verwenden, die Implementierung der Steuerungsebene anhand der Anweisungen im Implementierung der Steuerungsebene identifizieren

Beschränkungen

<ph type="x-smartling-placeholder">

</ph> Achtung: Alle Cloud Service Mesh-Cluster für ein Mesh-Netzwerk müssen registriert sein unter immer dieselbe Flotte nutzen, um Cloud Service Mesh zu verwenden. Andere Cluster im Projekt eines Cloud Service Mesh-Clusters darf nicht bei einem anderen Flotte.

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.
• Das Ändern der Release-Versionen ist nicht unterstützt.
• Migrationen von verwaltetes Cloud Service Mesh mit asmcli bis Cloud Service Mesh mit Flotten-API werden nicht unterstützt. Entsprechend wird das verwaltete Cloud Service Mesh mit der Flotten-API bereitgestellt. von --management manual bis --management automatic wird nicht unterstützt.
• Migrationen und Upgrades werden nur vom Cloud Service Mesh im Cluster unterstützt Version 1.9 oder höher mit Mesh CA installiert. 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

  • Kubernetes Gateway API

  Hinweis: Optionale Features können Sie auch ohne die IstioOperator API aktivieren. Weitere Informationen finden Sie unter Optionale Features im verwalteten Cloud Service Mesh aktivieren. Mit dem in asmcli enthaltenen Migrationstool können Sie außerdem andere optionale IstioOperator-Features automatisch konvertieren, damit sie mit der von Google verwalteten Steuerungsebene kompatibel sind. Weitere Informationen finden Sie unter Von IstioOperator migrieren.

• 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 die Istio-Option PILOT_JWT_ENABLE_REMOTE_JWKS=envoy. Im Vergleich zu Installationen auf reguläre und stabile Release-Versionen oder Installationen auf der rasche Release-Version vor dem 14. November 2023 nicht verfügbar ist, benötigen Sie möglicherweise zusätzliche ServiceEntry- und DestinationRule-Konfigurationen. Ein Beispiel finden Sie in der requestauthn-with-se.yaml.tmpl.

Unterschiede der Steuerungsebene

Zwischen istiod und Cloud Service Mesh gibt es Unterschiede bei den unterstützten Features Implementierungen der Steuerungsebene. 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 Funktions-APIs möglicherweise Unterschiede zwischen verschiedenen Plattformen.
• *: Gibt an, dass die Funktion unterstützt wird für und kann wie im Artikel Optionale Features aktivieren oder in der Funktionsübersicht, die in der Funktionstabelle verlinkt ist.
• §: Gibt an, dass das Element in die von der Zulassungsliste unterstützt werden. 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 das verwaltete Cloud Service Mesh in dieser Flotte 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 Nutzer eines verwalteten Cloud Service Mesh sind, erhalten Sie das ISTIOD Implementierung der Steuerungsebene, wenn Sie eine neue Flotte in derselben Google Cloud einrichten Organisation zum verwalteten Cloud Service Mesh, bis mindestens 30. Juni 2024. Wenn Sie einer dieser Nutzer sind, können Sie sich an den Support wenden, um dieses Verhalten zu optimieren. Nutzer, deren aktuelle Nutzung nicht mit TRAFFIC_DIRECTOR kompatibel ist Implementierung ohne Änderungen erhält weiterhin den ISTIOD Implementierung bis zum 8. September 2024. (Diese Nutzer erhielten einen Dienst Announcement.)
• Wenn ein Cluster in Ihrer Flotte beim Bereitstellen verwalteter Cluster Certificate Authority Service verwendet Cloud Service Mesh erhalten Sie die Implementierung der 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.

Implementierung der Steuerungsebene identifizieren

Führen Sie den folgenden Befehl aus, um die Implementierung der Steuerungsebene zu identifizieren:

  gcloud container fleet mesh describe --project FLEET_PROJECT_ID

Wenn Sie Cloud Service Mesh mit Google Cloud APIs verwenden (siehe Informationen zu Cloud Service Mesh, klicken Sie auf diesen Befehl, funktioniert nicht.

Die Ausgabe sieht in etwa so aus:

  ...
  membershipSpecs:
    projects/746296320118/locations/us-central1/memberships/demo-cluster-1:
      mesh:
        management: MANAGEMENT_AUTOMATIC
  membershipStates:
    projects/746296320118/locations/us-central1/memberships/demo-cluster-1:
      servicemesh:
        controlPlaneManagement:
          details:
          - code: REVISION_READY
            details: 'Ready: asm-managed'
          state: ACTIVE
          implementation: TRAFFIC_DIRECTOR
  ...

Die möglichen Werte implementation sind:

• TRAFFIC_DIRECTOR: Die Kerninfrastruktur von Google Cloud dient als Cloud Service Mesh-Steuerungsebene.
• ISTIOD: Die verwaltete Instanz von istiod dient als Cloud Service Mesh. Steuerungsebene.
• UPDATING: Der Cluster wird zwischen Implementierungen migriert. Bald erhält die TRAFFIC_DIRECTOR-Implementierung.

Von der verwaltete Steuerungsebene unterstützte Features

Installation, Upgrade und Rollback

Feature	Verwaltet (TD)	Verwaltet (istiod)
Installation auf GKE-Clustern mit der Fleet Feature API
Upgrades von ASM 1.9-Versionen mit Mesh CA
Direkte Upgrades (ohne Überspringen) 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

Hinweis :Indirekte Migrationen und Upgrades werden unterstützt. Sie können das standardmäßige Cloud Service Mesh Upgradepfade bis Sie das Cloud Service Mesh 1.21 mit einem in der clusterinternen Steuerungsebene haben Sie die Möglichkeit, zur verwalteten Steuerungsebene zu migrieren. Direkte Migrationen und Upgrades werden nur von Cloud Service Mesh-Versionen unterstützt 1.9 oder höher mit Mesh CA installiert. Installationen mit Istio CA müssen zuerst zu Mesh CA migriert werden.

Umgebungen

Feature	Verwaltet (TD)	Verwaltet (istiod)
GKE 1.25–1.27 in einer der unterstützten Regionen
GKE 1.25-1.27-Cluster mit Autopilot
Umgebungen außerhalb von Google Cloud (GKE Enterprise lokal, GKE Enterprise in anderen öffentlichen Clouds, Amazon EKS, Microsoft AKS, oder anderen Kubernetes-Clustern)

Skalieren

Feature	Verwaltet (TD)	Verwaltet (istiod)
1.000 Dienste und 5.000 Arbeitslasten pro Cluster
50 ServicePorts pro Mesh und 36 Pods pro ServicePort

Hinweis: Dies ist ein weiches Limit für die Anzahl der Dienste und Arbeitslasten, die pro Cluster. Wenden Sie sich an den Cloud-Support, wenn Sie dieses Limit überschreiten.

Plattformumgebung

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

Multi-Cluster-Bereitstellung

Feature	Verwaltet (TD)	Verwaltet (istiod)
Multiprimär
Primäre Fernbedienung
Erkennung von Multi-Cluster-Endpunkten mit deklarativer API
Erkennung von Multi-Cluster-Endpunkten mit Remote-Secrets

Hinweise zur Terminologie

• Eine multiprimäre Konfiguration bedeutet, dass die Konfiguration repliziert werden muss in allen Clustern.
• Eine Primär-Remote-Konfiguration bedeutet, dass ein einzelner Cluster Konfiguration und gilt als "Source of Truth".
• Das Cloud Service Mesh verwendet eine vereinfachte Netzwerkdefinition Konnektivität haben. Arbeitslastinstanzen befinden sich im selben Netzwerk, wenn sie ohne Gateway direkt kommunizieren können.

Basis-Images

Feature	Verwaltet (TD)	Verwaltet (istiod)
Distroless-Proxy-Image	†

† Cloud Service Mesh mit einer verwalteten Steuerungsebene (TD) unterstützt nur Distroless-Image-Typ. Sie können ihn nicht ändern.

Beachten Sie, dass distroless-Images nur minimale Binärdateien haben, sodass Sie die üblichen wie bash oder curl, weil sie im distroless-Image nicht vorhanden sind. Sie können jedoch sitzungsspezifische Container verwenden, um sie an einen ausgeführten Arbeitslast-Pod anzuhängen, und benutzerdefinierte Befehle ausführen. Siehe zum Beispiel Cloud Service Mesh-Logs erfassen

Sicherheit

VPC Service Controls

Feature	Verwaltet (TD)	Verwaltet (istiod)
Vorschau zu VPC Service Controls
GA: VPC Service Controls

Mechanismen zur Zertifikatsverteilung und -rotation

Feature	Verwaltet (TD)	Verwaltet (istiod)
Verwaltung von Arbeitslastzertifikaten
Externe Zertifikatsverwaltung auf Eingangs- und Ausgangs-Gateways.

Unterstützung von Zertifizierungsstellen (CA)

Feature	Verwaltet (TD)	Verwaltet (istiod)
Cloud Service Mesh-Zertifizierungsstelle
Certificate Authority Service
Istio CA
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.

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

Autorisierungsrichtlinie

Feature	Verwaltet (TD)	Verwaltet (istiod)
Autorisierungs-v1beta1-Richtlinie	†
BENUTZERDEFINIERTE Autorisierungsrichtlinie	§

† Die Implementierung der Cloud Service Mesh-Steuerungsebene unterstützt nicht den rules.from.source.RemoteIp- und rules.from.source.NotRemoteIp-Felder.

Peer-Authentifizierung

Feature	Verwaltet (TD)	Verwaltet (istiod)
Auto-mTLS
mTLS-PERMISSIVE-Modus
mTLS-STRICT-Modus	*	*
mTLS-DEAKTIVIERUNGsmodus

Authentifizierung anfordern

Feature	Verwaltet (TD)	Verwaltet (istiod)
JWT-Authentifizierung^(Hinweis 1)
JWT-Anforderungsbasiertes Routing
JWT-Copyanforderung an Header

Hinweise:

1. JWT von Drittanbietern ist standardmäßig aktiviert.
2. Fügen Sie bei der Definition der RequestAuthentication API den vollständigen fqdn/hostname in JWKSURI hinzu.
3. Die verwaltete Steuerungsebene erzwingt Envoy, JWKS abzurufen, wenn der JWKS-URI angegeben wird.

Telemetrie

Messwerte

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

† Die Cloud Service Mesh-Steuerungsebene unterstützt einen Teil der Istio Telemetrie API zum Konfigurieren von Zugriffslogs und trace.

Hinweis :Sie können Telemetrieprodukte von Drittanbietern wie Grafana, und Prometheus), aber wir können zukünftige Kompatibilität und Cloud-Support nicht garantieren. kann Ihnen bei deren Verwaltung nicht helfen.

Proxy-Anfrage-Logging

Feature	Verwaltet (TD)	Verwaltet (istiod)
Traffic logs
Zugriffslogs	*	*

Tracing

Feature	Verwaltet (TD)	Verwaltet (istiod)
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

Hinweis :Sie können Telemetrieprodukte von Drittanbietern wie Jaeger, Zipkin, und Grafana), können jedoch die zukünftige Kompatibilität und den Cloud-Support nicht garantieren. kann Ihnen bei deren Verwaltung nicht helfen.

Netzwerk

Mechanismen zum Abfangen und Umleiten von Traffic

Feature	Verwaltet (TD)	Verwaltet (istiod)
Traditionelle Verwendung von iptables mit init-Containern über CAP_NET_ADMIN
Istio Container Network Interface (CNI)
Whitebox-Sidecar

Protokollunterstützung

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

Hinweise:

1. 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.
2. 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. sendet Kafka eine Weiterleitungsadresse in einer protokollspezifischen Antwort und Diese Weiterleitung ist nicht mit der Routinglogik von Cloud Service Mesh kompatibel, dann das Protokoll nicht unterstützt wird.

Envoy-Bereitstellungen

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

CRD-Support

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

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

Feature	Verwaltet (TD)	Verwaltet (istiod)
Externer Load-Balancer eines Drittanbieters
Interner Google Cloud-Load-Balancer	*	*

Service Mesh-Cloud-Gateway

Feature	Verwaltet (TD)	Verwaltet (istiod)
Service Mesh-Cloud-Gateway

Kubernetes Gateway API

Feature	Verwaltet (TD)	Verwaltet (istiod)
Kubernetes Gateway API

Load-Balancing-Richtlinien

Feature	Verwaltet (TD)	Verwaltet (istiod)
Round-Robin
Mindestverbindungen
Zufällig
Passthrough
Konsistenter Hash
Ort

Diensteintrag

Feature	Verwaltet (TD)	Verwaltet (istiod)
ServiceEntry v1beta1	†

† Die Implementierung der Cloud Service Mesh-Steuerungsebene unterstützt Folgendes nicht: und Werte in Feldern:

• 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

Feature	Verwaltet (TD)	Verwaltet (istiod)
Zielregel (v1beta1)	†

† Die Implementierung der Cloud Service Mesh-Steuerungsebene unterstützt keine Feld trafficPolicy.loadBalancer.localityLbSetting und trafficPolicy.tunnel ein. Außerdem erfordert die Implementierung der Cloud Service Mesh-Steuerungsebene, dass das Zielregel, die Teilmengen definiert, befindet sich im selben Namespace und Cluster mit den Kubernetes-Dienst oder ServiceEntry.

Sidecar

Feature	Verwaltet (TD)	Verwaltet (istiod)
Sidecar v1beta1	†

† Die Implementierung der Cloud Service Mesh-Steuerungsebene unterstützt Folgendes nicht: und Werte in Feldern:

• Feld ingress
• Feld egress.port
• Feld egress.bind
• Feld egress.captureMode
• Feld inboundConnectionPool

MeshConfig

Feature	Verwaltet (TD)	Verwaltet (istiod)
LocalityLB	§
ExtensionProviders	§
CACert
ImageType – distroless	§
OutboundTrafficPolicy	§
defaultProviders.accessLogging
defaultProviders.tracing
defaultConfig.tracing.stackdriver	§
accessLogFile	§

ProxyConfig

Feature	Verwaltet (TD)	Verwaltet (istiod)
DNS-Proxy (ISTIO_META_DNS_CAPTURE, ISTIO_META_DNS_AUTO_ALLOCATE)
HTTP/1.0-Unterstützung (ISTIO_META_NETWORK)
Bildauswahl (Distroless- oder Basis-Image)	†

† Für die Injektion wird Distroless-Image verwendet.

Regionen

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

Region	Ort
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-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
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

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

Tools

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