🥇 Tilbake til mikrotjenester med Istio. Del 1

Merk. overs.: Tjenestenett har definitivt blitt en relevant løsning i moderne infrastruktur for applikasjoner som følger mikrotjenestearkitektur. Mens Istio kan være på leppene til mange DevOps-ingeniører, er det et ganske nytt produkt som, selv om det er omfattende når det gjelder egenskapene det gir, kan kreve en betydelig mengde tid å bli kjent med. Den tyske ingeniøren Rinor Maloku, som er ansvarlig for cloud computing for store kunder hos telekommunikasjonsselskapet Orange Networks, har skrevet en fantastisk serie med materialer som lar deg dykke raskt og dypt ned i Istio. Han begynner historien sin med hva Istio kan gjøre generelt og hvordan du raskt kan se det med egne øyne.

Samme — Et åpen kildekode-prosjekt utviklet i samarbeid med team fra Google, IBM og Lyft. Den løser kompleksiteten som oppstår i mikrotjenester-baserte applikasjoner, for eksempel:

Trafikkstyring: tidsavbrudd, forsøk på nytt, lastbalansering;
Безопасность: autentisering og autorisasjon for sluttbruker;
Observerbarhet: sporing, overvåking, logging.

Alle disse kan løses på applikasjonsnivå, men etter det vil ikke tjenestene dine lenger være "mikro". All den ekstra innsatsen for å løse disse problemene er sløsing med selskapets ressurser som kan brukes direkte til forretningsverdi. La oss se på et eksempel:

Prosjektleder: Hvor lang tid tar det å legge til en tilbakemeldingsfunksjon?
Utvikler: To spurter.

MP: Hva?.. Det er bare CRUD!
R: Å gjøre CRUD er den enkle delen, men vi må fortsatt autentisere og autorisere brukere og tjenester. Siden nettverket er upålitelig, må du implementere gjentatte forespørsler, så vel som effektbrytermønster hos klienter. Dessuten, for å sikre at hele systemet ikke krasjer, trenger du tidsavbrudd og skott (for flere detaljer om begge nevnte mønstre, se senere i artikkelen - ca. overs.), og for å oppdage problemer, overvåking, sporing, […]
MP: Å, så la oss bare sette inn denne funksjonen i produkttjenesten.

Jeg tror ideen er klar: mengden trinn og innsats som kreves for å legge til én tjeneste er enorm. I denne artikkelen skal vi se på hvordan Istio fjerner all kompleksiteten nevnt ovenfor (som ikke er ment å være forretningslogikk) fra tjenester.

Note: Denne artikkelen forutsetter at du har praktisk kunnskap om Kubernetes. Ellers anbefaler jeg å lese min introduksjon til Kubernetes og bare etter det fortsett å lese dette materialet.

Istio idé

I en verden uten Istio sender en tjeneste direkte forespørsler til en annen, og ved feil må tjenesten håndtere det selv: gjøre et nytt forsøk, gi en timeout, åpne en strømbryter osv.

Nettverkstrafikk i Kubernetes

Istio tilbyr en spesialisert løsning, fullstendig atskilt fra tjenester og fungerer ved å forstyrre nettverkskommunikasjonen. Og dermed implementerer den:

feiltoleranse: Basert på statuskoden i svaret, forstår den om forespørselen mislyktes og kjører den på nytt.
Kanarieutrullinger: omdirigerer bare en fast prosentandel av forespørslene til den nye versjonen av tjenesten.
Overvåking og beregninger: Hvor lang tid tok det før tjenesten svarte?
Sporing og observerbarhet: Legger til spesielle overskrifter til hver forespørsel og sporer dem på tvers av klyngen.
Безопасность: Henter JWT-token, autentiserer og autoriserer brukere.

Dette er bare noen få av mulighetene (egentlig bare noen få!) for å fascinere deg. La oss nå dykke ned i de tekniske detaljene!

Istio arkitektur

Istio avskjærer all nettverkstrafikk og bruker et sett med regler på den, og setter inn en smart proxy i form av en sidevognsbeholder i hver pod. Proxyer som aktiverer alle funksjoner danner en Dataplan, og de kan konfigureres dynamisk ved hjelp av Kontrollplan.

Dataplan

Proxyer satt inn i pods gjør at Istio enkelt kan oppfylle kravene vi trenger. La oss for eksempel sjekke funksjonene på nytt forsøk og strømbryter.

Hvordan gjenforsøk og kretsbrudd implementeres i Envoy

Oppsummering:

Envoy (vi snakker om en proxy plassert i en sidevognsbeholder, som er distribuert som separat produkt — ca. oversett.) sender en forespørsel til første instans av tjeneste B og mislykkes.
Envoy Sidecar prøver igjen (prøv på nytt). (1)
Forespørselen mislykkes og returneres til proxyen som kalte den.
Dette åpner Circuit Breaker og kaller neste tjeneste for påfølgende forespørsler. (2)

Dette betyr at du ikke trenger å bruke et annet Retry-bibliotek, du trenger ikke å lage din egen implementering av Circuit Breaking og Service Discovery i programmeringsspråket X, Y eller Z. Alt dette og mye mer er tilgjengelig direkte fra esken. i Istio og krever ikke no endringer i koden.

Flott! Nå vil du kanskje dra på reise med Istio, men du har fortsatt noen tvil, åpne spørsmål. Hvis dette er en universell løsning for alle anledninger i livet, så har du en naturlig mistanke: tross alt viser det seg at alle slike løsninger i virkeligheten er uegnet for alle tilfeller.

Og til slutt spør du: "Kan den tilpasses?"

Nå er du klar for sjøreisen, la oss bli kjent med kontrollflyet.

Kontrollplan

Den består av tre komponenter: Pilot, Mixer и Citadel, som jobber sammen for å konfigurere utsendinger til å rute trafikk, håndheve retningslinjer og samle inn telemetridata. Skjematisk ser det hele slik ut:

Interaksjon mellom kontrollplan og dataplan

Utsendinger (dvs. dataplan) konfigureres ved hjelp av Kubernetes CRD (Custom Resource Definitions) definert av Istio og spesielt beregnet for dette formålet. Hva dette betyr for deg er at de ser ut til å være bare en annen ressurs i Kubernetes med en kjent syntaks. Når den er opprettet, vil denne ressursen bli plukket opp av kontrollflyet og overført til utsendingene.

Tjenesteforhold til Istio

Vi har beskrevet Istios forhold til tjenester, men ikke omvendt: hvordan forholder tjenester seg til Istio?

For å være ærlig er tjenester like oppmerksomme på Istios tilstedeværelse som fisk er av vann når de spør seg selv: "Hva er vann likevel?"

illustrasjon Victoria Dimitrakopoulos: - Hvordan liker du vannet? – Hva er vann egentlig?

Dermed kan du ta en fungerende klynge og etter å ha distribuert Istio-komponentene, vil tjenestene som ligger i den fortsette å fungere, og etter å ha fjernet disse komponentene vil alt være bra igjen. Det er klart at i dette tilfellet vil du miste egenskapene som tilbys av Istio.

Nok teori – la oss sette denne kunnskapen ut i praksis!

Istio i praksis

Istio krever en Kubernetes-klynge med minst 4 vCPUer og 8 GB RAM tilgjengelig. For raskt å sette opp en klynge og følge instruksjonene fra artikkelen, anbefaler jeg å bruke Google Cloud Platform, som tilbyr nye brukere gratis $300.

Etter å ha opprettet en klynge og konfigurert tilgang til Kubernetes gjennom konsollverktøyet, kan du installere Istio gjennom Helm-pakkebehandlingen.

Rormontering

Installer Helm-klienten på datamaskinen din, som beskrevet i offisiell dokumentasjon. Vi vil bruke dette til å generere maler for installasjon av Istio i neste avsnitt.

Installerer Istio

Last ned Istio-ressurser fra siste utgivelse (den opprinnelige forfatterens lenke til versjon 1.0.5 er endret til den gjeldende, dvs. 1.0.6 - ca. oversettelse), trekk ut innholdet i én katalog, som jeg heretter vil kalle [istio-resources].

For enkelt å identifisere Istio-ressurser, opprette et navneområde i K8s-klyngen istio-system:

$ kubectl create namespace istio-system

Fullfør installasjonen ved å gå til katalogen [istio-resources] og kjø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 kommandoen vil sende ut nøkkelkomponentene til Istio til en fil istio.yaml. Vi modifiserte standardmalen for å passe oss selv, og spesifiserte følgende parametere:

global.mtls.enabled installert i false (dvs. mTLS-autentisering er deaktivert - ca.)for å forenkle datingprosessen vår;
tracing.enabled inkluderer forespørselssporing ved hjelp av Jaeger;
kiali.enabled installerer Kiali i en klynge for å visualisere tjenester og trafikk;
grafana.enabled installerer Grafana for å visualisere innsamlede beregninger.

La oss bruke de genererte ressursene med kommandoen:

$ kubectl apply -f istio.yaml

Installasjonen av Istio på klyngen er fullført! Vent til alle pods er i navneområdet istio-system vil kunne Running eller Completedved å kjøre kommandoen nedenfor:

$ kubectl get pods -n istio-system

Nå er vi klare til å fortsette i neste seksjon, hvor vi skal få programmet i gang.

Arkitektur av Sentiment Analysis-applikasjonen

La oss bruke eksemplet med Sentiment Analysis-mikrotjenesteapplikasjonen brukt i det allerede nevnte Introduksjonsartikkel til Kubernetes. Det er komplekst nok til å vise Istios evner i praksis.

Applikasjonen består av fire mikrotjenester:

Verktøy SA-Frontend, som betjener frontenden av en Reactjs-applikasjon;
Verktøy SA-WebApp, som serverer sentimentanalysespørsmål;
Verktøy SA-Logikk, som utfører seg selv sentimentanalyse;
Verktøy SA-Tilbakemelding, som mottar tilbakemeldinger fra brukere om nøyaktigheten av analysen.

I dette diagrammet ser vi i tillegg til tjenester også Ingress Controller, som i Kubernetes ruter innkommende forespørsler til de aktuelle tjenestene. Istio bruker et lignende konsept i sin Ingress Gateway, mer detaljer om dette vil følge.

Kjøre en applikasjon med en proxy fra Istio

For ytterligere operasjoner nevnt i artikkelen, klone depotet ditt istio-mestring. Den inneholder applikasjonen og manifestene for Kubernetes og Istio.

Innsetting av sidevogner

Innsetting kan gjøres automatisk eller for hånd. For å sette inn sidevognsbeholdere automatisk, må du sette en etikett til navneområdet istio-injection=enabled, som gjøres med følgende kommando:

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

Nå skal hver pod som skal distribueres i standard navneområde (default) vil motta sidevognsbeholderen. For å bekrefte dette, la oss distribuere testapplikasjonen ved å gå til rotkatalogen til depotet [istio-mastery] og kjører 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

Etter å ha distribuert tjenestene, la oss sjekke at podene har to beholdere (med selve tjenesten og sidevognen) ved å kjøre kommandoen kubectl get pods og sørg for at under kolonnen READY verdi spesifisert 2/2, som symboliserer at begge beholderne kjø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 slik ut:

Utsendingsfullmektig i en av podene

Nå som applikasjonen er oppe og kjører, må vi tillate at innkommende trafikk kommer inn i applikasjonen.

Ingress Gateway

Den beste praksisen for å oppnå dette (tillate trafikk i klyngen) er gjennom Ingress Gateway i Istio, som ligger i "kanten" av klyngen og lar deg aktivere Istio-funksjoner som ruting, lastbalansering, sikkerhet og overvåking for innkommende trafikk.

Ingress Gateway-komponenten og tjenesten som videresender den eksternt ble installert i klyngen under Istio-installasjonen. For å finne ut den eksterne IP-adressen til tjenesten, kjø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 vil fortsette å få tilgang til applikasjonen ved å bruke denne IP-en (jeg vil referere til den som EKSTERN-IP), så for enkelhets skyld vil vi skrive verdien inn i 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 prøver å få tilgang til denne IP-en via en nettleser nå, vil du få feilmeldingen Tjeneste utilgjengelig, fordi som standard blokkerer Istio all innkommende trafikk, Gateway er ennå ikke definert.

Gateway-ressurs

Gateway er en CRD (Custom Resource Definition) i Kubernetes, definert etter installasjon av Istio i klyngen og muliggjør muligheten til å spesifisere portene, protokollen og vertene som vi ønsker å tillate innkommende trafikk for.

I vårt tilfelle ønsker vi å tillate HTTP-trafikk på port 80 for alle verter. Oppgaven implementeres av følgende definisjon (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 konfigurasjonen trenger ingen forklaring bortsett fra velgeren istio: ingressgateway. Med denne velgeren kan vi spesifisere hvilken Ingress Gateway vi skal bruke konfigurasjonen på. I vårt tilfelle er dette Ingress Gateway-kontrolleren, som ble installert som standard i Istio.

Konfigurasjonen brukes ved å kalle følgende kommando:

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

Gatewayen gir nå tilgang til port 80, men har ingen anelse om hvor forespørsler skal rutes. For dette trenger du Virtuelle tjenester.

VirtualService-ressurs

VirtualService forteller Ingress Gateway hvordan den skal rute forespørsler som er tillatt i klyngen.

Forespørsler til vår applikasjon som kommer gjennom http-gateway må sendes til sa-frontend, sa-web-app og sa-feedback-tjenestene:

Ruter som må konfigureres med VirtualServices

La oss se på forespørslene som skal sendes til SA-Frontend:

Nøyaktig match underveis / skal sendes til SA-Frontend for å få index.html;
Prefikserte stier /static/* må sendes til SA-Frontend for å motta statiske filer som brukes i frontend, slik som CSS og JavaScript;
Baner matchet av regulære uttrykk '^.*.(ico|png|jpg)$', må sendes til SA-Frontend, pga Dette er bildene som vises på siden.

Implementeringen oppnås ved følgende konfigurasjon (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
Viktige punkter:

Denne virtuelle tjenesten refererer til forespørsler som kommer gjennom http-gateway;
В destination Tjenesten som forespørsler sendes til, bestemmes.

Note: Konfigurasjonen ovenfor er lagret i en fil sa-virtualservice-external.yaml, som også inneholder innstillinger for ruting i SA-WebApp og SA-Feedback, men er forkortet her i artikkelen for korthets skyld.

La oss bruke VirtualService ved å ringe:

Note: Når vi bruker Istio-ressurser, oppretter Kubernetes API-serveren en hendelse som mottas av Istio-kontrollplanet, og etter det blir den nye konfigurasjonen brukt på hver pods Envoy-proxyer. Og Ingress Gateway-kontrolleren ser ut til å være en annen utsending som er konfigurert i kontrollplanet. Alt dette ser slik ut i diagrammet:

Istio-IngressGateway-konfigurasjon for forespørselsruting

Sentiment Analysis-applikasjonen er nå tilgjengelig på http://{EXTERNAL-IP}/. Ikke bekymre deg hvis du får Ikke funnet-status: Noen ganger tar det litt lengre tid før konfigurasjonen trer i kraft og Envoy-cachene oppdateres.

Før du fortsetter, lek med appen litt for å generere trafikk. (dets tilstedeværelse er nødvendig for klarhet i påfølgende handlinger - ca. oversettelse).

Kiali: observerbarhet

For å komme til Kiali administrative grensesnitt, kjør følgende kommando:

... og åpne http://localhost:20001/, logger på som admin/admin. Her finner du mange nyttige funksjoner, for eksempel for å sjekke konfigurasjonen av Istio-komponenter, visualisere tjenester ved hjelp av informasjon samlet inn fra avskjærende nettverksforespørsler, få svar på spørsmålene "Hvem kontakter hvem?", "Hvilken versjon av tjenesten opplever feil?» og så videre. Generelt, utforsk mulighetene til Kiali før du går videre til å visualisere beregninger med Grafana.

Grafana: metrikkvisualisering

Beregninger samlet inn i Istio går inn i Prometheus og visualiseres med Grafana. For å komme til Grafanas administrative grensesnitt, kjør kommandoen nedenfor og åpne deretter http://localhost:3000/:

Klikk på menyen Hjemprodukt øverst til venstre og velge Istio Service Dashboard i øverste venstre hjørne, start med service sa-web-appfor å se på de innsamlede beregningene:

Det som venter oss her er en tom og helt kjedelig forestilling – ledelsen vil aldri godkjenne dette. La oss lage en liten belastning med følgende kommando:

Nå har vi mye finere grafer, og i tillegg til dem, fantastiske Prometheus-verktøy for overvåking og Grafana for å visualisere beregninger som vil tillate oss å lære om ytelse, helse, forbedringer/degradering i tjenester over tid.

Til slutt, la oss se på sporingsforespørsler i tjenester.

Jaeger: sporing

Vi vil trenge sporing fordi jo flere tjenester vi har, desto vanskeligere er det å finne årsaken til feilen. La oss se på en enkel sak fra bildet nedenfor:

Typisk eksempel på en tilfeldig mislykket forespørsel

Forespørselen kommer, faller - hva er grunnen? Første service? Eller den andre? Det er unntak i begge - la oss se på loggene til hver. Hvor ofte har du tatt deg selv i å gjøre dette? Arbeidet vårt er mer som programvaredetektiver enn utviklere...

Dette er et vanlig problem i mikrotjenester og løses ved distribuerte sporingssystemer, der tjenester sender en unik header til hverandre, hvoretter denne informasjonen videresendes til sporingssystemet, hvor den sammenlignes med forespørselsdataene. Her er en illustrasjon:

TraceId brukes til å identifisere forespørselen

Istio bruker Jaeger Tracer, som implementerer det leverandøruavhengige OpenTracing API-rammeverket. Du kan få tilgang til Jaeger-brukergrensesnittet med følgende kommando:

Gå nå til http://localhost:16686/ og velg en tjeneste sa-web-app. Hvis tjenesten ikke vises i rullegardinmenyen, vis/generer aktivitet på siden og oppdater grensesnittet. Etter det klikker du på knappen Finn spor, som vil vise de siste sporene - velg hvilken som helst - detaljert informasjon om alle sporene vises:

Dette sporet viser:

Forespørselen kommer inn istio-ingressgateway (dette er den første interaksjonen med en av tjenestene, og en sporings-ID genereres for forespørselen), hvoretter gatewayen sender forespørselen til tjenesten sa-web-app.
I tjeneste sa-web-app forespørselen blir plukket opp av envoy-sidevognen, et "barn" opprettes i spennet (det er derfor vi ser det i sporene) og omdirigeres til containeren sa-web-app. (Span - en logisk arbeidsenhet i Jaeger, som har et navn, starttidspunkt for operasjonen og dens varighet. Spenn kan nestes og bestilles. En rettet asyklisk graf over spenn danner et spor. — ca. oversett.)
Her behandles forespørselen etter metoden sentimentanalyse. Disse sporene er allerede generert av applikasjonen, dvs. de krevde kodeendringer.
Fra dette øyeblikket initieres en POST-forespørsel i sa-logikk. Sporings-ID må videresendes fra sa-web-app.
...

Note: I trinn 4 skal applikasjonen se overskriftene generert av Istio og sende dem til påfølgende forespørsler som vist i bildet nedenfor:

(A) Istio er ansvarlig for å videresende overskrifter; (B) Tjenester er ansvarlige for overskrifter

Istio gjør det meste av jobben fordi... genererer overskrifter for innkommende forespørsler, oppretter nye spenn i hver sidecare og videresender dem. Men uten å jobbe med overskrifter i tjenester, vil hele forespørselssporingsbanen gå tapt.

Følgende overskrifter må tas i betraktning:

Dette er ikke en vanskelig oppgave, men for å forenkle implementeringen er det allerede mange biblioteker - for eksempel, i sa-web-app-tjenesten, videresender RestTemplate-klienten disse overskriftene hvis du bare legger til Jaeger- og OpenTracing-bibliotekene til hans avhengighet.

Merk at Sentiment Analysis-applikasjonen demonstrerer implementeringer i Flask, Spring og ASP.NET Core.

Nå som det er klart hva vi får ut av esken (eller nesten ut av esken), la oss se på finjustert ruting, administrasjon av nettverkstrafikk, sikkerhet osv.!

Merk. overs.: Les om dette i neste del av materialer på Istio fra Rinor Maloku, oversettelser av disse vil følge på bloggen vår i nær fremtid. OPPDATERING (14. mars): Den andre delen er allerede publisert.

PS fra oversetter

Les også på bloggen vår:

"Tilbake til mikrotjenester med Istio": del 2 (ruting, trafikkkontroll), del 3 (autentisering og autorisasjon);
«Conduit - lettvekts servicenett for Kubernetes";
«Hva er et tjenestenettverk og hvorfor trenger jeg det [for en skyapplikasjon med mikrotjenester]?";
«En illustrert guide til nettverksbygging i Kubernetes. Del 1 og 2";
«Hvordan havnet denne sidevognscontaineren her [i Kubernetes]?'.

Kilde: www.habr.com