Itzuli mikrozerbitzuetara Istio-rekin. 1. zatia

Ohar. itzul.: Zerbitzu-sareak, zalantzarik gabe, gaur egungo azpiegituretan, mikrozerbitzuen arkitekturaren ondorengo aplikazioetarako gai nagusi bihurtu dira. Istio DevOps ingeniari askoren radarrean egon daitekeen arren, nahiko produktu berria da, eskaintzen dituen ezaugarrien aldetik konplexua bada ere, denbora asko behar izan dezake ezagutzeko. Rinor Maloku ingeniari alemaniarrak, Orange Networks telekomunikazio-enpresako bezero handientzako hodei-informazioaren arduraduna denak, Istio-n azkar eta sakonki murgiltzeko aukera ematen duten material sorta zoragarria idatzi du. Istio-k zer egin dezakeen eta zure begiekin azkar nola ikusten duzunarekin hasten du bere istorioa.

Istio — Kode irekiko proiektua, Google, IBM eta Lyft taldeekin elkarlanean garatua. Mikrozerbitzuetan oinarritutako aplikazioetan sortzen diren konplexutasunak konpontzen ditu, adibidez:

• trafikoaren kudeaketa: denbora-muga, berriro saiakerak, karga orekatzea;
• Безопасность: azken erabiltzailearen autentifikazioa eta baimena;
• behagarritasuna: trazadura, jarraipena, erregistroa.

Horiek guztiak aplikazio mailan konpondu daitezke, baina horren ondoren zure zerbitzuak ez dira "mikro" izango. Gai horiei aurre egiteko aparteko ahalegin guztia enpresa-baliabideen alferrik galtzea da, negozioaren baliorako zuzenean erabil litezkeenak. Demagun adibide bat:

Proiektu-kudeatzailea: zenbat denbora behar da feedback-a gehitzeko?
Garatzailea: bi sprint.

MP: Zer?... GORDINA besterik ez da!
R: CRUD egitea zereginaren zati erraza da, baina hala ere erabiltzaileak eta zerbitzuak autentifikatu eta baimendu behar ditugu. Sarea fidagarria ez denez, behin eta berriz eskaerak ezarri beharko dituzu, baita etengailuaren eredua bezeroetan. Gainera, sistema osoa huts egin ez zela ziurtatzeko, denbora-muga eta anteparatuak (Aipatutako bi ereduei buruz gehiago jakiteko, ikusi geroago artikuluan - gutxi gorabehera. itzul.), eta arazoak detektatzeko, jarraipena, trazadura, [...]

MP: Oh, jar dezagun funtzio hau Produktuen zerbitzuan.

Ideia argia dela uste dut: zerbitzu bakarra gehitzeko beharrezkoak diren urratsak eta esfortzuak izugarriak dira. Artikulu honetan, Istio-k goian aipatutako konplexutasun guztia (negozio-logikaren xedea ez duena) zerbitzuetatik nola kentzen duen ikusiko dugu.

Kontuan izan: artikuluak Kubernetesen lan-ezagutza duzula suposatzen du. Bestela, irakurtzea gomendatzen dut nire Kubernetes-en aurkezpena eta orduan bakarrik jarraitu material hau irakurtzen.

Istio ideia

Istiorik gabeko mundu batean, zerbitzu batek eskaera zuzenak egiten dizkio beste bati, eta hutsegite kasuan, zerbitzuak berak kudeatu behar du: saiakera berri bat egin, denbora-muga eman, etengailu bat ireki, etab.

Sareko trafikoa Kubernetes-en

Istio-k, berriz, zerbitzu eta funtzioetatik guztiz bereizten den irtenbide espezializatu bat eskaintzen du, sareko interakzioa oztopatuz. Eta horrela ezartzen du:

• akatsen tolerantzia: erantzuneko egoera kodean oinarrituta, eskaerak huts egin duen ala ez ulertzen du eta berriro bidaltzen du.
• Kanariar Ibilgailuak: eskaeren ehuneko finko bat soilik birbideratzen du zerbitzuaren bertsio berrira.
• Jarraipena eta neurketak: zenbat denbora behar izan du zerbitzuak erantzuteko?
• Trazadura eta behagarritasuna: Eskaera bakoitzari goiburu bereziak gehitzen dizkio eta klusterrean zehar trazatzen ditu.
• Безопасность: JWT token bat berreskuratzen du, erabiltzaileak autentifikatu eta baimentzen ditu.

Hauek dira zu intrigatzeko aukera batzuk (batzuk benetan!). Orain murgil gaitezen xehetasun teknikoetan!

Arkitektura

Istio-k sareko trafiko guztia atzematen du eta arau-multzo bat aplikatzen dio, proxy adimendun bat txertatuz alboko edukiontzi moduan pod bakoitzean. Aukera guztiak aktibatzen dituzten proxyek osatzen dute a Datuen planoa, eta dinamikoki doi daitezke Kontrol-hegazkina.

Datuen planoa

Podetan txertatzen diren proxyei esker, Istio-k behar ditugun baldintzak erraz lortzen ditu. Adibidez, egiaztatu ditzagun berriro saiakerak eta etengailuaren funtzioak.

Envoy-en berriro saiakerak eta etenaldiak nola ezartzen diren

Laburtzeko:

1. Jesukristo ( sidecar edukiontzi batean kokatutako proxy bati buruz ari gara, zein banatzen den eta nola produktu bereizia - gutxi gorabehera. itzul.) eskaera bat bidaltzen dio B zerbitzuko lehen instantziari eta huts egiten du.
2. Envoy Sidecar berriro saiatzen ari da (berriro saiatu). (1)
3. Huts egin duen eskaera deitu duen proxyari itzultzen zaio.
4. Honek Circuit Breaker irekitzen du eta hurrengo zerbitzura deitzen du hurrengo eskaeretarako. (2)

Horrek esan nahi du ez duzula hurrengo Berriz saiatu liburutegia erabili beharrik, ez duzula Zirkuitu-hausturaren eta Zerbitzuen Aurkikuntzaren inplementazio propioa egin behar X, Y edo Z programazio-lengoaian. Hori guztia eta gehiago eskuragarri dago. kutxa Istioan eta ez du eskatzen edozein kodea aldaketak.

Bikaina! Orain, agian, bidaia bat egin nahi duzu Istiorekin, baina oraindik zalantza batzuk daude, galdera irekiak. Bizitzako une guztietarako irtenbide unibertsala bada, orduan legezko susmoa duzu: azken finean, irtenbide horiek guztiak ez dira egokiak kasurako.

Eta azkenean galdetzen duzu: "Pertsonalizagarria al da?"

Orain itsasoko bidaiarako prest zaude, eta ezagut dezagun Kontrol Hegazkina.

Kontrol-hegazkina

Hiru osagaiz osatuta dago: Pilot, Mixer и Ziudadela, elkarrekin konfiguratzen duten Envoys trafikoa bideratzeko, politikak aplikatzeko eta telemetria datuak biltzeko. Eskematikoki, dena honelakoa da:

Kontrol-planoaren interakzioa Datu-planoarekin

Envoys (hau da, datu-hegazkina) konfiguratuta daude Kubernetes CRD (Personalizatutako Baliabideen Definizioak) Istio-k definitu eta horretarako bereziki diseinatua. Horrek esan nahi du zuretzat sintaxi ezaguna duten Kubernetes-en beste baliabide bat besterik ez direla. Sortu ondoren, baliabide hori kontrol-hegazkinak jasoko du eta Envoys-i aplikatuko die.

Zerbitzuen harremana Istiorekin

Istiok zerbitzuekin duen harremana deskribatu dugu, baina ez alderantziz: nola erlazionatzen dira zerbitzuak Istiorekin?

Egia esateko, zerbitzuek badakite Istioren presentziaz eta arrainek uraz dakite, euren buruari galdetzen diotenean: “Zer da ura, hala ere?”.

Ilustrazioa Victoria Dimitrakopoulos: Nola gustatzen zaizu ura? - Zer da ura hala ere?

Horrela, lan-kluster bat har dezakezu eta Istio osagaiak zabaldu ondoren, bertan dauden zerbitzuek lanean jarraituko dute, eta osagai horiek kendu ondoren, dena ondo egongo da berriro. Argi dago kasu honetan Istiok ematen dituen aukerak galduko dituzula.

Nahikoa teoria: jar ditzagun ezagutza hori praktikan!

Istio praktikan

Istio-k Kubernetes kluster bat behar du gutxienez 4 vCPU eta 8 GB RAM eskuragarri dituena. Klusterra azkar igotzeko eta artikuluko argibideak jarraitzeko, erabiltzaile berriak eskaintzen dituen Google Cloud Platform erabiltzea gomendatzen dut doan 300 $.

Klusterra sortu eta Kuberneteserako sarbidea kontsolaren utilitatearen bidez konfiguratu ondoren, Istio instalatu dezakezu Helm pakete-kudeatzailearen bidez.

Helm Instalazioa

Instalatu Helm bezeroa zure ordenagailuan atalean deskribatzen den moduan dokumentazio ofiziala. Istio instalatzeko txantiloiak sortzeko erabiliko dugu hurrengo atalean.

Instalazioa

Deskargatu Istio baliabideak azken bertsioa (Jatorrizko egilearen 1.0.5 bertsiorako esteka oraingora aldatu da, hau da, 1.0.6 - gutxi gorabehera itzul.), atera edukiak direktorio bakarrera, izenez aipatuko dudana [istio-resources].

Istio baliabideak erraz identifikatzeko, sortu izen-espazio bat K8s klusterrean istio-system:

$ kubectl create namespace istio-system

Osatu instalazioa direktoriora nabigatuz [istio-resources] eta komandoa exekutatu:

$ 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

Komando honek Istioren funtsezko osagaiak fitxategi batera aterako ditu istio.yaml. Txantiloi estandarra guk geuk aldatu dugu parametro hauek zehaztuz:

• global.mtls.enabled barruan instalatuta false (hau da, mTLS autentifikazioa desgaituta dago - gutxi gorabehera itzul.)gure datazio-prozesua errazteko;
• tracing.enabled Jaeger-ekin eskaerak trazatzea ahalbidetzen du;
• kiali.enabled Kiali kluster batean instalatzen du zerbitzuak eta trafikoa ikusteko;
• grafana.enabled Grafana instalatzen du bildutako neurketak ikusteko.

Aplikatu sortutako baliabideak komandoarekin:

$ kubectl apply -f istio.yaml

Istio-ren instalazioa klusterrean amaitu da! Itxaron lek guztiak izen-eremuan arte istio-system gai izango da Running edo Completedbeheko komandoa exekutatuz:

$ kubectl get pods -n istio-system

Orain prest gaude hurrengo atalera jarraitzeko, non aplikazioa planteatu eta exekutatzeko.

Sentimenduen Analisi Aplikazioen Arkitektura

Erabil dezagun lehen aipatutako honetan erabiltzen den Sentiment Analysis mikrozerbitzuaren aplikazioaren adibidea Kubernetes-en aurkezpen artikulua. Istioren aukerak praktikan erakusteko aski konplexua da.

Aplikazioa lau mikrozerbitzuk osatzen dute:

1. Zerbitzua SA-Frontend, Reactjs-en frontend aplikazioa balio duena;
2. Zerbitzua SA Web App, Sentimenduen Analisirako kontsultak zerbitzatzen dituena;
3. Zerbitzua SA Logikaberak egiten duena sentimenduen analisia;
4. Zerbitzua SA Iritzia, erabiltzaileen iritzia jasotzen duena, egindako analisiaren zehaztasunari buruz.

Diagrama honetan, zerbitzuez gain, Ingress Controller ere ikusten dugu, Kubernetesen sarrerako eskaerak dagozkien zerbitzuetara bideratzen dituena. Istio-k antzeko kontzeptu bat erabiltzen du Ingress Gateway-ren zati gisa, eta horren xehetasunak jarraituko dira.

Istioko proxy batekin aplikazio bat martxan jartzea

Artikuluan aipatutako eragiketa gehiago lortzeko, klonatu zure biltegia istio-maisu. Kubernetes eta Istiorako aplikazioa eta manifestuak ditu.

Alboko karroak sartzea

Txertaketa egin daiteke automatikoki edo eskuz. Alboko ontziak automatikoki txertatzeko, etiketa ezarri behar duzu izenen espazioan istio-injection=enabled, komando honen bidez egiten dena:

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

Orain izen-espazio lehenetsian zabalduko den pod bakoitza (default) bere sidecar edukiontzia lortuko du. Hori egiaztatzeko, inplementatu dezagun proba-aplikazio bat biltegiaren erro-direktoriora joanez [istio-mastery] eta hurrengo komandoa exekutatu:

$ 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

Zerbitzuak zabaldu ondoren, egiaztatu ontziek bi edukiontzi dituztela (zerbitzuarekin eta bere sidecarrekin) komandoa exekutatuz. kubectl get pods eta zutabearen azpian dagoela ziurtatuz READY zehaztutako balioa 2/2, bi edukiontziak martxan daudela sinbolizatuz:

$ 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

Ikusmen hau itxura du:

Envoy proxy ontzietako batean

Orain aplikazioa martxan dagoela, sarrerako trafikoa aplikazioan sartzen utzi behar dugu.

Ingress Gateway

Hori lortzeko praktikarik onena (klusterean trafikoa baimendu) bidezkoa da Ingress Gateway Istio-n, klusterraren "ertzean" kokatuta dagoena eta Istio-ren funtzioak gaitzeko aukera ematen dizu, hala nola bideraketa, karga orekatzea, segurtasuna eta sarrerako trafikoaren jarraipena.

Ingress Gateway osagaia eta kanpora birbidaltzen duen zerbitzua klusterrean instalatu ziren Istio instalazioan. Zerbitzu baten kanpoko IP helbidea jakiteko, exekutatu:

$ 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

IP hau erabiliz aplikaziora sartzen jarraituko dugu (KANPOKO IP bezala aipatuko dut), beraz, erosotasunerako, balioa aldagai batean idatziko dugu:

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

Orain arakatzaile baten bidez IP honetara sartzen saiatzen bazara, Zerbitzua erabilgarri ez dagoen errorea jasoko duzu, zeren lehenespenez, Istio-k sarrerako trafiko guztia blokeatzen duGateway bat definitu arte.

Gateway baliabidea

Gateway Kubernetes-en CRD (Personalizatutako Baliabideen Definizioa) bat da, Istio kluster batean instalatu ondoren definitua eta sarrerako trafikoa baimendu nahi dugun portuak, protokoloak eta ostalariak zehazteko gaitasuna ahalbidetzen duena.

Gure kasuan, HTTP trafikoa baimendu nahi dugu 80 atakan ostalari guztientzat. Arazoa ondoko definizioarekin gauzatzen da (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:
- "*"

Konfigurazio honek ez du azalpenik behar hautatzailea izan ezik istio: ingressgateway. Hautatzaile honekin, konfigurazioa zein Ingress Gatewayri aplikatu behar diogun zehaztu dezakegu. Gure kasuan, Istio-n lehenespenez instalatuta zegoen Ingress Gateway kontrolatzailea da.

Konfigurazioa komando honi deituz aplikatzen da:

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

Atebideak orain 80 atakarako sarbidea ahalbidetzen du, baina ez du ideiarik nondik bideratu eskaerak. Horretarako beharko duzu Zerbitzu birtualak.

Zerbitzu birtualaren baliabidea

Zerbitzu birtualak Ingress Gateway-ri esaten dio nola bideratu kluster barruan onartzen diren eskaerak.

http-gateway bidez gure aplikaziorako eskaerak sa-frontend, sa-web-app eta sa-feedback zerbitzuetara bidali behar dira:

VirtualServices-ekin konfiguratu beharreko ibilbideak

Kontuan izan SA-Frontend-era bidali beharreko eskaerak:

• Bat-etortze zehatza bidean / SA-Frontend-era bidali behar da index.html lortzeko;
• Aurrizkia duten bideak /static/* SA-Frontend-era bidali behar da frontend-ean erabiltzen diren fitxategi estatikoak lortzeko, hala nola CSS eta JavaScript;
• Adierazpen erregulararekin bat datozen bideak '^.*.(ico|png|jpg)$', SA-Frontend-era bidali behar da, izan ere Hauek dira orrialdean agertzen diren irudiak.

Inplementazioa hurrengo konfigurazioarekin lortzen da (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

puntu garrantzitsua:

 Zerbitzu Birtual honek iristen diren eskaerei egiten die erreferentzia http-atebidea;
 В destination eskaerak zein zerbitzura bidaltzen diren definitzen du.

Kontuan izan: goiko konfigurazioa fitxategi batean gordetzen da sa-virtualservice-external.yaml, SA-WebApp eta SA-Feedback-era bideratzeko ezarpenak ere baditu, baina laburtu egin da hemen artikuluan laburtzeko.
Aplikatu VirtualService deituz:

Kontuan izan: Istio baliabideak aplikatzen ditugunean, Kubernetes API Zerbitzariak Istio Kontrol Planak jasotzen duen gertaera bat abiarazten du, eta, horren ostean, konfigurazio berria pod bakoitzaren Envoy proxietan aplikatzen da. Eta Ingress Gateway kontrolagailua Kontrol Planoan konfiguratutako beste Envoy bat dela dirudi. Honek guztiak honela ikusten du diagraman:


Istio-IngressGateway konfigurazioa eskaera bideratzeko
Sentimenduen analisia eskuragarri dago orain http://{EXTERNAL-IP}/. Ez kezkatu Ez aurkitu egoera lortzen baduzu: batzuetan, pixka bat gehiago behar da konfigurazioa indarrean jartzeko eta Envoy cacheak eguneratzeko.
Jarraitu aurretik, jolastu pixka bat aplikazioarekin trafikoa sortzeko (Bere presentzia beharrezkoa da ondorengo ekintzetan argitasuna lortzeko - gutxi gorabehera.).
Kiali: behagarritasuna
Kiali administratzaile interfazera iristeko, exekutatu komando hau:

...eta irekia http://localhost:20001/admin/admin gisa saioa hasita. Hemen ezaugarri erabilgarriak aurkituko dituzu, adibidez, Istio osagaien konfigurazioa egiaztatzeko, sareko eskaerak atzematen jasotako informazioaren zerbitzuak ikusteko, "Nor ari da norekin harremanetan jartzen?", "Zerbitzuaren zein bertsio jasaten ari den galderen erantzunak lortzeko". porrotak?” eta abar. Oro har, arakatu Kiali-ren aukerak Grafana-rekin metrikak bistaratzen hasi aurretik.

Grafana: metrikaren bistaratzea
Istio-n bildutako neurketak Prometheus-en amaitzen dira eta Grafanarekin bistaratzen dira. Grafanako administratzaile interfazera iristeko, exekutatu beheko komandoa eta ireki http://localhost:3000/:

Menuan klik eginez Hasiera goiko ezkerrean eta hautatu Istio Zerbitzuaren Arbela goiko ezkerreko izkinan, hasi zerbitzuarekin sa-web-appbildutako neurketak ikusteko:

Hemen emanaldi huts eta guztiz aspergarri baten zain gaude - zuzendaritzak ez du inoiz hau onartuko. Sortu dezagun karga txiki bat komando honekin:

Orain askoz grafiko politagoak ditugu, eta horiez gain, monitorizaziorako Prometheus eta metrikak bistaratzeko Grafana tresna zoragarriak, errendimendua, osasun egoera, zerbitzuen hobekuntza/degradazioa denboran zehar ezagutzeko aukera emango digutenak.
Azkenik, ikus dezagun zerbitzuetan eskaeraren trazamendua.
Jaeger: trazadura
Trazadura beharko dugu, zenbat eta zerbitzu gehiago izan, orduan eta zailagoa delako porrotaren arrazoira iristea. Ikus dezagun beheko irudiko kasu sinple bat:


Ausazko huts egindako eskaera baten adibide tipikoa
Eskaera dator, erortzen da - zein da arrazoia? Lehen zerbitzua? Edo bigarrena? Bietan salbuespenak daude - ikus ditzagun bakoitzaren erregistroak. Zenbat aldiz harrapatu duzu zure burua hau egiten? Gure lana software detektibeen antza du garatzaileak baino...
Mikrozerbitzuetan oso hedatuta dagoen arazoa da eta banatutako trazatze-sistemek konpontzen dute, zeinetan zerbitzuek goiburu esklusibo bat pasatzen diote elkarri, eta ondoren informazio hori trazatze sistemara birbideratzen da, non eskaeraren datuekin alderatzen den. Hona hemen ilustrazio bat:


TraceId eskaera identifikatzeko erabiltzen da
Istio-k Jaeger Tracer erabiltzen du, saltzailetik independentea den OpenTracing API markoa ezartzen duena. Jaeger erabiltzailearen interfazera atzi dezakezu komando honekin:

Orain joan http://localhost:16686/ eta hautatu zerbitzu bat sa-web-app. Zerbitzua goitibeherako menuan agertzen ez bada, erakutsi/sortu jarduera orrialdean eta eguneratu interfazea. Horren ondoren egin klik botoian Bilatu arrastoak, azken arrastoak erakutsiko dituena - hautatu edozein - aztarna guztien informazio zehatza agertuko da:

Aztarna honek erakusten du:

 Eskaera sartzen da istio-ingressgateway (zerbitzuetako batekin lehenengo interakzioa da, eta Trace ID bat sortzen da eskaerarako), eta ondoren atebideak zerbitzura bidaltzen du eskaera. sa-web-app.
 Zerbitzuan sa-web-app eskaera Envoy sidecar-ak jasotzen du, tartean "ume" bat sortzen da (horregatik ikusten dugu arrastoetan) eta edukiontzira birbideratzen da sa-web-app. (span - Jaeger-en lan-unitate logiko bat, izena, operazioaren hasiera-ordua eta iraupena dituena. Tarteak habiaratu eta ordenatu daitezke. Tarteen grafiko azikliko zuzendu batek arrasto bat osatzen du. - gutxi gorabehera. itzul.)
 Hemen eskaera metodoaren bidez prozesatzen da sentimenduAnalisia. Aztarna horiek dagoeneko aplikazioak sortzen ditu, hau da. kode aldaketak eskatzen zituzten.
 Une honetatik aurrera, POST eskaera bat hasten da sa-logikoa. Bertatik bidali behar da traza IDa sa-web-app.
 ...

Kontuan izan: 4. urratsean, aplikazioak Istio-k sortutako goiburuak ikusi beharko lituzke eta ondorengo eskaerei pasatu, beheko irudian ikusten den moduan:


(A) Goiburuaren birbidaltzea Istioren ardura da; (B) Zerbitzuak goiburuen arduradunak dira
Istiok egiten du lanaren zatirik handiena sarrerako eskaeren goiburuak sortzen ditu, tarte berriak sortzen ditu alboko arreta bakoitzean eta birbidaltzen ditu. Hala ere, zerbitzuen barruan goiburuekin landu gabe, eskaeraren arrastoaren bide osoa galduko da.
Goiburu hauek kontuan hartu behar dira (birbidali):

Zeregin sinplea da, baina ezartzea errazteko, dagoeneko badago liburutegi asko - adibidez, sa-web-app zerbitzuan, RestTemplate bezeroak goiburu hauek birbidaltzen ditu Jaeger eta OpenTracing liburutegiak gehitzen badituzu. bere menpekotasunak.
Kontuan izan Sentiment Analysis aplikazioak Flask, Spring eta ASP.NET Core-en inplementazioak erakusten dituela.
Orain argi dagoenez zer ateratzen ari garen kutxatik (edo ia kutxatik ateratzen ari garen), ikus ditzagun bideratze-ematea, sareko trafikoaren kudeaketa, segurtasuna eta abar!
Ohar. itzul.: irakur ezazu horri buruz Rinor Maloku-ko Istio-ri buruzko materialen hurrengo zatian, eta horien itzulpenak gure blogean izango dira etorkizun hurbilean. UPDATE (Martxoak 14): Bigarren zatia dagoeneko argitaratua.
PS itzultzailetik
Irakurri ere gure blogean:

 "Itzuli mikrozerbitzuetara Istio-rekin": 2. zatia (bideratzea, trafikoa kontrolatzea), 3. zatia (autentifikazioa eta baimena);
 «Conduit - zerbitzu sare arina Kubernetesentzat»;
 «Zer da zerbitzu-sare bat eta zergatik behar dut [mikrozerbitzuekin hodeiko aplikazio baterako]?»;
 «Kubernetes-en sarean lan egiteko gida ilustratua. 1. eta 2. zatiak»;
 «Nola amaitu zen sidecar edukiontzi hau hemen [Kubernetesen]?'.

Iturria: www.habr.com