Funzionalità supportate che utilizzano le API Istio (control plane gestito)

Questa pagina descrive le funzionalità supportate e le limitazioni per Cloud Service Mesh utilizzando TRAFFIC_DIRECTOR o ISTIOD come control plane e le differenze tra ogni implementazione. Tieni presente che queste non sono opzioni che puoi scegliere. L'implementazione di ISTIOD è disponibile solo per gli utenti esistenti. Le nuove installazioni utilizzano l'implementazione TRAFFIC_DIRECTOR, se possibile.

Per un elenco delle API Istio e Google Cloud supportate da Cloud Service Mesh gestito con TRAFFIC_DIRECTOR, consulta Supporto delle API in Cloud Service Mesh gestito.

Per l'elenco delle funzionalità supportate di Cloud Service Mesh per un control plane in-cluster, consulta Utilizzo delle API Istio (control plane istiod in-cluster).

Se non sai quale control plane Cloud Service Mesh stai utilizzando, puoi controllare l'implementazione del control plane seguendo le istruzioni riportate in Identifica l'implementazione del control plane.

Limitazioni

Si applicano le seguenti limitazioni:

• I cluster GKE devono trovarsi in una delle regioni supportate.
• La versione GKE deve essere una versione supportata.
• Sono supportate solo le piattaforme elencate in Ambienti.
• I pod in esecuzione con hostNetwork: true non sono supportati.
• Cloud Service Mesh gestito non deve essere implementato in un cluster che ha anche un'implementazione in-cluster di OSS Istio o un control plane Cloud Service Mesh in-cluster.
• La modifica dei canali di rilascio non è supportata.
• Le migrazioni da Cloud Service Mesh gestito con asmcli a Cloud Service Mesh con l'API fleet non sono supportate. Allo stesso modo, il provisioning di Cloud Service Mesh gestito con l'API fleet da --management manual a --management automatic non è supportato.
• Le migrazioni da Cloud Service Mesh in-cluster sono supportate solo utilizzando la strategia di migrazione del cluster canary.
• Le migrazioni e gli upgrade sono supportati solo dalle versioni di Cloud Service Mesh in-cluster presenti nella tabella Versioni supportate e che utilizzano Mesh CA o Certificate Authority Service. Le installazioni con Istio CA (precedentemente nota come Citadel) devono prima eseguire la migrazione a Mesh CA.
• I limiti di scalabilità sono descritti in questa guida.
• È supportata solo l'opzione di deployment multi-primary per il multi-cluster: l'opzione di deployment primary-remote per il multi-cluster non è supportata.
• istioctl ps non è supportato. In alternativa, puoi utilizzare i comandi gcloud beta container fleet mesh debug come descritto nella sezione Risoluzione dei problemi.

• API non supportate:

  • WasmPlugin API

  • IstioOperator API

  • Kubernetes Ingress API

• Per informazioni dettagliate sul supporto e sulle limitazioni a livello di campo in tutte le API Istio, consulta Supporto dell'API Cloud Service Mesh.

• Puoi utilizzare il control plane gestito senza un abbonamento a GKE Enterprise, ma alcuni elementi e funzionalità dell'interfaccia utente nella console Google Cloud sono disponibili solo per gli abbonati a GKE Enterprise. Per informazioni su ciò che è disponibile per abbonati e non abbonati, consulta Differenze tra l'interfaccia utente di GKE Enterprise e Cloud Service Mesh.

• Durante il processo di provisioning di un control plane gestito, le CRD Istio corrispondenti al canale selezionato vengono installate nel cluster specificato. Se nel cluster sono presenti CRD Istio esistenti, queste verranno sovrascritte.

• Cloud Service Mesh gestito supporta solo il dominio DNS predefinito .cluster.local.

• Le nuove installazioni di Cloud Service Mesh gestito recuperano JWKS solo utilizzando Envoy, a meno che il parco risorse non contenga altri cluster per i quali questo comportamento non è abilitato. Equivale all'opzione Istio PILOT_JWT_ENABLE_REMOTE_JWKS=envoy. Rispetto alle installazioni che non hanno la condizione VPCSC_GA_SUPPORTED (vedi sotto), potresti aver bisogno di una configurazione aggiuntiva per le configurazioni ServiceEntry e DestinationRule. Per un esempio, vedi requestauthn-with-se.yaml.tmpl. Puoi determinare se la modalità di funzionamento attuale è equivalente a PILOT_JWT_ENABLE_REMOTE_JWKS=envoy determinando se i Controlli di servizio VPC sono supportati per il control plane (ovvero viene visualizzata la condizione VPCSC_GA_SUPPORTED).

• Il piano dati gestito è supportato solo per i workload senza sidecar aggiuntivi (diverso dal sidecar Cloud Service Mesh).

Differenze del control plane

Esistono differenze nelle funzionalità supportate tra le implementazioni del control plane ISTIOD e TRAFFIC_DIRECTOR. Per verificare quale implementazione stai utilizzando, consulta Identifica l'implementazione del control plane.

• : indica che la funzionalità è disponibile e attivata per impostazione predefinita.
• † - indica che le API delle funzionalità potrebbero presentare differenze tra le varie piattaforme.
• * indica che la funzionalità è supportata per la piattaforma e può essere attivata, come descritto in Attivare le funzionalità facoltative o nella guida alle funzionalità collegata nella tabella delle funzionalità.
• : indica che la funzionalità non è disponibile o non è supportata.

Le funzionalità predefinite e facoltative sono completamente supportate da Google Cloud Support. Le funzionalità non elencate esplicitamente nelle tabelle ricevono un'assistenza di tipo best-effort.

Cosa determina l'implementazione del control plane

Quando esegui il provisioning di Cloud Service Mesh gestito per la prima volta in un parco risorse, determiniamo quale implementazione del control plane utilizzare. La stessa implementazione viene utilizzata per tutti i cluster che eseguono il provisioning di Cloud Service Mesh gestito nel parco risorse.

Le nuove flotte di cui viene eseguito l'onboarding a Cloud Service Mesh gestito ricevono l'implementazione del control plane TRAFFIC_DIRECTOR, con alcune eccezioni:

• Se sei un utente esistente di Cloud Service Mesh gestito, ricevi l'implementazione del control plane ISTIOD quando esegui l'onboarding di un nuovo parco risorse nella stessa organizzazione Google Cloudin Cloud Service Mesh gestito, almeno fino al 30 giugno 2024. Se rientri in questa categoria, puoi contattare l'assistenza per perfezionare questo comportamento. Gli utenti il cui utilizzo esistente non è compatibile con l'implementazione di TRAFFIC_DIRECTOR senza modifiche continueranno a ricevere l'implementazione di ISTIOD fino all'8 settembre 2024. Questi utenti hanno ricevuto un annuncio di servizio.
• Se uno dei cluster GKE su Google Cloud nel tuo parco risorse contiene un control plane Cloud Service Mesh in-cluster quando esegui il provisioning di Cloud Service Mesh gestito, riceverai l'implementazione del control plane ISTIOD.
• Se un cluster nel tuo parco risorse utilizza GKE Sandbox, quando esegui il provisioning di Cloud Service Mesh gestito, ricevi l'implementazione del control plane ISTIOD.

Funzionalità supportate del control plane gestito

Installazione, upgrade e rollback

Funzionalità	Gestito (TD)	Gestito (istiod)
Installazione sui cluster GKE utilizzando l'API della funzionalità fleet
Upgrade dalle versioni di ASM 1.9 che utilizzano Mesh CA
Upgrade diretti (con salto di livello) dalle versioni di Cloud Service Mesh precedenti alla 1.9 (vedi note per gli upgrade indiretti)
Upgrade diretti (con salto di livello) da Istio OSS (vedi note per gli upgrade indiretti)
Upgrade diretti (con salto di livello) dal componente aggiuntivo Istio su GKE (vedi note per gli upgrade indiretti)
Attivare le funzionalità facoltative

Ambienti

Funzionalità	Gestito (TD)	Gestito (istiod)
Versioni GKE attualmente disponibili nei canali di rilascio, in una delle regioni supportate
Versioni GKE attualmente disponibili nei canali di rilascio, in una delle regioni supportate, cluster GKE Autopilot
Ambienti al di fuori di Google Cloud (GKE Enterprise on-premise, GKE Enterprise su altri cloud pubblici, Amazon EKS, Microsoft AKS o altri cluster Kubernetes)

Scala

Consulta la pagina Limiti di scalabilità.

Ambiente della piattaforma

Funzionalità	Gestito (TD)	Gestito (istiod)
Singola rete
Multi-network
Progetto singolo
Multi-project con VPC condiviso

Deployment multi-cluster

Funzionalità	Gestito (TD)	Gestito (istiod)
Multi-primaria
Primary-remote
Rilevamento degli endpoint multicluster con l'API dichiarativa
Rilevamento degli endpoint multi-cluster con secret remoti
Rilevamento degli endpoint multi-cluster con l'API dichiarativa e una topologia semplice

Note sulla terminologia

• Una configurazione multi-primaria significa che la configurazione deve essere replicata in tutti i cluster.
• Una configurazione primaria-remota significa che un singolo cluster contiene la configurazione ed è considerato la fonte di riferimento.
• Cloud Service Mesh utilizza una definizione semplificata di rete basata sulla connettività generale. Le istanze del workload si trovano sulla stessa rete se sono in grado di comunicare direttamente, senza un gateway.
• La topologia semplice per l'individuazione degli endpoint multi-cluster significa che ogni cluster nel parco risorse partecipa o non partecipa all'individuazione degli endpoint. Le topologie complesse non supportate includono (a) l'individuazione di endpoint unidirezionale (ad es. il cluster A può individuare gli endpoint nel cluster B, ma non viceversa) e (b) reti di individuazione di endpoint disgiunte (ad es. i cluster A e B possono individuare gli endpoint l'uno dell'altro, i cluster C e D possono individuare gli endpoint l'uno dell'altro, ma A/B e C/D non possono individuare gli endpoint l'uno dell'altro).

Immagini di base

Funzionalità	Gestito (TD)	Gestito (istiod)
Immagine proxy Distroless	†

† Istio pubblica le immagini proxy default, debug e distroless. Per Cloud Service Mesh con un control plane gestito (TRAFFIC_DIRECTOR): i cluster di cui è stato eseguito l'onboarding diretto utilizzano distroless per impostazione predefinita e non possono essere modificati. I cluster di cui è stata eseguita la migrazione utilizzano le immagini default per impostazione predefinita e possono attivare distroless utilizzando MeshConfig o l'annotazione del pod. Gli override di altri tipi di immagini (debug) non sono supportati.

Tieni presente che le immagini distroless hanno binari minimi, quindi non puoi eseguire i comandi soliti come bash o curl perché non sono presenti nell'immagine distroless. Tuttavia, puoi utilizzare i container effimeri per collegarti a un pod di workload in esecuzione per ispezionarlo ed eseguire comandi personalizzati. Ad esempio, consulta Raccolta dei log di Cloud Service Mesh.

Sicurezza

Controlli di servizio VPC

Funzionalità	Gestito (TD)	Gestito (istiod)
Controlli di servizio VPC

Meccanismi di distribuzione e rotazione dei certificati

Funzionalità	Gestito (TD)	Gestito (istiod)
Gestione dei certificati workload
Gestione dei certificati esterni sui gateway in entrata e in uscita.

Supporto dell'autorità di certificazione (CA)

Funzionalità	Gestito (TD)	Gestito (istiod)
Autorità di certificazione Cloud Service Mesh
Certificate Authority Service
Istio CA
Integrazione con CA personalizzate

Funzionalità di sicurezza

Oltre a supportare le funzionalità di sicurezza di Istio, Cloud Service Mesh offre ancora più funzionalità per proteggere le applicazioni.

Funzionalità	Gestito (TD)	Gestito (istiod)
Integrazione di IAP
Autenticazione degli utenti finali
Modalità dry run
Logging dei rifiuti
Policy di audit (non supportate)

Policy di autorizzazione

Funzionalità	Gestito (TD)	Gestito (istiod)
Policy v1beta1 di autorizzazione
Policy di autorizzazione personalizzata

Autenticazione peer

Funzionalità	Gestito (TD)	Gestito (istiod)
Auto-mTLS
Modalità mTLS PERMISSIVE
Modalità mTLS STRICT	*	*
Modalità mTLS DISABLE

Nota:anche se l'API PeerAuthentication non supporta la modalità DISABLE per l'implementazione del control plane TRAFFIC_DIRECTOR, puoi disattivare mTLS per workload specifici utilizzando l'API DestinationRule come soluzione alternativa. Per saperne di più, consulta Disattivazione di mTLS per CSM gestito.

Richiedi autenticazione

Funzionalità	Gestito (TD)	Gestito (istiod)
Autenticazione JWT(nota 1)
Routing basato su attestazioni JWT
JWT Copy Claim to Headers

Note:

1. Il JWT di terze parti è abilitato per impostazione predefinita.
2. Aggiungi il nome di dominio completo/nome host in JWKSURI durante la definizione dell'API RequestAuthentication.
3. Il control plane gestito impone a Envoy di recuperare JWKS quando viene specificato l'URI JWKS.
4. Gli algoritmi AES CBC A128CBC-HS256, A192CBC-HS384 e A256CBC-HS512 non sono consentiti in JWKS incorporati quando si utilizza l'implementazione del control plane TRAFFIC_DIRECTOR.

Telemetria

Metriche

Funzionalità	Gestito (TD)	Gestito (istiod)
Cloud Monitoring (metriche HTTP in-proxy)
Cloud Monitoring (metriche in-proxy TCP)
Esportazione delle metriche di Prometheus in Grafana (solo metriche Envoy)	*	*
Esportazione delle metriche di Prometheus in Kiali
Google Cloud Managed Service per Prometheus, esclusa la dashboard Cloud Service Mesh	*	*
API Istio Telemetry	†
Adattatori/backend personalizzati, in-process o out-of-process
Backend di telemetria e logging arbitrari

† Il control plane TRAFFIC_DIRECTOR supporta un sottoinsieme dell'API Istio Telemetry utilizzata per configurare i log di accesso e le tracce.

Logging delle richieste proxy

Funzionalità	Gestito (TD)	Gestito (istiod)
Log sul traffico
Log di accesso	*	*

Tracciamento

Funzionalità	Gestito (TD)	Gestito (istiod)
Cloud Trace	*	*
Tracciamento Jaeger (consente l'utilizzo di Jaeger gestito dal cliente)		Compatibile
Tracciamento Zipkin (consente l'utilizzo di Zipkin gestito dal cliente)		Compatibile

Networking

Meccanismi di intercettazione e reindirizzamento del traffico

Funzionalità	Gestito (TD)	Gestito (istiod)
Utilizzo di iptables utilizzando container init con CAP_NET_ADMIN		†
Container Network Interface (CNI) di Istio
Sidecar whitebox

† Ti consigliamo vivamente di utilizzare Container Network Interface (CNI) anziché i container init.

Supporto dei protocolli

Funzionalità	Gestito (TD)	Gestito (istiod)
IPv4
HTTP/1.1
HTTP/2
Flussi di byte TCP (nota 1)
gRPC
IPv6	†

Note:

1. Sebbene TCP sia un protocollo supportato per il networking e vengano raccolte metriche TCP, queste non vengono riportate. Le metriche vengono visualizzate solo per i servizi HTTP nella console Google Cloud .
2. I servizi configurati con funzionalità di livello 7 per i seguenti protocolli non sono supportati: WebSocket, MongoDB, Redis, MySQL, Kafka, Cassandra, RabbitMQ, Cloud SQL. Potresti riuscire a far funzionare il protocollo utilizzando il supporto del flusso di byte TCP. Se il flusso di byte TCP non può supportare il protocollo (ad esempio, Kafka invia un indirizzo di reindirizzamento in una risposta specifica del protocollo e questo reindirizzamento è incompatibile con la logica di routing di Cloud Service Mesh), allora il protocollo non è supportato. Sebbene le porte gateway possano essere create con i protocolli Mongo, MySQL e Redis, la mesh considera il traffico risultante come TCP standard, senza una gestione specifica del protocollo.
3. † In gRPC senza proxy, le funzionalità dual-stack IPv6 sono supportate solo in gRPC 1.66.1 o versioni successive in C++ e Python, gRPC Go v1.71 e/o gRPC Node.js v1.12. Se tenti di configurare funzionalità dual-stack con una versione di gRPC che non supporta dual-stack, i client utilizzeranno solo il primo indirizzo inviato da Traffic Director.

Deployment di Envoy

Funzionalità	Gestito (TD)	Gestito (istiod)
Sidecar
Gateway in entrata
Uscita diretta dai sidecar
Uscita tramite gateway in uscita	*	*

Supporto CRD

Funzionalità	Gestito (TD)	Gestito (istiod)
Risorsa sidecar
Risorsa di voce di servizio
Percentuale, fault injection, corrispondenza del percorso, reindirizzamenti, nuovi tentativi, riscrittura, timeout, nuovi tentativi, mirroring, manipolazione dell'intestazione e regole di routing CORS
API`WasmPlugin`
Operatore Istio

Bilanciatore del carico per il gateway in entrata Istio

Funzionalità	Gestito (TD)	Gestito (istiod)
Bilanciatore del carico esterno di terze parti
Google Cloud Bilanciatore del carico interno	*	*

Gateway cloud service mesh

Funzionalità	Gestito (TD)	Gestito (istiod)
Gateway cloud service mesh

API Kubernetes Gateway

Funzionalità	Gestito (TD)	Gestito (istiod)
API Kubernetes Gateway

Policy di bilanciamento del carico

Funzionalità	Gestito (TD)	Gestito (istiod)
Round robin
Numero minimo di connessioni
Casuale
Passthrough
Hash coerente
Località
GCPTrafficDistributionPolicy
GCPBackendPolicy

Modalità di bilanciamento del carico

Funzionalità	Gestito (TD)	Gestito (istiod)
RATE
UTILIZZO
CUSTOM_METRICS
IN-FLIGHT

Per saperne di più sulle modalità di bilanciamento, consulta la panoramica dei servizi di backend.

Voce di servizio

Funzionalità	Gestito (TD)	Gestito (istiod)
ServiceEntry v1beta1	†

† L'implementazione del control plane TRAFFIC_DIRECTOR supporta un sottoinsieme di campi ServiceEntry. Per l'elenco completo dei campi supportati, dei campi non supportati e delle limitazioni di configurazione, consulta Supporto API: ServiceEntry.

Regola di destinazione

Funzionalità	Gestito (TD)	Gestito (istiod)
DestinationRule v1beta1	†

† L'implementazione del control plane TRAFFIC_DIRECTOR richiede che la regola di destinazione che definisce i sottoinsiemi si trovi nello stesso spazio dei nomi e cluster del servizio Kubernetes o di ServiceEntry. Per l'elenco completo dei campi supportati, dei campi non supportati e delle limitazioni di configurazione, consulta Supporto API: DestinationRule.

Sidecar

Funzionalità	Gestito (TD)	Gestito (istiod)
Sidecar v1beta1	†

† L'implementazione del control plane TRAFFIC_DIRECTOR supporta un sottoinsieme di campi Sidecar. Per l'elenco completo dei campi supportati, dei campi non supportati e delle limitazioni di configurazione, consulta Supporto API: Sidecar.

Proxy DNS

Funzionalità	Gestito (TD)	Gestito (istiod)
Risoluzione dei nomi di Service tra i cluster	†
Risoluzione dei nomi di ServiceEntry in un cluster	†
Risoluzione del nome di Headless Service
Allocazione automatica degli indirizzi	†

† È necessaria la versione 1.21.5-asm.39 o successiva del sidecar.

EnvoyFilter

Funzionalità	Gestito (TD)	Gestito (istiod)
EnvoyFilter v1alpha3	†

† Consulta la pagina Estensibilità del piano dati per i campi supportati e le estensioni configurabili

MeshConfig

Funzionalità	Gestito (TD)	Gestito (istiod)
DiscoverySelectors
clusterLocal
LocalityLB	†
ExtensionProviders
CACert
ImageType - distroless	†
OutboundTrafficPolicy
defaultProviders.accessLogging
defaultProviders.tracing
defaultConfig.tracing.stackdriver
accessLogFile	†
accessLogFormat	†
accessLogEncoding	†

† Per informazioni dettagliate sul comportamento della configurazione, vedi Immagine proxy Distroless.
† Per informazioni dettagliate sul comportamento e sulle limitazioni della configurazione, vedi Configurazione del bilanciamento del carico locale.
† Per informazioni dettagliate sul comportamento e sulle limitazioni della configurazione, consulta Personalizzazione del formato e della codifica dei log di accesso di Envoy.

ProxyConfig

Funzionalità	Gestito (TD)	Gestito (istiod)
Supporto di HTTP/1.0 (ISTIO_META_NETWORK)
Selezione dell'immagine (distroless o immagine di base)
File collaterale nativo di Kubernetes (ENABLE_NATIVE_SIDECARS)

Regioni

I cluster GKE devono trovarsi in una delle seguenti regioni o in una zona all'interno delle seguenti regioni.

Regione	Località
africa-south1	Johannesburg
asia-east1	Taiwan
asia-east2	Hong Kong
asia-northeast1	Tokyo, Giappone
asia-northeast2	Osaka, Giappone
asia-northeast3	Corea del Sud
asia-south1	Mumbai, India
asia-south2	Delhi, India
asia-southeast1	Singapore
asia-southeast2	Giacarta
australia-southeast1	Sydney, Australia
australia-southeast2	Melbourne, Australia
europe-central2	Polonia
europe-north1	Finlandia
europe-north2	Stoccolma
europe-southwest1	Spagna
europe-west1	Belgio
europe-west2	Inghilterra
europe-west3	Francoforte, Germania
europe-west4	Paesi Bassi
europe-west6	Svizzera
europe-west8	Milano, Italia
europe-west9	Francia
europe-west10	Berlino, Germania
europe-west12	Torino, Italia
me-central1	Doha
me-central2	Dammam, Arabia Saudita
me-west1	Tel Aviv
northamerica-northeast1	Montréal, Canada
northamerica-northeast2	Toronto, Canada
northamerica-south1	Messico
southamerica-east1	Brasile
southamerica-west1	Cile
us-central1	Iowa
us-east1	Carolina del Sud
us-east4	Virginia del Nord
us-east5	Ohio
us-south1	Dallas
us-west1	Oregon
us-west2	Los Angeles
us-west3	Salt Lake City
us-west4	Las Vegas

Interfaccia utente

Funzionalità	Gestito (TD)	Gestito (istiod)
Dashboard di Cloud Service Mesh nella console Google Cloud
Cloud Monitoring
Cloud Logging

Strumenti

Funzionalità	Gestito (TD)	Gestito (istiod)
gcloud beta container fleet mesh debug strumento