Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Funzionalità supportate mediante le API Istio (control plane gestito)
In questa pagina vengono descritte le funzionalità e le limitazioni supportate per
Cloud Service Mesh utilizzando TRAFFIC_DIRECTOR o ISTIOD come piano di controllo e
differenze tra le singole implementazioni. Tieni presente che non si tratta di opzioni tra cui scegliere. L'implementazione di ISTIOD è disponibile solo per gli utenti esistenti.
Le nuove installazioni utilizzano l'implementazione TRAFFIC_DIRECTOR, se possibile.
Le migrazioni e gli upgrade sono supportati solo da Cloud Service Mesh nel cluster
versioni 1.9 e successive installate con Mesh CA. Le installazioni con la CA Istio (in precedenza conosciuta come Citadel) devono prima essere sottoposte a migrazione alla CA Mesh.
La scalabilità è limitata a 1000 servizi e 5000 carichi di lavoro per cluster.
È supportata solo l'opzione di deployment multi-principale per multi-cluster:
l'opzione di deployment primario-remote per multi-cluster non lo è.
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:
EnvoyFilter API
WasmPlugin API
IstioOperator API
Kubernetes Ingress API
Puoi utilizzare il piano di controllo 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 cosa è disponibile per gli abbonati e i non abbonati, consulta Differenze tra l'interfaccia utente di GKE Enterprise e Cloud Service Mesh.
Durante il processo di provisioning per un piano di controllo gestito,
I CRD Istio corrispondenti al canale selezionato sono installati
nel cluster specificato. Se nel cluster sono già presenti CRD Istio,
verranno sovrascritti.
Cloud Service Mesh gestito supporta solo il dominio DNS predefinito .cluster.local.
A partire dal 14 novembre 2023, le nuove installazioni di Cloud Service Mesh gestito sul
il canale di rilascio rapid recupera JWKS solo utilizzando Envoy. È equivalente all'opzione Istio PILOT_JWT_ENABLE_REMOTE_JWKS=envoy. Rispetto alle installazioni su
i canali di rilascio regolari e stabili o installazioni sul
di rilascio rapido prima del 14 novembre 2023, potresti aver bisogno di altre
Configurazioni ServiceEntry e DestinationRule. Per un esempio, vedi
requestauthn-with-se.yaml.tmpl
Differenze del piano di controllo
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 funzione è disponibile e
sono abilitate per impostazione predefinita.
†: indica che le API di funzionalità possono avere 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à è supportata dalla lista consentita. Gli utenti precedenti della versione gestita di Anthos Service Mesh
inseriti automaticamente nella lista consentita a livello di organizzazione.
Contatta l'assistenza Google Cloud per richiedere l'accesso o per controllare lo stato della lista consentita.
: indica che la funzionalità non è
disponibile o non è supportato.
Le funzionalità predefinite e facoltative sono completamente supportate dall'assistenza Google Cloud. Le funzionalità non elencate esplicitamente nelle tabelle si basano sul criterio del "best effort"
assistenza in tempo reale.
Cosa determina l'implementazione del piano di controllo
Quando esegui il provisioning di Cloud Service Mesh gestito la prima volta in un parco risorse,
per determinare quale implementazione del piano di controllo usare. La stessa implementazione
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 nella gestione di Cloud Service Mesh ricevono il
Implementazione del piano di controllo TRAFFIC_DIRECTOR, con alcune eccezioni:
Se sei un utente gestito esistente di Cloud Service Mesh, ricevi ISTIOD
dell'implementazione del piano di controllo durante l'onboarding di un nuovo parco risorse nello stesso Google Cloud
Organizzazione per Cloud Service Mesh gestito, almeno fino al 30 giugno 2024.
Se sei uno di questi utenti, puoi contattare l'assistenza per perfezionare questo comportamento.
Utenti il cui utilizzo esistente non è compatibile con TRAFFIC_DIRECTOR
implementazione senza modifiche continuerà a ricevere ISTIOD
implementazione fino all'8 settembre 2024. (Questi utenti hanno ricevuto
Announcement.)
Se un cluster nel parco risorse utilizza Certificate Authority Service quando esegui il provisioning
Cloud Service Mesh, riceverai l'implementazione del piano di controllo ISTIOD.
Se un cluster nel parco risorse contiene un mesh di servizi Cloud nel cluster
quando esegui il provisioning di Cloud Service Mesh gestito,
ricevono l'implementazione del piano di controllo ISTIOD.
Se un cluster del tuo parco utilizza
GKE Sandbox,
quando esegui il provisioning di Cloud Service Mesh gestito, ricevi l'implementazione del control plane ISTIOD.
Funzionalità supportate dal piano di controllo gestito
Installazione, upgrade e rollback
Funzionalità
Gestito (TD)
Gestito (stiod)
Installazione su cluster GKE utilizzando l'API delle funzionalità fleet
Upgrade dalle versioni di ASM 1.9 che utilizzano Mesh CA
Upgrade diretti (a livello di salto) dalle versioni di Cloud Service Mesh precedenti alla 1.9 (vedi le note per gli upgrade indiretti)
Upgrade diretti (a livello di salto) da Istio OSS (vedi le note per gli upgrade indiretti)
Upgrade diretti (a livello di salto) dal componente aggiuntivo Istio on GKE (vedi le 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 multi-cluster con secret remoti
Note sulla terminologia
Una configurazione multi-principale significa che la configurazione deve essere replicata
in tutti i cluster.
Una configurazione principale remota indica che un singolo cluster contiene la configurazione ed è considerato la fonte attendibile.
Cloud Service Mesh utilizza una definizione semplificata di rete basata sui criteri
e la connettività privata. Le istanze di carico di lavoro si trovano sulla stessa rete se sono in grado di comunicare direttamente, senza un gateway.
† Cloud Service Mesh con un piano di controllo gestito (TD) supporta solo
il tipo di immagine senza distroless. Non puoi modificarlo.
Tieni presente che le immagini distroless hanno binari minimi, quindi non puoi eseguire i comandi consueti come bash o curl perché non sono presenti nell'immagine distroless.
Tuttavia, puoi utilizzare i container temporanei da collegare a un pod del carico di lavoro in esecuzione
potrà esaminarlo ed eseguire comandi personalizzati. Ad esempio, consulta
Raccogliere i log di Cloud Service Mesh.
Oltre a supportare le funzionalità di sicurezza di Istio, Cloud Service Mesh
offre ancora più funzionalità per aiutarti a proteggere le tue applicazioni.
Sebbene TCP sia un protocollo supportato per il networking e
le metriche vengono raccolte, non vengono registrate. Le metriche vengono visualizzate solo per
HTTP nella console Google Cloud.
Servizi configurati con funzionalità di livello 7 per
non sono supportati i seguenti protocolli: WebSocket, MongoDB, Redis, Kafka,
Cassandra, RabbitMQ, Cloud SQL. Potresti riuscire a far funzionare il protocollo utilizzando il supporto dello stream di byte TCP. Se lo stream di byte TCP non può supportare il protocollo (ad esempio, Kafka invia un indirizzo di reindirizzamento in una risposta specifica per il protocollo e questo reindirizzamento non è compatibile con la logica di routing di Cloud Service Mesh), il protocollo non è supportato.
Deployment di Envoy
Funzionalità
Gestito (TD)
Gestito (stiod)
Sidecar
Gateway in entrata
In uscita direttamente dai file collaterali
In uscita tramite gateway in uscita
*
*
Supporto CRD
Funzionalità
Gestito (TD)
Gestito (stiod)
Risorsa Sidecar
Risorsa voce del servizio
Percentuale, inserimento di errori, corrispondenza dei percorsi, reindirizzamenti, nuovi tentativi, riscrittura,
timeout, nuovo tentativo, mirroring, manipolazione delle intestazioni e regole di routing CORS
Bilanciatore del carico per il gateway in entrata Istio
Funzionalità
Gestito (TD)
Gestito (stiod)
Bilanciatore del carico esterno di terze parti
Bilanciatore del carico interno Google Cloud
*
*
Gateway cloud mesh di servizi
Funzionalità
Gestito (TD)
Gestito (stiod)
Gateway cloud mesh di servizi
API Kubernetes Gateway
Funzionalità
Gestito (TD)
Gestito (istiod)
API Kubernetes Gateway
Criteri di bilanciamento del carico
Funzionalità
Gestito (TD)
Gestito (stiod)
Round robin
Connessioni minime
Casuale
Passthrough
Hash coerente
Località
Voce del servizio
Funzionalità
Gestito (TD)
Gestito (istiod)
ServiceEntry v1beta1
†
† L'implementazione del piano di controllo 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 di DNS_ROUND_ROBIN nel campo resolution
Valore di MESH_INTERNAL nel campo location
Indirizzo socket del dominio Unix nel campo endpoints[].address
Campo subjectAltNames
Regola di destinazione
Funzionalità
Gestito (TD)
Gestito (stiod)
TargetRule v1beta1
†
† L'implementazione del piano di controllo TRAFFIC_DIRECTOR non supporta
Campo trafficPolicy.loadBalancer.localityLbSetting e trafficPolicy.tunnel
.
Inoltre, l'implementazione del piano di controllo TRAFFIC_DIRECTOR richiede che
la regola di destinazione che definisce i sottoinsiemi si trova nello stesso spazio dei nomi e nello stesso cluster
il servizio Kubernetes o ServiceEntry.
Sidecar
Funzionalità
Gestito (TD)
Gestito (stiod)
Sidecar v1beta1
†
† L'implementazione del control plane di TRAFFIC_DIRECTOR non supporta i seguenti campi e valori nei campi:
Campo ingress
Campo egress.port
Campo egress.bind
Campo egress.captureMode
Campo inboundConnectionPool
MeshConfig
Funzionalità
Gestito (TD)
Gestito (stiod)
LocalityLB
§
ExtensionProviders
§
CACert
ImageType - distroless
§
OutboundTrafficPolicy
§
defaultProviders.accessLogging
defaultProviders.tracing
defaultConfig.tracing.stackdriver
§
accessLogFile
§
ProxyConfig
Funzionalità
Gestito (TD)
Gestito (stiod)
Proxy DNS (ISTIO_META_DNS_CAPTURE, ISTIO_META_DNS_AUTO_ALLOCATE)
Supporto HTTP/1.0 (ISTIO_META_NETWORK)
Selezione delle immagini (immagine senza distro o di base)
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 2024-10-10 UTC."],[],[]]
