Introduzione a OpenShift Service Mesh 3.2 con la modalità ambient di Istio

Siamo lieti di annunciare la disponibilità generale di Red Hat OpenShift Service Mesh 3.2. Questa release include la disponibilità generale della modalità ambient di Istio, una nuova modalità di deployment della service mesh senza sidecar, che riduce in modo significativo i costi delle risorse associati all'utilizzo della service mesh. Questa offre una soluzione a basso sovraccarico per le reti zero trust, con crittografia mTLS leggera da pod a pod e criteri di autorizzazione basati sulle identità dei carichi di lavoro, con la possibilità di aggiungere funzionalità più avanzate in base alle esigenze.

Basata sui progetti Istio, Envoy e Kiali, questa release aggiorna la versione di Istio alla 1.27 e quella di Kiali alla 2.17 ed è supportata su Red Hat OpenShift 4.18 e versioni successive. 

L'upgrade a OpenShift Service Mesh 3.2

Se esegui OpenShift Service Mesh 2.6 o versioni precedenti, occorrerà passare a OpenShift Service Mesh 3.0, 3.1 e poi alla versione 3.2. Ti consigliamo di eseguire tempestivamente la migrazione a OpenShift Service Mesh 3.0, perché la versione 2.6 raggiungerà la fine del ciclo di vita (EOL) il 30 giugno 2026 (prorogata di recente dal 12 marzo 2026). Nella documentazione di OpenShift Service Mesh 3.0 è disponibile una guida approfondita alla migrazione, che include un'analisi delle differenze tra OpenShift Service Mesh 2.6 e 3.0. Questo articolo del blog descrive l'utilizzo della console Kiali per la migrazione da OpenShift Service Mesh 2.6 a 3.0.

Per un esempio di OpenShift Service Mesh 3 in azione, con metriche completamente configurate e la console Kiali, vedi questo modello di soluzione.

Service mesh sidecarless: la modalità ambient di Istio

Questa release offre il supporto, disponibile a livello generale, per la modalità ambient di Istio in OpenShift Service Mesh. La modalità ambient di Istio è una importante novità, che abilita le funzionalità di service mesh sui carichi di lavoro senza la necessità di proxy sidecar.

Con la tradizionale architettura del dataplane di Istio, nota come "modalità sidecar", ogni pod applicativo richiede un container proxy sidecar per abilitare le funzionalità della service mesh. Sebbene questa sia un'architettura semplice, comporta un sovraccarico aggiuntivo durante l'esecuzione di una service mesh, poiché è necessario un container proxy per ogni container del carico di lavoro dell'applicazione. Ciò complica anche l'adozione della service mesh, perché i proxy sidecar devono essere aggiunti e aggiornati all’interno del ciclo di vita sia dell'applicazione sia della service mesh. Questo significa che le applicazioni devono essere riavviate al momento dell'introduzione e dell'aggiornamento della service mesh.

Con l'architettura in modalità ambient di Istio, il piano dati è suddiviso su due livelli di proxy: ztunnel e waypoint, che svolgono ruoli diversi. 

Proxy Ztunnel

Ztunnel è un proxy leggero condiviso a livello di nodo che intercetta il traffico al livello 4 fornendo sicurezza (la "Z" sta per "zero trust") sotto forma di crittografia mTLS (mutual Transport Layer Security), autenticazione, telemetria e semplici criteri di autorizzazione L4 basati sulle identità delle applicazioni. Fornisce, inoltre, metriche e log di base al livello 4 (ad esempio TCP) che, come tutte le metriche della service mesh, possono essere visualizzati tramite la console Kiali.

Il fatto che ztunnel sia scritto in Rust per questo scopo specifico consente di ottenere prestazioni elevate con un sovraccarico aggiuntivo minimo. 

Sebbene ztunnel venga eseguito come proxy a livello di nodo, un DaemonSet Kubernetes, implementa il reindirizzamento del traffico all'interno dello spazio dei nomi della rete di ogni pod. Questo significa che, dal punto di vista dell'isolamento della rete, il reindirizzamento e la crittografia del traffico avvengono effettivamente all'interno del pod, mantenendo così l'isolamento e la crittografia del traffico da pod a pod. Questo aspetto, e il modo in cui l'agente Istio CNI configura questo reindirizzamento del traffico, è discusso in modo più dettagliato nella documentazione Istio sul reindirizzamento del traffico ZTunnel.

Con la modalità ambient di Istio, se ti servono solo le funzionalità fornite da ztunnel, questo è l'unico proxy che devi eseguire; questo si traduce in una service mesh molto efficiente in termini di utilizzo delle risorse.

Proxy waypoint

Se gli utenti desiderano funzionalità di service mesh a livello di applicazione (livello 7), come la telemetria correlata a HTTP o gRPC, la gestione del traffico e i criteri di autorizzazione, possono aggiungere i proxy detti "waypoint". Questi vengono in genere distribuiti per spazio dei nomi, con un gruppo di carichi di lavoro applicativi strettamente correlati. 

Oltre alle funzionalità già fornite da ztunnel, un proxy waypoint aggiunge funzionalità come:

• routing HTTP e bilanciamento del carico, tentativi, timeout, interruzione dei circuiti, limitazione della frequenza e inserimento degli errori;
• criteri di autorizzazione avanzati basati su primitive L7, come il tipo di richiesta o l'intestazione HTTP;
• metriche HTTP, registrazione degli accessi e tracciamento.

I proxy waypoint vengono gestiti in modo simile ai gateway di ingresso, poiché i proxy Envoy standalone e simili hanno probabilmente un ciclo di vita legato ai carichi di lavoro delle applicazioni, anziché al piano di controllo della service mesh o allo ztunnel per nodo.

La modalità ambient di Istio è adatta alle tue esigenze? Quali sono i vantaggi e i limiti? 

La modalità ambient di Istio è ancora in evoluzione nella community di Istio e, al momento, è ideale per le nuove installazioni di service mesh, poiché presenta alcune limitazioni durante la migrazione o la combinazione con la modalità sidecar (ulteriori informazioni sull'argomento sono riportate di seguito).  

OpenShift 4.19 o le versioni successive devono essere utilizzate per le definizioni di risorse personalizzate (CRD) dell'API Kubernetes Gateway supportate, che sono consigliate per configurare i gateway di ingresso e sono necessarie per configurare i proxy waypoint dell'ambiente. OpenShift Service Mesh 4.18 e le versioni precedenti non includono né forniscono supporto per questi CRD.

Di seguito sono riportati alcuni dei vantaggi e degli svantaggi dell'adozione della modalità ambiente.

Costi delle risorse notevolmente ridotti.

Poiché i sidecar non sono più necessari, la modalità ambiente di Istio riduce in modo significativo l'ingombro delle risorse, in termini di memoria e di CPU necessarie per adottare le funzionalità della service mesh, come la crittografia mTLS. Rispetto alla modalità sidecar, abbiamo riscontrato una riduzione dell'utilizzo della memoria di oltre il 90% e una riduzione della CPU superiore al 50%. Si registra una riduzione ancora maggiore dell'utilizzo delle risorse quando si utilizza solo ztunnel. 

Rete zero trust leggera

Riteniamo che la motivazione principale per la modalità ambient di Istio sia la crittografia mTLS leggera da pod a pod. Poiché le reti zero trust stanno acquistando maggiore priorità, stiamo assistendo a un numero crescente di clienti che impone ai service mesh di applicare la crittografia mTLS su un numero elevato di applicazioni. La modalità ambient di Istio con solo ztunnel fornisce tutto questo, inclusa la gestione di identità e certificati, riducendo al minimo il sovrautilizzo delle risorse e l'impatto sui carichi di lavoro in esecuzione. Man mano che i requisiti aumentano, è possibile aggiungere waypoint per introdurre criteri e dati di telemetria a livello di applicazione, come quelli basati sui tipi di richiesta HTTP (ad esempio, /GET) o sugli header. 

Scalabilità migliorata 

Con meno proxy da gestire e un footprint notevolmente ridotto, il potenziale di scalabilità della modalità ambient di Istio è notevolmente maggiore rispetto alla modalità sidecar tradizionale. Sebbene alcuni clienti abbiano adattato le mesh per supportare migliaia di carichi di lavoro utilizzando le funzionalità di scoping e scalabilità di Istio, l'architettura della modalità ambient offre il potenziale per la scalabilità a decine o persino centinaia di migliaia di carichi di lavoro, riducendo il numero di ottimizzazioni necessarie. 

Potenziali caratteristiche prestazionali

Sebbene le misurazioni iniziali delle prestazioni della community di Istio fossero promettenti, stiamo ancora valutando le prestazioni della modalità ambient in una configurazione adatta alle aziende paragonabile a quella dei nostri clienti. Finora, abbiamo riscontrato prestazioni paragonabili a quelle della modalità sidecar, con la possibilità di miglioramenti nelle versioni future. Utilizzando unicamente ztunnel, le caratteristiche delle prestazioni saranno diverse rispetto all’utilizzo aggiuntivo di un waypoint, poiché il waypoint aumenta il sovraccarico a seconda della configurazione. Abbiamo anche riscontrato una criticità nota delle prestazioni, che limitava la scalabilità verticale di ztunnel e la cui risoluzione richiederà tempo. Riteniamo che l'architettura dell’ambient di Istio mostri il potenziale per migliorare le prestazioni nelle versioni future.

Adozione semplificata

Inoltre, la modalità ambient di Istio semplifica l'adozione della service mesh, eliminando la necessità di modificare i carichi di lavoro per aggiungere container sidecar. Infatti, non è nemmeno necessario riavviarli per aggiungerli alla mesh o al momento dell'upgrade della mesh. L'architettura a due livelli consente, inoltre, di adottare le funzionalità di Istio in modo incrementale, senza sostenere i costi delle risorse del proxy di livello 7 quando non è necessario. 

Livelli di supporto delle funzionalità

È necessario considerare che il livello di supporto per le funzionalità di Istio con la modalità ambient può differire dalla modalità sidecar tradizionale. Puoi consultare la tabella delle funzionalità supportate di Service Mesh. Le funzionalità avanzate, come multicluster e multimesh, sono ancora in fase di sviluppo, mentre la combinazione di carichi di lavoro con modalità sidecar e ambient presenta limitazioni, in particolare per l'utilizzo di proxy waypoint con sidecar. Per il punto di vista della community di Istio sulla modalità ambient rispetto alla modalità sidecar, consulta questa pagina. 

Considerazioni sull'upgrade

Nella modalità ambient di Istio, il piano dati può essere aggiornato senza riavviare i pod dei carichi di lavoro, come richiesto con i proxy sidecar. Lo svantaggio è che gli ztunnel sono agenti condivisi a livello di nodo che fanno parte del data path per più applicazioni. Pertanto, l'upgrade di ztunnel deve essere eseguito con attenzione. Ti consigliamo di eseguire l'upgrade durante una finestra di manutenzione o un periodo di traffico inferiore; comporterà la reimpostazione delle connessioni TCP di lunga durata su quel nodo. Anche gli upgrade basati su revisioni (canary) non sono ancora supportati in questa release. Sarà un'area di sviluppo nelle release future.

Introduzione alla modalità ambient di Istio

Per iniziare a utilizzare la modalità ambient di Istio, OpenShift Service Mesh fornisce la risorsa "Ztunnel" per installare e gestire ztunnel come daemonset. Questo viene installato insieme alle risorse "Istio" e "IstioCNI", che devono essere configurate con il profilo "ambient", anche nel caso in cui alcuni carichi di lavoro abbiano dei sidecar. 

Come per la modalità sidecar tradizionale, è anche importante configurare i "selettori di rilevamento" di Istio per garantire che il piano di controllo di Istio sia in grado di monitorare solo gli spazi dei nomi che devono far parte della mesh. Per la modalità ambient, l'etichetta "istio.io/dataplane-mode=ambient" viene utilizzata per indicare che uno spazio dei nomi o un carico di lavoro deve essere incluso nella mesh. Per maggiori informazioni sull'aggiunta di carichi di lavoro, consulta la documentazione della community di Istio.

Quando viene aggiunto un nuovo carico di lavoro alla mesh, l'agente Istio CNI collabora con il proxy ztunnel locale del nodo per configurare il reindirizzamento del traffico, in modo che tutto il traffico venga intercettato e aggiornato per utilizzare mTLS tramite il protocollo di tunneling HBONE di Istio. Ztunnel gestisce anche il recupero e la gestione dei certificati per tutti i pod sullo stesso nodo.

Se si desidera un proxy waypoint, è possibile aggiungerlo in modo simile a un gateway di ingresso o di uscita, utilizzando la risorsa Kubernetes "Gateway" dell'API Kubernetes Gateway, inclusa in OpenShift 4.19+. Ulteriori informazioni sull'installazione dei waypoint sono disponibili a questa pagina, mentre qui puoi trovare informazioni sull'utilizzo dei waypoint per le funzionalità L7.

Per una procedura dettagliata su come iniziare a utilizzare la modalità ambient di Istio, consulta la documentazione di OpenShift Service Mesh.

Se utilizzo già una service mesh, posso eseguire la migrazione alla modalità ambient?

Sebbene la modalità ambient sia ideale per i nuovi utenti di service mesh, può anche essere introdotta nei deployment di service mesh esistenti e combinata con i carichi di lavoro in modalità sidecar, con alcune avvertenze. Prevediamo, inoltre, che la modalità sidecar continuerà ad essere la modalità preferita, nei casi in cui è necessario l'intero set di funzionalità di un proxy Envoy dedicato per pod. 

Per introdurre la modalità ambient in una mesh esistente, la mesh (Istio e Istio CNI) deve essere aggiornata con il profilo "ambient" e tutti i carichi di lavoro con sidecar devono essere riavviati affinché possano comunicare con gli ztunnel utilizzando il protocollo di tunneling HBONE. 

Un limite attuale di questa coesistenza è che il traffico tra i proxy sidecar e i carichi di lavoro della modalità ambient, in genere ignora i proxy waypoint, quindi i criteri di livello 7 non verranno applicati per il carico di lavoro ambient.

Date queste limitazioni, è consigliabile che gli spazi dei nomi e i gruppi di applicazioni utilizzino o la modalità ambient o la modalità sidecar, anziché unire le modalità all'interno di carichi di lavoro applicativi con un livello di accoppiamento elevato. È inoltre importante evitare di confondere le etichette dei pod in modalità sidecar e ambient.

Kiali unito alla modalità ambient di Istio

Kiali, la console per Istio inclusa in OpenShift Service Mesh, offre numerose funzionalità per la configurazione, la visualizzazione e la convalida della modalità ambient di Istio. I carichi di lavoro possono trovarsi in diversi stati (in mesh con ztunnel, in mesh con waypoint, in modalità sidecar o non parte della mesh). Per questo, Kiali diventa ancora più importante per comprendere lo stato della mesh e risolvere i problemi quando le applicazioni distribuite non si comportano come previsto.

Ad ogni livello, Kiali fornisce chiare conferme della corretta configurazione della modalità ambient. Si inizia con il piano di controllo Istio in esecuzione con il profilo ambient abilitato e con gli spazi dei nomi e i carichi di lavoro etichettati, in modo che il traffico dei carichi di lavoro venga acquisito da ztunnel e/o waypoint come previsto. Infine, a livello di pod, è possibile verificare che il traffico sia protetto tramite il protocollo HBONE di Istio anziché il protocollo TCP non crittografato.

Kiali fornisce anche i log correlati tra ztunnel e waypoint, in modo da poter comprendere e risolvere i problemi relativi al trasferimento del traffico dal carico di lavoro a ogni proxy.

Sebbene i proxy waypoint siano simili ad altri proxy, Kiali ha una scheda specifica per mostrare quali servizi e carichi di lavoro sono stati registrati. 

Infine, i grafici della topologia per la modalità ambient hanno un aspetto diverso rispetto alla modalità sidecar. Poiché ora sono disponibili due livelli di proxy, per ogni carico di lavoro possono essere segnalati due set indipendenti di dati di telemetria: le metriche L4 (TCP), indicate in blu dagli ztunnel, e le metriche L7 (HTTP) in verde, laddove è stato configurato un waypoint. Kiali offre la possibilità di selezionare il tipo di traffico visualizzato.

Poiché è probabile che i proxy waypoint rappresentino gruppi di carichi di lavoro con un livello di accoppiamento elevato (che costituiscono una comune applicazione distribuita), la visualizzazione waypoint fornisce una panoramica di livello superiore della mesh in quella che potrebbe essere una mesh di grandi dimensioni.

Per maggiori informazioni su tutte le funzionalità di Kiali per la modalità ambient, consulta la documentazione della community di Kiali.

Aggiornamenti di Istio 1.27

Questa release include tutti gli aggiornamenti indicati nelle note di modifica di Istio 1.27. Ecco alcuni dei punti salienti.

Gateway API Inference Extensions (GIE)

Questa release include il supporto per Gateway API Inference Extensions. Per supportare meglio i clienti su Red Hat OpenShift AI 3, abbiamo eseguito il backport dell'implementazione disponibile a livello generale (versione 1.0) dell'API in questa release. Questa funzionalità è supportata solo con Red Hat OpenShift AI 3 ed è considerata una funzionalità in anteprima tecnologica per OpenShift Service Mesh 3.2. 

Multicluster con modalità ambient

Questa release introduce il supporto iniziale per la modalità ambient di Istio in una topologia multicluster e multiprimaria. Poiché questa funzionalità è ancora in fase di sviluppo upstream, l'abbiamo designata come "anteprima per sviluppatori" per OpenShift Service Mesh 3.2. 

Supporto nativo di nftables in modalità sidecar

In preparazione a Red Hat Enterprise Linux (RHEL) 10, Red Hat ha offerto al progetto Istio il supporto per nftables, grazie al supporto per la modalità sidecar introdotto in Istio 1.27. Il framework nftable è il successore moderno di iptables, la funzionalità Linux utilizzata da Istio per configurare le regole di reindirizzamento della rete. L'obiettivo è fornire prestazioni migliori, manutenzione e una gestione più flessibile delle regole per il reindirizzamento del traffico da e verso il sidecar Envoy. A partire da RHEL 10, nftables sarà lo strumento predefinito per la gestione delle regole di rete. Il supporto per RHEL 10 sarà disponibile in una versione futura di OpenShift.

Cert-manager Istio-CSR è disponibile a livello generale

L'operatore cert-manager è supportato per l'uso con OpenShift Service Mesh, anche se l'agente istio-csr è necessario affinché cert-manager possa firmare, distribuire e rinnovare i certificati per i carichi di lavoro. Con la pubblicazione dell'operatore cert-manager versione 1.18, questo agente è ora disponibile a livello generale e può essere utilizzato con tutte le versioni supportate di OpenShift Service Mesh. Per maggiori informazioni sulla collaborazione tra cert-manager e OpenShift Service Mesh per abilitare zero trust, leggi questo articolo del blog. Per la procedura che illustra come utilizzare cert-manager con OpenShift Service Mesh, consulta la documentazione.

Introduzione a OpenShift Service Mesh

Per sapere di più su Red Hat OpenShift Service Mesh, leggi questo articolo del blog e l’articolo successivo su multicluster service mesh. 

Per iniziare a utilizzare service mesh, devi prima installare l'operatore Red Hat OpenShift Service Mesh 3. Se non hai familiarità con le service mesh, ti consigliamo di prendere in considerazione la modalità ambient di Istio. Fornirà un'architettura di service mesh significativamente più efficiente in termini di risorse rispetto alla tradizionale modalità sidecar. Per iniziare a utilizzare la modalità ambient di Istio, leggi la documentazione. 

Per un esempio end-to-end sull'utilizzo di OpenShift Service Mesh con il monitoraggio dei carichi di lavoro degli utenti OpenShift, il tracciamento distribuito e Kiali, consulta questo modello di soluzione.