Werom nei mikrotsjinsten mei Istio. Diel 1

Noat. transl.: Tsjinstmeshes binne perfoarst in hyt ûnderwerp wurden yn 'e hjoeddeistige ynfrastruktuer foar applikaasjes nei mikroservicearsjitektuer. Wylst Istio op 'e radar kin wêze fan in protte DevOps-yngenieurs, is it in frij nij produkt dat, hoewol it kompleks is yn termen fan funksjes dy't it leveret, in signifikante tiid kin nimme om te witten. De Dútske yngenieur Rinor Maloku, dy't ferantwurdlik is foar cloud computing foar grutte kliïnten by it telekommunikaasjebedriuw Orange Networks, hat in prachtige searje materialen skreaun wêrmei jo fluch en djip yn Istio dûke kinne. Hy begjint syn ferhaal mei wat Istio kin en hoe't jo it fluch mei jo eigen eagen sjen kinne.

Istio - Open Source-projekt, ûntwikkele yn gearwurking mei teams fan Google, IBM en Lyft. It lost de kompleksiteiten op dy't ûntsteane yn applikaasjes basearre op mikrotsjinsten, bygelyks, lykas:

• ferkear behear: timeouts, opnij besykjen, load balancing;
• Feiligens: autentikaasje en autorisaasje fan ein brûkers;
• observabiliteit: tracing, monitoring, logging.

Allegear kinne wurde oplost op it tapassingsnivo, mar dêrnei sille jo tsjinsten net langer "mikro" wêze. Alle ekstra ynspanningen om dizze problemen oan te pakken is in fergriemerij fan bedriuwsboarnen dy't direkt kinne wurde brûkt foar saaklike wearde. Beskôgje in foarbyld:

Projektmanager: Hoe lang duorret it om in feedbackfunksje ta te foegjen?
Untwikkelder: Twa sprints.

MP: Wat?.. It is gewoan CRUD!
R: CRUD dwaan is it maklike diel fan 'e taak, mar wy moatte noch brûkers en tsjinsten ferifiearje en autorisearje. Om't it netwurk ûnbetrouber is, sille jo werhelle oanfragen moatte ymplementearje, lykas circuit breaker patroan yn kliïnten. Ek, om te soargjen dat it hiele systeem net crashte, timeouts en skotsjes (Sjoch letter yn it artikel foar mear details oer beide neamde patroanen.), en om problemen te ûntdekken, tafersjoch, tracing, […]

MP: Oh, lit ús dizze funksje dan gewoan yn 'e Produkttsjinst sette.

Ik tink dat it idee dúdlik is: it bedrach fan stappen en ynspanningen dy't nedich binne om ien tsjinst ta te foegjen is enoarm. Yn dit artikel sille wy sjen hoe't Istio alle hjirboppe neamde kompleksiteit (net rjochte troch saaklike logika) fan tsjinsten ferwideret.

remark: It artikel giet derfan út dat jo wurkje kennis fan Kubernetes. Oars advisearje ik it lêzen myn ynlieding ta Kubernetes en pas dan trochgean mei it lêzen fan dit materiaal.

Istio idee

Yn in wrâld sûnder Istio docht de iene tsjinst direkte oanfragen oan in oare, en yn gefal fan mislearring moat de tsjinst it sels behannelje: in nije poging dwaan, foar in time-out soargje, in circuit breaker iepenje, ensfh.

Netwurkferkear yn Kubernetes

Istio, oan 'e oare kant, biedt in spesjalisearre oplossing dy't folslein apart is fan tsjinsten en funksjes troch ynteraksje mei netwurkynteraksje. En sa ymplementearret it:

• marzje foar flaters: basearre op de status koade yn it antwurd, it begrypt as it fersyk mislearre en resubmits it.
• Canary Rollouts: ferwiist mar in fêst persintaazje oanfragen nei de nije ferzje fan de tsjinst.
• Monitoring en Metrics: hoe lang duorre it foar de tsjinst om te reagearjen?
• Tracing en observabiliteit: Foeget spesjale kopteksten ta oan elk fersyk en traceet se oer it kluster.
• Feiligens: Helje in JWT-token op, autentisearret en autorisearret brûkers.

Dit binne mar in pear fan 'e mooglikheden (echt mar in pear!) Om jo te yntrigearjen. Litte wy no dûke yn 'e technyske details!

Boukunde

Istio ûnderskept alle netwurkferkear en jildt dêr in set regels op, en ynfoegje in tûke proxy yn 'e foarm fan in sidecar-container yn elke pod. Proxy's dy't alle mooglikheden aktivearje foarmje in data fleanmasine, en se kinne dynamysk oanpast mei Kontrole fleanmasine.

data fleanmasine

De proxy's dy't yn 'e pods ynfoege wurde kinne Istio maklik de easken berikke dy't wy nedich binne. Litte wy bygelyks de werhellings en circuit breaker-funksjes kontrolearje.

Hoe opnij besykjen en circuit breaking wurde ymplementearre yn Envoy

Gearfetsje:

1. envoy (wy prate oer in proxy leit yn in sidecar-container, dy't wurdt ferspraat en hoe apart produkt - ca. oerset.) stjoert in fersyk nei it earste eksimplaar fan tsjinst B en mislearret.
2. Envoy Sidecar besiket it nochris (opnij besykje). (1)
3. It mislearre fersyk wurdt weromjûn nei de proxy dy't it neamde.
4. Dit iepenet de Circuit Breaker en ropt de folgjende tsjinst foar folgjende oanfragen. (2)

Dit betsjut dat jo de folgjende Retry-bibleteek net hoege te brûken, jo hoege net jo eigen ymplemintaasje te meitsjen fan Circuit Breaking en Service Discovery yn 'e programmeertaal X, Y of Z. Dit alles en mear is beskikber út 'e doaze yn Istio en net nedich no koade feroarings.

Grut! No kinne jo wol op reis mei Istio, mar der binne noch wat twifels, iepen fragen. As dit in universele oplossing is foar alle gelegenheden yn it libben, dan hawwe jo in legitime fertinking: ommers, al sokke oplossingen binne yndie net geskikt foar alle gefallen.

En as lêste freegje jo: "Is it oanpasber?"

No binne jo klear foar in seereis - en lit ús kunde komme mei Control Plane.

Kontrole fleanmasine

It bestiet út trije komponinten: Piloat, Mixer и Citadel, dy't tegearre envoys konfigurearje om ferkear te routeren, belied oan te passen en telemetrygegevens te sammeljen. Skematysk sjocht it der allegear sa út:

Ynteraksje fan Control Plane mei Data Plane

Envoys (d.w.s. data fleanmasine) wurde konfigurearre mei Kubernetes CRD (Definysjes fan oanpaste boarnen) definieare troch Istio en spesifyk ûntworpen foar dit doel. Wat dit foar jo betsjut is dat se gewoan in oare boarne binne yn Kubernetes mei in bekende syntaksis. Ienris oanmakke, sil dizze boarne wurde ophelle troch it kontrôlefleantúch en tapast op Envoys.

Relaasje fan tsjinsten oan Istio

Wy hawwe de relaasje fan Istio mei tsjinsten beskreaun, mar net oarsom: hoe ferhâlde tsjinsten mei Istio?

Om earlik te wêzen, tsjinsten witte oer de oanwêzigens fan Istio lykas fisken witte oer wetter, as se harsels ôffreegje: "Wat is wetter dochs?".

Yllustraasje Victoria Dimitrakopoulos: Hoe fynsto it wetter? - Wat is wetter dochs?

Sa kinne jo in wurkjende kluster nimme en nei it ynsetten fan de Istio-komponinten sille de tsjinsten dêryn trochgean te wurkjen, en nei it fuortheljen fan dizze komponinten sil alles wer goed wêze. It is dúdlik dat jo yn dit gefal de kânsen fan Istio ferlieze.

Genôch teory - lit ús dizze kennis yn 'e praktyk bringe!

Istio yn 'e praktyk

Istio fereasket in Kubernetes-kluster mei op syn minst 4 vCPU's en 8 GB RAM beskikber. Om it kluster fluch te ferheegjen en de ynstruksjes út it artikel te folgjen, advisearje ik it Google Cloud Platform te brûken, dat nije brûkers biedt fergees $ 300.

Nei it meitsjen fan it kluster en it ynstellen fan tagong ta Kubernetes fia it konsole-hulpprogramma, kinne jo Istio ynstallearje fia de Helm-pakketbehearder.

Helm ynstallaasje

Ynstallearje de Helm-kliïnt op jo kompjûter lykas beskreaun yn offisjele dokumintaasje. Wy sille it brûke om sjabloanen te generearjen foar it ynstallearjen fan Istio yn 'e folgjende seksje.

Ynstallaasje

Download Istio boarnen fan lêste release (de kepling fan 'e orizjinele auteur nei ferzje 1.0.5 is feroare nei de hjoeddeiske, d.w.s. 1.0.6 - sawat oerset.), ekstrahearje de ynhâld yn ien map, wêr't ik nei ferwize sil [istio-resources].

Foar maklike identifikaasje fan Istio-boarnen, meitsje in nammeromte yn it K8s-kluster istio-system:

$ kubectl create namespace istio-system

Folje de ynstallaasje troch nei de map te navigearjen [istio-resources] en it kommando útfiere:

$ 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

Dit kommando sil de kaaikomponinten fan Istio útfiere nei in bestân istio.yaml. Wy hawwe it standert sjabloan foar ússels oanpast troch de folgjende parameters op te jaan:

• global.mtls.enabled ynstallearre yn false (d.w.s. mTLS-ferifikaasje is útskeakele - sawat oerset.)te ferienfâldigjen ús dating proses;
• tracing.enabled makket fersyk tracing mooglik mei Jaeger;
• kiali.enabled ynstallearret Kiali yn in kluster om tsjinsten en ferkear te visualisearjen;
• grafana.enabled ynstallearret Grafana om de sammele metriken te visualisearjen.

Tapasse de generearre boarnen mei it kommando:

$ kubectl apply -f istio.yaml

Ynstallaasje fan Istio yn it kluster is foltôge! Wachtsje oant alle pods yn 'e nammeromte istio-system sil kinne Running of Completedtroch it kommando hjirûnder út te fieren:

$ kubectl get pods -n istio-system

Wy binne no ree om troch te gean nei de folgjende seksje, wêr't wy de applikaasje sille ferheegje en útfiere.

Sentiment Analysis Application Architecture

Litte wy it foarbyld brûke fan 'e Sentiment Analysis-mikroserviceapplikaasje brûkt yn' e al neamde Yntroduksje artikel nei Kubernetes. It is kompleks genôch om de mooglikheden fan Istio yn 'e praktyk sjen te litten.

De applikaasje bestiet út fjouwer mikrotsjinsten:

1. tsjinst SA-Frontend, dy't de front-end-applikaasje tsjinnet op Reactjs;
2. tsjinst SA Web App, dat tsjinnet Sentiment Analysis queries;
3. tsjinst SA Logicdy't sels útfiert sentimint analyze;
4. tsjinst SA Feedback, dy't feedback fan brûkers ûntfangt oer de krektens fan 'e útfierde analyze.

Yn dit diagram sjogge wy neist tsjinsten ek de Ingress Controller, dy't yn Kubernetes ynkommende oanfragen rûtes nei de oerienkommende tsjinsten. Istio brûkt in ferlykber konsept as ûnderdiel fan 'e Ingress Gateway, wêrfan details sille folgje.

In applikaasje starte mei in proxy fan Istio

Foar fierdere operaasjes neamd yn it artikel, klon jo repository istio-masterskip. It befettet de applikaasje en manifesten foar Kubernetes en Istio.

Sidecars ynfoegje

Ynfoegje kin makke wurde automatysk of troch hân. Om automatysk sidecar-konteners yn te foegjen, moatte jo it label ynstelle op de nammeromte istio-injection=enabled, dat wurdt dien troch it folgjende kommando:

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

No elke pod dy't sil wurde ynset yn de standert nammeromte (default) sil syn sidecar-kontainer krije. Om dit te ferifiearjen, litte wy in testapplikaasje ynsette troch nei de rootmap fan it repository te gean [istio-mastery] en it folgjende kommando útfiere:

$ 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

Nei it ynsetten fan de tsjinsten, kontrolearje dat de pods elk twa konteners hawwe (mei de tsjinst sels en syn sidecar) troch it kommando út te fieren kubectl get pods en soargje derfoar dat ûnder de kolom READY wearde oantsjutte 2/2, symbolisearret dat beide konteners rinne:

$ 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

Visueel sjocht it der sa út:

Envoy proxy yn ien fan 'e pods

No't de applikaasje op en rint, moatte wy ynkommende ferkear tastean om de applikaasje yn te gean.

Ingress Gateway

De bêste praktyk om dit te berikken (ferkear yn it kluster tastean) is troch Ingress Gateway yn Istio, dat leit oan 'e "râne" fan it kluster en lit jo Istio-funksjes ynskeakelje lykas routing, loadbalancing, feiligens en tafersjoch foar ynkommende ferkear.

De komponint Ingress Gateway en de tsjinst dy't it nei bûten stjoert, waarden ynstalleare op it kluster tidens de Istio-ynstallaasje. Om it eksterne IP-adres fan in tsjinst te finen, útfiere:

$ 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

Wy sille trochgean mei tagong ta de applikaasje mei dizze IP (ik sil it ferwize as EXTERNAL-IP), dus foar gemak skriuwe wy de wearde nei in fariabele:

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

As jo ​​besykje tagong te krijen ta dit IP fia in browser no, krije jo in Service Unavailable flater, om't standert blokkearret Istio alle ynkommende ferkearoant Gateway wurdt definiearre.

Gateway boarne

Gateway is in CRD (Custom Resource Definition) yn Kubernetes, definiearre nei it ynstallearjen fan Istio yn in kluster en it ynskeakeljen fan de mooglikheid om havens, protokol en hosts oan te jaan wêrfoar wy ynkommende ferkear tastean wolle.

Yn ús gefal wolle wy HTTP-ferkear op poarte 80 tastean foar alle hosts. It probleem wurdt realisearre troch de folgjende definysje (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:
- "*"

Dizze konfiguraasje hat gjin útlis nedich, útsein foar de selector istio: ingressgateway. Mei dizze selector kinne wy ​​oanjaan op hokker Ingress Gateway de konfiguraasje tapast wurdt. Yn ús gefal is dit de Ingress Gateway-controller, dy't standert yn Istio ynstalleare is.

De konfiguraasje wurdt tapast troch it folgjende kommando op te roppen:

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

De gateway jout no tagong ta poarte 80, mar hat gjin idee wêr't de fersiken moatte router wurde. Hjirfoar sille jo nedich hawwe Firtuele tsjinsten.

Firtuele tsjinst boarne

De VirtualService fertelt de Ingress Gateway hoe't fersiken dy't tastien binne binnen it kluster troch te stjoeren.

Oanfragen foar ús applikaasje dy't fia de http-gateway komme, moatte stjoerd wurde nei de sa-frontend, sa-web-app en sa-feedback tsjinsten:

Rûtes dy't wurde konfigureare mei VirtualServices

Beskôgje de oanfragen dy't moatte wurde stjoerd nei SA-Frontend:

• Krekte wedstriid lâns de wei / moat stjoerd wurde nei SA-Frontend om index.html te krijen;
• Paden mei in foarheaksel /static/* moat stjoerd wurde nei SA-Frontend om statyske bestannen te krijen yn 'e frontend, lykas CSS en JavaScript;
• Paden dy't oerienkomme mei de reguliere ekspresje '^.*.(ico|png|jpg)$', moat stjoerd wurde nei SA-Frontend, omdat Dit binne de foto's werjûn op 'e side.

De ymplemintaasje wurdt berikt troch de folgjende konfiguraasje (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

Wichtige punten:

 Dizze VirtualService ferwiist nei oanfragen dy't trochkomme http-poarte;
 В destination definiearret de tsjinst dêr't de oanfragen wurde stjoerd.

remark: De boppesteande konfiguraasje wurdt opslein yn in triem sa-virtualservice-external.yaml, dy't ek ynstellings befettet foar routing nei SA-WebApp en SA-Feedback, mar is hjir yn it artikel foar koarteheid ynkoarte.
VirtualService tapasse troch te skiljen:

remark: As wy Istio-boarnen tapasse, stjoert de Kubernetes API-tsjinner in evenemint dat it Istio Control Plane ûntfangt, en dêrnei wurdt de nije konfiguraasje tapast op de Envoy-proxy fan elke pod. En de Ingress Gateway-controller liket in oare envoy te wêzen konfigureare yn it Control Plane. Dit alles sjocht der sa út yn it diagram:


Istio-IngressGateway-konfiguraasje foar fersykrouting
Sentiment Analysis is no beskikber op http://{EXTERNAL-IP}/. Meitsje jo gjin soargen as jo de status Net fûn krije: soms duorret it wat langer foar't de konfiguraasje effekt hat en foar de Envoy-caches om te aktualisearjen.
Foardat jo trochgean, spielje in bytsje mei de applikaasje om ferkear te generearjen. (syn oanwêzigens is nedich foar dúdlikens yn folgjende aksjes - likernôch transl.).
Kiali: observabiliteit
Om nei de Kiali admin-ynterface te kommen, útfiere it folgjende kommando:

… en iepen http://localhost:20001/troch yn te loggen as admin/admin. Hjir fine jo in protte nuttige funksjes, bygelyks om de konfiguraasje fan Istio-komponinten te kontrolearjen, tsjinsten te visualisearjen fan ynformaasje sammele troch it ûnderskepen fan netwurkoanfragen, antwurden krije op 'e fragen "Wa kontaktet mei wa?", "Hokker ferzje fan 'e tsjinst ûnderfynt mislearrings?” ensafuorthinne. Ferkenne yn 't algemien de mooglikheden fan Kiali foardat jo trochgean mei it visualisearjen fan metriken mei Grafana.

Grafana: fisualisaasje fan metriken
De metriken sammele yn Istio einigje yn Prometheus en wurde visualisearre mei Grafana. Om nei de Grafana admin-ynterface te kommen, útfiere it kommando hjirûnder en iepenje dan http://localhost:3000/:

Troch op it menu te klikken Home lofts boppe en selektearje Istio Service Dashboard yn 'e boppeste linker hoeke, begjinne mei tsjinst sa-web-appom de sammele metriken te besjen:

Hjir wachtsje wy op in lege en folslein saaie foarstelling - it bestjoer sil dit noait goedkarre. Litte wy in lytse lading meitsje mei it folgjende kommando:

No hawwe wy folle moaier grafiken, en neist har, de prachtige ark Prometheus foar tafersjoch en Grafana foar it fisualisearjen fan metriken, wêrtroch't wy kinne leare oer prestaasjes, sûnensstatus, ferbetteringen / degradaasje yn tsjinsten oer de tiid.
As lêste, litte wy sjen nei tracing fan fersyk yn tsjinsten.
Jaeger: tracing
Wy sille tracing nedich wêze, om't hoe mear tsjinsten wy hawwe, hoe dreger it is om ta de oarsaak fan it mislearjen te kommen. Litte wy nei in ienfâldige saak sjen út 'e foto hjirûnder:


Typysk foarbyld fan in willekeurich mislearre fersyk
Fersyk komt, falt - wat is de reden? Earste tsjinst? Of twadde? D'r binne útsûnderingen yn beide - lit ús sjen nei de logs fan elk. Hoe faak hawwe jo josels betrape as jo dit dogge? Us baan liket mear op softwaredetectives dan op ûntwikkelders ...
Dit is in wiidferspraat probleem yn mikrotsjinsten en wurdt oplost troch ferspraat tracingsystemen, wêrby't tsjinsten in unike koptekst nei elkoar trochjaan, wêrnei't dizze ynformaasje wurdt omlaat nei it tracingsysteem, wêr't it wurdt fergelike mei de fersykgegevens. Hjir is in yllustraasje:


TraceId wurdt brûkt om it fersyk te identifisearjen
Istio brûkt Jaeger Tracer, dy't in ferkeaper-ûnôfhinklik OpenTracing API-ramt ymplementearret. Jo kinne tagong krije ta de brûkersynterface fan Jaeger mei it folgjende kommando:

Gean no nei http://localhost:16686/ en selektearje in tsjinst sa-web-app. As de tsjinst net wurdt werjûn yn it útklapmenu, toane / generearje aktiviteit op 'e side en fernij de ynterface. Klikje dêrnei op de knop Spoaren fine, dy't de meast resinte spoaren sjen sil - selektearje elk - detaillearre ynformaasje oer alle spoaren sil ferskine:

Dit spoar lit sjen:

 It fersyk komt binnen istio-ingressgateway (dit is de earste ynteraksje mei ien fan 'e tsjinsten, en in Trace ID wurdt generearre foar it fersyk), wêrnei't de poarte it fersyk nei de tsjinst stjoert sa-web-app.
 Yn 'e tsjinst sa-web-app it fersyk wurdt oppakt troch de Envoy-sidecar, in "bern" wurdt makke yn 'e span (dêrom sjogge wy it yn spoaren) en omlaat nei de kontener sa-web-app. (span - in logyske ienheid fan wurk yn Jaeger, mei in namme, de starttiid fan 'e operaasje en har doer. Spannen kinne wurde nested en besteld. In rjochte acyclyske grafyk fan spans foarmet in spoar. - ca. oerset.)
 Hjir wurdt it fersyk ferwurke troch de metoade sentimentanalyse. Dizze spoaren wurde al oanmakke troch de applikaasje, d.w.s. se easke koade feroarings.
 Fan dit stuit ôf wurdt in POST-fersyk inisjearre yn sa-logika. Trace ID moat trochstjoerd wurde fan sa-web-app.
 ...

remark: Yn stap 4 moat de applikaasje de kopteksten sjen generearre troch Istio en trochjaan oan folgjende oanfragen, lykas werjûn yn 'e ôfbylding hjirûnder:


(A) Header trochstjoere is de ferantwurdlikens fan Istio; (B) Tsjinsten binne ferantwurdlik foar kopteksten
Istio docht it grutste part fan it wurk omdat genereart kopteksten foar ynkommende oanfragen, makket nije spanten yn elke sidecare en stjoert se troch. Sûnder te wurkjen mei kopteksten binnen tsjinsten sil it folsleine tracepaad lykwols ferlern gean.
De folgjende kopteksten moatte wurde beskôge (trochstjoerd):

Dit is in ienfâldige taak, mar om de ymplemintaasje te ferienfâldigjen, is d'r al in protte biblioteken - bygelyks yn 'e sa-web-app-tsjinst stjoert de RestTemplate-kliïnt dizze kopteksten troch as jo gewoan de Jaeger- en OpenTracing-bibleteken tafoegje oan syn ôfhinklikens.
Tink derom dat de Sentiment Analysis-applikaasje ymplemintaasjes toant yn Flask, Spring, en ASP.NET Core.
No't it dúdlik is wat wy út 'e doaze krije (of hast út' e doaze), litte wy nei fine-tuning routing, netwurkferkearbehear, feiligens, en mear sjen!
Noat. transl.: lês der oer yn it folgjende diel fan materialen op Istio fan Rinor Maloku, wêrfan de oersettingen yn 'e heine takomst folgje yn ús blog. UPDATE (14 maart): Twadde diel al publisearre.
PS fan oersetter
Lês ek op ús blog:

 "Werom nei mikrotsjinsten mei Istio": diel 2 (routing, ferkearskontrôle), diel 3 (ferifikaasje en autorisaasje);
 «Conduit - lichtgewicht tsjinstmesh foar Kubernetes";
 «Wat is in tsjinstmesh en wêrom haw ik it nedich [foar in wolkapplikaasje mei mikrotsjinsten]?";
 «In yllustrearre gids foar netwurken yn Kubernetes. Diel 1 en 2";
 «Hoe kaam dizze sidecar-kontener hjir telâne [yn Kubernetes]?".

Boarne: www.habr.com