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 kan vara på läpparna hos många DevOps-ingenjörer, är det en ganska ny produkt som, även om den är heltäckande när det gäller de möjligheter som den tillhandahåller, kan kräva en betydande tid att bli bekant med. Den tyske ingenjören Rinor Maloku, som är ansvarig för cloud computing för stora kunder på telekommunikationsföretaget Orange Networks, har skrivit en underbar serie material som gör att du snabbt och djupt kan dyka in i Istio. 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 Open Source-projekt utvecklat i samarbete med team från Google, IBM och Lyft. Det löser komplexitet 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 kan lösas på applikationsnivå, men efter det kommer dina tjänster inte längre att vara "mikro". All extra ansträngning för att lösa dessa problem är ett slöseri med 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 en feedbackfunktion?
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 måste du 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 detaljer om båda nämnda mönster, se längre fram i artikeln - ca översättning), och för att upptäcka problem, övervakning, spårning, […]

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

Jag tror att tanken är tydlig: mängden steg och ansträngning som krävs för att lägga till en tjänst är enorm. I den här artikeln ska vi titta på hur Istio tar bort all komplexitet som nämns ovan (som inte är avsedd att vara 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.

Istio idé

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

Nätverkstrafik i Kubernetes

Istio erbjuder en specialiserad lösning, helt separerad från tjänster och fungerar genom att störa nätverkskommunikationen. Och så implementerar den:

• feltolerans: Baserat på statuskoden i svaret förstår den om begäran misslyckades och kör den 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. Proxyer som aktiverar alla funktioner bildar en Dataplan, och de kan konfigureras dynamiskt med hjälp av Kontrollplan.

Dataplan

Proxyer som är insatta i pods gör att Istio enkelt kan uppfylla de krav vi behöver. Låt oss till exempel kontrollera igen och strömbrytarens funktioner.

Hur återförsök och kretsavbrott 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ök igen). (1)
3. Begäran misslyckas och returneras till proxyn som anropade den.
4. Detta öppnar Circuit Breaker och anropar nästa tjänst för efterföljande förfrågningar. (2)

Detta innebär att du inte behöver använda ett annat Retry-bibliotek, du behöver inte göra din egen implementering av Circuit Breaking och Service Discovery i programmeringsspråket X, Y eller Z. Allt detta och mycket mer finns tillgängligt direkt från lådan i Istio och kräver inte ingen ändringar i koden.

Bra! Nu kanske du vill åka på en resa med Istio, men du 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 fall.

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

Nu är du redo för sjöresan, låt oss bekanta oss med kontrollplanet.

Kontrollplan

Den består av tre komponenter: Pilot, Mixer и Citadel, som arbetar tillsammans för att konfigurera envoys 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) definierade av Istio och specifikt avsedda för detta ändamål. Vad detta betyder för dig är att de verkar vara bara ytterligare en resurs i Kubernetes med en bekant syntax. När den har skapats kommer denna resurs att hämtas av kontrollplanet och appliceras på sändebuden.

Relation av tjänster till Istio

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

För att vara ärlig är tjänster lika medvetna om Istios närvaro som fiskar om vatten när de frågar sig själva, "Vad är vatten egentligen?"

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

Således kan du ta ett fungerande kluster och efter att ha distribuerat Istio-komponenterna kommer tjänsterna som finns i det att fortsätta att fungera, och efter att ha tagit bort dessa komponenter kommer allt att bli bra igen. Det är klart att du i det här fallet kommer att förlora funktionerna 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.

Efter att ha skapat ett kluster och konfigurerat åtkomst till Kubernetes via konsolverktyget kan du installera Istio genom Helm-pakethanteraren.

Roderinstallation

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

Installerar Istio

Ladda ner Istio-resurser från senaste släppningen (den ursprungliga författarens länk till version 1.0.5 har ändrats till den nuvarande, dvs. 1.0.6 - ca. översättning), extrahera innehållet i en katalog, som jag hädanefter kommer att kalla [istio-resources].

För att enkelt identifiera Istio-resurser, skapa ett namnområde i K8s-klustret 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 modifierade standardmallen för att passa oss själva och specificerade följande parametrar:

• global.mtls.enabled installerad i false (dvs mTLS-autentisering är inaktiverad - ungefär)för att förenkla vår dejtingprocess;
• tracing.enabled inkluderar 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 använda de genererade resurserna med kommandot:

$ kubectl apply -f istio.yaml

Installationen av Istio på klustret är klar! Vänta tills alla poddar finns i namnutrymmet istio-system kommer att kunna Running eller Completedgenom att köra kommandot nedan:

$ kubectl get pods -n istio-system

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

Arkitektur för Sentiment Analysis-applikationen

Låt oss använda exemplet med Sentiment Analysis-mikrotjänstapplikationen som används i det redan nämnda Introduktionsartikel till Kubernetes. 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 en Reactjs-applikation;
2. Tjänsten SA-WebApp, som betjänar Sentiment Analysis-frågor;
3. Tjänsten SA-Logik, som utför sig själv sentimentanalys;
4. Tjänsten SA-Feedback, som får feedback från användare om analysens noggrannhet.

I det här diagrammet ser vi, förutom tjänster, även Ingress Controller, som i Kubernetes dirigerar inkommande förfrågningar till lämpliga tjänster. Istio använder ett liknande koncept inom sin Ingress Gateway, mer detaljer om detta kommer att följa.

Kör en applikation med en proxy från Istio

För ytterligare åtgärder som nämns i artikeln, klona ditt arkiv istio-mästarskap. Den innehåller applikationen och manifesten för Kubernetes och Istio.

Sätta in sidvagnar

Insättning kan göras automatiskt eller manuellt. För att automatiskt infoga sidovagnscontainrar måste du ange en etikett för namnutrymmet istio-injection=enabled, vilket görs med följande kommando:

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

Nu kommer varje pod som kommer att distribueras i standardnamnutrymmet (default) kommer att få sin sidovagnsbehållare. För att verifiera detta, låt oss distribuera testapplikationen genom att gå 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, låt oss 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 ser det ut 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 ligger i "kanten" av klustret och låter dig aktivera Istio-funktioner som routing, lastbalansering, säkerhet och övervakning för inkommande trafik.

Ingress Gateway-komponenten och tjänsten som vidarebefordrar den externt 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 med denna IP (jag kommer att referera till den som EXTERNAL-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å ett felmeddelande om tjänsten ej tillgänglig, eftersom som standard blockerar Istio all inkommande trafik, Gateway har ännu inte definierats.

Gateway-resurs

Gateway är en CRD (Custom Resource Definition) i Kubernetes, definierad efter installation av Istio i klustret och möjliggör möjligheten att specificera portar, protokoll och värdar för vilka vi vill tillåta inkommande trafik.

I vårt fall vill vi tillåta HTTP-trafik på port 80 för alla värdar. Uppgiften implementeras enligt 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 är tillåtna inom klustret.

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

Rutter som behöver konfigureras med VirtualServices

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

• Exakt match på vägen / ska skickas till SA-Frontend för att få index.html;
• Prefixerade vägar /static/* måste skickas till SA-Frontend för att ta emot statiska filer som används i frontend, såsom CSS och JavaScript;
• Sökvägar matchade av reguljärt uttryck '^.*.(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 hänvisar till förfrågningar som kommer igenom http-gateway;
 В destination Vilken tjänst som förfrågningar skickas till bestäms.

Notera: Konfigurationen ovan lagras i en fil sa-virtualservice-external.yaml, som även innehåller inställningar för routing i SA-WebApp och SA-Feedback, men har förkortats här i artikeln för korthetens skull.
Låt oss tillämpa VirtualService genom att ringa:

Notera: När vi förbrukar Istio-resurser skapar Kubernetes API Server en händelse som tas emot av Istio Control Plane, och efter det tillämpas den nya konfigurationen 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 i diagrammet:


Istio-IngressGateway-konfiguration för begäran om routing
Applikationen Sentiment Analysis är nu tillgänglig på 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 Envoy-cachar att uppdatera.
Innan du fortsätter, lek med appen lite för att generera trafik. (dess närvaro är nödvändig för klarhet i efterföljande åtgärder - ungefärlig översättning).
Kiali: observerbarhet
För att komma till 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 kontrollera konfigurationen av Istio-komponenter, visualisera tjänster med hjälp av information som samlats in från avlyssning av nätverksförfrågningar, få svar på frågorna "Vem kontaktar vem?", "Vilken version av tjänsten upplever misslyckanden?” och så vidare. I allmänhet, utforska funktionerna hos Kiali innan du går vidare till att visualisera mätvärden med Grafana.

Grafana: statistikvisualisering
Mätvärden som samlas in i Istio går in i Prometheus och visualiseras med Grafana. För att komma till Grafanas administrativa gränssnitt, kör kommandot nedan och öppna sedan http://localhost:3000/:

Klicka på menyn Hem uppe till vänster och välja Istio Service Dashboard i det övre vänstra hörnet, börja med service sa-web-appför att titta på de insamlade mätvärdena:

Det som väntar oss här är en tom och helt tråkig föreställning – ledningen kommer aldrig att godkänna detta. Låt oss skapa en liten belastning med följande kommando:

Nu har vi mycket snyggare grafer, och utöver dem, underbara Prometheus-verktyg för övervakning och Grafana för att visualisera mätvärden som gör att vi kan lära oss om prestanda, hälsa, förbättringar/försämring 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:


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 arbete är mer som mjukvarudetektiver än utvecklare...
Detta är ett vanligt problem inom mikrotjänster och löses av distribuerade spårningssystem, där tjänster skickar en unik header till varandra, varefter denna information vidarebefordras till spårningssystemet, där den jämförs med begärandedata. Här är en illustration:


TraceId används för att identifiera begäran
Istio använder Jaeger Tracer, som implementerar det leverantörsoberoende OpenTracing API-ramverket. Du kan komma åt Jaegers användargränssnitt med följande kommando:

Gå nu till http://localhost:16686/ och välj en tjänst 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 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 skickar begäran till tjänsten sa-web-app.
 I tjänst sa-web-app förfrågan plockas upp av envoy sidovagn, ett "barn" skapas i spann (det är därför vi ser det i spåren) och omdirigeras till containern sa-web-app. (Spänna - en logisk arbetsenhet i Jaeger, som har ett namn, starttid för operationen och dess varaktighet. Spännen kan kapslas och beställas. En riktad acyklisk graf över spann bildar ett spår. - cirka. översätta.)
 Här behandlas förfrågan med metoden sentimentanalys. Dessa spår genereras redan av applikationen, dvs. de krävde kodändringar.
 Från och med detta ögonblick initieras en POST-begäran sa-logik. Spårnings-ID måste vidarebefordras från sa-web-app.
 .

Notera: I steg 4 bör applikationen se rubrikerna som genereras av Istio och skicka dem till efterföljande förfrågningar som visas i bilden nedan:


(A) Istio ansvarar för att vidarebefordra rubriker; (B) Tjänster ansvarar för rubriker
Istio gör det mesta av jobbet eftersom... genererar headers för inkommande förfrågningar, skapar nya spann i varje sidecare och vidarebefordrar dem. 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:

Detta är inte en svår uppgift, men för att förenkla dess genomförande finns det redan 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 missbruk.
Observera att Sentiment Analysis-applikationen demonstrerar implementeringar i Flask, Spring och ASP.NET Core.
Nu när det är klart vad vi får ut ur lådan (eller nästan ur lådan), låt oss titta på finjusterad routing, nätverkstrafikhantering, säkerhet, etc.!
Notera. transl.: Läs om detta i nästa del av material på Istio från Rinor Maloku, vars översättningar kommer att följa på vår blogg inom en snar framtid. UPPDATERING (14 mars): Den andra delen har redan publicerats.
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