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

Questa pagina descrive le funzionalità supportate e le limitazioni per Cloud Service Mesh che utilizza TRAFFIC_DIRECTOR o ISTIOD come control plane e le differenze tra le due implementazioni. Tieni presente che non si tratta di 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 con certezza quale control plane di 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 distribuito in un cluster che ha anche un deployment 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. Analogamente, 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 nel 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-primario per più cluster: l'opzione di deployment primario-remoto per più cluster non è supportata.
  • istioctl ps non è supportato. In alternativa, puoi utilizzare i comandi gcloud beta container fleet mesh debug come descritto in 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 delle API Cloud Service Mesh.

  • Puoi utilizzare il control plane gestito senza un abbonamento a GKE Enterprise, ma alcuni elementi UI e funzionalità nella console Google Cloud sono disponibili solo per gli abbonati a GKE Enterprise. Per informazioni su ciò che è disponibile per gli abbonati e i non abbonati, consulta Differenze della UI 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, verranno sovrascritti.

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

  • Le nuove installazioni di Cloud Service Mesh gestito recuperano i 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, consulta 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 se viene visualizzata la condizione VPCSC_GA_SUPPORTED).

  • Il piano dati gestito è supportato solo per i workload senza sidecar aggiuntivi (oltre al sidecar di 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 Attiva 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 dall'assistenza Google Cloud. Le funzionalità non elencate esplicitamente nelle tabelle ricevono assistenza secondo il principio del "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 in quel parco risorse.

I nuovi parchi risorse che eseguono l'onboarding in 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, riceverai l'implementazione del control plane ISTIOD quando esegui l'onboarding di un nuovo parco risorse nella stessa organizzazione Google Cloudin Cloud Service Mesh gestito, fino almeno al 30 giugno 2024. Se sei uno di questi utenti, puoi contattare l'assistenza per perfezionare questo comportamento. Gli utenti il cui utilizzo esistente non è compatibile con l'implementazione TRAFFIC_DIRECTOR senza modifiche continueranno a ricevere l'implementazione ISTIOD fino all'8 settembre 2024. (Questi utenti hanno ricevuto un annuncio di servizio).
  • Se un 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 del 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) deprecato
Installazione su cluster GKE utilizzando l'API della funzionalità parco risorse
Upgrade dalle versioni di ASM 1.9 che utilizzano Mesh CA
Upgrade diretti (skip-level) da versioni di Cloud Service Mesh precedenti alla 1.9 (consulta le note per gli upgrade indiretti)
Upgrade diretti (skip-level) da Istio OSS (consulta le note per gli upgrade indiretti)
Upgrade diretti (skip-level) dal componente aggiuntivo Istio on GKE (consulta le note per gli upgrade indiretti)
Attivazione delle funzionalità facoltative

Ambienti

Funzionalità Gestito (TD) Gestito (istiod) deprecato
Versioni di GKE attualmente disponibili nei canali di rilascio, in una delle regioni supportate
Versioni di GKE attualmente disponibili nei canali di rilascio, in una delle regioni supportate, cluster GKE Autopilot
Ambienti esterni a 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) deprecato
Rete singola
Multi-rete
Singolo progetto
Multiprogetto con VPC condiviso

Deployment multi-cluster

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

Note sulla terminologia

  • Una configurazione multi-principale significa che la configurazione deve essere replicata in tutti i cluster.
  • Una configurazione principale-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 dei workload si trovano sulla stessa rete se sono in grado di comunicare direttamente, senza un gateway.
  • La topologia semplice per il rilevamento degli endpoint multi-cluster significa che ogni cluster nel parco risorse partecipa o meno al rilevamento degli endpoint. Le topologie complesse non supportate includono (a) il rilevamento di endpoint unidirezionale (ad es. il cluster A può rilevare gli endpoint nel cluster B, ma non viceversa) e (b) reti di rilevamento di endpoint disgiunte (ad es. i cluster A e B possono rilevare gli endpoint l'uno dell'altro, i cluster C e D possono rilevare gli endpoint l'uno dell'altro, ma A/B e C/D non possono rilevare gli endpoint l'uno dell'altro).

Immagini di base

Funzionalità Gestito (TD) Gestito (istiod) deprecato
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 file 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 temporanei per collegarli a un pod di workload in esecuzione in modo da poterlo ispezionare ed eseguire comandi personalizzati. Ad esempio, consulta Raccolta dei log di Cloud Service Mesh.

Sicurezza

Controlli di servizio VPC

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

Meccanismi di distribuzione e rotazione dei certificati

Funzionalità Gestito (TD) Gestito (istiod) deprecato
Gestione dei certificati dei workload
Gestione dei certificati esterni sui gateway di ingress ed egress.

Supporto delle autorità di certificazione (CA)

Funzionalità Gestito (TD) Gestito (istiod) deprecato
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) deprecato
Integrazione di IAP
Autenticazione dell'utente finale
Modalità dry run
Logging dei rifiuti
Policy di audit (non supportate)

Policy di autorizzazione

Funzionalità Gestito (TD) Gestito (istiod) deprecato
Policy di autorizzazione v1beta1
Policy di autorizzazione CUSTOM

Autenticazione peer

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

† Sebbene l'API PeerAuthentication non supporti la modalità DISABLE per l'implementazione del control plane TRAFFIC_DIRECTOR, puoi disattivare mTLS per servizi o porte specifici utilizzando l'API DestinationRule. Per saperne di più, consulta Disattiva mTLS e Supporto delle API: PeerAuthentication.

Richiedi autenticazione

Funzionalità Gestito (TD) Gestito (istiod) deprecato
Autenticazione JWT(Nota 1)
Routing basato su claim JWT
JWT Copy Claim to Headers

Note:

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

Telemetria

Metriche

Funzionalità Gestito (TD) Gestito (istiod) deprecato
Cloud Monitoring (metriche HTTP in-proxy)
Cloud Monitoring (metriche TCP in-proxy)
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 di 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 di telemetria Istio utilizzata per configurare i log di accesso e la traccia.

Logging delle richieste proxy

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

Tracciamento

Funzionalità Gestito (TD) Gestito (istiod) deprecato
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) deprecato
Utilizzo di iptables utilizzando container init con CAP_NET_ADMIN †
Istio Container Network Interface (CNI)
Sidecar Whitebox
Configurazione della modalità di intercettazione

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

Supporto dei protocolli

Funzionalità Gestito (TD) Gestito (istiod) deprecato
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 le metriche TCP vengano raccolte, non vengono segnalate. 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 non è compatibile con la logica di routing di Cloud Service Mesh), il protocollo non è supportato. Sebbene le porte del gateway possano essere create con i protocolli Mongo, MySQL e Redis, il mesh tratta 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 gRPC Node.js v1.12. Se provi a configurare le funzionalità dual-stack con una versione di gRPC che non supporta il dual-stack, i client utilizzeranno solo il primo indirizzo inviato da Traffic Director.

Deployment di Envoy

Funzionalità Gestito (TD) Gestito (istiod) deprecato
Sidecar
Gateway in entrata
Traffico in uscita direttamente dai sidecar
Traffico in uscita tramite gateway in uscita * *

Assistenza CRD

Funzionalità Gestito (TD) Gestito (istiod) deprecato
Risorsa sidecar
Risorsa ServiceEntry
Percentuale, fault injection, corrispondenza del percorso, reindirizzamenti, nuovi tentativi, riscrittura, timeout, nuovo tentativo, mirroring, manipolazione dell'intestazione e regole di instradamento CORS
API "WasmPlugin"
Operatore Istio

Bilanciatore del carico per il gateway in entrata Istio

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

Gateway cloud del mesh di servizi

Funzionalità Gestito (TD) Gestito (istiod) deprecato
Gateway cloud del mesh di servizi

API Kubernetes Gateway

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

Policy di bilanciamento del carico

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

Modalità di bilanciamento del carico

Funzionalità Gestito (TD) Gestito (istiod) deprecato
TARIFFA
UTILIZZO
CUSTOM_METRICS
IN CORSO

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

Voce di servizio

Funzionalità Gestito (TD) Gestito (istiod) deprecato
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) deprecato
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 nello stesso 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) deprecato
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) deprecato
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 †

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

EnvoyFilter

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

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

MeshConfig

Funzionalità Gestito (TD) Gestito (istiod) deprecato
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, consulta Immagine proxy distroless.
† Consulta Configurazione del bilanciamento del carico di località per informazioni dettagliate sul comportamento e sulle limitazioni della configurazione.
† Consulta Personalizzazione del formato e della codifica dei log di accesso di Envoy per informazioni dettagliate sul comportamento e sulle limitazioni della configurazione.

ProxyConfig

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

Regioni

I cluster GKE devono trovarsi in una delle seguenti regioni o in qualsiasi 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) deprecato
Dashboard di Cloud Service Mesh nella console Google Cloud
Cloud Monitoring
Cloud Logging

Strumenti

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