Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Funzionalità supportate utilizzando 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 quando possibile.
Le migrazioni e gli upgrade sono supportati solo dalle versioni 1.9+ di Cloud Service Mesh in-cluster installate con Mesh CA. 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 multi-cluster:
l'opzione di deployment primary-remote per 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.
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 per un control plane gestito,
le CRD Istio corrispondenti al canale selezionato vengono installate nel
cluster specificato. Se nel cluster sono presenti CRD Istio esistenti, questi verranno sovrascritti.
Managed Cloud Service Mesh 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 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 se viene visualizzata la condizione VPCSC_GA_SUPPORTED).
Il piano dati gestito è supportato solo per i carichi di lavoro senza sidecar aggiuntivi
(diverso dal sidecar Cloud Service Mesh).
Differenze del control plane
Esistono differenze nelle funzionalità supportate tra le implementazioni del piano di controllo ISTIOD e TRAFFIC_DIRECTOR. Per verificare quale implementazione stai utilizzando, consulta
Identificare 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 alla 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 tua lista consentita.
: indica che la funzionalità non è
disponibile o non è supportata.
Le funzionalità predefinite e facoltative sono completamente supportate dall'assistenza di Google Cloud. Le funzionalità non elencate esplicitamente nelle tabelle ricevono assistenza
con il massimo impegno.
Cosa determina l'implementazione del control plane
Quando esegui il provisioning di Cloud Service Mesh gestito per la prima volta in un parco progetti, 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 Google Cloud
organizzazione in 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 del servizio.
Se uno dei cluster GKE on Google Cloud nel tuo parco risorse contiene un control plane Cloud Service Mesh interno al 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 on GKE (vedi note per gli upgrade indiretti)
Ambienti esterni a Google Cloud (GKE Enterprise on-premise,
GKE Enterprise su altri cloud pubblici, Amazon EKS, Microsoft AKS
o altri cluster Kubernetes)
Rilevamento degli endpoint multicluster con secret remoti
Rilevamento degli 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 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 carico di lavoro 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).
† Cloud Service Mesh con un control plane gestito (TD) supporta solo il tipo di immagine distroless. Non puoi modificarlo.
Tieni presente che le immagini distroless hanno binari minimi, quindi non puoi eseguire i soliti
comandi 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, vedi
Raccolta dei log di Cloud Service Mesh.
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
trace. Il control plane TRAFFIC_DIRECTOR
non supporta la configurazione della frequenza di campionamento delle tracce.
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), allora
il protocollo non è supportato. Sebbene le porte del gateway possano essere create con i protocolli Mongo, MySQL e Redis, la 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 tenti di configurare 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)
Sidecar
Gateway in entrata
Uscita direttamente dai sidecar
Uscita tramite gateway di 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
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
Connessioni minime
Casuale
Passthrough
Hash coerente
Località
GCPTrafficDistributionPolicy
GCPBackendPolicy
Voce di servizio
Funzionalità
Gestito (TD)
Gestito (istiod)
ServiceEntry v1beta1
†
† 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)
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 cluster del
servizio Kubernetes o ServiceEntry.
Sidecar
Funzionalità
Gestito (TD)
Gestito (istiod)
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)
Risoluzione dei nomi di Service nei 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 2025-09-12 UTC."],[],[],null,[]]
