🥇Torna ai microservizi con Istio. Parte 1

Nota del traduttore.: I service mesh sono sicuramente diventati una soluzione attuale nell'infrastruttura moderna per le applicazioni basate su architettura a microservizi. Sebbene Istio possa essere familiare a molti ingegneri DevOps, è un prodotto relativamente nuovo che, essendo complesso in termini di funzionalità offerte, può richiedere un tempo significativo per essere compreso. L'ingegnere tedesco Rinor Maloku, responsabile del cloud computing per grandi clienti nella compagnia di telecomunicazioni Orange Networks, ha scritto un eccellente ciclo di articoli che permettono di immergersi rapidamente e profondamente in Istio. Inizia la sua narrazione spiegando cosa può fare Istio e come si possa dare un'occhiata, in modo semplice, a ciò che offre.

Istio — Un progetto Open Source, sviluppato in collaborazione tra i team di Google, IBM e Lyft. Risolve le complessità che si presentano 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 applicativo, ma dopo ciò i vostri servizi smetteranno di essere "micro". Ogni ulteriore sforzo per risolvere questi problemi è un costo superfluo per l'azienda, che potrebbe invece essere investito in valori aziendali diretti. Prendiamo ad esempio:

Project Manager: Quanto tempo ci vorrà per aggiungere la funzionalità di feedback?
Sviluppatore: Due sprint.
PM: Cosa?.. È solo CRUD!
S: Creare il CRUD è la parte semplice del compito, ma abbiamo anche bisogno di autenticare e autorizzare utenti e servizi. Poiché la rete è inaffidabile, sarà necessario implementare richieste ripetute, e inoltre il pattern circuit breaker nei client. Inoltre, per assicurarci che l'intero sistema non crolli, saranno necessari timeout e bulkheads (ulteriori dettagli su entrambi i pattern menzionati si trovano più avanti nell'articolo — nota del traduttore), e per poter rilevare i problemi, sarà necessaria una monitorizzazione, tracciamento, […]
PM: Oh, allora semplicemente integriamo questa funzionalità nel servizio Product.

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

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

L'idea di Istio

Nel mondo senza Istio, un servizio effettua richieste dirette a un altro servizio, e in caso di errore, il servizio deve gestire la situazione da solo: tentando di nuovo, prevedendo un timeout, attivando un circuit breaker, e così via.

Il traffico di rete in Kubernetes

Istio, invece, offre una soluzione specializzata, completamente separata dai servizi e funzionante attraverso l'intervento nelle interazioni di rete. E in questo modo attua:

Affidabilità: basandosi sul codice di stato nella risposta, comprende se si è verificato un errore nella richiesta e la ripete.
Deployment canary: reindirizza a una nuova versione del servizio solo una percentuale fissa di richieste.
Monitoraggio e metriche: in quanto tempo ha risposto il servizio?
Tracciabilità e monitoraggio: aggiunge intestazioni speciali a ciascuna richiesta e ne esegue la tracciabilità nel cluster.
Sicurezza: estrae il token JWT, autentica e autorizza gli utenti.

Queste sono solo alcune delle funzionalità (davvero solo alcune!) per stuzzicare la vostra curiosità. Ora immergiamoci nei dettagli tecnici!

Architettura di Istio

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

Data Plane

I proxy inseriti nei pod consentono a Istio di soddisfare con facilità i requisiti necessari. Ad esempio, verifichiamo le funzionalità di retry e circuit breaker.

Come i retry e il circuit breaking sono implementati in Envoy

In sintesi:

Envoy (si tratta del proxy situato nel contenitore sidecar, che viene distribuito anche come prodotto separato — nota di traduzione) invia la richiesta al primo esemplare del servizio B e si verifica un errore.
Envoy Sidecar tenta un nuovo tentativo (retry). (1)
La richiesta con errore viene restituita al proxy che l'ha inviata.
Così si apre il Circuit Breaker e viene chiamato il servizio successivo per le richieste successive. (2)

Questo significa che non sarà necessario utilizzare un'altra libreria Retry, né implementare la propria soluzione di Circuit Breaking e Service Discovery nel linguaggio di programmazione X, Y o Z. Tutto ciò e molto altro è disponibile out-of-the-box in Istio e non richiede alcuna modifica nel codice.

Ottimo! Ora potresti voler intraprendere un viaggio con Istio, ma hai ancora alcuni dubbi e domande aperte. Se si tratta di una soluzione universale per ogni situazione, sorgono legittimi sospetti: infatti, tutte le soluzioni di questo tipo si rivelano in realtà inadatte a ogni caso.

E infine chiederai: "È configurabile?"

Ora sei pronto per il viaggio marittimo - e conosciamoci con il Control Plane.

Control Plane

Esso è composto da tre componenti: Pilot, Mixer e Citadel, che in sinergia configurano gli Envoy per il routing del traffico, applicano politiche e raccolgono dati telemetrici. Schema rappresentativo di tutto questo:

Interazione del Control Plane con il Data Plane

Gli Envoy (cioè, il data plane) sono configurati tramite Kubernetes CRD (Custom Resource Definitions), definite da Istio e progettati specificamente 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à gestita dal control plane e applicata a Envoy.

La relazione dei servizi con Istio

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

A dire il vero, i servizi conoscono Istio tanto quanto i pesci conoscono l'acqua, quando si chiedono: «Cos'è veramente l'acqua?».

Illustrazione Victoria Dimitrakopoulos: — Ti piace l'acqua? — Cos'è veramente l'acqua?

In questo modo, è possibile prendere un cluster funzionante e, dopo aver distribuito i componenti di Istio, i servizi al suo interno continueranno a funzionare, e dopo la rimozione di questi componenti, tutto tornerà a funzionare. È chiaro che perderete le funzionalità offerte da Istio.

Basta teoria: mettiamo in pratica queste conoscenze!

Istio in pratica

Istio richiede un cluster Kubernetes, con almeno 4 vCPU e 8 GB di RAM disponibili. Per avviare rapidamente il 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'utilità della 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 i modelli per l'installazione di Istio nella prossima sezione.

Istio può essere installato in due modi. Puoi

Scarica le risorse Istio dalla ultima release (il link originale per la versione 1.0.5 è stato aggiornato alla versione attuale, cioè 1.0.6 - nota del traduttore), estrai il contenuto in una cartella, che in seguito 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, andando nella cartella [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 stamperà i componenti chiave di Istio nel file istio.yaml. Abbiamo modificato il modello standard secondo le nostre necessità, specificando i seguenti parametri:

global.mtls.enabled impostato su false (ossia, l'autenticazione mTLS è disabilitata - nota del traduttore.), per semplificare il nostro processo di onboarding;
tracing.enabled abilita il tracciamento delle richieste tramite Jaeger;
kiali.enabled installa Kiali nel cluster per la visualizzazione dei servizi e del traffico;
grafana.enabled installa Grafana per la visualizzazione delle metriche raccolte.

Applicheremo le risorse generate dal team:

$ kubectl apply -f istio.yaml

L'installazione di Istio nel cluster è completata! Attendere che tutti i pod nello spazio dei nomi istio-system siano in stato Esecuzione o Completato, eseguendo il comando sottostante:

$ kubectl get pods -n istio-system

Ora siamo pronti a proseguire nella prossima sezione, dove solleveremo e avvieremo l'applicazione.

Architettura dell'applicazione Sentiment Analysis

Utilizzeremo l'esempio di un'applicazione a microservizi di Sentiment Analysis, utilizzata nell'articolo introduttivo già menzionato . È abbastanza complessa da dimostrare le potenzialità di Istio nella pratica.L'applicazione è composta da quattro microservizi:

, che gestisce il frontend dell'applicazione su Reactjs;

Servizio SA-FrontendSA-WebApp
Servizio , che gestisce le richieste di Sentiment Analysis;SA-Logic
Servizio , che esegue ilsentiment analysis SA-Feedback;
Servizio SA-Feedback, che raccoglie il feedback degli utenti sulla precisione dell'analisi effettuata.

In questo schema, oltre ai servizi, vediamo anche l'Ingress Controller, che in Kubernetes instrada le richieste in ingresso verso i servizi corrispondenti. In Istio si utilizza un concetto simile all'interno della Ingress Gateway, di cui seguiranno ulteriori dettagli.

Avvio dell'applicazione con proxy di Istio

Per ulteriori operazioni menzionate nell'articolo, clona il repository istio-mastery. Esso contiene l'applicazione e i manifest per Kubernetes e Istio.

Inserimento dei sidecar

L'inserimento può avvenire automaticamente o manualmente. Per l'inserimento automatico dei contenitori sidecar, sarà necessario etichettare lo spazio dei nomi istio-injection=enabled, il che può essere fatto con il seguente comando:

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

Ora ogni pod che verrà distribuito nello spazio dei nomi predefinito (default) riceverà il suo contenitore sidecar. Per verificare ciò, andiamo a distribuire un'applicazione di test, passando alla directory radice del repository [istio-mastery] e 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 contenitori (quello del servizio e il suo sidecar), eseguendo il comando kubectl get pods e assicurandoci che nella colonna READY sia indicato il valore 2/2, che simbolizza che entrambi i contenitori sono stati avviati:

$ kubectl get pods
NOME                            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, questo appare così:

Il proxy Envoy in uno dei pod

Ora che l'applicazione è avviata e funzionante, dobbiamo consentire il traffico in ingresso nell'applicazione.

Ingress Gateway

La migliore pratica per ottenere ciò (per consentire il traffico nel cluster) è tramite Ingress Gateway in Istio, che si trova al 'confine' del cluster e consente di abilitare per il traffico in ingresso funzionalità di Istio come la gestione del traffico, il bilanciamento del carico, la sicurezza e il monitoraggio.

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

$ 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 collegheremo all'applicazione tramite questo IP e da qui in avanti (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 provi ad accedere a questo IP tramite il browser ora, riceverai un errore Service Unavailable, poiché per impostazione predefinita Istio blocca tutto il traffico in entrata, fino a quando non viene definito un Gateway.

Risorsa Gateway

Il Gateway è una CRD (Custom Resource Definition) in Kubernetes, definita dopo l'installazione di Istio nel cluster e che abilita la possibilità di specificare porte, protocolli e host per cui vogliamo consentire il traffico in entrata.

Nel nostro caso vogliamo consentire il traffico HTTP sulla porta 80 per tutti gli host. Questo obiettivo viene raggiunto 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 necessita di spiegazioni tranne che per il selettore istio: ingressgateway. Con questo selettore possiamo specificare a quale Ingress Gateway applicare la configurazione. Nel nostro caso, si tratta del controller Ingress Gateway preinstallato in Istio.

La configurazione viene applicata eseguendo 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 informazioni su dove instradare le richieste. A questo scopo sono necessari Virtual Services.

La risorsa VirtualService

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

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

Le rotte che devono essere configurate con VirtualServices

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

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

L'implementazione è realizzata 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) Punti importanti: Questo VirtualService si riferisce alle richieste che arrivano tramite http-gateway; In destination definisce il servizio a cui vengono inviati le richieste. Nota: La configurazione sopra è memorizzata nel file sa-virtualservice-external.yaml, che contiene anche le impostazioni per il routing in SA-WebApp e SA-Feedback, ma è stato abbreviato qui nell'articolo per brevità. Applichiamo VirtualService chiamando: $ 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 crea 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 è un altro Envoy configurato nel piano di controllo. Tutto questo nella scheda appare così: Configurazione di Istio-IngressGateway per il routing delle richieste L'applicazione Sentiment Analysis è diventata accessibile a http://{EXTERNAL-IP}/. Non preoccuparti se ricevi lo stato Not Found: a volte può essere necessario un po' più di tempo affinché la configurazione entri in vigore e le cache di Envoy vengano aggiornate. Prima di continuare, lavora 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, esegui 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 apri http://localhost:20001/, effettuando il login come admin/admin. Qui troverai molte funzionalità utili, ad esempio per verificare la configurazione dei componenti Istio, visualizzare i servizi sulla base delle informazioni raccolte durante l'intercettazione delle richieste di rete, ottenere risposte alle domande "Chi sta chiamando chi?", "Quale versione del servizio ha problemi?" e così via. In generale, esplora le funzionalità di Kiali prima di procedere con la 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, esegui il comando qui sotto, dopodiché apri 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 sul menu Home in alto a sinistra e selezionando Istio Service Dashboard nell'angolo in alto a sinistra, inizia con il servizio sa-web-app, per visualizzare le metriche raccolte: Qui ci aspetta una presentazione vuota e completamente noiosa — la guida non approverebbe mai una cosa del genere. Creiamo un po' di carico con il seguente comando: $ while true; do curl -i http://$EXTERNAL_IP/sentiment -H "Content-type: application/json" -d '{"sentence": "I love yogobella"}'; sleep .8; done Ora abbiamo grafici molto più carini, e in aggiunta a questi — ottimi strumenti come 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 alla tracciatura delle richieste nei servizi. Jaeger : tracciatura La tracciatura ci sarà utile, perché più sono i nostri servizi, più è complicato risalire alla causa di un errore. Diamo un'occhiata a un semplice caso nell'immagine qui sotto: Esempio tipico di una richiesta casuale non riuscita La richiesta arriva, fallisce — qual è la causa? Il primo servizio? O il secondo? Esistono delle eccezioni in entrambi i casi — diamo un'occhiata ai log di ciascuno. Quanto spesso ti sei sorpreso a farlo? Il nostro lavoro assomiglia più a quello degli investigatori del software piuttosto che a quello degli sviluppatori… Questo è un problema comune nei microservizi e viene risolto con sistemi di tracciamento distribuiti, in cui i servizi si scambiano intestazioni uniche e questa informazione viene poi reindirizzata a un sistema di tracciamento, dove viene abbinata ai dati della richiesta. Ecco un'illustrazione: Per identificare la richiesta viene utilizzato il TraceId In Istio viene utilizzato il Jaeger Tracer, che implementa un framework indipendente dal fornitore OpenTracing API. Puoi accedere all'interfaccia utente di Jaeger con 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 è visualizzato nel menu a discesa — interagisci/genera attività sulla pagina e aggiorna l'interfaccia. Dopo, clicca sul pulsante Cerca Tracce, che mostrerà le tracce più recenti — seleziona una qualsiasi — verranno mostrate informazioni dettagliate su tutte le tracce: Questa traccia mostra: La richiesta arriva a istio-ingressgateway (questo è il primo contatto con uno dei servizi e per la richiesta viene generato un Trace ID), dopo di che il gateway inoltra la richiesta al servizio sa-web-app. Nel servizio sa-web-app la richiesta viene catturata dal sidecar di Envoy, viene creato un «figlio» nel span (ed è per questo che lo vediamo nelle tracce) e viene reindirizzata al container sa-web-app. (Span — un'unità logica di lavoro in Jaeger, che ha un nome, un'ora di inizio dell'operazione e la sua durata. Gli span possono essere nidificati e ordinati. Un grafo aciclico diretto di span forma una traccia. — nota del traduttore) Qui la richiesta viene elaborata con il metodo sentimentAnalysis. Queste tracce sono già state generate dall'applicazione, ovvero sono stati necessari cambiamenti nel codice. Da questo momento viene iniziata una richiesta POST a sa-logic. Il Trace ID deve essere passato da sa-web-app. … Nota: Al quarto passo, l'applicazione deve visualizzare le intestazioni generate da Istio e trasmetterle alle richieste successive, come mostrato nell'immagine qui sotto: (A) Istio si occupa del passaggio delle intestazioni; (B) I servizi si occupano delle intestazioni Istio fa gran parte del lavoro, poiché genera intestazioni per le richieste in entrata, crea nuovi span in ogni sidecar e li trasmette. Tuttavia, senza la gestione delle intestazioni all'interno dei servizi, il percorso completo della tracciatura della richiesta andrà perso. È necessario considerare (trasmettere) le seguenti intestazioni: x-request-id x-b3-traceid x-b3-spanid x-b3-parentspanid x-b3-sampled x-b3-flags x-ot-span-context Questo non è un compito difficile, tuttavia, per semplificare la sua implementazione, esistono già molte librerie — ad esempio, nel servizio sa-web-app, il client RestTemplate trasmette queste intestazioni, se si aggiungono semplicemente le librerie Jaeger e OpenTracing nelle sue dipendenze. Si noti che l'applicazione Sentiment Analysis dimostra implementazioni su Flask, Spring e ASP.NET Core. Ora che è chiaro cosa otteniamo di serie (o quasi «di serie»), consideriamo questioni come instradamento fine, gestione del traffico di rete, sicurezza, ecc.! Nota del traduttore.: leggi di più nella prossima parte del materiale su Istio di Rinor Maloku, le cui traduzioni arriveranno sul nostro blog a breve. UPDATE (14 marzo): La seconda parte già pubblicato. P.S. dal traduttore Leggete 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 alla configurazione della rete in Kubernetes. Parti 1 e 2»; «Come è finito questo container 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 definisce il servizio a cui vengono inviati le richieste.

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

Applichiamo VirtualService chiamando:

Nota: Quando applichiamo le risorse Istio, il server API di Kubernetes genera un evento, che viene ricevuto dal Control Plane di Istio, e solo dopo questa nuova configurazione viene applicata ai proxy Envoy di ciascun pod. Il controller Ingress Gateway è 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 accessibile a http://{EXTERNAL-IP}/. Non preoccuparti se ricevi lo stato Not Found: a volte può essere necessario un po' più di tempo affinché la configurazione entri in vigore e le cache di Envoy vengano aggiornate.

Prima di continuare, lavora 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, esegui il seguente comando:

… e apri http://localhost:20001/, effettuando il login come admin/admin. Qui troverai molte funzionalità utili, ad esempio per verificare la configurazione dei componenti Istio, visualizzare i servizi sulla base delle informazioni raccolte durante l'intercettazione delle richieste di rete, ottenere risposte alle domande "Chi sta chiamando chi?", "Quale versione del servizio ha problemi?" e così via. In generale, esplora le funzionalità di Kiali prima di procedere con la 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, esegui il comando qui sotto, dopodiché apri http://localhost:3000/:

Cliccando sul menu Home in alto a sinistra e selezionando Istio Service Dashboard nell'angolo in alto a sinistra, inizia con il servizio sa-web-app, per visualizzare le metriche raccolte:

Qui ci aspetta una presentazione vuota e completamente noiosa — la guida non approverebbe mai una cosa del genere. Creiamo un po' di carico con il seguente comando:

Ora abbiamo grafici molto più carini, e in aggiunta a questi — ottimi strumenti come 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 alla tracciatura delle richieste nei servizi.

Jaeger : tracciatura

La tracciatura ci sarà utile, perché più sono i nostri servizi, più è complicato risalire alla causa di un errore. Diamo un'occhiata a un semplice caso nell'immagine qui sotto:

Esempio tipico di una richiesta casuale non riuscita

La richiesta arriva, fallisce — qual è la causa? Il primo servizio? O il secondo? Esistono delle eccezioni in entrambi i casi — diamo un'occhiata ai log di ciascuno. Quanto spesso ti sei sorpreso a farlo? Il nostro lavoro assomiglia più a quello degli investigatori del software piuttosto che a quello degli sviluppatori…

Questo è un problema comune nei microservizi e viene risolto con sistemi di tracciamento distribuiti, in cui i servizi si scambiano intestazioni uniche e questa informazione viene poi reindirizzata a un sistema di tracciamento, dove viene abbinata ai dati della richiesta. Ecco un'illustrazione:

Per identificare la richiesta viene utilizzato il TraceId

In Istio viene utilizzato il Jaeger Tracer, che implementa un framework indipendente dal fornitore OpenTracing API. Puoi accedere all'interfaccia utente di Jaeger con il seguente comando:

Ora vai su http://localhost:16686/ e seleziona il servizio sa-web-app. Se il servizio non è visualizzato nel menu a discesa — interagisci/genera attività sulla pagina e aggiorna l'interfaccia. Dopo, clicca sul pulsante Cerca Tracce, che mostrerà le tracce più recenti — seleziona una qualsiasi — verranno mostrate informazioni dettagliate su tutte le tracce:

Questa traccia mostra:

La richiesta arriva a istio-ingressgateway (questo è il primo contatto con uno dei servizi e per la richiesta viene generato un Trace ID), dopo di che il gateway inoltra la richiesta al servizio sa-web-app.
Nel servizio sa-web-app la richiesta viene presa in carico dal sidecar Envoy, viene creato un "figlio" nello span (per questo lo vediamo nei tracciamenti) e viene reindirizzato nel container sa-web-app. (Span — un'unità logica di lavoro in Jaeger, che ha un nome, un tempo di inizio dell'operazione e la sua durata. Gli span possono essere nidificati e ordinati. Un grafo diretto aciclico di span forma il trace. — nota del traduttore.
Qui la richiesta viene elaborata con il metodo sentimentAnalysis. Queste tracce sono già state generate dall'applicazione, ovvero sono stati necessari cambiamenti nel codice.
Da questo momento viene iniziata una richiesta POST a sa-logic. Il Trace ID deve essere passato da sa-web-app.
…

Nota: Al quarto passo, l'applicazione deve visualizzare le intestazioni generate da Istio e trasmetterle alle richieste successive, come mostrato nell'immagine qui sotto:

(A) Istio si occupa del passaggio delle intestazioni; (B) I servizi si occupano delle intestazioni

Istio svolge un ruolo fondamentale, poiché genera intestazioni per le richieste in ingresso, crea nuovi span in ogni sidecar e li trasmette. Tuttavia, senza la gestione delle intestazioni all'interno dei servizi, l'intero percorso di tracciamento della richiesta andrà perso.

È necessario considerare (trasmettere) le seguenti intestazioni:

Questo non è un compito difficile, tuttavia, per semplificare la sua implementazione, esistono già molte librerie — ad esempio, nel servizio sa-web-app, il client RestTemplate trasmette queste intestazioni, se si aggiungono semplicemente le librerie Jaeger e OpenTracing nelle sue dipendenze.

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

Ora che è chiaro cosa otteniamo di serie (o quasi «di serie»), consideriamo questioni come instradamento fine, gestione del traffico di rete, sicurezza, ecc.!

Nota del traduttore.: leggi di più nella prossima parte del materiale su Istio di Rinor Maloku, le cui traduzioni arriveranno sul nostro blog a breve. UPDATE (14 marzo): La seconda parte già pubblicato.