Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
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 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.
Cloud Service Mesh gestito non deve essere deployment in un cluster che ha anche un deployment in-cluster di OSS Istio o un control plane Cloud Service Mesh in-cluster.
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-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 nella sezione
Risoluzione dei problemi.
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 (diversi dal 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à è
supportata dalla lista consentita. Gli utenti precedenti di Anthos Service Mesh gestito vengono inseriti automaticamente nella lista consentita a livello di organizzazione.
Contatta Google Cloud l'assistenza per richiedere l'accesso
o per controllare lo stato della lista consentita.
: 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 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 nel parco risorse.
I nuovi fleet 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, 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 di 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 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) 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 (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 (skip-level) dal componente aggiuntivo Istio on GKE (consulta le note per gli upgrade indiretti)
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)
Rilevamento degli endpoint multi-cluster con secret remoti
Rilevamento di endpoint multi-cluster con 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 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 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) 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).
† 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 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.
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.
Il JWT di terze parti è abilitato per impostazione predefinita.
Aggiungi il nome di dominio completo/nome host in JWKSURI durante la definizione dell'API RequestAuthentication.
Il control plane gestito impone a Envoy di recuperare JWKS quando viene specificato l'URI JWKS.
Gli algoritmi AES CBC A128CBC-HS256, A192CBC-HS384 e A256CBC-HS512 non sono consentiti nei JWKS in linea 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
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 .
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.
† 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 provi a 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) deprecato
Sidecar
Gateway in entrata
Traffico in uscita direttamente dai sidecar
Traffico in uscita tramite gateway in uscita
*
*
Supporto CRD
Funzionalità
Gestito (TD)
Gestito (istiod) deprecato
Risorsa sidecar
Risorsa di ingresso del servizio
Regole di instradamento per percentuale, fault injection, corrispondenza dei percorsi, reindirizzamenti, nuovi tentativi, riscrittura, timeout, nuovo tentativo, mirroring, manipolazione delle intestazioni e CORS
† L'implementazione del control plane TRAFFIC_DIRECTOR non supporta i seguenti campi e valori nei campi:
Campo workloadSelector
Campo endpoints[].network
Campo endpoints[].locality
Campo endpoints[].weight
Campo endpoints[].serviceAccount
Valore DNS_ROUND_ROBIN nel campo resolution
Valore MESH_INTERNAL nel campo location
Indirizzo del socket di dominio Unix nel campo endpoints[].address
Campo subjectAltNames
Due o più voci endpoints[] se il campo resolution ha il valore DNS
Regola di destinazione
Funzionalità
Gestito (TD)
Gestito (istiod) deprecato
DestinationRule v1beta1
†
† L'implementazione del control plane TRAFFIC_DIRECTOR non supporta i seguenti campi.
Campo trafficPolicy.loadBalancer.localityLbSetting
Campo trafficPolicy.tunnel
Campo trafficPolicy.tls.credentialName
Campo trafficPolicy.portLevelSettings[].tls.credentialName
Inoltre, 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.
Sidecar
Funzionalità
Gestito (TD)
Gestito (istiod) deprecato
Sidecar v1beta1
†
† L'implementazione del control plane TRAFFIC_DIRECTOR non supporta i seguenti campi e valori nei campi:
Campo ingress
Campo egress.port
Campo egress.bind
Campo egress.captureMode
Campo inboundConnectionPool
Proxy DNS
Funzionalità
Gestito (TD)
Gestito (istiod) deprecato
Risoluzione dei nomi di Service tra i cluster
†
Risoluzione dei nomi di ServiceEntry in un cluster
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 2026-10-23 UTC."],[],[]]
