Torniamo ai microservizi con Istio. Parte 1

Nota. trad.: Le mesh di servizi sono sicuramente diventate un tema caldo nell'infrastruttura odierna per le applicazioni che seguono l'architettura dei microservizi. Sebbene Istio possa essere sul radar di molti ingegneri DevOps, si tratta di un prodotto abbastanza nuovo che, sebbene complesso in termini di funzionalità fornite, può richiedere molto tempo per essere familiarizzato. L'ingegnere tedesco Rinor Maloku, responsabile del cloud computing per grandi clienti presso la società di telecomunicazioni Orange Networks, ha scritto una meravigliosa serie di materiali che consentono di immergersi rapidamente e profondamente in Istio. Inizia la sua storia con ciò che Istio può fare e come puoi vederlo rapidamente con i tuoi occhi.

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

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

Tutti questi problemi possono essere risolti a livello di applicazione, tuttavia in seguito i vostri servizi non saranno più "micro". Tutti gli sforzi aggiuntivi per affrontare questi problemi rappresentano uno spreco di risorse aziendali che potrebbero essere utilizzate direttamente per ottenere valore aziendale. Considera un esempio:

Project Manager: quanto tempo ci vuole per aggiungere una funzione di feedback?
Sviluppatore: due sprint.

MP: Cosa?.. è semplicemente CRUD!
R: Fare CRUD è la parte facile del compito, ma dobbiamo comunque autenticare e autorizzare utenti e servizi. Poiché la rete non è affidabile, dovrai implementare anche richieste ripetute modello dell'interruttore nei clienti. Inoltre, per assicurarti che l'intero sistema non si blocchi, avrai bisogno di timeout e paratie (per maggiori dettagli su entrambi i modelli citati, vedere più avanti nell'articolo - trad. ca.), e al fine di individuare problemi, monitorare, tracciare, […]

MP: Oh, allora inseriamo questa funzionalità nel servizio Prodotto.

Penso che l'idea sia chiara: la quantità di passaggi e di sforzi necessari per aggiungere un servizio è enorme. In questo articolo esamineremo come Istio rimuove dai servizi tutta la complessità sopra menzionata (che non è intesa come logica aziendale).

Nota: questo articolo presuppone che tu abbia una conoscenza pratica di Kubernetes. Altrimenti consiglio la lettura la mia introduzione a Kubernetes e solo allora continua a leggere questo materiale.

Idea Istio

In un mondo senza Istio, un servizio effettua richieste dirette a un altro e, in caso di guasto, il servizio deve gestirlo da solo: effettuare un nuovo tentativo, prevedere un timeout, aprire un interruttore, ecc.

Traffico di rete in Kubernetes

Istio offre una soluzione specializzata, completamente separata dai servizi e funzionante interferendo con la comunicazione di rete. E quindi implementa:

• tolleranza ai guasti: in base al codice di stato presente nella risposta, capisce se la richiesta è fallita e la reinoltra.
• Lancio delle Canarie: reindirizza solo una percentuale fissa di richieste alla nuova versione del servizio.
• Monitoraggio e metriche: quanto tempo ha impiegato il servizio a rispondere?
• Tracciamento e osservabilità: aggiunge intestazioni speciali a ciascuna richiesta e le traccia nel cluster.
• sicurezza: recupera il token JWT, autentica e autorizza gli utenti.

Queste sono solo alcune delle possibilità (davvero poche!) per incuriosirvi. Ora tuffiamoci nei dettagli tecnici!

Architettura

Istio intercetta tutto il traffico di rete e vi applica una serie di regole, inserendo un proxy intelligente sotto forma di contenitore sidecar in ciascun pod. I proxy che attivano tutte le funzionalità formano a Piano datie possono essere regolati dinamicamente con Piano di controllo.

Piano dati

I proxy inseriti nei pod consentono a Istio di raggiungere facilmente i requisiti di cui abbiamo bisogno. Ad esempio, controlliamo i tentativi e le funzioni dell'interruttore.

Come vengono implementati i nuovi tentativi e le interruzioni di circuito in Envoy

Per riassumere:

1. Inviato (stiamo parlando di un proxy situato in un contenitore sidecar, che è distribuito come prodotto separato - ca. trad.) invia una richiesta alla prima istanza del servizio B e fallisce.
2. L'inviato Sidecar ci sta riprovando (riprova). (1)
3. La richiesta non riuscita viene restituita al proxy che l'ha chiamata.
4. Questo apre il Circuit Breaker e chiama il servizio successivo per le richieste successive. (2)

Ciò significa che non è necessario utilizzare un'altra libreria Retry, né è necessario realizzare la propria implementazione di Circuit Breaking e Service Discovery nel linguaggio di programmazione X, Y o Z. Tutto questo e molto altro è disponibile immediatamente a Istio e non richiede no modifiche al codice.

Grande! Ora potresti voler fare un viaggio con Istio, ma hai ancora qualche dubbio, domande aperte. Se questa è una soluzione universale per tutte le occasioni della vita, allora hai un naturale sospetto: dopo tutto, tutte queste soluzioni in realtà risultano inadatte in ogni caso.

E infine ti chiedi: “È personalizzabile?”

Ora sei pronto per il viaggio in mare, facciamo conoscenza con il piano di controllo.

Piano di controllo

Si compone di tre componenti: Pilota, Mixer и Cittadella, che insieme configurano Envoys per instradare il traffico, applicare policy e raccogliere dati di telemetria. Schematicamente, il tutto assomiglia a questo:

Interazione del piano di controllo con il piano dati

Gli inviati (ovvero il piano dati) vengono configurati utilizzando CRD di Kubernetes (Custom Resource Definitions) definite da Istio e specificatamente destinate a questo scopo. Ciò significa per te che sembrano essere solo un'altra risorsa in Kubernetes con una sintassi familiare. Una volta creata, questa risorsa verrà raccolta dal piano di controllo e applicata agli Inviati.

Rapporto di 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 sanno della presenza di Istio così come i pesci sanno dell'acqua, quando si chiedono: “Ma poi cos'è l'acqua?”.

illustrazione Vittoria Dimitrakopoulos: - Come ti piace l'acqua? - Cos'è comunque l'acqua?

Pertanto, puoi prendere un cluster funzionante e dopo aver distribuito i componenti Istio, i servizi in esso contenuti continueranno a funzionare e, dopo aver rimosso questi componenti, tutto andrà di nuovo bene. È chiaro che in questo caso si perderanno le opportunità offerte da Istio.

Basta teoria: mettiamo in pratica questa conoscenza!

Istio in pratica

Istio richiede un cluster Kubernetes con almeno 4 vCPU e 8 GB di RAM disponibili. Per configurare rapidamente un cluster e seguire le istruzioni dell'articolo, consiglio di utilizzare Google Cloud Platform, che offre nuovi utenti gratis $ 300.

Dopo aver creato il cluster e configurato l'accesso a Kubernetes tramite l'utilità della console, puoi installare Istio tramite il gestore pacchetti Helm.

Installazione del timone

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

Installazione

Scarica le risorse Istio da ultima uscita (il collegamento dell'autore originale alla versione 1.0.5 è stato modificato in quello attuale, ovvero 1.0.6 - trad. ca.), estrai il contenuto in un'unica directory, a cui mi riferirò come [istio-resources].

Per identificare facilmente le 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 in un file istio.yaml. Abbiamo modificato il modello standard per adattarlo alle nostre esigenze, specificando i seguenti parametri:

• global.mtls.enabled installato in false (ovvero l'autenticazione mTLS è disabilitata - trad. approssimativa)per semplificare il nostro processo di datazione;
• tracing.enabled include il tracciamento delle richieste tramite Jaeger;
• kiali.enabled installa Kiali in un cluster per visualizzare servizi e traffico;
• grafana.enabled installa Grafana per visualizzare le metriche raccolte.

Applicare le risorse generate con il comando:

$ kubectl apply -f istio.yaml

L'installazione di Istio nel cluster è completata! Attendi fino a quando tutti i pod nello spazio dei nomi istio-system sarà in grado di Running o Completedeseguendo il comando seguente:

$ kubectl get pods -n istio-system

Ora siamo pronti per passare alla sezione successiva, dove genereremo ed eseguiremo l'applicazione.

Architettura dell'applicazione per l'analisi del sentiment

Usiamo l'esempio dell'applicazione microservizio Sentiment Analysis utilizzata nel già menzionato Articolo introduttivo a Kubernetes. È abbastanza complesso da mostrare le possibilità di Istio nella pratica.

L'applicazione è composta da quattro microservizi:

1. Servizio SA-frontend, che serve l'applicazione front-end su Reactjs;
2. Servizio Applicazione Web SA, che serve le query di Sentiment Analysis;
3. Servizio Logica SA, che si esibisce da solo analisi del sentimento;
4. Servizio Feedback SA, che riceve feedback dagli utenti sull'accuratezza dell'analisi.

In questo diagramma, oltre ai servizi, vediamo anche l'Ingress Controller, che in Kubernetes instrada le richieste in entrata ai servizi corrispondenti. Istio utilizza un concetto simile come parte di Ingress Gateway, i cui dettagli seguiranno.

Avvio di un'applicazione con un proxy da Istio

Per ulteriori operazioni menzionate nell'articolo, clona il tuo repository istio-padronanza. Contiene l'applicazione e i manifest per Kubernetes e Istio.

Inserimento sidecar

È possibile effettuare l'inserimento автоматически o manualmente. Per inserire automaticamente i contenitori sidecar, dovrai impostare un'etichetta sullo spazio dei nomi istio-injection=enabled, che viene eseguito dal 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 suo contenitore sidecar. Per verificarlo, distribuiamo un'applicazione di prova andando nella directory principale del repository [istio-mastery] 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, controlla che i pod abbiano due contenitori ciascuno (con il servizio stesso e il suo sidecar) eseguendo il comando kubectl get pods e assicurandosi che sotto la colonna READY valore specificato 2/2, a simboleggiare che entrambi i contenitori 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 appare così:

Proxy Envoy in uno dei pod

Ora che l'applicazione è attiva e funzionante, dobbiamo consentire al traffico in entrata di entrare nell'applicazione.

Portale di ingresso

La procedura migliore per raggiungere questo obiettivo (consentire il traffico nel cluster) è attraverso Portale di ingresso in Istio, che si trova all'"estremità" del cluster e consente di abilitare funzionalità Istio come routing, bilanciamento del carico, sicurezza e monitoraggio del traffico in entrata.

Il componente Ingress Gateway e il servizio che lo inoltra verso l'esterno sono stati installati sul cluster durante l'installazione di Istio. Per scoprire l'indirizzo IP esterno di un 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

Continueremo ad accedere all'applicazione utilizzando questo IP (lo chiamerò EXTERNAL-IP), quindi per comodità scriveremo 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 un browser adesso, riceverai un errore di servizio non disponibile, perché per impostazione predefinita Istio blocca tutto il traffico in entrata, Il gateway non è stato ancora definito.

Risorsa del gateway

Il gateway è una CRD (Custom Resource Definition) in Kubernetes, definita dopo aver installato Istio nel cluster e abilitando la possibilità di specificare le porte, il protocollo e gli host per i quali vogliamo consentire il traffico in entrata.

Nel nostro caso, vogliamo consentire il traffico HTTP sulla porta 80 per tutti gli host. Il problema si realizza 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 gateway Ingress applicare la configurazione. Nel nostro caso, si tratta del controller Ingress Gateway, installato per impostazione predefinita in Istio.

La configurazione viene applicata richiamando il seguente comando:

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

Il gateway ora consente l'accesso alla porta 80, ma non ha idea di dove instradare le richieste. Per questo avrai bisogno Servizi virtuali.

Risorsa del servizio virtuale

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

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

Percorsi da configurare con VirtualServices

Considera le richieste che dovrebbero essere inviate a SA-Frontend:

• Corrispondenza esatta lungo la strada / dovrebbe essere inviato a SA-Frontend per ottenere index.html;
• Percorsi con un prefisso /static/* dovrebbe essere inviato a SA-Frontend per ottenere file statici utilizzati nel frontend, come CSS e JavaScript;
• Percorsi che corrispondono all'espressione regolare '^.*.(ico|png|jpg)$', deve essere inviato a SA-Frontend, perché Queste sono le immagini visualizzate nella pagina.

L'implementazione si ottiene mediante 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)

Важные моменты:



 	
 Этот VirtualService относится к запросам, приходящим через http-gateway;


 	
 В destination определяется сервис, куда отправляются запросы.




Примечание: Конфигурация выше хранится в файле sa-virtualservice-external.yaml, который также содержит настройки для маршрутизации в SA-WebApp и SA-Feedback, но был сокращён здесь в статье для лаконичности.

Применим VirtualService вызовом:

$ kubectl apply -f resource-manifests/istio/sa-virtualservice-external.yaml
virtualservice.networking.istio.io/sa-external-services created
Примечание: Когда мы применяем ресурсы Istio, Kubernetes API Server создаёт событие, которое получает Istio Control Plane, и уже после этого новая конфигурация применяется к прокси-серверам Envoy каждого pod'а. А контроллер Ingress Gateway представляется очередным Envoy, сконфигурированным в Control Plane. Всё это на схеме выглядит так:


Конфигурация Istio-IngressGateway для маршрутизации запросов
Приложение Sentiment Analysis стало доступным по http://{EXTERNAL-IP}/. Не переживайте, если вы получаете статус Not Found: иногда требуется чуть больше времени для того, чтобы конфигурация вступила в силу и кэши Envoy обновились.
Перед тем, как продолжить, поработайте немного с приложением, чтобы сгенерировать трафик (его наличие необходимо для наглядности в последующих действиях — прим. перев.).
Kiali : наблюдаемость
Чтобы попасть в административный интерфейс Kiali, выполните следующую команду:
$ kubectl port-forward 
    $(kubectl get pod -n istio-system -l app=kiali 
    -o jsonpath='{.items[0].metadata.name}') 
    -n istio-system 20001
… и откройте http://localhost:20001/, залогинившись под admin/admin. Здесь вы найдете множество полезных возможностей, например, для проверки конфигурации компонентов Istio, визуализации сервисов по информации, собранной при перехвате сетевых запросов, получения ответов на вопросы «Кто к кому обращается?», «У какой версии сервиса возникают сбои?» и т.п. В общем, изучите возможности Kiali перед тем, как двигаться дальше — к визуализации метрик с Grafana.

Grafana: визуализация метрик
Собранные в Istio метрики попадают в Prometheus и визуализируются с Grafana. Чтобы попасть в административный интерфейс Grafana, выполните команду ниже, после чего откройте 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
Кликнув на меню Home слева сверху и выбрав Istio Service Dashboard в левом верхнем углу, начните с сервиса sa-web-app, чтобы посмотреть на собранные метрики:

Здесь нас ждёт пустое и совершенно скучное представление — руководство никогда такое не одобрит. Давайте же создадим небольшую нагрузку следующей командой:
$ while true; do 
    curl -i http://$EXTERNAL_IP/sentiment 
    -H "Content-type: application/json" 
    -d '{"sentence": "I love yogobella"}'; 
    sleep .8; done
Вот теперь у нас гораздо более симпатичные графики, а в дополнение к ним — замечательные инструменты Prometheus для мониторинга и Grafana для визуализации метрик, что позволят нам узнать о производительности, состоянии здоровья, улучшениях/деградации в работе сервисов на протяжении времени.
Наконец, посмотрим на трассировку запросов в сервисах.
Jaeger : трассировка
Трассировка нам потребуется, потому что чем больше у нас сервисов, тем сложнее добраться до причины сбоя. Посмотрим на простой случай из картинки ниже:


Типовой пример случайного неудачного запроса
Запрос приходит, падает — в чём же причина? Первый сервис? Или второй? Исключения есть в обоих — давайте посмотрим на логи каждого. Как часто вы ловили себя за таким занятием? Наша работа больше похожа на детективов программного обеспечения, а не разработчиков…
Это широко распространённая проблема в микросервисах и решается она распределёнными системами трассировки, в которых сервисы передают друг другу уникальный заголовок, после чего эта информация перенаправляется в систему трассировки, где она сопоставляется с данными запроса. Вот иллюстрация:


Для идентификации запроса используется TraceId
В Istio используется Jaeger Tracer, который реализует независимый от вендоров фреймворк OpenTracing API. Получить доступ к пользовательского интерфейсу Jaeger можно следующей командой:
$ kubectl port-forward -n istio-system 
    $(kubectl get pod -n istio-system -l app=jaeger 
    -o jsonpath='{.items[0].metadata.name}') 16686
Теперь зайдите на http://localhost:16686/ и выберите сервис sa-web-app. Если сервис не показан в выпадающем меню — проявите/сгенерируйте активность на странице и обновите интерфейс. После этого нажмите на кнопку Find Traces, которая покажет самые последние трейсы — выберите любой — покажется детализированная информация по всем трейсам:

Этот трейс показывает:

 Запрос приходит в istio-ingressgateway (это первое взаимодействие с одним из сервисов, и для запроса генерируется Trace ID), после чего шлюз направляет запрос в сервис sa-web-app.
 В сервисе sa-web-app запрос подхватывается Envoy sidecar'ом, создаётся «ребёнок» в span'е (поэтому мы видим его в трейсах) и перенаправляется в контейнер sa-web-app. (Span — логическая единица работы в Jaeger, имеющая название, время начало операции и её продолжительность. Span'ы могут быть вложенными и упорядоченными. Ориентированный ациклический граф из span'ов образует trace. — прим. перев.)
 Здесь запрос обрабатывается методом sentimentAnalysis. Эти трейсы уже сгенерированы приложением, т.е. для них потребовались изменения в коде.
 С этого момента инициируется POST-запрос в sa-logic. Trace ID должен быть проброшен из sa-web-app.
 …

Примечание: На 4 шаге приложение должно увидеть заголовки, сгенерированные Istio, и передать их в последующие запросы, как показано на изображении ниже:


(A) За проброс заголовков отвечает Istio; (B) За заголовки отвечают сервисы
Istio делает основную работу, т.к. генерирует заголовки для входящих запросов, создаёт новые span'ы в каждом sidecare'е и пробрасывает их. Однако без работы с заголовками внутри сервисов полный путь трассировки запроса будет утерян.
Необходимо учитывать (пробрасывать) следующие заголовки:
x-request-id
x-b3-traceid
x-b3-spanid
x-b3-parentspanid
x-b3-sampled
x-b3-flags
x-ot-span-context
Это несложная задача, однако для упрощения её реализации уже существует множество библиотек — например, в сервисе sa-web-app клиент RestTemplate пробрасывает эти заголовки, если просто добавить библиотеки Jaeger и OpenTracing в его зависимости.
Заметьте, что приложение Sentiment Analysis демонстрирует реализации на Flask, Spring и ASP.NET Core.
Теперь, когда стало ясно, что мы получаем из коробки (или почти «из коробки»), рассмотрим вопросы тонко настраиваемой маршрутизации, управления сетевым трафиком, безопасности и т.п.!
Прим. перев.: об этом читайте в следующей части материалов по Istio от Rinor Maloku, переводы которых последуют в нашем блоге в ближайшее время. UPDATE (14 марта): Вторая часть уже опубликована.
P.S. от переводчика
Читайте также в нашем блоге:

 «Назад к микросервисам вместе с Istio»: часть 2 (маршрутизация, управление трафиком), часть 3 (аутентификация и авторизация);
 «Conduit — легковесный service mesh для Kubernetes»;
 «Что такое service mesh и почему он мне нужен [для облачного приложения с микросервисами]?»;
 «Иллюстрированное руководство по устройству сети в Kubernetes. Части 1 и 2»;
 «Как этот sidecar-контейнер оказался здесь [в Kubernetes]?».

Источник: habr.com
route:

- destination:

host: sa-frontend             # 2

port:

number: 80

Punti importanti:

 Questo servizio virtuale si riferisce alle richieste in arrivo gateway http;
 В destination Viene determinato il servizio a cui vengono inviate le richieste.

Nota: La configurazione di cui sopra è memorizzata in un file sa-virtualservice-external.yaml, che contiene anche le impostazioni per l'instradamento a SA-WebApp e SA-Feedback, ma è stato abbreviato qui nell'articolo per brevità.
Applicare VirtualService chiamando:

Nota: quando applichiamo le risorse Istio, il server API Kubernetes attiva un evento ricevuto dal piano di controllo Istio e, successivamente, la nuova configurazione viene applicata al proxy Envoy di ciascun pod. E il controller del gateway Ingress sembra essere un altro Envoy configurato nel piano di controllo. Tutto questo appare così nel diagramma:


Configurazione Istio-IngressGateway per l'instradamento delle richieste
L'analisi del sentiment è ora disponibile su http://{EXTERNAL-IP}/. Non preoccuparti se ottieni lo stato Non trovato: a volte è necessario un po' più di tempo perché la configurazione abbia effetto e perché le cache di Envoy si aggiornino.
Prima di procedere, gioca un po' con l'applicazione per generare traffico. (la sua presenza è necessaria per chiarezza nelle azioni successive - trad. ca.).
Kiali: osservabilità
Per accedere all'interfaccia di amministrazione di Kiali, esegui il seguente comando:

...e aperto http://localhost:20001/, accedendo come admin/admin. Qui troverai molte funzionalità utili, ad esempio, per verificare la configurazione dei componenti Istio, visualizzare i servizi utilizzando le informazioni raccolte dall'intercettazione delle richieste di rete, ottenere risposte alle domande "Chi sta contattando chi?", "Quale versione del servizio sta sperimentando fallimenti?" e così via. In generale, esplora le capacità di Kiali prima di passare alla visualizzazione delle metriche con Grafana.

Grafana: visualizzazione delle metriche
Le metriche raccolte in Istio finiscono in Prometheus e vengono visualizzate con Grafana. Per accedere all'interfaccia di amministrazione di Grafana, esegui il comando seguente, quindi apri http://localhost:3000/:

Cliccando sul menù Casa in alto a sinistra e seleziona Pannello di controllo del servizio Istio nell'angolo in alto a sinistra, inizia con il servizio sa-web-appper esaminare le metriche raccolte:

Ciò che ci aspetta qui è uno spettacolo vuoto e completamente noioso: la direzione non lo approverà mai. Creiamo un piccolo carico con il seguente comando:

Ora abbiamo grafici molto più belli e, oltre a questi, meravigliosi strumenti Prometheus per il monitoraggio e Grafana per la visualizzazione delle metriche che ci permetteranno di conoscere prestazioni, salute, miglioramenti/degrado dei servizi nel tempo.
Infine, esaminiamo il tracciamento delle richieste nei servizi.
Jaeger: tracciamento
Avremo bisogno di essere rintracciati, perché più servizi abbiamo, più difficile sarà risalire alla causa del guasto. Diamo un'occhiata a un caso semplice dall'immagine qui sotto:


Tipico esempio di richiesta casuale non riuscita
La richiesta arriva, cade - qual è il motivo? Primo servizio? O il secondo? Ci sono eccezioni in entrambi: diamo un'occhiata ai log di ciascuno. Quanto spesso ti sei sorpreso a farlo? Il nostro lavoro è più simile a quello dei detective del software che degli sviluppatori...
Questo è un problema comune nei microservizi e viene risolto dai sistemi di tracciamento distribuito, in cui i servizi si scambiano un'intestazione univoca, dopodiché queste informazioni vengono inoltrate al sistema di tracciamento, dove vengono confrontate con i dati della richiesta. Ecco un'illustrazione:


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

Ora vai a http://localhost:16686/ e seleziona un servizio sa-web-app. Se il servizio non è mostrato nel menu a discesa, mostra/genera attività sulla pagina e aggiorna l'interfaccia. Successivamente fare clic sul pulsante Trova tracce, che mostrerà le tracce più recenti - seleziona qualsiasi - appariranno informazioni dettagliate su tutte le tracce:

Questa traccia mostra:

 Arriva la richiesta istio-ingressgateway (questa è la prima interazione con uno dei servizi e viene generato un Trace ID per la richiesta), dopodiché il gateway invia la richiesta al servizio sa-web-app.
 Nel servizio sa-web-app la richiesta viene raccolta dal sidecar Envoy, viene creato un “figlio” nello span (ecco perché lo vediamo nelle tracce) e reindirizzato al contenitore sa-web-app. (Durata - un'unità logica di lavoro in Jaeger, avente un nome, l'ora di inizio dell'operazione e la sua durata. Le campate possono essere nidificate e ordinate. Un grafico aciclico diretto delle campate forma una traccia. - ca. trad.)
 Qui la richiesta viene elaborata con il metodo sentimentAnalysis. Queste tracce sono già generate dall'applicazione, ovvero richiedevano modifiche al codice.
 Da questo momento viene avviata una richiesta POST sa-logica. L'ID di traccia deve essere inoltrato da sa-web-app.
 ...

Nota: Nel passaggio 4, l'applicazione dovrebbe vedere le intestazioni generate da Istio e trasmetterle alle richieste successive come mostrato nell'immagine seguente:


(A) Istio è responsabile dell'inoltro delle intestazioni; (B) I servizi sono responsabili delle intestazioni
Istio fa la maggior parte del lavoro perché genera intestazioni per le richieste in entrata, crea nuovi span in ogni sidecare e li inoltra. Tuttavia, senza utilizzare le intestazioni all'interno dei servizi, l'intero percorso di traccia della richiesta andrà perso.
Devono essere considerate (inoltrate) le seguenti intestazioni:

Questo è un compito semplice, ma per semplificarne l'implementazione esiste già molte biblioteche - ad esempio, nel servizio sa-web-app, il client RestTemplate inoltra queste intestazioni se si aggiungono semplicemente le librerie Jaeger e OpenTracing a le sue dipendenze.
Si noti che l'applicazione Sentiment Analysis illustra le implementazioni in Flask, Spring e ASP.NET Core.
Ora che è chiaro cosa otterremo fuori dagli schemi (o quasi), diamo un'occhiata alla messa a punto del routing, alla gestione del traffico di rete, alla sicurezza e altro ancora!
Nota. trad.: Leggi questo nella prossima parte dei materiali su Istio di Rinor Maloku, le cui traduzioni seguiranno sul nostro blog nel prossimo futuro. AGGIORNAMENTO (14 marzo): Seconda parte è già stato pubblicato.
PS da traduttore
Leggi anche sul nostro blog:

 "Torna ai microservizi con Istio": parte 2 (percorsi, controllo del traffico), parte 3 (autenticazione e autorizzazione);
 «Conduit: mesh di servizi leggera per Kubernetes";
 «Cos'è un service mesh e perché ne ho bisogno [per un'applicazione cloud con microservizi]?";
 «Una guida illustrata al networking in Kubernetes. Parti 1 e 2";
 «Come è finito qui [in Kubernetes] questo container sidecar?'.

Fonte: habr.com