🥇Tilbage til mikrotjenester med Istio. Del 1

Bemærk. overs.: Tjenestenet er bestemt blevet et varmt emne i nutidens infrastruktur for applikationer, der følger mikroservicearkitektur. Selvom Istio kan være på radaren hos mange DevOps-ingeniører, er det et ret nyt produkt, der, selvom det er komplekst med hensyn til funktioner, det giver, kan tage en betydelig mængde tid at lære at kende. Den tyske ingeniør Rinor Maloku, som er ansvarlig for cloud computing for store kunder hos teleselskabet Orange Networks, har skrevet en vidunderlig række af materialer, der giver dig mulighed for hurtigt og dybt at dykke ned i Istio. Han begynder sin historie med, hvad Istio kan, og hvordan du hurtigt kan se det med dine egne øjne.

Samme — Open Source-projekt, udviklet i samarbejde med teams fra Google, IBM og Lyft. Det løser de kompleksiteter, der opstår i applikationer baseret på mikrotjenester, for eksempel, såsom:

trafikstyring: timeouts, genforsøg, belastningsbalancering;
Безопасность: slutbrugergodkendelse og autorisation;
observerbarhed: sporing, overvågning, logning.

Alle af dem kan løses på applikationsniveau, men derefter vil dine tjenester ikke længere være "mikro". Al den ekstra indsats for at løse disse problemer er spild af virksomhedens ressourcer, der kan bruges direkte til forretningsværdi. Overvej et eksempel:

Projektleder: Hvor lang tid tager det at tilføje en feedbackfunktion?
Udvikler: To spurter.

MP: Hvad?.. Det er bare CRUD!
R: At lave CRUD er den nemme del af opgaven, men vi skal stadig godkende og autorisere brugere og tjenester. Da netværket er upålideligt, bliver du nødt til at implementere gentagne anmodninger, samt afbrydermønster hos klienter. Også for at sikre, at hele systemet ikke gik ned, timeouts og skotter (Se senere i artiklen for flere detaljer om begge nævnte mønstre.), og for at opdage problemer, overvågning, sporing, […]
MP: Åh, lad os så bare sætte denne funktion ind i produkttjenesten.

Jeg tror, ideen er klar: mængden af trin og indsats, der kræves for at tilføje en enkelt tjeneste, er enorm. I denne artikel tager vi et kig på, hvordan Istio fjerner al den kompleksitet, der er nævnt ovenfor (ikke målrettet af forretningslogik) fra tjenester.

Bemærk: Artiklen forudsætter, at du har praktisk viden om Kubernetes. Ellers anbefaler jeg at læse min introduktion til Kubernetes og først derefter fortsætte med at læse dette materiale.

Istio idé

I en verden uden Istio stiller en tjeneste direkte henvendelser til en anden, og i tilfælde af fejl skal tjenesten selv klare det: lav et nyt forsøg, sørge for en timeout, åbne en strømafbryder osv.

Netværkstrafik i Kubernetes

Istio tilbyder på den anden side en specialiseret løsning, der er fuldstændig adskilt fra tjenester og funktioner ved at forstyrre netværksinteraktion. Og dermed implementerer den:

fejltolerance: baseret på statuskoden i svaret, forstår den, om anmodningen mislykkedes, og sender den igen.
Kanariske udrulninger: omdirigerer kun en fast procentdel af anmodninger til den nye version af tjenesten.
Overvågning og målinger: Hvor lang tid tog det for tjenesten at reagere?
Sporing og observerbarhed: Tilføjer specielle overskrifter til hver anmodning og sporer dem på tværs af klyngen.
Безопасность: Henter et JWT-token, godkender og autoriserer brugere.

Dette er blot nogle få af mulighederne (virkelig kun nogle få!) for at fascinere dig. Lad os nu dykke ned i de tekniske detaljer!

Arkitektur

Istio opsnapper al netværkstrafik og anvender et sæt regler på den ved at indsætte en smart proxy i form af en sidevognsbeholder i hver pod. Fuldmagter, der aktiverer alle muligheder, danner en Datafly, og de kan justeres dynamisk med Kontrolplan.

Datafly

Proxyerne, der indsættes i pods, gør det muligt for Istio nemt at opnå de krav, vi har brug for. Lad os f.eks. tjekke genforsøg og strømafbryderfunktionerne.

Hvordan genforsøg og kredsløbsbrud implementeres i Envoy

For at opsummere:

udsending (vi taler om en proxy placeret i en sidevognscontainer, som distribueres og hvordan separat produkt - ca. oversættelse) sender en anmodning til den første instans af tjeneste B og mislykkes.
Envoy Sidecar prøver igen (prøve igen). (1)
Den mislykkede anmodning returneres til den proxy, der kaldte den.
Dette åbner Circuit Breaker og kalder den næste service for efterfølgende anmodninger. (2)

Det betyder, at du ikke behøver at bruge det næste Gentry-bibliotek, du behøver ikke at lave din egen implementering af Circuit Breaking og Service Discovery i programmeringssproget X, Y eller Z. Alt dette og mere er tilgængeligt fra boks i Istio og kræver ikke nej kodeændringer.

Store! Nu vil du måske tage på rejse med Istio, men der er stadig nogle tvivl, åbne spørgsmål. Hvis dette er en universel løsning til alle lejligheder i livet, så har du en berettiget mistanke: trods alt er alle sådanne løsninger faktisk ikke egnede til nogen sag.

Og til sidst spørger du: "Kan det tilpasses?"

Nu er du klar til en sørejse – og lad os stifte bekendtskab med Control Plane.

Kontrolplan

Den består af tre komponenter: Pilot, Mixer и Citadel, som sammen konfigurerer udsendinge til at dirigere trafik, anvende politikker og indsamle telemetridata. Skematisk ser det hele sådan ud:

Interaktion mellem kontrolplan og dataplan

Udsendinge (dvs. dataplan) er konfigureret med Kubernetes CRD (Custom Resource Definitions) defineret af Istio og specielt designet til dette formål. Hvad dette betyder for dig er, at de blot er endnu en ressource i Kubernetes med en velkendt syntaks. Når den er oprettet, vil denne ressource blive samlet op af kontrolplanet og overført til udsendinge.

Relation af tjenester til Istio

Vi har beskrevet Istios forhold til services, men ikke omvendt: hvordan forholder services sig til Istio?

For at være ærlig ved tjenesterne om tilstedeværelsen af Istio såvel som fisk kender til vand, når de spørger sig selv: "Hvad er vand overhovedet?".

illustration Victoria Dimitrakopoulos: Hvordan kan du lide vandet? - Hvad er vand overhovedet?

Således kan du tage en fungerende klynge, og efter at have installeret Istio-komponenterne, vil tjenesterne i den fortsætte med at fungere, og efter at have fjernet disse komponenter, vil alt være i orden igen. Det er klart, at du i dette tilfælde vil miste de muligheder, Istio giver.

Nok teori - lad os omsætte denne viden i praksis!

Istio i praksis

Istio kræver en Kubernetes-klynge med mindst 4 vCPU'er og 8 GB RAM tilgængelig. For hurtigt at hæve klyngen og følge instruktionerne fra artiklen anbefaler jeg at bruge Google Cloud Platform, som tilbyder nye brugere gratis $300.

Efter at have oprettet klyngen og konfigureret adgang til Kubernetes gennem konsolværktøjet, kan du installere Istio gennem Helm-pakkehåndteringen.

Hjelm installation

Installer Helm-klienten på din computer som beskrevet i officiel dokumentation. Vi vil bruge det til at generere skabeloner til installation af Istio i næste afsnit.

Installation

Download Istio-ressourcer fra seneste udgivelse (den originale forfatters link til version 1.0.5 er blevet ændret til den nuværende, dvs. 1.0.6 - ca. oversættelse), udtræk indholdet til en enkelt mappe, som jeg vil referere til som [istio-resources].

For nem identifikation af Istio-ressourcer skal du oprette et navneområde i K8s-klyngen istio-system:

$ kubectl create namespace istio-system

Fuldfør installationen ved at navigere til biblioteket [istio-resources] og køre kommandoen:

$ 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

Denne kommando vil udlæse nøglekomponenterne i Istio til en fil istio.yaml. Vi har ændret standardskabelonen for os selv ved at specificere følgende parametre:

global.mtls.enabled installeret i false (dvs. mTLS-godkendelse er deaktiveret - ca. oversættelse)for at forenkle vores datingproces;
tracing.enabled muliggør sporing af anmodninger med Jaeger;
kiali.enabled installerer Kiali i en klynge for at visualisere tjenester og trafik;
grafana.enabled installerer Grafana for at visualisere de indsamlede metrics.

Anvend de genererede ressourcer med kommandoen:

$ kubectl apply -f istio.yaml

Installationen af Istio i klyngen er færdig! Vent, indtil alle pods i navnerummet istio-system vil være i stand Running eller Completedved at køre kommandoen nedenfor:

$ kubectl get pods -n istio-system

Vi er nu klar til at fortsætte til næste afsnit, hvor vi vil rejse og køre applikationen.

Applikationsarkitektur for sentimentanalyse

Lad os bruge eksemplet med Sentiment Analysis-mikrotjenesteapplikationen, der blev brugt i det allerede nævnte Introduktionsartikel til Kubernetes. Det er komplekst nok til at vise Istios muligheder i praksis.

Applikationen består af fire mikrotjenester:

Service SA-frontend, som betjener front-end-applikationen på Reactjs;
Service SA Web App, som serverer Sentiment Analysis-forespørgsler;
Service SA Logiksom udfører sig selv følelsesanalyse;
Service SA Feedback, som modtager feedback fra brugerne om nøjagtigheden af den udførte analyse.

I dette diagram ser vi udover tjenester også Ingress Controller, som i Kubernetes dirigerer indgående forespørgsler til de tilsvarende tjenester. Istio bruger et lignende koncept som en del af Ingress Gateway, hvis detaljer vil følge.

Start af en applikation med en proxy fra Istio

For yderligere operationer nævnt i artiklen, klon dit lager istio-mesterskab. Den indeholder applikationen og manifester for Kubernetes og Istio.

Indsættelse af sidevogne

Indsættelse kan foretages automatisk eller med hånden. For automatisk at indsætte sidevognsbeholdere skal du indstille etiketten til navneområdet istio-injection=enabled, hvilket udføres af følgende kommando:

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

Nu skal hver pod, der vil blive implementeret i standardnavnerummet (default) får sin sidevognsbeholder. For at bekræfte dette, lad os implementere et testprogram ved at gå til rodbiblioteket i depotet [istio-mastery] og køre følgende 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

Når du har implementeret tjenesterne, skal du kontrollere, at pods har to beholdere (med selve tjenesten og dens sidevogn) ved at køre kommandoen kubectl get pods og sørg for, at under kolonnen READY værdi angivet 2/2, der symboliserer, at begge containere kører:

$ 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

Visuelt ser det sådan ud:

Envoy proxy i en af pods

Nu hvor applikationen er oppe at køre, skal vi tillade indgående trafik at komme ind i applikationen.

Ingress Gateway

Den bedste praksis for at opnå dette (tillad trafik i klyngen) er via Ingress Gateway i Istio, som er placeret i "kanten" af klyngen og giver dig mulighed for at aktivere Istio-funktioner såsom routing, belastningsbalancering, sikkerhed og overvågning af indgående trafik.

Ingress Gateway-komponenten og den service, der videresender den udad, blev installeret på klyngen under Istio-installationen. For at finde ud af en tjenestes eksterne IP-adresse skal du køre:

$ 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 vil fortsætte med at få adgang til applikationen ved hjælp af denne IP (jeg vil referere til den som EXTERNAL-IP), så for nemheds skyld skriver vi værdien til en variabel:

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

Hvis du forsøger at få adgang til denne IP via en browser nu, får du fejlmeddelelsen Service Unavailable, fordi som standard blokerer Istio al indgående trafikindtil Gateway er defineret.

Gateway ressource

Gateway er en CRD (Custom Resource Definition) i Kubernetes, defineret efter installation af Istio i en klynge og muliggør muligheden for at specificere porte, protokol og værter, for hvilke vi ønsker at tillade indgående trafik.

I vores tilfælde ønsker vi at tillade HTTP-trafik på port 80 for alle værter. Problemet realiseres med følgende 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:
- "*"

Denne konfiguration behøver ingen forklaring undtagen for vælgeren istio: ingressgateway. Med denne vælger kan vi angive, hvilken Ingress Gateway, der skal anvendes konfigurationen på. I vores tilfælde er dette Ingress Gateway-controlleren, som blev installeret som standard i Istio.

Konfigurationen anvendes ved at kalde følgende kommando:

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

Gatewayen giver nu adgang til port 80, men har ingen idé om, hvor anmodningerne skal rutes. Til dette skal du bruge Virtuelle tjenester.

Virtual Service ressource

VirtualService fortæller Ingress Gateway, hvordan man dirigerer anmodninger, der er tilladt i klyngen.

Anmodninger til vores applikation, der kommer gennem http-gatewayen, skal sendes til sa-frontend, sa-web-app og sa-feedback-tjenesterne:

Ruter, der skal konfigureres med VirtualServices

Overvej de anmodninger, der skal sendes til SA-Frontend:

Præcis match undervejs / skal sendes til SA-Frontend for at få index.html;
Stier med et præfiks /static/* skal sendes til SA-Frontend for at få statiske filer brugt i frontend, såsom CSS og JavaScript;
Stier, der matcher det regulære udtryk '^.*.(ico|png|jpg)$', skal sendes til SA-Frontend, pga Det er billederne, der vises på siden.

Implementeringen opnås ved følgende 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
Vigtige punkter:

Denne VirtualService henviser til anmodninger, der kommer igennem http-gateway;
В destination definerer den service, som anmodningerne sendes til.

Bemærk: Konfigurationen ovenfor er gemt i en fil sa-virtualservice-external.yaml, som også indeholder indstillinger for routing til SA-WebApp og SA-Feedback, men for kortheds skyld er blevet forkortet her i artiklen.

Anvend VirtualService ved at ringe til:

Bemærk: Når vi anvender Istio-ressourcer, udløser Kubernetes API-serveren en hændelse, som Istio-kontrolplanet modtager, og derefter anvendes den nye konfiguration på hver pods Envoy-proxyer. Og Ingress Gateway-controlleren ser ud til at være en anden udsending, der er konfigureret i kontrolplanet. Alt dette ser sådan ud i diagrammet:

Istio-IngressGateway-konfiguration til anmodningsrouting

Stemningsanalyse er nu tilgængelig på http://{EXTERNAL-IP}/. Bare rolig, hvis du får statussen Ikke fundet: nogle gange tager det lidt længere tid, før konfigurationen træder i kraft, og for Envoy-cachene at opdatere.

Før du fortsætter, skal du lege lidt med programmet for at generere trafik. (dets tilstedeværelse er nødvendig for klarhed i efterfølgende handlinger - ca. oversættelse).

Kiali: observerbarhed

For at komme til Kiali admin-grænsefladen skal du køre følgende kommando:

...og åben http://localhost:20001/ved at logge ind som admin/admin. Her finder du mange nyttige funktioner, for eksempel til at kontrollere konfigurationen af Istio-komponenter, visualisere tjenester fra information indsamlet ved at opsnappe netværksanmodninger, få svar på spørgsmålene "Hvem kontakter hvem?", "Hvilken version af tjenesten oplever fiaskoer?” og så videre. Udforsk generelt mulighederne i Kiali, før du går videre til at visualisere metrikker med Grafana.

Grafana: visualisering af metrikker

De målinger, der er indsamlet i Istio, ender i Prometheus og visualiseres med Grafana. For at komme til Grafana-administrationsgrænsefladen skal du køre kommandoen nedenfor og derefter åbne http://localhost:3000/:

Ved at klikke på menuen Home øverst til venstre og vælg Istio Service Dashboard i øverste venstre hjørne, start med service sa-web-appfor at se de indsamlede metrics:

Her venter vi på en tom og fuldstændig kedelig forestilling – det vil ledelsen aldrig godkende. Lad os oprette en lille belastning med følgende kommando:

Nu har vi meget smukkere grafer, og udover dem, de vidunderlige værktøjer Prometheus til overvågning og Grafana til visualisering af metrikker, som vil give os mulighed for at lære om ydeevne, sundhedstilstand, forbedringer/forringelse af tjenester over tid.

Lad os endelig se på anmodningssporing i tjenester.

Jaeger: sporing

Vi får brug for sporing, for jo flere tjenester vi har, jo sværere er det at finde årsagen til fejlen. Lad os se på en simpel sag fra billedet nedenfor:

Typisk eksempel på en tilfældig mislykket anmodning

Anmodningen kommer, falder - hvad er grunden? Første service? Eller anden? Der er undtagelser i begge - lad os se på logfilerne for hver. Hvor ofte har du taget dig selv i at gøre dette? Vores job er mere som softwaredetektiver end udviklere...

Dette er et udbredt problem i mikrotjenester og løses af distribuerede sporingssystemer, hvor tjenester videregiver en unik header til hinanden, hvorefter denne information omdirigeres til sporingssystemet, hvor den sammenlignes med anmodningsdataene. Her er en illustration:

TraceId bruges til at identificere anmodningen

Istio bruger Jaeger Tracer, som implementerer en leverandøruafhængig OpenTracing API-ramme. Du kan få adgang til Jaeger-brugergrænsefladen med følgende kommando:

Gå nu til http://localhost:16686/ og vælg en tjeneste sa-web-app. Hvis tjenesten ikke vises i rullemenuen, skal du vise/generere aktivitet på siden og opdatere grænsefladen. Klik derefter på knappen Find spor, som vil vise de seneste spor - vælg en hvilken som helst - detaljerede oplysninger om alle spor vises:

Dette spor viser:

Anmodningen kommer ind istio-ingressgateway (dette er den første interaktion med en af tjenesterne, og der genereres et Trace ID for anmodningen), hvorefter gatewayen sender anmodningen til tjenesten sa-web-app.
I brug sa-web-app anmodningen opfanges af envoy-sidevognen, et "barn" oprettes i spændet (det er derfor, vi ser det i spor) og omdirigeres til containeren sa-web-app. (Span - en logisk arbejdsenhed i Jaeger, der har et navn, starttidspunktet for operationen og dens varighed. Spænd kan indlejres og bestilles. En rettet acyklisk graf over spænder danner et spor. - ca. oversættelse)
Her behandles anmodningen efter metoden sentimentanalyse. Disse spor er allerede genereret af applikationen, dvs. de krævede kodeændringer.
Fra dette øjeblik startes en POST-anmodning i sa-logik. Spor ID skal videresendes fra sa-web-app.
...

Bemærk: I trin 4 skal applikationen se overskrifterne genereret af Istio og videregive dem til efterfølgende anmodninger, som vist på billedet nedenfor:

(A) Videresendelse af overskrifter er Istios ansvar; (B) Tjenester er ansvarlige for overskrifter

Istio udfører hovedparten af arbejdet pga genererer overskrifter til indgående anmodninger, opretter nye spænd i hver sidecare og videresender dem. Men uden at arbejde med overskrifter inde i tjenester, vil hele anmodningssporingsstien gå tabt.

Følgende overskrifter skal tages i betragtning (videresendt):

Dette er en simpel opgave, men for at forenkle implementeringen er der allerede mange biblioteker - for eksempel i sa-web-app-tjenesten videresender RestTemplate-klienten disse overskrifter, hvis du blot tilføjer Jaeger- og OpenTracing-bibliotekerne til dens afhængigheder.

Bemærk, at Sentiment Analysis-applikationen demonstrerer implementeringer i Flask, Spring og ASP.NET Core.

Nu hvor det er klart, hvad vi får ud af kassen (eller næsten ud af kassen), lad os se på finjustering af routing, netværkstrafikstyring, sikkerhed og meget mere!

Bemærk. overs.: læs om dette i næste del af materialer på Istio af Rinor Maloku, hvis oversættelser vil følge på vores blog i den nærmeste fremtid. OPDATER (14. marts): Anden del allerede offentliggjort.

PS fra oversætteren

Læs også på vores blog:

"Tilbage til mikrotjenester med Istio": del 2 (ruteplanlægning, trafikkontrol), del 3 (godkendelse og autorisation);
«Conduit - letvægts servicenet til Kubernetes";
«Hvad er et servicemesh, og hvorfor har jeg brug for det [til en cloud-applikation med mikrotjenester]?";
«En illustreret guide til netværk i Kubernetes. Del 1 og 2";
«Hvordan endte denne sidevognscontainer her [i Kubernetes]?'.

Kilde: www.habr.com