All'inizio di quest'anno, abbiamo annunciato il nuovo operatore per Istio su Red Hat OpenShift, che sarà disponibile nell'anteprima per sviluppatori dalla prossima generazione di OpenShift Service Mesh - Versione 3. Questo articolo fornisce informazioni importanti sui cambiamenti che verranno apportati a OpenShift Service Mesh nel 2024. Nel frattempo, abbiamo continuato a sviluppare l'operatore Sail, a offrire supporto ai clienti su OpenShift Service Mesh 2 e ad acquisire feedback sui nostri piani per OpenShift Service Mesh 3. Sebbene il nuovo operatore sia ancora nell'anteprima per sviluppatori, questo articolo fornisce un aggiornamento, illustra i piani futuri e offre alcune linee guida su come gli utenti di OpenShift Service Mesh possono prepararsi per OpenShift Service Mesh 3.
Aggiornamenti di Service Mesh 3.0
Al momento, l'operatore Kubernetes di Service Mesh 3 è nella fase di sviluppo come operatore "Sail", ed è disponibile come operatore Kubernetes della community nell'Operator Hub di OpenShift. L'operatore Kubernetes Sail viene aggiornato giornalmente, pertanto è ancora in fase evolutiva, è soggetto a modifiche e potrebbe evolversi in modo diverso da quanto descritto in questo articolo del blog; in questo momento può essere quindi utilizzato solo per la sperimentazione. Per informazioni più recenti sull'operatore Kubernetes, consulta il file README incluso.
Abbiamo in programma il trasferimento dell'operatore Kubernetes della community all'organizzazione istio-ecosystem upstream, con l'intento di ottenere una maggiore collaborazione della community e migliorare il progetto Istio di base aumentandone la compatibilità su OpenShift. Gli artefatti del prodotto downstream di OpenShift Service Mesh 3 saranno disponibili nell'organizzazione appena creata openshift-service-mesh, mentre per Service Mesh 2 continuerà a essere utilizzata l'organizzazione maistra.
Un operatore Kubernetes in esclusiva per Istio
Come spiegato in un precedente articolo del blog, OpenShift Service Mesh 3 si baserà su un nuovo operatore Kubernetes per Istio. A differenza dell'attuale operatore Kubernetes di OpenShift Service Mesh 2, il nuovo operatore gestirà solo le risorse Istio e non tenterà di configurare le integrazioni Istio come Kiali. I componenti complementari, come Kiali, le metriche, il tracciamento e altri, saranno gestiti da operatori Kubernetes di prodotti con supporto indipendente.
Al primo rilascio dell'operatore Sail, la risorsa personalizzata per l'installazione del piano di controllo Istio era denominata IstioHelmInstall. Questa risorsa è stata poi chiamata "Istio" per indicare che è responsabile della creazione e della gestione di una singola istanza di Istio (un piano di controllo e un piano dati).
A differenza della risorsa personalizzata ServiceMeshControlPlane utilizzata in OpenShift Service Mesh 2, la risorsa Istio utilizza i valori Helm di Istio upstream per definire la configurazione di Istio. Ciò semplifica agli utenti la traduzione degli esempi di configurazione della community in OpenShift Service Mesh 3 e ci aiuta a garantire che le attività future volte a migliorare la configurazione saranno frutto della collaborazione con la community di Istio. Non escludiamo una futura convergenza con l'API Istio Operator della community, che viene utilizzata con il processo di installazione di istioctl e con l'installazione dell'operatore Istio upstream, ormai sconsigliata.
Le nostre prossime iniziative prevedono il perfezionamento dell'organizzazione della configurazione e migliorie al supporto di alcune funzionalità come le revisioni di Istio, gli upgrade di tipo canary e la multitenancy. Per informazioni più recenti, consulta il file README dell'operatore Kubernetes.
Selezione dei rilasci
Al primo rilascio, l'operatore Sail avrebbe distribuito l'ultima versione di Istio, ovvero la diramazione Master di Istio in fase di sviluppo. Sebbene ciò sarebbe stato utile per sperimentare le ultime novità della community Istio, nella maggior parte dei casi gli utenti avrebbero dovuto utilizzare una versione ufficiale di Istio per accertarsi della stabilità e della compatibilità con istioctl e con le integrazioni come Kiali.
Ora, per impostazione predefinita, viene utilizzata l'ultima versione di Istio, attualmente la 1.20. Per configurare questa versione, utilizza il campo version nella CRD di Istio. Durante la creazione di una nuova istanza con la console OpenShift, è ora disponibile un menu a discesa che presenta l'elenco delle versioni di Istio selezionabili. Le versioni di Istio disponibili sono definite nel file versions.yaml, che viene aggiornato con ogni nuova versione di Istio disponibile.
Menu a discesa per la selezione della versione di Istio
L'operatore Kubernetes del futuro OpenShift Service Mesh 3, che sarà basato sull'operatore Sail, gestirà le versioni di OpenShift Service Mesh in modo simile. Benché questo campo version sia simile al campo version della risorsa ServiceMeshControlPlane in Service Mesh 2.x, è differente in quanto permette agli utenti di specificare la versione fino al livello di rilascio Z della patch (ad esempio 3.1.1). Sebbene supporterà solo le più recenti release di patch di OpenShift Service Mesh, questa funzionalità permetterà agli utenti di aggiungere o eseguire il rollback a una determinata versione della patch "Z", offrendo maggiore controllo e flessibilità nella gestione degli aggiornamenti delle patch.
Convalida della configurazione
Il campo principale per la configurazione di Istio con la nuova CRD è il campo values. Questo campo altamente funzionale permette di fare riferimento diretto ai valori di configurazione di Istio Helm. Inoltre, al campo abbiamo aggiunto la convalida, in modo da rilevare valori di configurazione inesistenti e altri errori di configurazione in base alle convalide protobuf di Istio upstream.
Tali convalide consentono anche di gestire il campo values come segue:
$ oc explain istio.spec.values
KIND: Istio
VERSION: operator.istio.io/v1alpha1
RESOURCE: values <Object>
DESCRIPTION:
Values defines the values to be passed to the Helm chart when installing
Istio.
FIELDS:
base <Object>
cni <Object>
defaultRevision <string>
global <Object>
istio_cni <Object>
istiodRemote <Object>
meshConfig <>
ownerName <string>
pilot <Object>
revision <string>
revisionTags <[]string>
sidecarInjectorWebhook <Object>
telemetry <Object>
ztunnel <>
A volte è opportuno sostituire queste convalide, ad esempio per accedere a una configurazione sperimentale che non fa ancora parte dello schema protobuf di Istio. Per questo abbiamo incluso anche un campo rawValues, che è identico al campo values, ma senza convalide.
Occorre sempre tenere presente che i campi resource, values e rawValues di Istio sono sperimentali e soggetti a modifiche. Per informazioni più recenti, consulta il file README del progetto.
Stato e configurazione di Istio
Dopo aver applicato la configurazione di Istio, è necessario convalidare lo stato del piano di controllo. A tale scopo, utilizza il comando seguente:
$ kubectl get istioundefinedundefinedundefined
NAME READY STATUS VERSION AGE
istio-sample True Healthy v1.20.0 62sundefinedundefined
In alternativa, utilizza il campo di stato:
Definizione della risorsa personalizzata (CRD) di Istio
Dopo averlo esteso, puoi utilizzare il campo status.appliedValues per verificare che la configurazione sia stata applicata come previsto con il campo spec.values.
Istio su OpenShift
Come previsto dalla nostra iniziativa di collaborazione con la community Istio, Red Hat continua a contribuire a Istio upstream per migliorarne la compatibilità su OpenShift. Ciò offre vantaggi a noi perché ci aiuta a semplificare il passaggio alla fase di produzione di Istio, ma anche alla community, ai clienti e ai partner. I nostri contributi semplificano la gestione della community Istio su OpenShift, ottimizzando al contempo l'onboarding alla versione supportata di OpenShift Service Mesh.
Un esempio di valido contributo è la rimozione della necessità di concedere il privilegio anyuid di Security Context Constraint (SCC) al piano di controllo e ai componenti del piano dati di Istio, come evidenziato di recente in Istio 1.20. Continueremo a fornire contributi simili. Al momento stiamo lavorando affinché la mesh Ambient di Istio funzioni su OpenShift.
Procedure consigliate per i gateway
Al momento del suo annuncio, l'operatore Kubernetes installava automaticamente i gateway, in maniera simile al profilo di configurazione dell'installazione Istio predefinito. Questo approccio è coerente con OpenShift Service Mesh 2.x, che crea i gateway di ingresso e di uscita predefiniti, chiamati rispettivamente istio-ingressgateway e istio-egressgateway.
Sebbene questi gateway creati automaticamente siano utili per iniziare, non offrono la configurabilità necessaria agli ambienti di produzione. Riteniamo inoltre che i gateway possano essere creati e gestiti meglio con le loro applicazioni nel piano dati anziché nel piano di controllo. I gateway creati e gestiti con le relative applicazioni costituiscono anche una procedure più efficace dal punto di vista della sicurezza, poiché limitano l'ambito di un gateway a un insieme di applicazioni più ristretto e gli permettono di adottare il ciclo di vita delle proprie applicazioni anziché quello del piano di controllo.
Abbiamo quindi deciso di rimuovere i gateway del piano di controllo per favorire la creazione di gateway con le rispettive applicazioni utilizzando o l'inserimento del gateway o l'API Gateway di Kubernetes. Come specificato in ServiceMeshControlPlane di OpenShift Service Mesh 2.x, istio-ingressgateway e istio-egressgateway non saranno inclusi in Service Mesh 3.0. Forniremo invece configurazioni di esempio dei gateway per l'applicazione Bookinfo tramite l'inserimento del gateway e l'API Gateway di Kubernetes.
Con l' inserimento del gateway, la creazione e la gestione dei gateway funzionano in modo simile a qualsiasi altro carico di lavoro su Kubernetes o OpenShift, tramite una risorsa Deployment in cui viene inserito un proxy Envoy. Questo approccio offre al proprietario dell'applicazione il controllo completo del gateway. È il metodo consigliato per creare e gestire i gateway in OpenShift Service Mesh 2.3 e nelle versioni successive.
Con l' API Gateway, in anteprima tecnologica a partire da OpenShift Service Mesh 2.4, con ogni istanza del gateway viene creata e configurata un'istanza di distribuzione del gateway.
Queste opzioni consentono di creare e gestire i gateway con le applicazioni, idealmente all'interno di un flusso di lavoro GitOps.
API Gateway di Kubernetes
L'API Gateway di Kubernetes rappresenta la nuova generazione di API per la modellazione delle reti in Kubernetes e offre più flessibilità ed estensibilità rispetto all'attuale API Ingress di Kubernetes, per gestire le reti delle organizzazioni di grandi dimensioni. Inizialmente progettata per gestire il traffico da nord a sud proveniente dai client esterni al cluster, è stata ampliata fino a includere il traffico da est a ovest, inclusa la service mesh. L'iniziativa GAMMA è stata creata per definire le modalità di applicazione dell'API Gateway agli scenari di utilizzo della service mesh. Istio ora include alcuni esempi di configurazione dell'API Gateway relativi alla maggior parte delle attività documentate, come la gestione del traffico.
Benché l'API Gateway sia ancora in anteprima tecnologica in OpenShift Service Mesh 2.4 e debba essere abilitata con un flag di funzionalità, è ora generalmente disponibile alla community. La versione 1.0 dell'API è disponibile in Istio 1.20 (che sarà incluso in OpenShift Service Mesh 2.6 e versioni successive). In futuro, Istio prevede di rendere l'API Gateway predefinita per la gestione completa del traffico, ma per il momento continuerà a supportare le API Istio Gateway, VirtualService, DestinationRule ecc.
L'entusiasmo per le potenzialità del progetto API Gateway di offrire uno standard comune per le reti Kubernetes va ben oltre la service mesh.
Stiamo sviluppando un'implementazione basata sull'API Gateway di OpenShift Ingress che gli utenti possono distribuire, indipendentemente dalla service mesh, tramite l' operatore Ingress dell'API Gateway. Per approfondimenti su questo lavoro e sull'API Gateway, consulta questo articolo del blog e l' aggiornamento più recente.
Il team che ha presentato 3Scale API Management è intanto al lavoro sul progetto Kuadrant.io che applicherà l'API Gateway nei contesti in cui il traffico esterno entra nei gateway Ingress, ad esempio le connessioni multicluster, il bilanciamento del carico globale, la limitazione della velocità, le autorizzazioni e molto altro. Troverai altre informazioni su questo progetto in uno dei prossimi articoli del blog.
Primi passi con i componenti aggiuntivi di Istio come Kiali
Una delle principali novità di OpenShift Service Mesh 3.0 è che l'operatore Kubernetes gestirà solo Istio. Le integrazioni come Kiali, il tracciamento distribuito e le metriche verranno installate e gestite in modo indipendente. Sebbene questo approccio possa aggiungere ulteriori passaggi all'esperienza di chi inizia, riteniamo che le maggiori modularità e flessibilità nella configurazione di questi componenti siano una valida miglioria.
Per consentire agli utenti di essere operativi in breve tempo, abbiamo aggiunto al file README dell'operatore Kubernetes istruzioni su come configurare Istio con Istioctl e con Gateway, Prometheus, Jaeger e Kiali. Viene così offerto un ambiente di prova e sviluppo equivalente a quello offerto attualmente da OpenShift Service Mesh 2.x. Inoltre, fornisce un'anteprima del flusso di lavoro di installazione che prevediamo di distribuire in OpenShift Service Mesh 3, in cui Istio verrà installato in modo autonomo, e i componenti aggiuntivi verranno installati in modo indipendente. La Service Mesh 3.0 supportata utilizzerà gli operatori Kubernetes dei prodotti supportati per ogni componente aggiuntivo di Istio con una distribuzione di Istioctl supportata. Le configurazioni dei componenti aggiuntivi Istio gestite dalla community sono solo a scopo dimostrativo e di sviluppo e non devono essere utilizzate negli ambienti di produzione.
Prepararsi a Service Mesh 3.0
Gli utenti di OpenShift Service Mesh 2 possono già prepararsi all'adozione di Service Mesh 3.0.
È importante ricordare che OpenShift Service Mesh 3 sarà ancora basato su Istio, e che le API stabili di Istio che sono probabilmente utilizzate dagli utenti finali non verranno modificate. Le novità di OpenShift Service Mesh 3 che sarà necessario adottare sono le risorse di configurazione del piano di controllo come ServiceMeshControlPlane,ServiceMeshMemberRoll e ServiceMeshMemberRoll. Queste risorse sono in genere gestite dagli amministratori o dai team della piattaforma e non dai proprietari delle applicazioni. Continueremo a esplorare le modalità con cui gli amministratori possono eseguire la migrazione delle configurazioni del piano di controllo esistenti alle configurazioni di Service Mesh 3.
La configurazione specifica dell'applicazione, ovvero le risorse Istio come VirtualServices, DestinationRules e persino PeerAuthentication, non subiranno modifiche. Gli utenti potranno così iniziare a utilizzare o ad ampliare l'utilizzo di OpenShift Service Mesh 2 con fiducia, senza dover eseguire la migrazione di configurazioni specifiche di applicazioni o servizi durante il passaggio a OpenShift Service Mesh 3.
È possibile intraprendere già da oggi alcune azioni che possono semplificare il passaggio a OpenShift Service Mesh 3.0. Oltre a utilizzare la versione più recente di OpenShift Service Mesh (2.4+), gli utenti possono:
- Adottare o passare all'approccio di inserimento del gateway per creare e gestire i gateway Istio con le relative applicazioni anziché con il piano di controllo Istio (che è l'impostazione predefinita in Service Mesh 2.0). Come descritto in precedenza, il piano di controllo della versione 3.0 non crea i gateway.
- Se non sono necessari più piani di controllo, utilizza la modalità cluster-wide, che esegue Istiod come risorsa a livello del cluster. Questa sarà l'impostazione predefinita in Service Mesh 3.0, e offrirà la possibilità di creare più piani di controllo con la funzionalità di prossimo rilascio Multiple-Control Plane.
- Configura Service Mesh per monitorare il carico di lavoro degli utenti di OpenShift o il servizio di osservabilità di Red Hat Advanced Cluster Management per acquisire le metriche. Entrambi forniscono uno stack di monitoraggio idoneo alla fase di produzione, con avvisi più configurabili ed estensibili rispetto all'insieme di metriche installato con OpenShift Service Mesh 2.x (che verrà rimosso in Service Mesh 3).
- Utilizza risorse Kiali e Jaeger configurate esternamente invece di configurarle direttamente all'interno della risorsa ServiceMeshControlPlane. Oltre a fornire più flessibilità per la gestione di Kiali e Jaeger, queste verranno configurate in modo indipendente in Service Mesh 3.
Un articolo del blog di prossima pubblicazione approfondirà ciascuno di questi argomenti.
Prospettive di OpenShift Service Mesh
All'inizio del 2024 verrà rilasciata OpenShift Service Mesh 2.5 (basata su Istio 1.18). Nel 2024 verrà anche realizzata una versione 2.6 basata su Istio 1.20 o successiva. In questo modo i clienti avranno almeno un anno di supporto in più per eseguire l'upgrade dalla versione 2 alla versione 3 di OpenShift Service Mesh. La versione 2.6 ci garantirà anche più tempo per raccogliere i feedback su OpenShift Service Mesh 3, mentre questa sarà ancora nella versione di anteprima tecnologica.
Per OpenShift Service Mesh 3 continuiamo a sviluppare le funzionalità del nuovo operatore Kubernetes, tra cui l'ottimizzazione delle CRD per gestire meglio la configurazione di Istio e l'aggiunta di funzionalità di supporto migliorate per gli upgrade canary dei piani di controllo Istio. L'anteprima tecnologica è prevista per la fine del primo trimestre 2024, mentre la soluzione sarà generalmente disponibile nella seconda metà del 2024. Questi obiettivi sono ovviamente soggetti a modifica. Continueremo a offrire supporto ai clienti di OpenShift Service Mesh 2.x fino a quando non avremo realizzato una versione di OpenShift Service Mesh 3 che saremo orgogliosi di rendere disponibile a tutti.
Visita questa pagina per scoprire di più su Red Hat OpenShift Service Mesh.
Sull'autore
Jamie Longmuir is the product manager leading Red Hat OpenShift Service Mesh. Prior to his journey as a product manager, Jamie spent much of his career as a software developer with a focus on distributed systems and cloud infrastructure automation. Along the way, he has had stints as a field engineer and training developer working for both small startups and large enterprises.
Ricerca per canale
Automazione
Novità sull'automazione IT di tecnologie, team e ambienti
Intelligenza artificiale
Aggiornamenti sulle piattaforme che consentono alle aziende di eseguire carichi di lavoro IA ovunque
Hybrid cloud open source
Scopri come affrontare il futuro in modo più agile grazie al cloud ibrido
Sicurezza
Le ultime novità sulle nostre soluzioni per ridurre i rischi nelle tecnologie e negli ambienti
Edge computing
Aggiornamenti sulle piattaforme che semplificano l'operatività edge
Infrastruttura
Le ultime novità sulla piattaforma Linux aziendale leader a livello mondiale
Applicazioni
Approfondimenti sulle nostre soluzioni alle sfide applicative più difficili
Serie originali
Raccontiamo le interessanti storie di leader e creatori di tecnologie pensate per le aziende
Prodotti
- Red Hat Enterprise Linux
- Red Hat OpenShift
- Red Hat Ansible Automation Platform
- Servizi cloud
- Scopri tutti i prodotti
Strumenti
- Formazione e certificazioni
- Il mio account
- Supporto clienti
- Risorse per sviluppatori
- Trova un partner
- Red Hat Ecosystem Catalog
- Calcola il valore delle soluzioni Red Hat
- Documentazione
Prova, acquista, vendi
Comunica
- Contatta l'ufficio vendite
- Contatta l'assistenza clienti
- Contatta un esperto della formazione
- Social media
Informazioni su Red Hat
Red Hat è leader mondiale nella fornitura di soluzioni open source per le aziende, tra cui Linux, Kubernetes, container e soluzioni cloud. Le nostre soluzioni open source, rese sicure per un uso aziendale, consentono di operare su più piattaforme e ambienti, dal datacenter centrale all'edge della rete.
Seleziona la tua lingua
Red Hat legal and privacy links
- Informazioni su Red Hat
- Opportunità di lavoro
- Eventi
- Sedi
- Contattaci
- Blog di Red Hat
- Diversità, equità e inclusione
- Cool Stuff Store
- Red Hat Summit