Istio è un livello di service mesh open source e configurabile che connette, monitora e protegge i container in un cluster Kubernetes. Attualmente, Istio è compatibile nativamente solo con Kubernetes, ma la sua natura open source permette a chiunque di scrivere estensioni che abilitano l'esecuzione di Istio su qualsiasi software cluster. Oggi ci concentreremo sull'uso di Istio con Kubernetes, il suo caso di utilizzo più diffuso.

Kubernetes è uno strumento per l'orchestrazione di container e l'unità di base di Kubernetes è il nodo. Un nodo è costituito da uno o più container, insieme a file system o altri componenti. Un'architettura di microservizi potrebbe avere una dozzina di nodi differenti, ognuno dei quali rappresenta microservizi diversi. Kubernetes gestisce la disponibilità e l'uso delle risorse dei nodi, aggiungendo i pod se la domanda aumenta con pod autoscaler. Istio immette ulteriori container nel pod per aggiungere sicurezza, gestione e monitoraggio.

Poiché è open source, è possibile eseguire Istio su qualsiasi provider di cloud pubblico che lo supporti e su qualsiasi cloud privato con amministratori disponibili.

Il seguente video illustra più in dettaglio i concetti base di Istio:

Quando le organizzazioni passano ai microservizi, devono supportare dozzine o centinaia di applicazioni specifiche. Gestire questi endpoint separatamente significa supportare un gran numero di macchine virtuali o VM, compresa la richiesta. Un software cluster come Kubernetes può creare i pod e ridimensionarli, ma Kubernetes non fornisce instradamento, regole del traffico o strumenti di monitoraggio o debug validi.

Immettere la service mesh.

Con l'aumentare del numero dei servizi, crescono esponenzialmente anche le modalità potenziali di comunicazione. Due servizi hanno solo due percorsi di comunicazione. Tre servizi ne hanno sei, mentre 10 servizi ne hanno 90. Una service mesh fornisce un unico modo per configurare questi percorsi di comunicazione creando una politica per la comunicazione.

Una service mesh gestisce i servizi e indirizza il traffico delle comunicazioni secondo una configurazione predefinita. Ciò significa che invece di configurare un container in esecuzione (o di scrivere il codice per farlo), un amministratore può fornire la configurazione alla service mesh, che completerà l'attività. Questo in precedenza era sempre necessario con i server web e la comunicazione service-to-service.

Il modo più comune per raggiungere questo obiettivo in un cluster è quello di utilizzare 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 è basato su Kubernetes e aggiunge container sostanzialmente invisibili al programmatore e all'amministratore. Tali container, definiti "sidecar", agiscono da "tramite", gestendo il traffico e monitorando le interazioni tra i componenti. I due lavorano in combinazione in tre modalità: configurazione, monitoraggio e gestione.

Configurazione

Il metodo principale per impostare la configurazione con Kubernetes è rappresentato dal comando kubectl, comunemente "kubectl -f", dove il file è un file YAML. Gli utenti Istio possono eseguire tipi di file YAML nuovi e differenti con kubectl oppure utilizzare il nuovo comando ioctl opzionale.

Monitoraggio

Con Istio puoi facilmente monitorare l'integrità delle tue applicazioni in esecuzione con Kubernetes. Gli strumenti di Istio permettono di gestire e visualizzare l'integrità delle applicazioni, fornendo più insight rispetto al semplice monitoraggio generale di cluster e nodi fornito da Kubernetes.

Gestione

Poiché l'interfaccia di Istio è essenzialmente la stessa di Kubernetes, per gestirla non sono richieste ulteriori competenze. Infatti, Istio consente all'utente di creare politiche che influenzano e gestiscono l'intero cluster Kubernetes, riducendo il tempo di gestione di ogni cluster ed eliminando al contempo la necessità di un codice di gestione personalizzato.

I principali vantaggi di una service mesh includono funzionalità migliorate di debug, monitoraggio, instradamento, sicurezza e utilizzo efficace. Istio quindi gestirà un gruppo di servizi più ampio con minore sforzo.

Debug migliorato

Supponiamo, ad esempio, che un servizio abbia più dipendenze. Il servizio pay_claim di una compagnia di assicurazioni richiama il servizio deductible_amt, che richiama il servizio is_member_covered, e così via. Una catena di dipendenze complessa potrebbe avere 10 o 12 chiamate di servizi. In caso di errore di uno di questi 12 servizi, si verificherà una serie di errori a cascata che causerà un errore di tipo 500, 400 o forse di mancata risposta.

Per effettuare il debug di questa serie di chiamate, è possibile utilizzare una traccia di stack. Sul frontend, gli sviluppatori lato client possono visualizzare quali elementi vengono rifiutati dai server web, in quale ordine, ed esaminarli. I programmatori di frontend possono ottenere un diagramma a cascata per assistenza nel debug.

Quello che l'esempio non mostra è cosa succede nel data center, in che modo il callback=parselLotamaAudiences richiama altri quattro servizi Web e quali rispondono più lentamente. In seguito vedremo come Istio fornisca strumenti per tracciare le chiamate delle funzioni in un diagramma molto simile a questo.

Monitoraggio e osservabilità

I team DevOps e l'amministrazione IT possono avere la necessità di osservare il traffico per esaminare la latenza, il time-in-service, gli errori come percentuale di traffico e così via. Spesso necessitano di un dashboard. Un dashboard fornisce una visualizzazione della somma o della media dii quelle metriche nel tempo - a volte con la possibilità di eseguire il "drill down" ad uno specifico nodo, servizio o pod. Kubernetes non fornisce questa funzionalità in modo nativo.

Politica

Per impostazione predefinita, Kubernetes consente a ogni pod di inviare il traffico a ogni altro pod. Istio consente agli amministratori di creare una politica per limitare i servizi che possono interagire tra loro. Così, ad esempio, i servizi possono richiamare solo altri servizi con dipendenze reali. Un'altra politica per mantenere attivi i servizi è un limite di percentuale, che impedirà al traffico in eccesso di intasare un servizio ed eviterà gli attacchi DoS (Denial of Service).

Instradamento e bilanciamento del carico

Per impostazione predefinita, Kubernetes fornisce un bilanciamento del carico round-robin. Se sono disponibili sei pod che forniscono un microservizio, Kubernetes fornirà una funzione di bilanciamento del carico, o "servizio", che invia richieste a ogni pod in ordine crescente e ciclico. Ma, a volte, un'azienda implementerà diverse versioni dello stesso servizio in produzione.

L'esempio più semplice è la distribuzione blu/verde. In questo caso, il software potrebbe creare una versione completamente nuova dell'applicazione in produzione, senza indirizzare gli utenti di produzione a questa applicazione. Una volta promossa la nuova versione, l'azienda può mantenere i vecchi server in funzione per accelerare lo switchback in caso di errore.

Con Istio, questa operazione è semplice come utilizzare i tag in un file di configurazione. Gli amministratori possono anche utilizzare le etichette per indicare a quale tipo di servizio connettersi e creare regole in base alle intestazioni. Così, ad esempio, gli utenti beta possono essere instradati a un pod "canary" con la build migliore e più recente, mentre gli utenti regolari vanno alla build di produzione stabile.

Interruzione del circuito

Se un servizio è sovraccarico o indisponibile, le richieste aggiuntive avranno esito negativo, continuando a sovraccaricare il sistema. Poiché Istio tiene traccia di errori e ritardi, può forzare una pausa - consentendo il ripristino di un servizio - dopo un numero specifico di richieste impostato dalla politica. È possibile far rispettare questa politica in tutto il cluster, creando un piccolo file di testo e indicando a Istio di utilizzarlo come nuova politica.

Sicurezza

Istio fornisce identità, politica e crittografia per impostazione predefinita, oltre alle funzioni AAA (Authentication, Authorization, Audit - Autenticazione, Autorizzazione, Audit). Eventuali pod gestiti che comunicano tra loro utilizzeranno il traffico codificato, impedendo qualsiasi intrusione. Il servizio di identità, unito alla crittografia, assicura che nessun utente non autorizzato possa eseguire chiamate di servizio "fake" o "spoof". AAA fornisce ai professionisti della sicurezza e delle operazioni gli strumenti necessari per attività di monitoraggio meno sovraccariche.

Amministrazione semplificata

Le applicazioni tradizionali richiedono ancora le funzioni di identificazione, creazione delle politiche e sicurezza offerte da Istio. Ciò ha portato i programmatori e gli amministratori a utilizzare un livello di astrazione errato, reimplementando le stesse regole di sicurezza più volte per ogni servizio. Istio consente loro di lavorare al giusto livello, impostando una politica per il cluster tramite un unico pannello di controllo.