Cos'è Istio?

Al momento della scrittura, Istio funziona in modo nativo solo con Kubernetes, ma la sua natura open source consente a chiunque di scrivere estensioni che consentono l'esecuzione di Istio su qualsiasi software cluster. Oggi ci concentriamo sull'uso di Istio con Kubernetes, il suo caso d'uso più diffuso.

Kubernetes è uno strumento di orchestrazione dei container e un'unità centrale di Kubernetes è un nodo. Un nodo è composto da uno o più container, insieme a file system o altri componenti. Un'architettura di microservizi potrebbe avere una dozzina di nodi diversi, ognuno dei quali rappresenta diversi microservizi. Kubernetes gestisce la disponibilità e il consumo di risorse dei nodi, aggiungendo pod man mano che la domanda aumenta con il programma di scalatura automatica del pod. Istio aggiunge altri container nel pod per aggiungere sicurezza, gestione e monitoraggio.

Poiché è open source, Istio può essere eseguito su qualsiasi provider di cloud pubblico che lo supporti e su qualsiasi cloud privato con amministratori disponibili.

Il video riportato di seguito spiega meglio le nozioni di base di Istio:

Quando le organizzazioni si spostano nei microservizi, devono supportare decine o centinaia di app specifiche. Gestire questi endpoint separatamente significa supportare numerose macchine virtuali o VM, inclusa la domanda. Un software cluster come Kubernetes può creare pod e scalarli, ma Kubernetes non fornisce un instradamento, regole di traffico, potenti strumenti di monitoraggio o debug.

Inserisci la mesh di servizi.

Con l’aumento del numero di servizi, il numero di potenziali modi di comunicare aumenta in modo esponenziale. Due servizi hanno solo due percorsi di comunicazione. Tre servizi ne hanno sei, mentre 10 servizi ne hanno 90. Un mesh di servizi fornisce un unico modo per configurare questi percorsi di comunicazione creando un criterio per la comunicazione.

Un mesh di servizi organizza i servizi e dirige il traffico delle comunicazioni secondo una configurazione predefinita. Significa che invece di configurare un container in esecuzione (o scrivere un codice per farlo), un amministratore può fornire la configurazione al service mesh e lasciargli completare il lavoro. Questo accadeva sempre con i server Web e la comunicazione service-to-service.

Il modo più comune per farlo in un cluster è usare il modello sidecar. Un sidecar è un nuovo container all'interno del pod che instrada e osserva il traffico delle comunicazioni tra servizi e container.

Come accennato in precedenza, Istio si sovrappone a Kubernetes, aggiungendo container invisibili al programmatore e all'amministratore. Chiamati container sidecar, questi agiscono come una persona che sta in mezzo, dirigendo il traffico e monitorando le interazioni tra i componenti. I due lavorano in combinazione in tre modi: configurazione, monitoraggio e gestione.

Il metodo principale per impostare la configurazione con Kubernetes è il comando kubectl, comunemente "kubectl -f <filename>" in cui il file è un file YAML. Gli utenti Istio possono eseguire nuovi e diversi tipi di file YAML con kubectl oppure usare il nuovo comando ioctl opzionale.

Con Istio, puoi monitorare facilmente lo stato di salute delle tue app in esecuzione con Kubernetes. Gli strumenti di Istio possono gestire e visualizzare lo stato di salute delle applicazioni, offrendo insight più dettagliati rispetto al semplice monitoraggio generale dei cluster e dei nodi fornito da Kubernetes.

Dal momento che l'interfaccia di Istio è fondamentalmente la stessa di Kubernetes, gestirla non richiede quasi nessun lavoro aggiuntivo. In effetti, Istio consente all'utente di creare politiche che influiscono e gestiscono l'intero cluster Kubernetes, riducendo i tempi di gestione di ciascun cluster eliminando la necessità di un codice di gestione personalizzato.

I principali benefici di un service mesh includono le funzionalità per migliorare il debug, il monitoraggio, l'instradamento, la sicurezza e l'uso. Vale a dire, con Istio, serve meno impegno per gestire un gruppo più ampio di servizi.

Supponiamo, ad esempio, che un servizio abbia più dipendenze. Il servizio pay_claim di una compagnia assicurativa richiama il servizio deductible_amt, che richiama il servizio is_member_covered e così via. Una catena di dipendenze complessa può avere 10 o 12 chiamate al servizio. Quando una di queste 12 chiamate non avviene, si verificherà una serie di guasti a cascata che si tradurranno in una sorta di errore 500, 400 o, forse, nell'assenza di una risposta.

Per eseguire il debug di quel set di chiamate, puoi usare qualcosa come uno stack trace. Sul front-end, gli sviluppatori lato client possono vedere quali elementi vengono estratti dai server Web, in quale ordine ed esaminarli. I programmatori front-end possono ottenere un diagramma a cascata per facilitare il debug.

Quello che l'esempio non mostra è quello che accade all'interno del data center: il modo in cui callback=parsellotamaAudiences chiama altri quattro servizi Web e quali rispondono più lentamente. Più avanti vedremo in che modo Istio fornisce strumenti per tracciare le chiamate di funzione in un diagramma molto simile a questo.

I team DevOps e l'amministrazione IT potrebbero voler osservare il traffico per vedere latenza, time-in-service, errori come percentuale del traffico e così via. Spesso vogliono vedere una dashboard. Una dashboard fornisce una visualizzazione della somma, o media, o di tali metriche nel tempo, magari con la possibilità di approfondire un nodo, servizio o pod specifico. Kubernetes non fornisce queste funzioni in modo nativo.

Per impostazione predefinita, Kubernetes consente a ogni pod di inviare traffico a tutti gli altri pod. Istio consente agli amministratori di creare una policy per limitare i servizi che possono funzionare tra loro. Quindi, ad esempio, i servizi possono chiamare solo altri servizi che sono vere dipendenze. Un'altra policy per mantenere attivi i servizi è un limite di velocità, che impedirà al traffico in eccesso di intasare un servizio e prevenire gli attacchi denial-of-service.

Per impostazione predefinita, Kubernetes fornisce un bilanciamento del carico round-robin. Se sono presenti sei pod che forniscono un microservizio, Kubernetes fornirà un bilanciatore del carico, o un servizio che invia le richieste a ciascun pod in ordine crescente e poi ricomincia da capo. Tuttavia, a volte un'azienda distribuisce versioni diverse dello stesso servizio in produzione.

L'esempio più semplice potrebbe essere una distribuzione blu o verde. In tal caso, il software potrebbe creare una versione completamente nuova dell'applicazione in produzione senza inviare utenti di produzione ad essa. Dopo aver promosso la nuova versione, l'azienda può mantenere i vecchi server per rendere rapido il passaggio in caso di guasto.

Con Istio, è semplice come usare i tag in un file di configurazione. Gli amministratori possono inoltre utilizzare le etichette per indicare a quale tipo di servizio connettersi e creare regole in base alle intestazioni. Ad esempio, gli utenti beta possono passare a un pod canary con la build più recente e migliore, mentre gli utenti regolari possono passare alla build di produzione stabile.

Se un servizio è sovraccarico o inattivo, altre richieste non hanno esisto positivo pur continuando a sovraccaricare il sistema. Dal momento che Istio tiene traccia degli errori e dei ritardi, può forzare una pausa, consentendo a un servizio di riprendersi, dopo un numero specifico di richieste impostato dalla policy. Puoi applicare questa policy all'intero cluster creando un piccolo file di testo e indicando a Istio di usarlo come nuova policy.

Per impostazione predefinita, Istio fornisce identità, policy e crittografia, insieme all'autenticazione, all'autorizzazione e alla verifica (AAA). Tutti i pod in gestione che comunicano con altri usano traffico crittografato, impedendo qualsiasi osservazione. Il servizio di identità, combinato con la crittografia, aiuta a garantire che nessun utente non autorizzato possa falsificare o "spoofare" una chiamata di servizio. AAA fornisce ai professionisti della sicurezza e delle operazioni gli strumenti necessari per il monitoraggio, con meno spese generali.

Le applicazioni tradizionali necessitano ancora delle caratteristiche di identità, policy e sicurezza offerte da Istio. Questo fa sì che i programmatori e gli amministratori lavorino al livello sbagliato di astrazione, reimplementando le stesse regole di sicurezza più e più volte per ogni servizio. Istio consente loro di lavorare al livello giusto, impostando le policy per il cluster tramite un unico pannello di controllo.