Iniziamo una serie di post in cui mostreremo alcune delle numerose funzionalità della rete di servizi Istio Service Mesh in combinazione con Red Hat OpenShift e Kubernetes.
Parte uno, oggi:
- Spiegheremo il concetto di container sidecar di Kubernetes e formuleremo il tema principale di questa serie di post: «non dovete modificare il vostro codice».
- Introdurremo il concetto fondamentale di Istio: le regole di instradamento. Tutte le altre funzionalità di Istio si basano su di esse, poiché le regole consentono di dirigere il traffico verso i microservizi, utilizzando file YAML esterni al codice dei servizi. Discuteremo anche dello schema di implementazione Canary Deployment. Bonus di Capodanno: 10 corsi interattivi su Istio
La parte due, che uscirà presto, vi racconterà:
- Come Istio implementa il Pool Ejection in combinazione con il Circuit Breaker e mostrerà come Istio consente di rimuovere dalla scheda di bilanciamento un pod non funzionante o che lavora male.
- Inoltre, esamineremo il tema del Circuit Breaker del primo post per vedere come Istio possa essere coinvolto. Mostreremo come instradare il traffico e gestire gli errori di rete senza alcuna modifica ai codici dei servizi, utilizzando file di configurazione YAML e comandi da terminale.
Parte tre:
- Parleremo di tracciamento e monitoraggio, che sono già integrati o facilmente aggiungibili a Istio. Mostreremo come utilizzare strumenti come Prometheus, Jaeger e Grafana in combinazione con la scalabilità di OpenShift per gestire senza sforzo l'architettura a microservizi.
- Passeremo dal monitoraggio e dalla gestione degli errori all'introdurre errori intenzionalmente nel sistema. In altre parole, impareremo a fare fault injection senza modificare il codice sorgente, il che è molto importante dal punto di vista del testing—poiché se si modifica il codice, si rischia di introdurre ulteriori errori.
Infine, nel post finale su Istio Service Mesh:
- Passeremo al Lato Scuro. Più precisamente, impareremo a utilizzare lo schema Dark Launch, quando il codice viene implementato e testato direttamente sui dati di produzione, senza influenzare il funzionamento del sistema. Qui entra in gioco la capacità di Istio di separare il traffico. La possibilità di eseguire test su dati di produzione dal vivo, senza influire sul funzionamento del sistema di produzione, è il modo più convincente di verifica.
- A partire dal Dark Launch, mostreremo come utilizzare il modello Canary Deployment per ridurre i rischi e semplificare l'inserimento di nuovo codice. La Canary Deployment in sé non è certo una novità, ma Istio consente di implementare questo schema semplicemente tramite file YAML non complessi.
- Infine, mostreremo come utilizzare Istio Egress per consentire l'accesso ai servizi a coloro che si trovano al di fuori dei vostri cluster, per sfruttare le funzionalità di Istio nel lavoro con Internet.
Quindi, partiamo...
Strumenti di monitoraggio e gestione di Istio: tutto il necessario per coordinare i microservizi nella rete di servizi .
Che cos'è la rete di servizi Istio
La rete di servizi implementa per un gruppo di servizi funzioni come monitoraggio del traffico, controllo degli accessi, scoperta, sicurezza, tolleranza ai guasti e altre utilità. Istio consente di fare tutto questo senza alcuna modifica al codice dei servizi stessi. Qual è il segreto di questo incanto? Istio collega un proprio proxy a ciascun servizio sotto forma di container sidecar (sidecar è un carrello per motociclette), quindi tutto il traffico verso quel servizio passa attraverso il proxy, che decide, in base alle politiche impostate, come, quando e se quel traffico deve raggiungere il servizio. Istio consente anche di implementare tecniche avanzate di DevOps, come le canary deployments, i circuit breakers, il fault injection e molte altre.
Come Istio lavora con i container e Kubernetes
La rete di servizi Istio è un'implementazione sidecar di tutto ciò che serve per costruire e gestire microservizi: monitoraggio, tracciamento, circuit breakers, instradamento, bilanciamento del carico, fault injection, ripetizioni, timeout, mirroring, controllo degli accessi, limitazione della velocità e molto altro. E sebbene oggi esistano molte librerie per implementare queste funzionalità direttamente nel codice, Istio vi consente di ottenere tutto ciò senza modificare il vostro codice.
Secondo il modello sidecar, Istio viene eseguito in un container Linux, che si trova nello stesso -pod del servizio controllato e inietta (inject) ed estrae (extract) funzionalità e informazioni in base alla configurazione specificata. Sottolineiamo, si tratta della vostra configurazione personale, e vive al di fuori del vostro codice. Pertanto, il codice diventa molto più semplice e conciso.
È importante notare che l'aspetto operativo dei microservizi non è affatto legato al codice stesso, il che significa che la loro gestione può essere tranquillamente affidata agli specialisti IT. In effetti, perché uno sviluppatore dovrebbe occuparsi di circuit breaker e fault injection? Rispondere sì, ma gestirli e crearli? Eliminando tutto ciò dal codice, i programmatori potranno concentrarsi completamente sulle funzionalità applicative. Inoltre, il codice stesso diventerà più corto e semplice.
Service Mesh
Istio, che implementa funzioni di gestione dei microservizi al di fuori del loro codice, è appunto il concetto di Service Mesh. In altre parole, è un insieme coordinato di uno o più binari che formano una rete di funzioni di rete.
Come Istio lavora con i microservizi
Ecco come funzionano i container sidecar in relazione a e visto dall'alto: avviate un'istanza di Minishift, create un progetto per Istio (chiamiamolo "istio-system"), installate e avviate tutti i componenti associati a Istio. Poi, mentre create progetti e pod, aggiungete informazioni di configurazione ai vostri deployment, e i vostri pod inizieranno a utilizzare Istio. In modo semplificato, il diagramma appare così:
Ora è possibile modificare le impostazioni di Istio per organizzare, ad esempio, fault injection, supporto o altre funzionalità di Istio, il tutto senza toccare il codice delle applicazioni stesse. Supponiamo che vogliate reindirizzare tutto il traffico web degli utenti del vostro cliente più grande (Foo Corporation) a una nuova versione del sito. È sufficiente creare una regola di routing di Istio che cerchi @foocorporation.com nell'identificatore dell'utente e compia il relativo reindirizzamento. Per tutti gli altri utenti, non cambierà nulla. Nel frattempo, potrete testare tranquillamente la nuova versione del sito. E notate che per questo non è necessario coinvolgere gli sviluppatori.
E costerà molto?
Assolutamente no. Istio funziona abbastanza velocemente, è scritto in e crea un sovraccarico molto ridotto. Inoltre, la possibile perdita di prestazioni online è compensata dall'aumento della produttività degli sviluppatori. Almeno in teoria: non dimenticate che il tempo degli sviluppatori ha un costo. Per quanto riguarda i costi software, Istio è un software open source, quindi può essere ottenuto e utilizzato gratuitamente.
Imparate da soli
Il team Red Hat Developer Experience ha sviluppato una pratica approfondita su Istio (in inglese). Funziona su Linux, MacOS e Windows, e il codice è disponibile in versioni per Java e Node.js.
10 lezioni interattive su Istio
Modulo 1 — Iniziale
Introduzione a Istio
30 minuti
Scopriamo il Service Mesh, impariamo a installare Istio in un cluster Kubernetes OpenShift.
Distribuzione di microservizi in Istio
30 minuti
Utilizziamo Istio per distribuire tre microservizi con Spring Boot e Vert.x.
Modulo 2 – Intermedio
Monitoraggio e tracciamento in Istio
60 minuti
Esploriamo gli strumenti di monitoraggio integrati di Istio, metriche configurabili, nonché OpenTracing tramite Prometheus e Grafana.
Routing semplice in Istio
60 minuti
Impariamo a gestire il routing in Istio utilizzando regole semplici.
Regole di routing avanzate
60 minuti
Scopriamo il routing intelligente in Istio, gestione degli accessi, bilanciamento del carico e limitazione della velocità.
Modulo 3 – Esperto
Fault Injection in Istio
60 minuti
Esploriamo scenari di gestione dei guasti in applicazioni distribuite, creando errori HTTP e ritardi di rete, e impariamo a applicare il chaos engineering per ripristinare l'ambiente.
Circuit Breaker in Istio
30 minuti
Installiamo Siege per testare la pressione dei siti e impariamo a garantire la resilienza del backend tramite retry, circuit breaker e pool ejection.
Egress e Istio
10 minuti
Utilizziamo le rotte Egress per creare regole di interazione tra servizi interni e API e servizi esterni.
Istio e Kiali
15 minuti
Impariamo a utilizzare Kiali per ottenere una panoramica del service mesh e studiare il flusso di richieste e dati.
Mutual TLS in Istio
15 minuti
Creiamo un Istio Gateway e un VirtualService, quindi approfondiamo il mutual TLS (mTLS) e le sue configurazioni.
Modulo 3.1 — Approfondimento: Istio Service Mesh per microservizi
Di cosa parla il libro:
- Cosa sono i service mesh.
- Il sistema Istio e il suo ruolo nell'architettura dei microservizi.
- Utilizzo di Istio per risolvere le seguenti problematiche:
- Failover;
- Routing;
- Testing del caos;
- Sicurezza;
- Raccolta di telemetria tramite tracciamento, metriche e Grafana.
Serie di articoli sui service mesh e Istio
Provalo da solo
Questa serie di post non ha l'obiettivo di fornire un'immersione profonda nel mondo di Istio. Vogliamo solo presentarvi il concetto stesso e, magari, ispirarvi a provare Istio da soli. Potete farlo completamente gratuitamente, e Red Hat fornisce tutti gli strumenti necessari per iniziare a esplorare OpenShift, Kubernetes, i container Linux e Istio, ovvero: , e altre risorse sul nostro . Non aspettate, iniziate oggi stesso!
Regole di routing di Istio: indirizziamo le richieste di servizio dove necessario
e gestiscono perfettamente in modo che le richieste a siano instradate verso i pod corretti. Questa è una delle ragioni principali per cui esiste Kubernetes: instradamento e bilanciamento del carico. E se avete bisogno di un instradamento più preciso e sofisticato? Ad esempio, per utilizzare simultaneamente due versioni di un microservizio. Come possono aiutare le regole di instradamento di Istio?
Le regole di instradamento sono le normative che, di fatto, determinano la scelta del percorso. Qualunque sia il livello di complessità del sistema, il principio generale di funzionamento di queste regole rimane semplice: le richieste vengono instradate in base a determinati parametri e valori degli header HTTP.
Diamo un'occhiata a degli esempi:
Kubernetes per impostazione predefinita: semplice '50 a 50'
Nel nostro esempio mostreremo come utilizzare simultaneamente in OpenShift due versioni dello stesso microservizio, chiamandole v1 e v2. Ogni versione viene eseguita nel proprio pod Kubernetes, e per impostazione predefinita qui si utilizza un instradamento ciclico bilanciato uniformemente (evenly balanced round robin routing). Ogni pod riceve la sua quota di richieste in base al numero delle sue istanze del microservizio, in altre parole, delle repliche. Istio consente di modificare manualmente questo bilanciamento.
Supponiamo di aver distribuito su OpenShift due versioni del nostro servizio di raccomandazione, recommendation-v1 e recommendation-v2.
In figura 1 si può vedere che quando ogni servizio è rappresentato da un'istanza, le richieste si alternano uniformemente tra di essi: 1-2-1-2-… Questo è il modo in cui funziona l'instradamento di Kubernetes per impostazione predefinita:
Distribuzione pesata tra le versioni
In figura 2 si mostra cosa accade se si aumenta il numero di repliche del servizio v2 da una a due (questo avviene con il comando oc scale —replicas=2 deployment/recommendation-v2). Come possiamo vedere, le richieste tra v1 e v2 ora si dividono nel rapporto 'uno a tre': 1-2-2-1-2-2-…:
Ignora la versione con Istio
Istio consente di modificare facilmente la distribuzione delle richieste come desideriamo. Ad esempio, possiamo inviare tutto il traffico solo a recommendation-v1 utilizzando il seguente file yaml di Istio:
Qui bisogna prestare attenzione a questo: i pod vengono selezionati in base alle etichette. Nel nostro esempio, utilizziamo l'etichetta v1. Il parametro 'weight: 100' significa che il 100% del traffico sarà instradato verso tutti i pod del servizio che hanno l'etichetta v1.
Distribuzione direttiva tra le versioni (Canary Deployment)
Successivamente, utilizzando il parametro weight, possiamo indirizzare il traffico a entrambi i pod, ignorando il numero di istanze di microservizi in esecuzione in ciascuno di essi. Ad esempio, qui stiamo in modo direttivo portando il 90% del traffico su v1 e il 10% su v2:
Instradamento separato per utenti mobili
Infine, mostreremo come instradare forzatamente il traffico degli utenti mobili verso il servizio v2 e tutti gli altri verso v1. A questo scopo analizziamo il valore user-agent nell'header della richiesta usando espressioni regolari:
Ora tocca a te
L'esempio con espressioni regolari per analizzare gli header dovrebbe motivarvi a esplorare le proprie varianti di applicazione delle regole di instradamento di Istio. Vale la pena ricordare che qui si aprono possibilità molto ampie, in quanto i valori degli header possono essere formati nel codice sorgente delle applicazioni.
E ricordate che Ops, non Dev
Tutto ciò che abbiamo mostrato negli esempi sopra viene realizzato senza alcuna modifica al codice sorgente, fatta eccezione per i casi in cui è necessario formare header specifici delle richieste. Istio sarà utile sia per gli sviluppatori, che potranno utilizzarlo nella fase di testing, sia per gli specialisti della gestione dei sistemi IT, che ne trarranno grandi benefici in produzione.
Quindi ripetiamo il leitmotiv di questa serie di post: non è necessario modificare il proprio codice. Non è necessario costruire nuove immagini o avviare nuovi container. Tutto ciò viene realizzato al di fuori del codice.
Metti in moto l'immaginazione
Basta immaginare quali opportunità si aprono con l'analisi degli header tramite espressioni regolari. Vuoi reindirizzare il tuo cliente più grande a una versione speciale dei tuoi ? Легко! Нужна отдельная версия для браузера Chrome? Не проблема! Вы можете маршрутизировать трафик практически по любой его характеристике.
Provalo da solo
Leggere di Istio, Kubernetes e OpenShift è una cosa, ma perché non provare a fare tutto con le tue mani? Il team ho preparato una guida dettagliata (in inglese) che ti aiuterà a comprendere rapidamente queste tecnologie. La guida è anche 100% open source, quindi è disponibile pubblicamente. Il file funziona su macOS, Linux e Windows, e il codice sorgente è disponibile nelle versioni Java e node.js (presto saranno disponibili versioni in altre lingue). Basta aprire il relativo repository git nel tuo browser .
Nel prossimo post: affrontiamo i problemi con stile
Oggi hai visto di cosa sono capaci le regole di instradamento di Istio. Ora immagina tutto ciò applicato alla gestione degli errori. Di questo parleremo nel prossimo post.
Fonte: habr.com
