🥇Torna ai microservizi con Istio. Parte 1

Nota di traduzione.: I service mesh sono sicuramente una soluzione attuale nell'infrastruttura moderna per applicazioni che seguono un'architettura a microservizi. Sebbene Istio possa essere noto a molti ingegneri DevOps, è un prodotto piuttosto nuovo che, essendo complesso in termini di funzionalità offerte, può richiedere tempo significativo per essere familiarizzato. L'ingegnere tedesco Rinor Maloku, responsabile del cloud computing per grandi clienti presso la compagnia di telecomunicazioni Orange Networks, ha scritto un ottimo ciclo di materiali che permettono di approfondire Istio in modo piuttosto rapido. Inizia il suo racconto spiegando cosa può fare Istio e come si possa rapidamente vedere con i propri occhi.

Istio — Un progetto Open Source, sviluppato in collaborazione tra team di Google, IBM e Lyft. Risolve le complessità che sorgono nelle applicazioni basate su microservizi, come ad esempio:

Gestione del traffico: timeout, retry, bilanciamento del carico;
Sicurezza: autenticazione e autorizzazione dell'utente finale;
Osservabilità: tracciamento, monitoraggio, registrazione.

Tutti questi problemi possono essere risolti a livello di applicazione, ma dopo questo i tuoi servizi smetteranno di essere "micro". Tutti gli sforzi aggiuntivi per risolvere questi problemi rappresentano un dispendio di risorse per l'azienda che potrebbero essere impiegate direttamente per il valore commerciale. Consideriamo un esempio:

Project Manager: Quanto tempo ci vuole per aggiungere una funzione di feedback?
Sviluppatore: Due sprint.
PM: Cosa?.. Ma è solo CRUD!
S: Realizzare il CRUD è la parte semplice del lavoro, ma dovremo anche autenticare e autorizzare utenti e servizi. Poiché la rete è inaffidabile, sarà necessario implementare retry e anche il pattern del circuit breaker nei client. Inoltre, per garantire che l'intero sistema non vada in crash, serviranno timeout e bulkheads (per maggiori dettagli sui due pattern menzionati, vedere più avanti nell'articolo – nota del traduttore), e per rilevare i problemi saranno necessari monitoraggio, tracciamento, […]
PM: Oh, allora semplicemente inseriamo questa funzionalità nel servizio Product.

Penso che l'idea sia chiara: il volume di passaggi e sforzi necessari per aggiungere un servizio è enorme. In questo articolo, esamineremo come Istio elimina tutte le complessità sopra menzionate (non rilevanti per la logica aziendale) dai servizi.

Nota: L'articolo presuppone che tu abbia conoscenze pratiche su Kubernetes. In caso contrario, ti consiglio di leggere la mia introduzione a Kubernetes e solo dopo questo continuare a leggere il materiale presente.

L'idea di Istio

In un mondo senza Istio, un servizio effettua richieste dirette a un altro e, in caso di errore, il servizio deve gestirlo autonomamente: riprovare, prevedere un timeout, aprire un circuit breaker, e così via.

Il traffico di rete in Kubernetes

Istio offre una soluzione specializzata, completamente separata dai servizi e che funziona intervenendo nelle interazioni di rete. In questo modo realizza:

Resilienza: basandosi sul codice di stato nella risposta, comprende se si è verificato un errore nella richiesta e la ripete.
Distribuzioni canary: reindirizza solo una percentuale fissa di richieste alla nuova versione del servizio.
Monitoraggio e metriche: quanto tempo ha impiegato il servizio per rispondere?
Tracciamento e osservabilità: aggiunge intestazioni speciali a ogni richiesta e ne esegue la tracciatura nel cluster.
Sicurezza: estrae il token JWT, autentica e autorizza gli utenti.

Queste sono solo alcune delle possibilità (veramente solo alcune!) per incuriosirti. Ora immergiamoci nei dettagli tecnici!

Architettura di Istio

Istio intercetta tutto il traffico di rete e applica su di esso un insieme di regole, inserendo un proxy intelligente in ogni pod sotto forma di container sidecar. I proxy, che attivano tutte le funzionalità, costituiscono Data Plane, e possono essere configurati dinamicamente tramite Control Plane.

Data Plane

I proxy inseriti nei pod permettono a Istio di soddisfare facilmente le nostre esigenze. Ad esempio, verifichiamo le funzionalità di retry e circuit breaker.

Come sono implementati i retry e il circuit breaking in Envoy

Riassumendo:

Envoy (si parla del proxy situato nel container sidecar, che si distribuisce anche come prodotto separato — nota del traduttore.) invio della richiesta al primo esemplare del servizio B e si verifica l'errore.
Envoy Sidecar tenta nuovamente (retry). (1)
La richiesta con errore viene restituita al proxy che l'ha chiamata.
Così si apre il Circuit Breaker e viene chiamato il servizio successivo per le richieste successive. (2)

Questo significa che non dovrete utilizzare un'altra libreria Retry, non dovrete implementare il Circuit Breaking e il Service Discovery nel linguaggio di programmazione X, Y o Z. Tutto questo e molto altro è disponibile out-of-the-box in Istio e non richiede nessuna modifica del codice.

Ottimo! Ora potreste voler intraprendere un viaggio con Istio, ma ci sono ancora alcuni dubbi e domande aperte. Se si tratta di una soluzione universale per ogni occasione, allora sorgerebbe un sospetto legittimo: infatti, tutte queste soluzioni si rivelano in realtà inadatte a qualsiasi caso.

E finalmente vi chiederete: "È configurabile?"

Ora siete pronti per il viaggio in mare — e facciamo conoscenza con il Control Plane.

Control Plane

È composto da tre componenti: Pilot, Mixer e Citadel, — che, collaborando, configurano gli Envoy per la roteazione del traffico, applicano politiche e raccolgono dati telemetrici. Schematizzando, tutto ciò appare così:

Interazione del Control Plane con il Data Plane

Gli Envoy (cioè il data plane) sono configurati tramite Kubernetes CRD (Custom Resource Definitions), definiti da Istio e specificamente progettati per questo scopo. Per voi questo significa che vengono presentati come una risorsa in Kubernetes con una sintassi familiare. Dopo la creazione, questa risorsa sarà identificata dal control plane e applicata agli Envoy.

Relazione dei servizi con Istio

Abbiamo descritto la relazione di Istio con i servizi, ma non il contrario: come si rapportano i servizi a Istio?

A dire il vero, ai servizi è noto della presenza di Istio quanto ai pesci — dell'acqua, quando si chiedono: "Cos'è davvero l'acqua?".

Illustrazione Victoria Dimitrakopoulos: — Com'è l'acqua? — Cos'è davvero l'acqua?

Così potete prendere un cluster funzionante e dopo il deployment dei componenti di Istio, i servizi al suo interno continueranno a funzionare, e dopo la rimozione di questi componenti — tutto tornerà a posto. È ovvio che in questo modo perderete le capacità fornite da Istio.

Abbastanza teoria — ora mettiamo in pratica queste conoscenze!

Istio nella pratica

Istio richiede un cluster Kubernetes, nel quale siano disponibili almeno 4 vCPU e 8 GB di RAM. Per avviare rapidamente un cluster e seguire le istruzioni dell'articolo, consiglio di utilizzare Google Cloud Platform, che offre ai nuovi utenti 300 € gratis.

Dopo aver creato il cluster e configurato l'accesso a Kubernetes tramite l'utility da riga di comando, è possibile installare Istio tramite il gestore di pacchetti Helm.

Installazione di Helm

Installa il client Helm sul tuo computer, come indicato in documentazione ufficiale. Lo utilizzeremo per generare modelli per l'installazione di Istio nella sezione seguente.

Installazione di Istio

Scarica le risorse Istio da l'ultima versione disponibile (il link originale per la versione 1.0.5 è stato aggiornato, quindi ora è 1.0.6 — nota del traduttore), estrae il contenuto in una directory che d'ora in poi chiamerò [istio-resources].

Per facilitare l'identificazione delle risorse Istio, crea uno spazio dei nomi nel cluster K8s istio-system:

$ kubectl create namespace istio-system

Completa l'installazione, accedendo alla directory [istio-resources] ed eseguendo il comando:

$ helm template install/kubernetes/helm/istio 
  --set global.mtls.enabled=false 
  --set tracing.enabled=true 
  --set kiali.enabled=true 
  --set grafana.enabled=true 
  --namespace istio-system > istio.yaml

Questo comando genererà i componenti chiave di Istio nel file istio.yaml. Abbiamo modificato il modello standard per adattarlo alle nostre esigenze, specificando i seguenti parametri:

global.mtls.enabled impostato su false (cioè l'autenticazione mTLS è disattivata — nota del traduttore), per semplificare il nostro processo di apprendimento;
tracing.enabled attiva il tracciamento delle richieste tramite Jaeger;
kiali.enabled installa Kiali nel cluster per visualizzare i servizi e il traffico;
grafana.enabled installa Grafana per visualizzare le metriche raccolte.

Applicheremo le risorse generate con il comando:

$ kubectl apply -f istio.yaml

L'installazione di Istio nel cluster è completa! Attendi fino a quando tutti i pod nello spazio dei nomi istio-system saranno in stato Esecuzione o Completed, eseguendo il comando qui sotto:

$ kubectl get pods -n istio-system

Ora siamo pronti a proseguire nella sezione successiva, dove lanceremo e avvieremo l'applicazione.

Architettura dell'applicazione Sentiment Analysis

Utilizzeremo un esempio di applicazione microservizi di Sentiment Analysis, già menzionata in un articolo introduttivo su Kubernetes. È piuttosto complessa per dimostrare le capacità di Istio nella pratica.

L'applicazione è composta da quattro microservizi:

Servizio SA-Frontend, che gestisce il frontend dell'applicazione su Reactjs;
Servizio SA-WebApp, che gestisce le richieste di Sentiment Analysis;
Servizio SA-Logic, che esegue il vero analisi del sentiment;
Servizio SA-Feedback, che raccoglie feedback dagli utenti sulla precisione dell'analisi effettuata.

Nello schema oltre ai servizi vediamo anche l'Ingress Controller, che in Kubernetes instrada le richieste in ingresso verso i corrispondenti servizi. In Istio viene utilizzata una concezione simile nell'ambito dell'Ingress Gateway, di cui seguiranno ulteriori dettagli.

Avvio dell'applicazione con il proxy di Istio

Per ulteriori operazioni menzionate nell'articolo, clonati il repository istio-mastery. Contiene l'applicazione e i manifesti per Kubernetes e Istio.

Inserimento dei sidecar

L'inserimento può essere effettuato installati automaticamente o mano. Per l'inserimento automatico dei container sidecar sarà necessario impostare una label allo spazio dei nomi istio-injection=enabled, il che si fa con il seguente comando:

$ kubectl label namespace default istio-injection=enabled
namespace/default labeled

Ora ogni pod che verrà distribuito nello spazio dei nomi predefinito (default) riceverà il proprio container sidecar. Per assicurarci di ciò, distribuiamo un'applicazione di test, accedendo alla directory radice del repository . In questo ramo il codice del frontend è stato modificato per reindirizzare gli utenti a Auth0 per l'autenticazione e utilizzare il token JWT nelle richieste ad altri servizi. Ultimo, implementato nel seguente modo ( ed eseguendo il seguente comando:

$ kubectl apply -f resource-manifests/kube
persistentvolumeclaim/sqlite-pvc created
deployment.extensions/sa-feedback created
service/sa-feedback created
deployment.extensions/sa-frontend created
service/sa-frontend created
deployment.extensions/sa-logic created
service/sa-logic created
deployment.extensions/sa-web-app created
service/sa-web-app created

Dopo aver distribuito i servizi, verifichiamo che i pod abbiano due container (uno con il servizio e l'altro con il suo sidecar), eseguendo il comando kubectl get pods e verificando che nella colonna READY sia indicato il valore 2/2, che simboleggia che entrambi i container sono in esecuzione:

$ kubectl get pods
NAME                           READY     STATUS    RESTARTS   AGE
sa-feedback-55f5dc4d9c-c9wfv   2/2       Running   0          12m
sa-frontend-558f8986-hhkj9     2/2       Running   0          12m
sa-logic-568498cb4d-2sjwj      2/2       Running   0          12m
sa-logic-568498cb4d-p4f8c      2/2       Running   0          12m
sa-web-app-599cf47c7c-s7cvd    2/2       Running   0          12m

Visivamente si presenta in questo modo:

Proxy Envoy in uno dei pod

Ora che l'applicazione è attiva e funzionante, dobbiamo consentire al traffico in ingresso di raggiungere l'applicazione.

Ingress Gateway

La migliore pratica per ottenere ciò (consentire il traffico nel cluster) è attraverso Ingress Gateway in Istio, che si trova ai "confini" del cluster e permette di attivare per il traffico in ingresso funzioni di Istio come il routing, il bilanciamento del carico, la sicurezza e il monitoraggio.

Il componente Ingress Gateway e il servizio che lo espone all'esterno sono stati installati nel cluster durante l'installazione di Istio. Per scoprire l'indirizzo IP esterno del servizio, eseguire:

$ kubectl get svc -n istio-system -l istio=ingressgateway
NAME                   TYPE           CLUSTER-IP     EXTERNAL-IP
istio-ingressgateway   LoadBalancer   10.0.132.127   13.93.30.120

Ci riferiremo all'applicazione tramite questo IP da ora in poi (lo chiamerò EXTERNAL-IP), quindi per comodità registriamo il valore in una variabile:

$ EXTERNAL_IP=$(kubectl get svc -n istio-system 
  -l app=istio-ingressgateway 
  -o jsonpath='{.items[0].status.loadBalancer.ingress[0].ip}')

Se provate ad accedere a questo IP tramite il browser ora, riceverete un errore di Servizio Non Disponibile, poiché per impostazione predefinita Istio blocca tutto il traffico in ingresso, finché non viene definito un Gateway.

Risorsa Gateway

Il Gateway è un CRD (Custom Resource Definition) in Kubernetes, definito dopo l'installazione di Istio nel cluster, che attiva la possibilità di specificare porte, protocolli e host per i quali vogliamo consentire il traffico in ingresso.

Nel nostro caso vogliamo consentire il traffico HTTP sulla porta 80 per tutti gli host. Questo obiettivo viene realizzato con la seguente definizione (http-gateway.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: http-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
- "*"

Questa configurazione non ha bisogno di spiegazioni, ad eccezione del selettore istio: ingressgateway. Con questo selettore possiamo specificare a quale Ingress Gateway applicare la configurazione. Nel nostro caso, si tratta del controller Ingress Gateway che è stato installato di default in Istio.

La configurazione viene applicata con il seguente comando:

$ kubectl apply -f resource-manifests/istio/http-gateway.yaml gateway.networking.istio.io/http-gateway creato

Ora il gateway consente l'accesso alla porta 80, ma non ha idea di dove instradare le richieste. Per questo serviranno Virtual Services.

Risorsa VirtualService

Il VirtualService indica all'Ingress Gateway come instradare le richieste permesse all'interno del cluster.

Le richieste alla nostra applicazione, che arrivano tramite http-gateway, devono essere inviate ai servizi sa-frontend, sa-web-app e sa-feedback:

Le rotte da configurare con i VirtualServices

Consideriamo le richieste che devono essere indirizzate a SA-Frontend:

Corrispondenza esatta del percorso / deve essere inviata a SA-Frontend per ricevere index.html;
I percorsi con prefisso /static/* devono essere inviati a SA-Frontend per ricevere file statici utilizzati nel frontend, come CSS e JavaScript;
I percorsi che rientrano nell'espressione regolare '^.*.(ico|png|jpg)$', devono essere inviati a SA-Frontend, poiché sono immagini visualizzate nella pagina.

L'implementazione viene raggiunta con la seguente configurazione (sa-virtualservice-external.yaml):

kind: VirtualService metadata: name: sa-external-services spec: hosts: - "*" gateways: - http-gateway # 1 http: - match: - uri: exact: \/ - uri: exact: \/callback - uri: prefix: \/static - uri: regex: '^.*.(ico|png|jpg) Aspetti importanti: Questo VirtualService si riferisce alle richieste che arrivano tramite http-gateway; In destination viene definito il servizio a cui vengono inviati le richieste. Nota: La configurazione sopra è memorizzata in un file sa-virtualservice-external.yaml, che contiene anche impostazioni per il routing in SA-WebApp e SA-Feedback, ma è stata abbreviata qui nell'articolo per brevità. Applichiamo il VirtualService con la chiamata: $ kubectl apply -f resource-manifests/istio/sa-virtualservice-external.yaml virtualservice.networking.istio.io/sa-external-services creato Nota: Quando applichiamo le risorse Istio, il server API di Kubernetes genera un evento, che viene ricevuto dal piano di controllo Istio, e solo dopo questa nuova configurazione viene applicata ai proxy Envoy di ogni pod. E il controller Ingress Gateway viene rappresentato da un ulteriore Envoy, configurato nel piano di controllo. In uno schema, tutto questo appare così: Configurazione di Istio-IngressGateway per il routing delle richieste L'applicazione Sentiment Analysis è diventata disponibile su http://{EXTERNAL-IP}/. Non preoccupatevi se ricevete lo stato Not Found: a volte è necessario un po' più di tempo affinché la configurazione abbia effetto e le cache di Envoy vengano aggiornate. Prima di procedere, lavorate un po' con l'applicazione per generare traffico (la sua presenza è necessaria per la chiarezza nelle azioni successive — nota del traduttore). Kiali : osservabilità Per accedere all'interfaccia amministrativa di Kiali, eseguite il seguente comando: $ kubectl port-forward $(kubectl get pod -n istio-system -l app=kiali -o jsonpath='{.items[0].metadata.name}') -n istio-system 20001 … e aprite http://localhost:20001/, accedendo con admin/admin. Qui troverete molte utilità, ad esempio per controllare la configurazione dei componenti Istio, visualizzare i servizi in base alle informazioni raccolte durante l'intercettazione delle richieste di rete, ricevere risposte a domande come «Chi contatta chi?», «Quale versione del servizio ha dei malfunzionamenti?» e così via. In generale, esplorate le possibilità di Kiali prima di passare oltre — alla visualizzazione delle metriche con Grafana. Grafana: visualizzazione delle metriche Le metriche raccolte in Istio vengono inviate a Prometheus e visualizzate con Grafana. Per accedere all'interfaccia amministrativa di Grafana, eseguite il comando sottostante, quindi aprite http://localhost:3000/: $ kubectl -n istio-system port-forward $(kubectl -n istio-system get pod -l app=grafana -o jsonpath={.items[0].metadata.name}) 3000 Cliccando nel menu Home in alto a sinistra e selezionando Istio Service Dashboard nella parte superiore sinistra, iniziate con il servizio sa-web-app, per visualizzare le metriche raccolte: Qui ci aspetta una rappresentazione vuota e completamente noiosa — la guida non approverebbe mai qualcosa del genere. Creiamo piuttosto un carico con il seguente comando: $ while true; do curl -i http://$EXTERNAL_IP/sentiment -H "Content-type: application/json" -d '{"sentence": "Amo yogobella"}'; sleep .8; done Ora abbiamo grafici molto più gradevoli e, in aggiunta, strumenti fantastici di Prometheus per il monitoraggio e Grafana per la visualizzazione delle metriche, che ci permetteranno di conoscere le prestazioni, lo stato di salute, miglioramenti/degradazioni nel funzionamento dei servizi nel tempo. Infine, diamo un'occhiata al tracciamento delle richieste nei servizi. Jaeger: tracciamento Il tracciamento ci sarà utile, perché più sono i nostri servizi, più difficile è individuare la causa di un malfunzionamento. Consideriamo un caso semplice dall'immagine qui sotto: Un esempio tipico di richiesta casualmente fallita La richiesta arriva, fallisce - qual è la causa? Il primo servizio? O il secondo? Ci sono eccezioni in entrambi - diamo un'occhiata ai log di ciascuno. Quanto spesso ti sei trovato a fare questo? Il nostro lavoro assomiglia di più a quello di detective software, piuttosto che a quello di sviluppatori... Questo è un problema comune nei microservizi e viene risolto tramite sistemi di tracciamento distribuiti, in cui i servizi si scambiano un'intestazione unica, e quindi queste informazioni vengono reindirizzate in un sistema di tracciamento, dove vengono abbinate ai dati della richiesta. Ecco un'illustrazione: Per identificare la richiesta si utilizza il TraceId In Istio viene utilizzato Jaeger Tracer, che implementa un framework OpenTracing API indipendente dai fornitori. Per accedere all'interfaccia utente di Jaeger, puoi utilizzare il seguente comando: $ kubectl port-forward -n istio-system $(kubectl get pod -n istio-system -l app=jaeger -o jsonpath='{.items[0].metadata.name}') 16686 Ora vai su http://localhost:16686/ e seleziona il servizio sa-web-app. Se il servizio non appare nel menu a discesa, genera un'attività sulla pagina e aggiornare l'interfaccia. Dopo di che, clicca sul pulsante Find Traces, che mostrerà gli ultimi tracciamenti - seleziona uno qualsiasi - verranno visualizzate informazioni dettagliate su tutti i tracciamenti: Questo tracciamento mostra: La richiesta arriva in istio-ingressgateway (questo è il primo interazione con uno dei servizi e per la richiesta viene generato un Trace ID), dopodiché il gateway indirizza la richiesta al servizio sa-web-app. Nel servizio sa-web-app la richiesta viene acquisita dal sidecar Envoy, viene creato un "figlio" nello span (quindi lo vediamo nei tracciamenti) e viene inoltrata al contenitore sa-web-app. (Span — unità logica di lavoro in Jaeger, che ha un nome, un orario di inizio operazione e una durata. Gli span possono essere nidificati e ordinati. Un grafo aciclico orientato di span forma un trace. — nota del traduttore) Qui la richiesta viene elaborata con il metodo sentimentAnalysis. Questi trace sono già stati generati dall'applicazione, cioè hanno richiesto modifiche al codice. A questo punto viene avviata una richiesta POST a sa-logic. L'ID del trace deve essere passato da sa-web-app. … Nota: Nel passaggio 4 l'applicazione deve vedere gli header generati da Istio e passarli alle richieste successive, come mostrato nell'immagine sottostante: (A) Istio è responsabile del passaggio degli header; (B) I servizi sono responsabili degli header Istio svolge il lavoro principale, poiché genera header per le richieste in entrata, crea nuovi span in ogni sidecar e li passa. Tuttavia, senza lavorare con gli header all'interno dei servizi, il percorso completo del trace della richiesta andrà perso. È necessario considerare (passare) i seguenti header: x-request-id x-b3-traceid x-b3-spanid x-b3-parentspanid x-b3-sampled x-b3-flags x-ot-span-context Non è un compito difficile, tuttavia esistono già numerose librerie — ad esempio, nel servizio sa-web-app il client RestTemplate passa questi header se si aggiungono semplicemente le librerie Jaeger e OpenTracing a le sue dipendenze. Si noti che l'applicazione Sentiment Analysis dimostra implementazioni su Flask, Spring e ASP.NET Core. Ora che è chiaro cosa otteniamo di default (o quasi "di default"), consideriamo questioni di routing fine, gestione del traffico di rete, sicurezza e così via! Nota di traduzione.: leggi al riguardo nella prossima parte dei materiali su Istio di Rinor Maloku, le cui traduzioni seguiranno nel nostro blog a breve. UPDATE (14 marzo): La seconda parte è già stata pubblicata. P.S. dal traduttore Leggi anche nel nostro blog: «Tornare ai microservizi con Istio»: parte 2 (routing, gestione del traffico), parte 3 (autenticazione e autorizzazione); «Conduit — un service mesh leggero per Kubernetes»; «Che cos'è un service mesh e perché ne ho bisogno [per un'applicazione cloud con microservizi]?»; «Guida illustrata sulla configurazione della rete in Kubernetes. Parti 1 e 2»; «Come è arrivato questo contenitore sidecar qui [in Kubernetes]?». Fonte: habr.com route: - destination: host: sa-frontend # 2 port: number: 80
Punti importanti:

Questo VirtualService si riferisce alle richieste che arrivano tramite http-gateway;
In destination viene definito il servizio a cui vengono inviati le richieste.

Nota: La configurazione sopra è memorizzata in un file sa-virtualservice-external.yaml, che contiene anche impostazioni per il routing in SA-WebApp e SA-Feedback, ma è stato abbreviato qui nell'articolo per brevità.

Applicare VirtualService richiamando:

Nota: Quando utilizziamo le risorse di Istio, il Kubernetes API Server genera un evento che viene ricevuto dal Control Plane di Istio, e solo dopo questa nuova configurazione viene applicata ai proxy server Envoy di ciascun pod. E il controller Ingress Gateway viene considerato un ulteriore Envoy, configurato nel Control Plane. Tutto ciò appare così nello schema:

Configurazione di Istio-IngressGateway per il routing delle richieste

L'applicazione Sentiment Analysis è diventata disponibile su http://{EXTERNAL-IP}/. Non preoccupatevi se ricevete lo stato Not Found: a volte è necessario un po' più di tempo affinché la configurazione abbia effetto e le cache di Envoy vengano aggiornate.

Prima di procedere, lavorate un po' con l'applicazione per generare traffico (la sua presenza è necessaria per la chiarezza nelle azioni successive — nota del traduttore).

Kiali : osservabilità

Per accedere all'interfaccia amministrativa di Kiali, eseguite il seguente comando:

… e aprite http://localhost:20001/, accedendo con admin/admin. Qui troverete molte utilità, ad esempio per controllare la configurazione dei componenti Istio, visualizzare i servizi in base alle informazioni raccolte durante l'intercettazione delle richieste di rete, ricevere risposte a domande come «Chi contatta chi?», «Quale versione del servizio ha dei malfunzionamenti?» e così via. In generale, esplorate le possibilità di Kiali prima di passare oltre — alla visualizzazione delle metriche con Grafana.

Grafana: visualizzazione delle metriche

Le metriche raccolte in Istio vengono inviate a Prometheus e visualizzate con Grafana. Per accedere all'interfaccia amministrativa di Grafana, eseguite il comando sottostante, quindi aprite http://localhost:3000/:

Cliccando nel menu Home in alto a sinistra e selezionando Istio Service Dashboard nella parte superiore sinistra, iniziate con il servizio sa-web-app, per visualizzare le metriche raccolte:

Qui ci aspetta una rappresentazione vuota e completamente noiosa — la guida non approverebbe mai qualcosa del genere. Creiamo piuttosto un carico con il seguente comando:

Ora abbiamo grafici molto più gradevoli e, in aggiunta, strumenti fantastici di Prometheus per il monitoraggio e Grafana per la visualizzazione delle metriche, che ci permetteranno di conoscere le prestazioni, lo stato di salute, miglioramenti/degradazioni nel funzionamento dei servizi nel tempo.

Infine, diamo un'occhiata al tracciamento delle richieste nei servizi.

Jaeger: tracciamento

Il tracciamento ci sarà utile, perché più sono i nostri servizi, più difficile è individuare la causa di un malfunzionamento. Consideriamo un caso semplice dall'immagine qui sotto:

Un esempio tipico di richiesta casualmente fallita

La richiesta arriva, fallisce - qual è la causa? Il primo servizio? O il secondo? Ci sono eccezioni in entrambi - diamo un'occhiata ai log di ciascuno. Quanto spesso ti sei trovato a fare questo? Il nostro lavoro assomiglia di più a quello di detective software, piuttosto che a quello di sviluppatori...

Questo è un problema comune nei microservizi e viene risolto tramite sistemi di tracciamento distribuiti, in cui i servizi si scambiano un'intestazione unica, e quindi queste informazioni vengono reindirizzate in un sistema di tracciamento, dove vengono abbinate ai dati della richiesta. Ecco un'illustrazione:

Per identificare la richiesta si utilizza il TraceId

In Istio viene utilizzato Jaeger Tracer, che implementa un framework OpenTracing API indipendente dai fornitori. Per accedere all'interfaccia utente di Jaeger, puoi utilizzare il seguente comando:

Ora vai su http://localhost:16686/ e seleziona il servizio sa-web-app. Se il servizio non appare nel menu a discesa, genera un'attività sulla pagina e aggiornare l'interfaccia. Dopo di che, clicca sul pulsante Find Traces, che mostrerà gli ultimi tracciamenti - seleziona uno qualsiasi - verranno visualizzate informazioni dettagliate su tutti i tracciamenti:

Questo tracciamento mostra:

La richiesta arriva in istio-ingressgateway (questo è il primo interazione con uno dei servizi e per la richiesta viene generato un Trace ID), dopodiché il gateway indirizza la richiesta al servizio sa-web-app.
Nel servizio sa-web-app la richiesta viene catturata dal sidecar Envoy, viene creato un "figlio" nello span (per questo lo vediamo nei tracciamenti) e viene reindirizzata nel contenitore sa-web-app. (Span — un'unità logica di lavoro in Jaeger, che ha un nome, un orario di inizio operazione e la sua durata. Gli span possono essere annidati e ordinati. Un grafo orientato aciclico di span forma il trace. — nota del traduttore)
Qui la richiesta viene elaborata con il metodo sentimentAnalysis. Questi trace sono già stati generati dall'applicazione, cioè hanno richiesto modifiche al codice.
A questo punto viene avviata una richiesta POST a sa-logic. L'ID del trace deve essere passato da sa-web-app.
…

Nota: Nel passaggio 4 l'applicazione deve vedere gli header generati da Istio e passarli alle richieste successive, come mostrato nell'immagine sottostante:

(A) Istio è responsabile del passaggio degli header; (B) I servizi sono responsabili degli header

Istio svolge il lavoro principale, poiché genera intestazioni per le richieste in arrivo, crea nuovi span in ciascun sidecar e li trasferisce. Tuttavia, senza la gestione delle intestazioni all'interno dei servizi, il percorso completo di tracciamento della richiesta sarà perso.

È necessario considerare (passare) i seguenti header:

Non è un compito difficile, tuttavia esistono già numerose librerie — ad esempio, nel servizio sa-web-app il client RestTemplate passa questi header se si aggiungono semplicemente le librerie Jaeger e OpenTracing a le sue dipendenze.

Si noti che l'applicazione Sentiment Analysis dimostra implementazioni su Flask, Spring e ASP.NET Core.

Ora che è chiaro cosa otteniamo di default (o quasi "di default"), consideriamo questioni di routing fine, gestione del traffico di rete, sicurezza e così via!

Nota di traduzione.: leggi al riguardo nella prossima parte dei materiali su Istio di Rinor Maloku, le cui traduzioni seguiranno nel nostro blog a breve. UPDATE (14 marzo): La seconda parte è già stata pubblicata.