Unterstützte Features, die Istio APIs verwenden (verwaltete Steuerungsebene)

Auf dieser Seite werden die unterstützten Features und Einschränkungen für Cloud Service Mesh mit Cloud Service Mesh oder istiod als Steuerungsebene sowie die Unterschiede zwischen den einzelnen Implementierungen beschrieben. Beachten Sie, dass diese Optionen nicht zur Auswahl stehen. Die Implementierung von istiod ist nur für bestehende Nutzer verfügbar. Neuinstallationen verwenden die Cloud Service Mesh-Implementierung.

Eine Liste der von Cloud Service Mesh unterstützten Features für eine clusterinterne Steuerungsebene finden Sie unter Looker APIs im Cluster (istiod-Steuerungsebene im Cluster) verwenden. Wenn Sie nicht sicher sind, welche Cloud Service Mesh-Steuerungsebene Sie verwenden, können Sie die Implementierung der Steuerungsebene mithilfe der Anleitung unter Implementierung der Steuerungsebene identifizieren prüfen.

Beschränkungen

Achtung: Alle Cloud Service Mesh-Cluster für ein Mesh-Netzwerk müssen immer bei derselben Flotte registriert sein, um Cloud Service Mesh verwenden zu können. Andere Cluster im Projekt eines Cloud Service Mesh-Clusters dürfen nicht bei einer anderen Flotte registriert sein.

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 wird nicht unterstützt.
• Migrationen vom verwalteten Cloud Service Mesh mit asmcli zu Cloud Service Mesh mit Flotten-API werden nicht unterstützt. Ebenso wird die Bereitstellung des verwalteten Cloud Service Mesh mit der Flotten-API von --management manual bis --management automatic nicht unterstützt.
• Migrationen und Upgrades werden nur von clusterinternen Cloud Service Mesh-Versionen ab 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

  • Kubernetes Gateway API

  Hinweis: Sie können optionale Features 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 Features in der Google Cloud Console sind jedoch nur für GKE Enterprise-Abonnenten verfügbar. Informationen dazu, was Abonnenten und Nicht-Abonnenten zur Verfügung steht, finden Sie unter Unterschiede zwischen 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 vorhandene Istio-CRDs vorhanden sind, werden sie überschrieben

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

• Seit dem 14. November 2023 rufen neue Installationen von verwaltetem Cloud Service Mesh auf dem schnellen Releasekanal JWKS nur mit Envoys ab. Dies entspricht der Istio-Option PILOT_JWT_ENABLE_REMOTE_JWKS=envoy. Im Vergleich zu Installationen auf den Release-Versionen regular und stable oder Installationen auf der schnellen Release-Version vor dem 14. November 2023 benötigen Sie möglicherweise zusätzliche ServiceEntry- und DestinationRule-Konfigurationen. Ein Beispiel findest du in der requestauthn-with-se.yaml.tmpl.

Unterschiede der Steuerungsebene

Die unterstützten Features der Implementierungen der istiod und der Cloud Service Mesh-Steuerungsebene unterscheiden sich. Informationen zur Prüfung, 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 es bei Feature APIs auf verschiedenen Plattformen Unterschiede geben kann.
• *: Gibt an, dass das Feature für die Plattform unterstützt wird und aktiviert werden kann, wie unter Optionale Features aktivieren oder im Funktionsleitfaden, den Sie in der Featuretabelle verlinkt haben, beschrieben.
• §: Gibt an, dass die Funktion von der Zulassungsliste unterstützt wird. Wenden Sie sich an den Google Cloud-Support, um Zugriff anzufordern.
•  – 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, bestimmen wir, welche Implementierung der Steuerungsebene verwendet werden soll. Für alle Cluster, die in dieser Flotte verwaltete Cloud Service Mesh bereitstellen, wird dieselbe Implementierung verwendet.

Neue Flotten, die im verwalteten Cloud Service Mesh eingerichtet werden, erhalten mit einigen Ausnahmen die Implementierung der Steuerungsebene TRAFFIC_DIRECTOR:

• Wenn Sie bereits ein verwaltetes Cloud Service Mesh-Nutzer sind, erhalten Sie die Implementierung der ISTIOD-Steuerungsebene mindestens bis zum 24. Juni 2024, wenn Sie eine neue Flotte in derselben Google Cloud-Organisation für das verwaltete Cloud Service Mesh einrichten. Wenn Sie einer dieser Nutzer sind, können Sie sich an den Support wenden, um dieses Verhalten zu optimieren.
• Wenn ein Cluster in Ihrer Flotte bei der Bereitstellung des verwalteten Cloud Service Mesh den Certificate Authority Service verwendet, erhalten Sie die Implementierung der Steuerungsebene ISTIOD.
• Wenn ein Cluster in Ihrer Flotte beim Bereitstellen des verwalteten Cloud Service Mesh eine clusterinterne Cloud Service Mesh-Steuerungsebene enthält, erhalten Sie die Implementierung der Steuerungsebene ISTIOD.
• Wenn ein Cluster in Ihrer Flotte GKE Sandbox verwendet, erhalten Sie beim Bereitstellen des verwalteten Cloud Service Mesh die Implementierung der ISTIOD-Steuerungsebene.

Implementierung der Steuerungsebene identifizieren

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

  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), funktioniert dieser Befehl 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
  ...

Mögliche Werte für 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 haben Sie die Implementierung TRAFFIC_DIRECTOR.

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 (ü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. Das bedeutet, dass Sie dem standardmäßigen Cloud Service Mesh-Upgradepfad durch jede Version folgen können, bis Sie Cloud Service Mesh mit einer clusterinternen Steuerungsebene erreichen. Anschließend können Sie zur verwalteten Steuerungsebene migrieren. Direkte Migrationen und Upgrades werden nur von Cloud Service Mesh-Versionen ab 1.9 unterstützt, die mit Mesh CA installiert wurden. 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 (lokale GKE Enterprise, GKE Enterprise in anderen öffentlichen Clouds, Amazon EKS, Microsoft AKS oder andere Kubernetes-Cluster)

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 unterstützt werden. 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
Multi-Cluster-Endpunkterkennung mit deklarativer API
Multi-Cluster-Endpunkterkennung mit Remote-Secrets

Hinweise zur Terminologie

• Eine Konfiguration mit mehreren primären Instanzen bedeutet, dass die Konfiguration in allen Clustern repliziert werden muss.
• Eine Primär-Remote-Konfiguration bedeutet, dass ein einzelner Cluster die Konfiguration enthält und als „Source of Truth“ gilt.
• Cloud Service Mesh verwendet eine vereinfachte Definition eines Netzwerks, die auf der allgemeinen Konnektivität basiert. 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 den Image-Typ „Distroless“. Diese Einstellung kann nicht geändert werden.

Da Distroless-Images nur minimale Binärprogramme haben, 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 sie an einen laufenden Arbeitslast-Pod anzuhängen, um ihn zu prüfen und benutzerdefinierte Befehle auszuführen. Ein Beispiel finden Sie unter Cloud Service Mesh-Logs erfassen.

Sicherheit

VPC Service Controls

Feature	Verwaltet (TD)	Verwaltet (istiod)
Vorschau von VPC Service Controls
VPC Service Controls allgemein

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 zur Unterstützung der Istio-Sicherheitsfeatures bietet Cloud Service Mesh noch mehr Funktionen zum Schutz Ihrer Anwendungen.

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	†
Autorisierungsrichtlinie BENUTZERDEFINIERT	§

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

Peer-Authentifizierung

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

Authentifizierung anfordern

Feature	Verwaltet (TD)	Verwaltet (istiod)
JWT-Authentifizierung^(Hinweis 1)
JWT-anforderungsbasiertes Routing
JWT-Kopieranforderung in Header

Hinweise:

1. JWT von Drittanbietern ist standardmäßig aktiviert.
2. Fügen Sie den vollständigen fqdn/hostname in JWKSURI ein, während Sie die RequestAuthentication API definieren.
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	*	*
Looker 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, mit der Zugriffslogs und trace konfiguriert werden.

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

Logging von Proxy-Anfragen

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 konfigurieren, aber wir können die zukünftige Kompatibilität nicht garantieren. Außerdem kann der Cloud-Support Ihnen bei deren Verwaltung nicht helfen.

Netzwerk

Mechanismen zum Abfangen und Umleiten von Zugriffen

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 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, 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.

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

Hinweis :Diese Funktion ist nur in der schnellen Release-Version verfügbar.

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 folgenden Felder und Werte in Feldern werden von der Implementierung der Cloud Service Mesh-Steuerungsebene nicht unterstützt:

• Feld workloadSelector
• Feld endpoints[].network
• Feld endpoints[].locality
• Feld endpoints[].weight
• Feld endpoints[].serviceAccount
• Wert „DNS_ROUND_ROBIN“ im Feld „resolution“
• Wert „MESH_INTERNAL“ im Feld „location“
• Unix-Domain-Socket-Adresse im Feld endpoints[].address

Zielregel

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

† Die Implementierung der Cloud Service Mesh-Steuerungsebene unterstützt die Felder trafficPolicy.loadBalancer.localityLbSetting und trafficPolicy.tunnel nicht. Darüber hinaus erfordert die Implementierung der Cloud Service Mesh-Steuerungsebene, dass sich die Zielregel, die Teilmengen definiert, im selben Namespace und Cluster wie der Kubernetes-Dienst oder ServiceEntry befindet.

Sidecar

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

† Die folgenden Felder und Werte in Feldern werden von der Implementierung der Cloud Service Mesh-Steuerungsebene nicht unterstützt:

• 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)	†

† Distroless-Bild wird für die Einschleusung verwendet.

Regionen

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

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