Introduzione a OpenShift Service Mesh 3.1

Red Hat ha rilasciato OpenShift Service Mesh 3.1, incluso in Red Hat OpenShift Container Platform e Red Hat OpenShift Platform Plus. Basata sui progetti Istio, Envoy e Kiali, questa versione aggiorna la versione di Istio a 1.26 e Kiali a 2.11, ed è supportato su OpenShift Container Platform 4.16 e versioni successive.

Questa è la prima release secondaria successiva a Red Hat OpenShift Service Mesh 3.0, un aggiornamento principale per la convergenza di OpenShift Service Mesh con il progetto della community Istio, con installazione e gestione tramite l'operatore Sail. Questa modifica contribuisce a garantire che OpenShift Service Mesh sia in grado di offrire le ultime funzionalità stabili di Istio con il supporto di Red Hat.

Esegui l'upgrade a OpenShift Service Mesh 3.1

Se si esegue OpenShift Service Mesh 2.6 o una versione precedente, è necessario eseguire l'upgrade a OpenShift Service Mesh 3.0 prima di eseguire l'upgrade alla 3.1. Consigliamo di eseguire tempestivamente la migrazione a OpenShift Service Mesh 3.0, poiché la versione 2.6 raggiungerà la fine del suo ciclo di vita il 12 marzo 2026. Una guida approfondita alla migrazione è disponibile nella documentazione di OpenShift Service Mesh 3.0, che include un’analisi delle differenze tra OpenShift Service Mesh 2.6 e 3.0.  

Di recente abbiamo anche pubblicato un articolo che descrive come utilizzare la console Kiali per la migrazione da OpenShift Service Mesh 2.6 a 3.0.

Per vedere OpenShift Service Mesh 3.0 in azione con metriche preconfigurate e la console Kiali, consulta questa analisi della soluzione.

Supporto API Kubernetes Gateway in OCP 4.19 e versioni successive

Kubernetes Gateway API è la nuova generazione di API Kubernetes Ingress, di bilanciamento del carico e di API service mesh. Istio prevede di rendere Kubernetes Gateway API il set predefinito di API per la creazione e la gestione del traffico utilizzando una service mesh, ed è necessario per l'utilizzo della modalità ambient di Istio. Si tenga presente che non è prevista la rimozione delle API Istio stabili, come VirtualService, DestinationRule e altre. A volte può essere necessario utilizzare tali API per sfruttare le funzionalità che non sono state ancora aggiunte all'API Kubernetes Gateway.

Sebbene OpenShift Service Mesh 3.0 includesse il supporto per l'API Kubernetes Gateway, richiedeva agli utenti di installare le definizioni delle risorse personalizzate (CRD) non supportate per sfruttare questa funzionalità. La situazione è cambiata a partire da OpenShift Container Platform 4.19 e versioni successive, con i CRD necessari ora disponibili per impostazione predefinita in OpenShift. Non è più necessario installare questi CRD separatamente. Red Hat supporta pienamente i CRD dell'API Gateway inclusi in OpenShift.

Per offrire un supporto ottimizzato per i carichi di lavoro e i modelli di traffico dell'IA generativa, abbiamo incluso il supporto Technology Preview per Gateway API Inference Extension eseguendo il backport di questa funzionalità su OpenShift Service Mesh 3.1.

Supporto dual-stack generalmente disponibile per i cluster x86

Questa versione rende disponibile il supporto dual-stack per i carichi di lavoro IPv4 e IPv6 con OpenShift Service Mesh sui cluster OpenShift che eseguono hardware x86. Per abilitare il supporto dual-stack in OpenShift Service Mesh, è necessario impostare il flag ISTIO_DUAL_STACK su true nella risorsa cliente di Istio. Questo passaggio è descritto nella documentazione upstream di sail-operator per il dual-stack, e nella documentazione della community Istio dual-stack, seguite dalla documentazione del prodotto OpenShift Service Mesh.

Passa ai container UBI Micro

Questa versione trasferisce la maggior parte dei container, inclusi i container chiave istiod e proxy (Envoy) per utilizzare immagini di base UBI Micro. UBI Micro è un'immagine Universal Base Image (UBI) di Red Hat Enterprise Linux di dimensioni minime, ottenuta escludendo un gestore di pacchetti e tutte le sue dipendenze, che normalmente sono incluse in un'immagine container. L'adozione di UBI Micro aiuta a ridurre al minimo la superficie di attacco delle immagini dei container distribuite all’interno di OpenShift Service Mesh.

Verso una service mesh sidecar-less: la modalità ambient mode di Istio

OpenShift Service Mesh 3.1 si basa su Istio 1.26 e include aggiornamenti per lo più incrementali rispetto a OpenShift Service Mesh 3.0, che era basato su Istio 1.24. Ciò è dovuto al fatto che la community di Istio e Red Hat sono molto concentrati sul dataplane della service mesh di nuova generazione: la modalità ambient di Istio.

Negli ultimi anni abbiamo assistito a una crescita costante dell'utilizzo delle service mesh, ma la necessità di proxy sidecar è spesso un ostacolo all'adozione, a causa delle risorse aggiuntive (memoria e CPU, principalmente) necessarie per eseguire i container sidecar accanto a ciascun container applicativo. Ciò complica l'adozione della service mesh, perché è necessario aggiungere e aggiornare i proxy sidecar all’interno del ciclo di vita del pod. Ciò significa che è necessario riavviare le applicazioni per introdurre un aggiornamento della service mesh.

La modalità ambient di Istio mira a risolvere questi problemi eliminando la necessità di proxy sidecar e suddividendo il dataplane di Istio in due livelli separati. Ciò consente l'adozione incrementale delle funzionalità di service mesh con una minore complessità per i proprietari delle applicazioni.

Questa architettura suddivisa comporta un numero significativamente inferiore di proxy distribuiti per abilitare la service mesh, riducendo notevolmente le risorse necessarie per eseguire una service mesh. Poiché la modalità ambient di Istio non richiede proxy sidecar, è possibile aggiungere e rimuovere le applicazioni dalla mesh senza dover modificare o riavviare i pod applicativi.

I due livelli separati della modalità ambient di Istio sono:

• Ztunnel: un proxy leggero a livello di nodo, di livello 4 (eseguito come Daemonset in Kubernetes), che crea un socket di ascolto all'interno dello spazio dei nomi di rete del pod dell'applicazione per aggiornare in modo trasparente il traffico a livello di pod con la crittografia mTLS. Ztunnel si occupa anche della gestione dei certificati e delle identità, esclusivamente per i pod nel nodo. Solo con Ztunnel è possibile ottenere la crittografia mTLS automatica, la telemetria di livello 4 e la gestione delle policy.
• Waypoint: Un proxy Envoy facoltativo, simile a un gateway, distribuito per un set di applicazioni (con ambito dello spazio dei nomi per impostazione predefinita) per fornire funzionalità mesh di livello 7, come le policy di sicurezza e traffico a livello di applicazione, la telemetria a livello di applicazione e le funzionalità di resilienza della mesh. A differenza dei sidecar, è possibile aggiungere i proxy waypoint in base alle esigenze e scalarli indipendentemente dai container delle applicazioni.

Per maggiori dettagli sull'architettura in modalità ambient di Istio e sui compromessi, si legga Try Istio ambient mode on Red Hat OpenShift.

OpenShift Service Mesh 3.1 aggiorna lo stato della modalità ambient di Istio su Technology Preview, con un proxy Ztunnel pienamente supportato da Red Hat, che utilizza OpenSSL per la crittografia garantendone la progettazione per FIPS. OpenShift Service Mesh 3.1 include la documentazione per iniziare a utilizzare la modalità ambient di Istio su OpenShift all’interno della guida all'installazione. Svilupperemo questo aspetto nei prossimi mesi man mano che ci si avvicina alla disponibilità generale.

Si tenga presente che la modalità ambient di Istio richiede l'API Kubernetes Gateway, pertanto va utilizzata su OpenShift Container Platform 4.19 o versioni successive, inclusi i CRD dell'API Gateway supportati, installati per impostazione predefinita. Se si desidera sperimentare la modalità ambient di Istio sulle versioni precedenti di OpenShift, è necessario installare i CRD dell'API Kubernetes Gateway non supportati, come descritto nella documentazione della community Istio. Si tenga presente che l'upgrade ai CRD dell'API Kubernetes Gateway supportati in OCP 4.19 può comportare tempi di inattività.

Consigliamo inoltre di sperimentare la modalità ambient di Istio su cluster in cui non è già installato OpenShift Service Mesh per ridurre la probabilità di interferire con i deployment di service mesh esistenti. In futuro, forniremo la documentazione sull'esecuzione di un dataplane in modalità ambient insieme a un dataplane in modalità sidecar, oltre a indicazioni sulla migrazione delle applicazioni dalla modalità sidecar alla modalità ambient.

Si tenga presente che, a partire da Istio 1.26, non tutte le funzionalità della modalità sidecar sono supportate in modalità ambient, e alcune funzionalità rimangono "Alpha" nell'upstream Istio. La modalità ambiente potrebbe non essere adatta a tutti gli scenari di utilizzo della service mesh. Le lacune principali sono la configurazione di più cluster di rete e l'interoperabilità tra i dataplane in modalità ambient e sidecar. La community di Istio sta sviluppando queste e altre funzionalità.

Aggiornamenti di Kiali

Kiali è la console per la service mesh di Istio inclusa in OpenShift Service Mesh. Questa versione lo aggiorna alla 2.11, che include molti aggiornamenti e miglioramenti (come la modalità ambient di Istio).

Aggiornamenti delle pagine mesh

La pagina mesh continua a essere migliorata come dashboard per il monitoraggio dello stato dell'infrastruttura di Istio, che copre il piano di controllo Istio stesso, i componenti del dataplane e i componenti aggiuntivi di osservabilità come Prometheus e Tempo. Questa versione include diversi aggiornamenti, tra cui i gateway Istio e i componenti del dataplane in modalità ambient: Ztunnel e Waypoint. Dalla pagina della mesh è possibile esaminare i componenti per rivelare le informazioni principali sullo stato, incluse le metriche e i dump di configurazione relativi a ciascun componente.

Prestazioni e scalabilità con mesh di grandi dimensioni

Una preoccupazione comune a Kiali riguarda le prestazioni, poiché il numero di carichi di lavoro nella service mesh aumenta. In passato, Kiali avrebbe faticato a rispondere con service mesh di grandi dimensioni. Le domande frequenti sul progetto Kiali ora includono una nuova sezione sulle prestazioni che fornisce indicazioni per l'utilizzo di Kiali con deployment mesh di grandi dimensioni. Questa versione include aggiornamenti per migliorare le prestazioni, inclusi aggiornamenti per gestire meglio le mesh di grandi dimensioni.

Ad esempio, per impostazione predefinita, Kiali tenta immediatamente di eseguire il rendering di una pagina e aggiorna automaticamente la maggior parte delle pagine in base all'impostazione del menu a discesa Intervallo di aggiornamento. Per le mesh di grandi dimensioni, anche il rendering iniziale può essere lento, ritardando l'utilizzo della console. Kiali ora offre un’impostazione di aggiornamento manuale, che si limita ad aggiornare una pagina quando si clicca su manualmente su Refresh. È possibile impostarla tramite il manuale spec.kiali_feature_flags.ui_defaults.refresh_interval: nella Custom Resource Definition (CRD) di Kiali. 

È anche possibile disabilitare le convalide per migliorare le prestazioni e la reattività con le mesh di grandi dimensioni. È possibile farlo impostando la configurazione dell'operatore Kiali spec.external_services.istio.validation_reconcile_interval su 0.

Inizia a utilizzare OpenShift Service Mesh

Se non hai familiarità con OpenShift Service Mesh,, inizia dall’introduzione a OpenShift Service Mesh e dalle nostre istruzioni per l’installazione. Per un esempio completo, consulta l’analisi della soluzione Ottimizzazione del traffico e dell'osservabilità con OpenShift Service Mesh 3.

Se parti da OpenShift Service Mesh 3.0, consulta la documentazione sull'upgrade per conoscere i diversi approcci all'aggiornamento dell'operatore OpenShift Service Mesh 3, i piani di controllo Istio, la risorsa Istio CNI e i proxy che compongono il dataplane.

Se parti da OpenShift Service Mesh 2.6 o versioni precedenti, leggi le differenze tra OpenShift Service Mesh 2 e 3, e la nostra ricca documentazione sulla migrazione. È disponibile anche un articolo del blog che descrive la procedura con Kiali.