🥇Zréck op Mikroservicer mat Istio. Deel 1

Note. iwwersat.: Service Meshes sinn definitiv eng relevant Léisung an der moderner Infrastruktur fir Uwendungen no der Mikroservicearchitektur ginn. Wärend Istio vläicht op de Lippen vu villen DevOps Ingenieuren ass, ass et e relativ neit Produkt dat, obwuel et ëmfaassend ass wat d'Fäegkeeten ugeet, e wesentleche Betrag vun Zäit brauch fir vertraut ze ginn. Den däitschen Ingenieur Rinor Maloku, dee fir Cloud Computing fir grouss Clientë bei der Telekommunikatiounsfirma Orange Networks verantwortlech ass, huet eng wonnerbar Serie vu Materialien geschriwwen, déi Iech erlaabt Iech séier an déif an Istio ze tauchen. Hie fänkt seng Geschicht un mat deem wat den Istio am Allgemengen maache kann a wéi een et séier mat Ären eegenen Ae gesäit.

Istio - En Open Source Projet entwéckelt an Zesummenaarbecht mat Teams vu Google, IBM a Lyft. Et léist Komplexitéiten déi a Mikroservicer-baséiert Uwendungen entstinn, wéi:

Verkéier Management: Timeouts, Neiversichten, Belaaschtung;
Sécherheet: Enn Benotzer Authentifikatioun an Autorisatioun;
Observabilitéit: Tracing, Iwwerwachung, Logged.

All dës kënnen um Applikatiounsniveau geléist ginn, awer duerno sinn Är Servicer net méi "Mikro". All déi extra Effort fir dës Probleemer ze léisen ass e Verschwendung vu Firmeressourcen déi direkt fir Geschäftswäert benotzt kënne ginn. Loosst eis e Beispill kucken:

Project Manager: Wéi laang dauert et fir eng Feedback Feature ze addéieren?
Entwéckler: Zwee Sprints.

MP: Wat? .. Et ass just CRUD!
R: CRUD maachen ass den einfachen Deel, awer mir mussen nach ëmmer Benotzer a Servicer authentifizéieren an autoriséieren. Well d'Netzwierk net zouverlässeg ass, musst Dir widderholl Ufroen ëmsetzen, souwéi Circuit breaker Muster an Clienten. Och, fir sécherzestellen, datt de ganze System net crasht, braucht Dir Timeouts an Schotten (fir méi Detailer iwwer béid genannte Mustere, kuckt méi spéit am Artikel - ongeféier Iwwersetzung), a fir Problemer z'entdecken, Iwwerwaachung, Tracing, […]
MP: Oh, dann loosse mer dës Fonktioun einfach an de Produktservice setzen.

Ech mengen d'Iddi ass kloer: d'Quantitéit u Schrëtt an Effort déi néideg ass fir ee Service derbäi ze ginn ass enorm. An dësem Artikel wäerte mir kucken wéi Istio all déi uewe genannte Komplexitéit läscht (dat ass net geduecht fir Geschäftslogik ze sinn) vu Servicer.

Remarque: Dësen Artikel gëtt ugeholl datt Dir Aarbechtskenntnisser vu Kubernetes hutt. Soss, ech recommandéieren liesen meng Aféierung zu Kubernetes an nëmmen duerno weider dëst Material liesen.

Istio Iddi

An enger Welt ouni Istio mécht ee Service direkt Ufroen un en aneren, an am Fall vun engem Echec muss de Service et selwer handhaben: en neie Versuch maachen, en Timeout ubidden, e Circuit Breaker opmaachen, asw.

Netzverkéier an Kubernetes

Istio bitt eng spezialiséiert Léisung, komplett getrennt vu Servicer a funktionnéieren andeems d'Netzkommunikatioun stéiert. An esou implementéiert et:

Feeler Toleranz: Baséierend op de Statuscode an der Äntwert versteet et ob d'Demande gescheitert ass an et nei ausféiert.
Kanaresch Rollouts: redirect nëmmen e fixe Prozentsaz vun Ufroen op déi nei Versioun vum Service.
Iwwerwachung a Metriken: Wéi laang huet et gedauert fir de Service ze reagéieren?
Tracing an Observabilitéit: Füügt speziell Header un all Ufro un a verfollegt se iwwer de Cluster.
Sécherheet: Erhëlt JWT Token, authentifizéiert an autoriséiert Benotzer.

Dëst sinn nëmmen e puer vun de Méiglechkeeten (wierklech nëmmen e puer!) Fir Iech ze intrigéieren. Loosst eis elo an déi technesch Detailer tauchen!

Istio Architektur

Istio interceptéiert all Netzverkéier an applizéiert eng Rei vu Reegele fir et, a setzt e Smart Proxy a Form vun engem Sidecar Container an all Pod. Proxyen déi all Fäegkeeten aktivéieren bilden eng Daten Fliger, a si kënnen dynamesch konfiguréiert ginn benotzt Kontroll Fliger.

Daten Fliger

Proxyen, déi an Pods agebaut ginn, erlaaben Istio einfach den Ufuerderungen ze erfëllen, déi mir brauchen. Zum Beispill, loosst eis d'Wiederprobéieren an de Circuit Breaker Funktiounen iwwerpréiwen.

Wéi Neiversichten a Circuitbriechung am Envoy ëmgesat ginn

Fir ze resuméieren:

spécial (mir schwätzen iwwer e Proxy deen an engem Sidecar Container läit, dee verdeelt gëtt als separat Produit — ca. Iwwersetzung) schéckt eng Ufro un déi éischt Instanz vum Service B a feelt.
Envoy Sidecar probéiert nach eng Kéier (probéieren). (1)
D'Ufro feelt a gëtt zréck an de Proxy deen et genannt huet.
Dëst mécht Circuit Breaker op a rifft den nächste Service fir spéider Ufroen. (2)

Dëst bedeit datt Dir keng aner Retry-Bibliothéik benotze musst, Dir musst net Är eege Implementatioun vu Circuit Breaking a Service Discovery an der Programméiersprooch X, Y oder Z maachen. All dëst a vill méi ass verfügbar aus der Këscht zu Istio a verlaangt net nee Ännerungen am Code.

Super! Elo wëllt Dir vläicht op eng Rees mat Istio goen, awer Dir hutt nach e puer Zweifel, oppe Froen. Wann dëst eng universell Léisung fir all Occasiounen am Liewen ass, dann hutt Dir en natierleche Verdacht: schliisslech sinn all esou Léisungen an der Realitéit fir all Fall net gëeegent.

A schliisslech frot Dir: "Ass et personaliséierbar?"

Elo sidd Dir prett fir d'Mier Rees, loosst eis d'Kontrollplane vertraut maachen.

Kontroll Fliger

Et besteet aus dräi Komponenten: Pilot, Mixer и Zitadell, déi zesumme schaffen fir Envoys ze konfiguréieren fir de Verkéier ze routen, Politiken ëmzesetzen an Telemetrie-Daten ze sammelen. Schematesch gesäit et alles esou aus:

Interaktioun vu Kontrollplane mat Dataplane

Envoys (dh Datefliger) sinn konfiguréiert mat Kubernetes CRD (Custom Ressource Definitiounen) definéiert vun Istio a speziell fir dësen Zweck geduecht. Wat dat fir Iech bedeit ass datt se schéngen just eng aner Ressource a Kubernetes mat enger vertrauter Syntax ze sinn. Eemol erstallt, gëtt dës Ressource vum Kontrollfliger opgeholl an op d'Envoys applizéiert.

Relatioun vun Servicer zu Istio

Mir hunn dem Istio seng Relatioun zu de Servicer beschriwwen, awer net de Géigendeel: wéi bezéie sech d'Servicer op Istio?

Fir éierlech ze sinn, sinn d'Servicer sou bewosst iwwer d'Präsenz vun Istio wéi Fësch vu Waasser, wa se sech froen: "Wat ass Waasser iwwerhaapt?"

Illustration Victoria Dimitrakopoulos: - Wéi gefällt dir d'Waasser? - Wat ass Waasser iwwerhaapt?

Also kënnt Dir en Aarbechtscluster huelen an nodeems Dir d'Istio Komponenten ofgebaut hutt, wäerte d'Servicer, déi an deem sinn, weider schaffen, an nodeems Dir dës Komponenten ewechgeholl hutt, ass alles erëm gutt. Et ass kloer datt Dir an dësem Fall d'Fäegkeete vun Istio verléiert.

Genuch Theorie - loosst eis dëst Wëssen an d'Praxis ëmsetzen!

Istio an der Praxis

Istio erfuerdert e Kubernetes Cluster mat mindestens 4 vCPUs an 8 GB RAM verfügbar. Fir séier e Cluster opzestellen an d'Instruktioune vum Artikel ze befollegen, recommandéieren ech Google Cloud Plattform ze benotzen, déi nei Benotzer ubitt fräi $ 300.

Nodeems Dir e Cluster erstallt hutt an den Zougang zu Kubernetes duerch d'Konsol Utility konfiguréiert hutt, kënnt Dir Istio iwwer den Helm Package Manager installéieren.

Helm Installatioun

Installéiert den Helm Client op Ärem Computer, wéi beschriwwen an offiziell Dokumentatioun. Mir benotzen dëst fir Schablounen ze generéieren fir Istio an der nächster Sektioun z'installéieren.

Installéiert Istio

Download Istio Ressourcen vun lescht Verëffentlechung (de Link vum ursprénglechen Auteur op d'Versioun 1.0.5 gouf op déi aktuell geännert, d.h. 1.0.6 - ongeféier Iwwersetzung), Extrait den Inhalt an een Dossier, deen ech vun elo un nennen [istio-resources].

Fir einfach Istio Ressourcen z'identifizéieren, erstellt e Nummraum am K8s Cluster istio-system:

$ kubectl create namespace istio-system

Fëllt d'Installatioun un andeems Dir an de Verzeichnis gitt [istio-resources] a lafen de Kommando:

$ 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

Dëse Kommando wäert d'Schlësselkomponente vun Istio op eng Datei erausginn istio.yaml. Mir hunn d'Standard Schabloun geännert fir eis selwer ze passen, déi folgend Parameteren uginn:

global.mtls.enabled installéiert an false (dh mTLS Authentifikatioun ass deaktivéiert - ongeféier.)eis ze vereinfachen daten Prozess;
tracing.enabled ëmfaasst Ufro Tracing benotzt Jaeger;
kiali.enabled installéiert Kiali an e Cluster fir Servicer a Verkéier ze visualiséieren;
grafana.enabled installéiert Grafana fir gesammelt Metriken ze visualiséieren.

Loosst eis déi generéiert Ressourcen mam Kommando benotzen:

$ kubectl apply -f istio.yaml

Installatioun vun Istio op de Stärekoup ass fäerdeg! Waart bis all Pods am Nummraum sinn istio-system wäert kënnen Running oder Completedandeems Dir de Kommando hei drënner leeft:

$ kubectl get pods -n istio-system

Elo si mir prett fir an der nächster Sektioun weiderzemaachen, wou mir d'Applikatioun opmaachen a lafen.

Architektur vun der Sentiment Analyse Applikatioun

Loosst eis d'Beispill vun der Sentiment Analysis Microservice Applikatioun benotzen déi an der scho genannter benotzt gëtt Aféierung Artikel zu Kubernetes. Et ass komplex genuch fir dem Istio seng Fäegkeeten an der Praxis ze weisen.

D'Applikatioun besteet aus véier Mikroservicer:

Service SA-Frontend, déi de Frontend vun enger Reactjs Applikatioun servéiert;
Service SA-WebApp, déi Sentiment Analyse Ufroen déngt;
Service SA-Logik, déi sech selwer mécht Gefill Analyse;
Service SA-Feedback, déi Feedback vun de Benotzer iwwer d'Genauegkeet vun der Analyse kritt.

An dësem Diagramm, nieft de Servicer, gesi mir och den Ingress Controller, deen an Kubernetes erakommen Ufroe fir déi entspriechend Servicer leet. Istio benotzt en ähnlecht Konzept a senger Ingress Gateway, méi Detailer vun deem wäerte verfollegen.

Lafen eng Applikatioun mat engem Proxy vun Istio

Fir weider Operatiounen, déi am Artikel ernimmt sinn, klon Äre Repository istio-Maîtrise. Et enthält d'Applikatioun a Manifestatiounen fir Kubernetes an Istio.

Sidecars asetzen

Insertion kann gemaach ginn automatesch oder duerch Hand. Fir automatesch Sidecar Container anzeginn, musst Dir e Label op den Nummraum setzen istio-injection=enabled, wat mam folgendem Kommando gemaach gëtt:

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

Elo all Pod deen am Standardnameraum ofgesat gëtt (default) kritt säi Sidecar Container. Fir dëst z'iwwerpréiwen, loosst eis d'Testapplikatioun ofsetzen andeems Dir an de Root Verzeechnes vum Repository gitt [istio-mastery] a lafen de folgende 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

Nodeems mir d'Servicer ofgesat hunn, loosst eis iwwerpréiwen datt d'Pods zwee Container hunn (mam Service selwer a sengem Sidecar) andeems Dir de Kommando leeft kubectl get pods a sécherstellen, datt ënnert der Kolonn READY spezifizéierte Wäert 2/2, symboliséiert datt béid Container lafen:

$ 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

Visuell gesäit et esou aus:

Envoy Proxy an engem vun de Pods

Elo datt d'Applikatioun op a lafen ass, musse mir den Entréeën Traffic erlaben an d'Applikatioun ze kommen.

Ingress Gateway

Déi bescht Praxis fir dëst z'erreechen (Verkéier am Stärekoup erlaben) ass duerch Ingress Gateway zu Istio, deen um "Rand" vum Cluster läit an erlaabt Iech Istio Features z'aktivéieren wéi Routing, Laaschtbalancéierung, Sécherheet an Iwwerwaachung fir den erakommen Traffic.

D'Ingress Gateway Komponent an de Service deen et extern weiderginn, goufen am Cluster während der Istio Installatioun installéiert. Fir déi extern IP Adress vum Service erauszefannen, lafen:

$ 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

Mir wäerte weider op d'Applikatioun mat dëser IP zougräifen (ech wäert et als EXTERNAL-IP bezeechnen), also fir d'Bequemlechkeet schreiwen mir de Wäert an eng Variabel:

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

Wann Dir probéiert elo op dës IP iwwer e Browser ze kommen, kritt Dir e Service Unavailable Feeler, well Par défaut blockéiert Istio all erakommen Traffic, Gateway ass nach net definéiert.

Gateway Ressource

Gateway ass e CRD (Custom Resource Definition) a Kubernetes, definéiert nodeems Dir Istio am Cluster installéiert huet an d'Fäegkeet erlaabt d'Ports, de Protokoll an d'Host ze spezifizéieren, fir déi mir den Entréeën Traffic erlaben wëllen.

An eisem Fall wëlle mir HTTP-Traffic um Port 80 fir all Hosten erlaben. D'Aufgab gëtt duerch déi folgend Definitioun ëmgesat (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:
- "*"

Dës Konfiguratioun brauch keng Erklärung ausser fir de Selektor istio: ingressgateway. Mat dësem Selector kënne mir spezifizéieren op wéi eng Ingress Gateway d'Konfiguratioun applizéiert gëtt. An eisem Fall ass dëst den Ingress Gateway Controller, deen als Standard an Istio installéiert gouf.

D'Konfiguratioun gëtt applizéiert andeems Dir de folgende Kommando rufft:

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

D'Paart erlaabt elo Zougang zum Hafen 80, awer huet keng Ahnung wou d'Ufroe rutschen. Fir dëst braucht Dir Virtuell Servicer.

VirtualService Ressource

De VirtualService erzielt den Ingress Gateway wéi Dir Ufroen routert déi am Cluster erlaabt sinn.

Ufroe fir eis Applikatioun, déi duerch http-Gateway kommen, mussen un de sa-frontend, sa-web-app a sa-feedback Servicer geschéckt ginn:

Routen déi mat VirtualServices konfiguréiert musse ginn

Loosst eis d'Ufroe kucken, déi un SA-Frontend geschéckt solle ginn:

Genau Match laanscht de Wee / soll op SA-Frontend geschéckt ginn index.html ze kréien;
Präfix Weeër /static/* muss op SA-Frontend geschéckt ginn fir statesch Dateien ze kréien, déi am Frontend benotzt ginn, wéi CSS a JavaScript;
Weeër passend vum reguläre Ausdrock '^.*.(ico|png|jpg)$', muss SA-Frontend geschéckt ginn, well Dëst sinn d'Biller op der Säit ugewisen.

D'Ëmsetzung gëtt duerch déi folgend Konfiguratioun erreecht (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
Wichteg Punkten:

Dëse VirtualService bezitt sech op Ufroen déi duerchkommen http-Gateway;
В destination De Service, un deen Ufroe geschéckt ginn, gëtt festgeluecht.

Remarque: D'Konfiguratioun uewendriwwer gëtt an enger Datei gespäichert sa-virtualservice-external.yaml, déi och Astellunge fir Routing an SA-WebApp an SA-Feedback enthält, awer hei am Artikel fir Kuerzegkeet verkierzt.

Loosst eis VirtualService uwenden andeems Dir urufft:

Remarque: Wa mir Istio Ressourcen verbrauchen, erstellt de Kubernetes API Server en Event dat vum Istio Kontrollplane kritt gëtt, an duerno gëtt déi nei Konfiguratioun op all Pod seng Envoy Proxies applizéiert. An den Ingress Gateway Controller schéngt en aneren Envoy ze sinn, deen am Kontrollplang konfiguréiert ass. All dëst gesäit esou am Diagramm aus:

Istio-IngressGateway Configuratioun fir Ufro Routing

Sentiment Analysis Applikatioun ass elo verfügbar op http://{EXTERNAL-IP}/. Maacht Iech keng Suergen wann Dir de Status Not Found kritt: Heiansdo dauert et e bësse méi laang fir d'Konfiguratioun a Kraaft ze trëtt an d'Envoy-Cache fir ze aktualiséieren.

Ier Dir weidergeet, spillt e bësse mat der App fir Traffic ze generéieren. (seng Präsenz ass néideg fir Kloerheet an de spéideren Aktiounen - ongeféier Iwwersetzung).

Kiali: Beobachtbarkeet

Fir op d'Kiali administrativ Interface ze kommen, fuert de folgende Kommando:

... an oppen http://localhost:20001/, aloggen als admin/admin. Hei fannt Dir vill nëtzlech Fonctiounen, zum Beispill, d'Konfiguratioun vun Istio Komponenten ze kontrolléieren, Servicer ze visualiséieren mat Hëllef vun Informatiounen gesammelt aus Offangen Reseau Ufroen, kréien Äntwerten op d'Froen "Wien kontaktéiert wien?", "Wéi Versioun vum Service erliewt Feeler?" a sou weider. Am Allgemengen, entdeckt d'Fäegkeete vu Kiali ier Dir weider geet fir Metriken mat Grafana ze visualiséieren.

Grafana: Metrik Visualiséierung

Metriken, déi am Istio gesammelt ginn, ginn an de Prometheus a gi mat Grafana visualiséiert. Fir op d'Grafana administrativ Interface ze kommen, fuert de Kommando hei ënnen an dann op http://localhost:3000/:

Klickt op de Menü Home uewe lénks a wielt Istio Service Dashboard am Eck uewe lénks, Start mat Service sa-web-appfir déi gesammelt Metriken ze kucken:

Wat eis hei waart ass eng eidel a komplett langweileg Leeschtung - d'Gestioun wäert dat ni zoustëmmen. Loosst eis eng kleng Laascht erstellen mat dem folgenden Kommando:

Elo hu mir vill méi schéin Grafiken, an zousätzlech zu hinnen, wonnerbar Prometheus Tools fir Iwwerwaachung a Grafana fir Metriken ze visualiséieren, déi eis erlaben iwwer Leeschtung, Gesondheet, Verbesserungen / Degradatioun vun de Servicer iwwer Zäit ze léieren.

Schlussendlech kucke mer d'Tracing Ufroen a Servicer.

Jaeger: Tracing

Mir wäerten Tracing brauchen, well wat méi Servicer mir hunn, dest méi schwéier ass et op d'Ursaach vum Echec ze kommen. Loosst eis en einfache Fall aus dem Bild hei ënnen kucken:

Typesch Beispill vun enger zoufälleg gescheitert Ufro

D'Demande kënnt, fällt - wat ass de Grond? Éischt Service? Oder déi zweet? Et ginn Ausnahmen a béid - loosst eis d'Logbicher vun all kucken. Wéi oft hutt Dir Iech selwer gefaangen dëst ze maachen? Eis Aarbecht ass méi wéi Software Detektiven wéi Entwéckler ...

Dëst ass e gemeinsame Problem a Mikroservicer a gëtt duerch verdeelt Tracing Systemer geléist, an deenen d'Servicer en eenzegaartegen Header matenee passéieren, duerno gëtt dës Informatioun un den Tracing System weidergeleet, wou se mat den Ufrodaten verglach gëtt. Hei ass eng Illustratioun:

TraceId gëtt benotzt fir d'Ufro z'identifizéieren

Istio benotzt Jaeger Tracer, deen de Verkeefer-onofhängege OpenTracing API Kader implementéiert. Dir kënnt op d'Jaeger User Interface mat dem folgenden Kommando zougräifen:

Elo gitt op http://localhost:16686/ a wielt e Service sa-web-app. Wann de Service net am Dropdown-Menü gewise gëtt, weisen / generéieren Aktivitéit op der Säit an aktualiséieren den Interface. Duerno klickt op de Knäppchen Fannt Spuren, déi déi lescht Spure weisen - wielt all - detailléiert Informatioun iwwer all Spure erschéngt:

Dës Spur weist:

D'Demande kënnt eran istio-ingressgateway (dëst ass déi éischt Interaktioun mat engem vun de Servicer, an eng Trace ID gëtt fir d'Ufro generéiert), duerno schéckt de Paart d'Ufro un de Service sa-web-app.
Am Service sa-web-app d'Ufro gëtt vum Envoy Sidecar opgeholl, e "Kand" gëtt an der Spann erstallt (dofir gesi mir et an de Spueren) an an de Container ëmgeleet sa-web-app. (Span - eng logesch Eenheet vun der Aarbecht an Jaeger, déi en Numm huet, Startzäit vun der Operatioun a senger Dauer. Spannungen kënnen nestéiert a bestallt ginn. Eng geriicht azyklesch Grafik vu Spann bilden eng Spuer. — ca. Iwwersetzung)
Hei gëtt d'Ufro duerch d'Methode veraarbecht sentiment Analyse. Dës Spure si scho vun der Applikatioun generéiert, d.h. si verlaangt Code Ännerungen.
Vun dësem Moment un gëtt eng POST Ufro initiéiert an sa-Logik. Trace ID muss weiderginn vun sa-web-app.
...

Remarque: Am Schrëtt 4 soll d'Applikatioun d'Header gesinn, déi vum Istio generéiert ginn an se op spéider Ufroe weiderginn wéi am Bild hei ënnendrënner:

(A) Istio ass verantwortlech fir d'Forwarding Header; (B) Servicer si verantwortlech fir Header

Istio mécht déi meescht Aarbecht well ... generéiert Header fir erakommen Ufroen, erstellt nei Spannungen an all Sidecare a schéckt se weider. Wéi och ëmmer, ouni mat Header bannent Servicer ze schaffen, wäert de vollen Ufro Trace Wee verluer goen.

Déi folgend Header musse berücksichtegt ginn:

Dëst ass keng schwiereg Aufgab, awer fir seng Ëmsetzung ze vereinfachen ass et schonn vill Bibliothéiken - zum Beispill, am sa-Web-App Service, schéckt de RestTemplate Client dës Header weider wann Dir einfach d'Jaeger an d'OpenTracing Bibliothéike bäidréit seng Ofhängegkeeten.

Notéiert datt d'Sentiment Analysis Applikatioun Implementatiounen am Flask, Fréijoer an ASP.NET Core demonstréiert.

Elo datt et kloer ass wat mir aus der Këscht kréien (oder bal aus der Këscht), kucke mer op fein gestëmmte Routing, Netzwierkverkéiersmanagement, Sécherheet, etc.!

Note. iwwersat.: Liest iwwer dëst am nächsten Deel vu Materialien op Istio vum Rinor Maloku, Iwwersetzunge vun deenen op eisem Blog an der nächster Zukunft kommen. Wéi fonctionnéiert (14. Mäerz): Den zweeten Deel ass scho publizéiert.

PS vum Iwwersetzer

Liest och op eisem Blog:

"Zréck op Mikroservicer mat Istio": Deel 2 (Routing, Verkéierskontroll), Deel 3 (Authentifikatioun an Autorisatioun);
«Conduit - liicht Service Mesh fir Kubernetes";
«Wat ass e Service Mesh a firwat brauch ech een [fir eng Cloud Applikatioun mat Mikroservicer]?";
«En illustréierte Guide fir Netzwierker zu Kubernetes. Deel 1 an 2";
«Wéi ass dëse Sidecar Container hei opgehalen [a Kubernetes]?".

Source: will.com