Tillbaka till mikrotjänster med Istio. Del 1

Notera. transl.: Servicenät har definitivt blivit en relevant lösning i modern infrastruktur för applikationer som följer mikrotjänstarkitektur. Även om Istio kanske är bekant för många DevOps-ingenjörer, är det en ganska ny produkt som, med tanke på dess komplexitet vad gäller kapacitet, kan ta en betydande tid att vänja sig vid. Den tyske ingenjören Rinor Maloku, som är ansvarig för cloud computing för storkunder på teleföretaget Orange Networks, har skrivit en underbar serie material som gör att du kan dyka in i Istio ganska snabbt och djupt. Han börjar sin berättelse med vad Istio kan göra generellt och hur man snabbt kan se det med egna ögon.

Samma — Ett projekt med öppen källkod utvecklat i samarbete mellan team från Google, IBM och Lyft. Det löser komplexiteten som uppstår i mikrotjänster-baserade applikationer, såsom:

• Trafikledning: timeouts, försök igen, lastbalansering;
• Безопасность: autentisering och auktorisering av slutanvändare;
• Observerbarhet: spårning, övervakning, loggning.

Alla dessa går att lösa på applikationsnivå, men då blir dina tjänster inte längre "mikro". Varje ytterligare ansträngning för att lösa dessa problem är en onödig utgift av företagets resurser som skulle kunna användas direkt för affärsnytta. Låt oss titta på ett exempel:

Projektledare: Hur lång tid tar det att lägga till feedbackfunktionen?
Utvecklare: Två spurter.

MP: Vadå?... Det är bara CRUD!
R: Att göra CRUD är den enkla delen, men vi måste fortfarande autentisera och auktorisera användare och tjänster. Eftersom nätverket är opålitligt, kommer det att vara nödvändigt att implementera upprepade förfrågningar, liksom strömbrytare mönster hos kunder. Dessutom, för att säkerställa att hela systemet inte kraschar, behöver du timeouts och skott (för mer information om båda dessa mönster, se vidare i artikeln – översättarens anmärkning), och för att upptäcka problem behöver du övervakning, spårning, […]

MP: Åh, låt oss bara lägga in den här funktionen i produkttjänsten då.

Jag tror att du förstår: mängden steg och ansträngning som krävs för att lägga till en enda tjänst är enorm. I den här artikeln ska vi titta på hur Istio tar bort alla ovanstående komplexiteter (som inte är inriktade på affärslogik) från tjänster.

Notera: Den här artikeln förutsätter att du har praktisk kunskap om Kubernetes. Annars rekommenderar jag att läsa Min introduktion till Kubernetes och först efter det fortsätter du att läsa detta material.

Istios idé

I en värld utan Istio gör en tjänst direkta förfrågningar till en annan, och om ett fel inträffar måste tjänsten hantera det själv: försök igen, ge en timeout, öppna en strömbrytare osv.

Nätverkstrafik i Kubernetes

Istio, å andra sidan, erbjuder en dedikerad lösning som är helt frikopplad från tjänster och fungerar genom att störa nätverkskommunikation. Och så implementerar den:

• feltolerans: Baserat på statuskoden i svaret avgör den om begäran misslyckades och försök igen.
• Kanarie-utrullningar: omdirigerar endast en fast procentandel av förfrågningarna till den nya versionen av tjänsten.
• Övervakning och mätvärden: hur lång tid tog det för tjänsten att svara?
• Spårning och observerbarhet: lägger till speciella rubriker till varje begäran och spårar dem över klustret.
• Безопасность: hämtar JWT-token, autentiserar och auktoriserar användare.

Det här är bara några av möjligheterna (egentligen bara några!) för att fängsla dig. Låt oss nu dyka in i de tekniska detaljerna!

Istio arkitektur

Istio fångar upp all nätverkstrafik och tillämpar en uppsättning regler på den, och infogar en smart proxy i form av en sidovagnsbehållare i varje pod. Fullmakt som aktiverar alla funktioner form Dataplan, och de kan konfigureras dynamiskt med hjälp av Kontrollplan.

Dataplan

Proxies injicerade i pods gör det enkelt för Istio att uppfylla de krav vi behöver. Låt oss till exempel kontrollera igen och strömbrytarens funktioner.

Hur återförsök och kretsbrytning implementeras i Envoy

För att sammanfatta:

1. Sändebud (vi talar om en proxy placerad i en sidovagnscontainer, som distribueras som separat produkt - cirka. översätt.) skickar en begäran till den första instansen av tjänst B och misslyckas.
2. Envoy Sidecar försöker igen (försöker igen). Lagring
3. Begäran returneras till den anropande proxyn med ett misslyckande.
4. Detta öppnar kretsbrytaren och anropar nästa tjänst för efterföljande förfrågningar. Lagring

Det betyder att du inte behöver använda ännu ett Retry-bibliotek, du behöver inte implementera ditt eget Circuit Breaking and Service Discovery i programmeringsspråket X, Y eller Z. Allt detta och mer finns tillgängligt direkt i Istio och kräver inte ingen ändringar i koden.

Stor! Nu kanske du vill åka på en resa med Istio, men har fortfarande några tvivel, öppna frågor. Om detta är en universell lösning för alla tillfällen i livet, så har du en naturlig misstanke: trots allt visar sig alla sådana lösningar i verkligheten vara olämpliga för alla tillfällen.

Och till sist frågar du: "Går det anpassningsbart?"

Nu är du redo för en sjöresa - låt oss lära känna kontrollplanet.

Kontrollplan

Den består av tre komponenter: Pilot, Mixer и Citadel, — som arbetar tillsammans för att konfigurera sändebud för att dirigera trafik, tillämpa policyer och samla in telemetridata. Schematiskt ser det hela ut så här:

Interaktion mellan kontrollplan och dataplan

Envoy (dvs. dataplan) konfigureras med hjälp av Kubernetes CRD (Custom Resource Definitions) definierad av Istio och speciellt utformad för detta ändamål. Vad detta betyder för dig är att de bara visas som ytterligare en resurs i Kubernetes med en välbekant syntax. När den har skapats kommer denna resurs att hämtas av kontrollplanet och appliceras på sändebuden.

Relationen mellan tjänster och Istio

Vi har beskrivit Istios relation till tjänster, men inte tvärtom: hur förhåller sig tjänster till Istio?

Uppriktigt sagt är Istios närvaro lika välkänd för tjänster som fisk är för att vattna när de frågar sig själva: "Vad är vatten egentligen?"

illustration Victoria Dimitrakopoulos: - Hur gillar du vattnet? – Vad är vatten egentligen?

Så du kan ta ett fungerande kluster och efter att ha distribuerat Istio-komponenter kommer tjänsterna i det att fortsätta att fungera, och efter att ha tagit bort dessa komponenter kommer allt att bli bra igen. Uppenbarligen kommer du att förlora de funktioner som tillhandahålls av Istio.

Nog med teori - låt oss omsätta denna kunskap i praktiken!

Istio i praktiken

Istio kräver ett Kubernetes-kluster med minst 4 vCPU:er och 8 GB RAM tillgängligt. För att snabbt konfigurera ett kluster och följa instruktionerna i artikeln rekommenderar jag att du använder Google Cloud Platform, som erbjuder nya användare Gratis $300.

När du har skapat ditt kluster och konfigurerat åtkomst till Kubernetes via konsolverktyget kan du installera Istio via Helm-pakethanteraren.

Installerar Helm

Installera Helm-klienten på din dator enligt beskrivningen i officiell dokumentation. Vi kommer att använda detta för att generera mallar för installation av Istio i nästa avsnitt.

Installerar Istio

Ladda ner Istio-resurser från senaste utgåvan (den ursprungliga författarens länk till version 1.0.5 har ändrats till den nuvarande, dvs. 1.0.6 — översättarens anmärkning), extrahera innehållet i en katalog, som jag kommer att anropa från och med nu [istio-resources].

För att enkelt identifiera Istio-resurser, skapa ett namnområde i ditt K8s-kluster istio-system:

$ kubectl create namespace istio-system

Slutför installationen genom att gå till katalogen [istio-resources] och kör kommandot:

$ 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

Detta kommando matar ut nyckelkomponenterna i Istio till en fil istio.yaml. Vi har modifierat standardmallen för att passa våra behov och specificerar följande parametrar:

• global.mtls.enabled installerad i false (dvs mTLS-autentisering är inaktiverad - översättarens anmärkning), för att göra vår dejtingprocess enklare;
• tracing.enabled Aktiverar spårning av begäran med Jaeger;
• kiali.enabled installerar Kiali i ett kluster för att visualisera tjänster och trafik;
• grafana.enabled Installerar Grafana för att visualisera insamlade mätvärden.

Låt oss tillämpa de genererade resurserna med kommandot:

$ kubectl apply -f istio.yaml

Installationen av Istio i klustret är klar! Vänta tills alla poddar i namnområdet istio-system kommer att kunna Running eller Completed, genom att köra kommandot nedan:

$ kubectl get pods -n istio-system

Nu är vi redo att fortsätta med nästa avsnitt där vi kommer att få igång applikationen.

Applikationsarkitektur för sentimentanalys

Låt oss använda exemplet med Sentiment Analysis-mikrotjänstapplikationen som används i det redan nämnda Introduktion till Kubernetes artikel. Det är tillräckligt komplext för att visa Istios kapacitet i praktiken.

Applikationen består av fyra mikrotjänster:

1. Tjänsten SA-Frontend, som tjänar gränssnittet för Reactjs-applikationen;
2. Tjänsten SA-WebApp, som betjänar sentimentanalysförfrågningar;
3. Tjänsten SA-Logik, som utförs av sig själv sentimentanalys;
4. Tjänsten SA-Feedback, som får feedback från användare om noggrannheten i den utförda analysen.

I detta diagram ser vi förutom tjänster även Ingress Controller, som i Kubernetes dirigerar inkommande förfrågningar till motsvarande tjänster. Istio använder ett liknande koncept i sin Ingress Gateway, som vi kommer att ta upp mer i detalj senare.

Kör en applikation med proxy från Istio

För ytterligare operationer som nämns i artikeln, klona förvaret för dig själv istio-mästarskap. Den innehåller applikationen och manifesten för Kubernetes och Istio.

Sätta in sidvagnar

Insättningen kan göras automatiskt eller manuellt. För att automatiskt infoga sidovagnsbehållare måste du ställa in en etikett för namnområdet istio-injection=enabled, vilket görs av följande kommando:

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

Nu kommer varje pod som kommer att distribueras i standardnamnrymden (default) kommer att få sin sidovagnsbehållare. För att verifiera detta, låt oss distribuera ett testprogram genom att navigera till rotkatalogen för förvaret. [istio-mastery] och kör följande kommando:

$ 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

Efter att ha distribuerat tjänsterna kommer vi att kontrollera att poddarna har två behållare (med själva tjänsten och dess sidovagn) genom att köra kommandot kubectl get pods och se till att under kolumnen READY angivet värde 2/2, som symboliserar att båda behållarna körs:

$ 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

Visuellt representeras det så här:

Envoy proxy i en av poddarna

Nu när applikationen är igång måste vi tillåta inkommande trafik att komma in i applikationen.

Ingress Gateway

Den bästa praxis för att uppnå detta (tillåt trafik i klustret) är genom Ingress Gateway i Istio, som finns i "kanten" av klustret och gör att Istio-funktioner som routing, lastbalansering, säkerhet och övervakning kan aktiveras för inkommande trafik.

Ingress Gateway-komponenten och tjänsten som exponerar den installerades i klustret under Istio-installationen. För att ta reda på tjänstens externa IP-adress, kör:

$ 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

Vi kommer att fortsätta att komma åt applikationen via denna IP (jag kommer att referera till den som EXTERN-IP), så för enkelhetens skull kommer vi att skriva värdet i en variabel:

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

Om du försöker komma åt denna IP via en webbläsare nu, kommer du att få felmeddelandet Service Unavailable, eftersom Som standard blockerar Istio all inkommande trafik., tills Gateway har definierats.

Gateway-resurs

Gateway är en CRD (Custom Resource Definition) i Kubernetes som definieras efter att Istio har installerats i klustret och möjliggör möjligheten att ange de portar, protokoll och värdar som vi vill tillåta inkommande trafik för.

I vårt fall vill vi tillåta HTTP-trafik till port 80 för alla värdar. Uppgiften realiseras genom följande definition (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:
- "*"

Denna konfiguration behöver ingen förklaring förutom väljaren istio: ingressgateway. Med denna väljare kan vi specificera vilken Ingress Gateway som ska tillämpas på konfigurationen. I vårt fall är detta Ingress Gateway-kontrollern som installerades som standard i Istio.

Konfigurationen tillämpas genom att anropa följande kommando:

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

Gatewayen tillåter nu åtkomst till port 80, men har ingen aning om var förfrågningar ska dirigeras. För detta behöver du Virtuella tjänster.

VirtualService-resurs

VirtualService berättar för Ingress Gateway hur man dirigerar förfrågningar som löses inom klustret.

Förfrågningar till vår applikation som kommer via http-gateway ska skickas till sa-frontend, sa-web-app och sa-feedback-tjänsterna:

Rutter som behöver konfigureras med VirtualServices

Låt oss titta på förfrågningarna som ska skickas till SA-Frontend:

• Exakt vägmatchning / ska skickas till SA-Frontend för att få index.html;
• Banor med prefix /static/* ska skickas till SA-Frontend för att få statiska filer som används i frontend, såsom CSS och JavaScript;
• Sökvägar som matchar det reguljära uttrycket '^.*.(ico|png|jpg)$', måste skickas till SA-Frontend, eftersom det här är bilderna som visas på sidan.

Implementeringen uppnås genom följande konfiguration (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
 Viktiga punkter:
 
 Denna virtuella tjänst gäller för förfrågningar som kommer igenom http-gateway;
 
 В destination Vilken tjänst som förfrågningar skickas till bestäms.
Notera: Ovanstående konfiguration lagras i filen sa-virtualservice-external.yaml, som även innehåller inställningar för routing till SA-WebApp och SA-Feedback, men har förkortats här i artikeln för korthets skull.
Låt oss tillämpa VirtualService genom att ringa:
Notera: När vi förbrukar Istio-resurser avger Kubernetes API-server en händelse som tas emot av Istio Control Plane, och den nya konfigurationen tillämpas sedan på varje pods Envoy-proxyer. Och Ingress Gateway-kontrollern verkar vara en annan envoy som är konfigurerad i kontrollplanet. Allt detta ser ut så här på diagrammet:

 Istio-IngressGateway-konfiguration för begäran om routing
Appen Sentiment Analysis är nu tillgänglig http://{EXTERNAL-IP}/. Oroa dig inte om du får statusen Not Found: Ibland tar det lite längre tid för konfigurationen att träda i kraft och för Envoys cacheminne att uppdateras.
Innan du fortsätter, leka lite med appen för att generera trafik. (dess närvaro är nödvändig för klarhet i efterföljande åtgärder - översättarens anteckning).
Kiali: observerbarhet
För att komma åt Kiali administrativa gränssnitt, kör följande kommando:
...och öppna http://localhost:20001/, loggar in som admin/admin. Här hittar du många användbara funktioner, till exempel för att inspektera konfigurationen av Istio-komponenter, visualisera tjänster baserat på information som samlats in genom att avlyssna nätverksförfrågningar, få svar på frågor som "Vem ringer vem?", "Vilken version av tjänsten misslyckas?" etc. Överlag, utforska Kialis möjligheter innan du går vidare till statistikvisualisering med Grafana.
Grafana: Visualisera statistik
Mätvärden som samlas in i Istio matas in i Prometheus och visualiseras med Grafana. För att komma åt Grafanas administratörsgränssnitt, kör kommandot nedan och öppna sedan http://localhost:3000/:
Genom att klicka på menyn Hem uppe till vänster och välja Istio Service Dashboard i det övre vänstra hörnet, börja med tjänsten sa-web-appför att se de insamlade mätvärdena:
Det som väntar oss här är en tom och helt tråkig föreställning – detta kommer ledningen aldrig att godkänna. Låt oss skapa en liten belastning med följande kommando:
Nu har vi mycket snyggare grafer, och utöver dem har vi fantastiska verktyg som Prometheus för övervakning och Grafana för att visualisera mätvärden, vilket gör att vi kan lära oss om prestanda, hälsa, förbättringar/försämringar av tjänster över tid.
Låt oss slutligen titta på spårningsförfrågningar i tjänster.
Jaeger: Spåra
Vi kommer att behöva spårning för ju fler tjänster vi har, desto svårare är det att hitta orsaken till felet. Låt oss titta på ett enkelt fall från bilden nedan:

 Ett typiskt exempel på en slumpmässig misslyckad begäran
Begäran kommer, faller - Vad är anledningen? Första service? Eller den andra? Det finns undantag i båda - låt oss titta på loggarna för var och en. Hur ofta har du gripit dig själv med att göra detta? Vårt jobb är mer som mjukvarudetektiver än utvecklare...
Detta är ett vanligt problem i mikrotjänster och löses av distribuerade spårningssystem, där tjänster skickar en unik rubrik till varandra, som sedan vidarebefordras till spårningssystemet där den matchas mot begärandata. Här är en illustration:

 TraceId används för att identifiera begäran.
Istio använder Jaeger Tracer, som implementerar det leverantörsneutrala OpenTracing API-ramverket. Du kan komma åt Jaegers användargränssnitt med följande kommando:
Gå nu till http://localhost:16686/ och välj tjänsten sa-web-app. Om tjänsten inte visas i rullgardinsmenyn, visa/generera aktivitet på sidan och uppdatera gränssnittet. Efter det klickar du på knappen Hitta spår, som visar de senaste spåren - välj valfritt - detaljerad information om alla spår kommer att visas:
Detta spår visar:
 
 Förfrågan kommer in istio-ingressgateway (detta är den första interaktionen med en av tjänsterna, och ett spårnings-ID genereras för begäran), varefter gatewayen vidarebefordrar begäran till tjänsten sa-web-app.
 
 I tjänst sa-web-app förfrågan plockas upp av envoy sidvagn, ett "barn" skapas i spann (det är därför vi ser det i spåren) och skickas vidare till containern sa-web-app. (Spänna — En logisk arbetsenhet i Jaeger, med ett namn, starttiden för operationen och dess varaktighet. Spännen kan kapslas och beställas. En riktad acyklisk graf över spann bildar ett spår. — ca. översätt.)
 
 Här behandlas förfrågan med metoden sentimentanalys. Dessa spår genereras redan av applikationen, det vill säga de krävde ändringar i koden.
 
 Från och med denna tidpunkt initieras en POST-begäran till sa-logik. Spårnings-ID måste skickas från sa-web-app.
 
 .
Notera: I steg 4 bör applikationen se rubrikerna som genereras av Istio och skicka dem vidare till efterföljande förfrågningar, som visas i bilden nedan:

 (A) Istio ansvarar för vidarebefordran av rubriker; (B) Rubriker är tjänsternas ansvar
Istio gör det tunga lyftet eftersom genererar headers för inkommande förfrågningar, skapar nya spann i varje sidecare och skickar dem vidare. Men utan att arbeta med rubriker inuti tjänster, kommer hela sökvägen för begäran att gå förlorad.
Följande rubriker måste beaktas (vidarebefordras):
Detta är ingen svår uppgift, men det finns redan ett sätt att förenkla dess genomförande många bibliotek — till exempel, i sa-web-app-tjänsten, vidarebefordrar RestTemplate-klienten dessa rubriker om du bara lägger till Jaeger- och OpenTracing-biblioteken till hans beroenden.
Observera att Sentiment Analysis-appen demonstrerar implementeringar i Flask, Spring och ASP.NET Core.
Nu när det är klart vad vi får ur lådan (eller nästan ur lådan), låt oss titta på finjusterad routing, nätverkstrafikhantering, säkerhet och mer!
Notera. transl.: Läs om detta i nästa del av materialet på Istio av Rinor Maloku, vars översättningar kommer att följa på vår blogg inom en snar framtid. UPPDATERING (14 mars): Den andra delen redan publicerat.
PS från översättaren
Läs även på vår blogg:
 

• "Tillbaka till mikrotjänster med Istio": del 2 (dirigering, trafikkontroll), del 3 (autentisering och auktorisering);
• «Conduit - lättviktsnät för Kubernetes";
• «Vad är ett servicenät och varför behöver jag ett [för en molnapplikation med mikrotjänster]?";
• «En illustrerad guide till nätverk i Kubernetes. Del 1 och 2";
• «Hur hamnade den här sidvagnscontainern här [i Kubernetes]?".

Källa: will.com