Reen al mikroservoj kun Istio. Parto 1

Notu. transl.: Servaj retoj sendube fariĝis varma temo en la hodiaŭa infrastrukturo por aplikoj post mikroserva arkitekturo. Dum Istio povas esti sur la radaro de multaj DevOps-inĝenieroj, ĝi estas sufiĉe nova produkto, kiu, kvankam kompleksa laŭ funkcioj kiujn ĝi provizas, povas preni signifan tempon por ekkoni. La germana inĝeniero Rinor Maloku, kiu respondecas pri nuba komputado por grandaj klientoj ĉe la telekomunika kompanio Orange Networks, verkis mirindan serion da materialoj, kiuj permesas vin rapide kaj profunde plonĝi en Istio. Li komencas sian rakonton per tio, kion Istio povas fari kaj kiel vi povas rapide vidi ĝin per viaj propraj okuloj.

Istio — Open Source-projekto, evoluigita kunlabore kun teamoj de Google, IBM kaj Lyft. Ĝi solvas la kompleksaĵojn kiuj ŝprucas en aplikoj bazitaj sur mikroservoj, ekzemple, kiel:

• trafikadministrado: tempoforpasoj, reprovoj, ŝarĝobalancado;
• Sekureco: aŭtentikigo kaj rajtigo de finuzanto;
• observeblo: spurado, monitorado, protokolado.

Ĉiuj ili povas esti solvitaj je la aplikaĵo, tamen post tio viaj servoj ne plu estos "mikro". La tuta ekstra penado por trakti ĉi tiujn aferojn estas malŝparo de firmaaj rimedoj, kiuj povus esti uzataj rekte por komerca valoro. Konsideru ekzemplon:

Projektestro: Kiom da tempo necesas por aldoni reagan funkcion?
Ellaboranto: Du spurtoj.

MP: Kio?.. Ĝi estas nur KRUDA!
R: Fari CRUD estas la facila parto de la tasko, sed ni ankoraŭ bezonas aŭtentikigi kaj rajtigi uzantojn kaj servojn. Ĉar la reto estas nefidinda, vi devos efektivigi ripetajn petojn, same kiel ŝablono de cirkvito en klientoj. Ankaŭ, por certigi, ke la tuta sistemo ne kraŝis, tempomortoj kaj fakmuroj (Vidu poste en la artikolo por pliaj detaloj pri ambaŭ menciitaj ŝablonoj.), kaj por detekti problemojn, monitorado, spurado, [...]

MP: Ho, ni simple metu ĉi tiun funkcion en la Produktan servon do.

Mi pensas, ke la ideo estas klara: la kvanto da paŝoj kaj peno necesaj por aldoni ununuran servon estas grandega. En ĉi tiu artikolo, ni rigardos kiel Istio forigas la tutan kompleksecon menciitan supre (ne celita de komerca logiko) de servoj.

Примечание: La artikolo supozas, ke vi havas laborscion pri Kubernetes. Alie, mi rekomendas legi mia enkonduko al Kubernetes kaj nur tiam daŭre legu ĉi tiun materialon.

Istio ideo

En mondo sen Istio, unu servo faras rektajn petojn al alia, kaj en kazo de malsukceso, la servo devas pritrakti ĝin mem: fari novan provon, provizi tempon, malfermi ŝaltilon ktp.

Reta trafiko en Kubernetes

Istio, aliflanke, ofertas specialigitan solvon kiu estas tute aparta de servoj kaj funkcioj malhelpante retan interagon. Kaj tiel ĝi efektivigas:

• kulpo toleremo: surbaze de la statuskodo en la respondo, ĝi komprenas ĉu la peto malsukcesis kaj resendas ĝin.
• Kanariaj Disvolviĝoj: alidirektas nur fiksitan procenton de petoj al la nova versio de la servo.
• Monitorado kaj Metriko: kiom da tempo daŭris por la servo respondi?
• Spurado kaj observeblo: Aldonas specialajn titolojn al ĉiu peto kaj spuras ilin tra la areto.
• Sekureco: Prenas JWT-ĵetonon, aŭtentikigas kaj rajtigas uzantojn.

Ĉi tiuj estas nur kelkaj el la eblecoj (vere nur kelkaj!) por intrigi vin. Nun ni plonĝu en la teknikajn detalojn!

Arkitekturo

Istio kaptas la tutan retan trafikon kaj aplikas aron de reguloj al ĝi, enigante inteligentan prokurilon en la formo de kroma ujo en ĉiun podon. Prokuriloj kiuj aktivigas ĉiujn eblecojn formas a Datuma Aviadilo, kaj ili povas esti dinamike ĝustigitaj per Kontrola Ebeno.

Datuma Aviadilo

La prokuriloj, kiuj estas enigitaj en la podojn, permesas al Istio facile atingi la postulojn, kiujn ni bezonas. Ekzemple, ni kontrolu la reprovojn kaj ŝaltilfunkciojn.

Kiel reprovoj kaj cirkvitrompiĝo estas efektivigitaj en Envoy

Resume:

1. sendita (ni parolas pri prokurilo situanta en sidecar-ujo, kiu estas distribuata kaj kiel aparta produkto - ĉ. traduk.) sendas peton al la unua okazo de servo B kaj malsukcesas.
2. Envoy Sidecar denove provas (reprovi). (1)
3. La malsukcesa peto estas resendita al la prokurilo, kiu vokis ĝin.
4. Ĉi tio malfermas la Circuit Breaker kaj vokas la sekvan servon por postaj petoj. (2)

Ĉi tio signifas, ke vi ne devas uzi la sekvan Retry-bibliotekon, vi ne devas fari vian propran efektivigon de Circuit Breaking kaj Service Discovery en la programlingvo X, Y aŭ Z. Ĉio ĉi kaj pli disponeblas el la skatolo en Istio kaj ne postulas ne kodŝanĝoj.

Bonege! Nun vi eble volas vojaĝi kun Istio, sed ankoraŭ estas kelkaj duboj, malfermitaj demandoj. Se ĉi tio estas universala solvo por ĉiuj okazoj en la vivo, tiam vi havas laŭleĝan suspekton: ja ĉiuj tiaj solvoj fakte ne taŭgas por ajna kazo.

Kaj finfine vi demandas: "Ĉu ĝi estas agordebla?"

Nun vi estas preta por marvojaĝo - kaj ni konatiĝu kun Kontrolaviadilo.

Kontrola Ebeno

Ĝi konsistas el tri komponentoj: Piloto, Miksaĵo и citadelon, kiuj kune agordas Senditojn por direkti trafikon, devigi politikojn kaj kolekti telemetriajn datumojn. Skeme, ĉio aspektas jene:

Interago de Kontrola Ebeno kun Datuma Ebeno

Senditoj (t.e. datenaviadilo) estas agordita kun Kubernetes CRD ( Propraj Rimedaj Difinoj ) difinitaj de Istio kaj specife desegnitaj por ĉi tiu celo. Kion ĉi tio signifas por vi estas, ke ili estas nur alia rimedo en Kubernetes kun konata sintakso. Fojo kreita, ĉi tiu rimedo estos prenita de la kontrolaviadilo kaj aplikita al Senditoj.

Rilato de servoj al Istio

Ni priskribis la rilaton de Istio al servoj, sed ne inverse: kiel servoj rilatas al Istio?

Verdire, servoj scias pri la ĉeesto de Istio same kiel fiŝoj scias pri akvo, kiam ili demandas sin: "Kio estas akvo ĉiuokaze?".

Ilustraĵo Viktorio Dimitrakopoulos: Kiel vi ŝatas la akvon? - Kio estas ĉiuokaze akvo?

Tiel, vi povas preni funkciantan grapolon kaj post deplojado de la Istio-komponentoj, la servoj en ĝi daŭre funkcios, kaj post forigo de ĉi tiuj komponantoj, ĉio estos bone denove. Estas klare, ke en ĉi tiu kazo vi perdos la ŝancojn provizitajn de Istio.

Sufiĉas teorio - ni praktiku ĉi tiun scion!

Istio en praktiko

Istio postulas Kubernetes-areton kun almenaŭ 4 vCPUoj kaj 8 GB da RAM disponeblaj. Por rapide levi la areton kaj sekvi la instrukciojn de la artikolo, mi rekomendas uzi la Google Cloud Platform, kiu ofertas novajn uzantojn senpagaj $300.

Post krei la areton kaj agordi aliron al Kubernetes per la konzola ilo, vi povas instali Istio per la pakadministranto Helm.

Helm Instalado

Instalu la Helm-klienton en via komputilo kiel priskribite en oficiala dokumentaro. Ni uzos ĝin por generi ŝablonojn por instali Istio en la sekva sekcio.

Instalado

Elŝutu Istio-resursojn de lasta eldono (la ligilo de la originala aŭtoro al versio 1.0.5 estis ŝanĝita al la nuna, t.e. 1.0.6 - ĉ. traduk.), ĉerpi la enhavon al ununura dosierujo, kiun mi referencos kiel [istio-resources].

Por facila identigo de Istio-resursoj, kreu nomspacon en la K8s-areto istio-system:

$ kubectl create namespace istio-system

Kompletigu la instaladon navigante al la dosierujo [istio-resources] kaj rulante la komandon:

$ 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

Ĉi tiu komando eligos la ŝlosilajn komponantojn de Istio al dosiero istio.yaml. Ni modifis la norman ŝablonon por ni mem specifante la jenajn parametrojn:

• global.mtls.enabled instalita en false (t.e. mTLS-aŭtentikigo estas malŝaltita - ĉ. tradukado)simpligi nian rendevuan procezon;
• tracing.enabled ebligas peton spuradon kun Jaeger;
• kiali.enabled instalas Kiali en areton por bildigi servojn kaj trafikon;
• grafana.enabled instalas Grafana por bildigi la kolektitajn metrikojn.

Apliku la generitajn rimedojn per la komando:

$ kubectl apply -f istio.yaml

Instalado de Istio en la areto estas kompleta! Atendu ĝis ĉiuj balgoj en la nomspaco istio-system povos Running aŭ Completedrulante la suban komandon:

$ kubectl get pods -n istio-system

Ni nun pretas daŭrigi al la sekva sekcio, kie ni levos kaj ruligos la aplikaĵon.

Sentiment Analysis Application Architecture

Ni uzu la ekzemplon de la mikroserva aplikaĵo Sentiment Analysis uzata en la jam menciita Enkonduka artikolo al Kubernetes. Estas sufiĉe kompleksa por montri la eblecojn de Istio praktike.

La aplikaĵo konsistas el kvar mikroservoj:

1. servo SA-Frontend, kiu servas la antaŭfinan aplikaĵon sur Reactjs;
2. servo SA Retejo, kiu servas demandojn pri Sentimenta Analizo;
3. servo SA Logikokiu plenumas sin analizo de sentoj;
4. servo SA Reago, kiu ricevas komentojn de uzantoj pri la precizeco de la analizo farita.

En ĉi tiu diagramo, krom servoj, ni ankaŭ vidas la Ingress-Regilon, kiu en Kubernetes direktas envenantajn petojn al la respondaj servoj. Istio uzas similan koncepton kiel parton de la Eniro-Enirejo, kies detaloj sekvos.

Lanĉante aplikaĵon kun prokurilo de Istio

Por pliaj operacioj menciitaj en la artikolo, klonu vian deponejon istio-majstrado. Ĝi enhavas la aplikaĵon kaj manifestojn por Kubernetes kaj Istio.

Enmetante kromĉarojn

Enmeto povas esti farita aŭtomate aŭ permane. Por aŭtomate enmeti flankajn ujojn, vi devas agordi la etikedon al la nomspaco istio-injection=enabled, kiu estas farita per la sekva komando:

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

Nun ĉiu pod kiu estos deplojita en la defaŭlta nomspaco (default) ricevos sian kromĉaron ujon. Por kontroli ĉi tion, ni deplojigu testan aplikaĵon irante al la radika dosierujo de la deponejo [istio-mastery] kaj rulante la sekvan komandon:

$ 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

Deplojinte la servojn, kontrolu, ke la podoj havas po du ujojn (kun la servo mem kaj ĝia kromĉaro) per la komando. kubectl get pods kaj certigante ke sub la kolono READY specifita valoro 2/2, simbolante ke ambaŭ ujoj funkcias:

$ 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

Vide ĝi aspektas jene:

Sendi prokurilon en unu el la balgoj

Nun kiam la aplikaĵo funkcias, ni devas permesi al envenanta trafiko eniri la aplikaĵon.

Eniro Enirejo

La plej bona praktiko por atingi ĉi tion (permesi trafikon en la areto) estas per Eniro Enirejo en Istio, kiu situas ĉe la "rando" de la areto kaj permesas al vi ebligi Istio-funkciojn kiel vojigo, ŝarĝoekvilibro, sekureco kaj monitorado por envenanta trafiko.

La Ingress Gateway-komponento kaj la servo kiu plusendas ĝin eksteren estis instalitaj sur la areto dum la instalaĵo de Istio. Por ekscii la eksteran IP-adreson de servo, rulu:

$ 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

Ni daŭre aliros la aplikaĵon uzante ĉi tiun IP (mi nomos ĝin EXTERNAL-IP), do por oportuno, ni skribos la valoron al variablo:

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

Se vi provas aliri ĉi tiun IP per retumilo nun, vi ricevos eraron pri Nedisponebla Servo, ĉar defaŭlte Istio blokas la tutan envenantan trafikonĝis Enirejo estas difinita.

Enireja rimedo

Gateway estas CRD (Persona Rimeda Difino) en Kubernetes, difinita post instalo de Istio en areto kaj ebliganta la kapablon specifi havenojn, protokolon kaj gastigantojn, por kiuj ni volas permesi envenantan trafikon.

En nia kazo, ni volas permesi HTTP-trafikon sur haveno 80 por ĉiuj gastigantoj. La problemo realiĝas per la sekva difino (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:
- "*"

Ĉi tiu agordo bezonas neniun klarigon krom la elektilo istio: ingressgateway. Per ĉi tiu elektilo, ni povas specifi al kiu Ingress Gateway apliki la agordon. En nia kazo, ĉi tio estas la regilo Ingress Gateway, kiu estis instalita defaŭlte en Istio.

La agordo estas aplikata per vokado de la sekva komando:

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

La enirejo nun permesas aliron al haveno 80 sed ne havas ideon kien direkti la petojn. Por ĉi tio vi bezonos Virtualaj Servoj.

Rimedo de Virtuala Servo

La VirtualService diras al la Eniro-Enirejo kiel direkti petojn, kiuj estas permesitaj ene de la areto.

Petoj al nia aplikaĵo venantaj tra la http-pordejo devas esti senditaj al la sa-frontend, sa-web-app kaj sa-feedback-servoj:

Itineroj agordataj per VirtualServices

Konsideru la petojn, kiuj devus esti senditaj al SA-Frontend:

• Ĝuste kongruo laŭ la vojo / estu sendita al SA-Frontend por ricevi index.html;
• Vojetoj kun prefikso /static/* devus esti sendita al SA-Frontend por uzi statikajn dosierojn en la fasado, kiel CSS kaj JavaScript;
• Vojetoj kongruantaj kun la regula esprimo '^.*.(ico|png|jpg)$', devas esti sendita al SA-Frontend, ĉar Ĉi tiuj estas la bildoj montritaj sur la paĝo.

La efektivigo estas atingita per la sekva agordo (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

Gravaj punktoj:

 Ĉi tiu VirtualService rilatas al petoj venantaj http-enirejo;
 В destination difinas la servon al kiu la petoj estas senditaj.

Примечание: La supra agordo estas konservita en dosiero sa-virtualservice-external.yaml, kiu ankaŭ enhavas agordojn por vojigo al SA-WebApp kaj SA-Feedback, sed estis mallongigita ĉi tie en la artikolo por koncizeco.
Apliki VirtualService per voko:

Примечание: Kiam ni aplikas Istio-resursojn, la Kubernetes API-Servilo lanĉas eventon, kiun ricevas la Istio-Kontrol-Aviadilo, kaj post tio, la nova agordo estas aplikata al la prokuriloj de Envoy de ĉiu pod. Kaj la regilo de Ingress Gateway ŝajnas esti alia Sendito agordita en la Kontrolaviadilo. Ĉio ĉi aspektas jene en la diagramo:


Istio-IngressGateway-agordo por petovojigo
Analizo de sentoj nun disponeblas http://{EXTERNAL-IP}/. Ne maltrankviliĝu se vi ricevas statuson Ne Trovita: foje necesas iom pli longe por ke la agordo efektiviĝu kaj ke la Envoy-kaŝmemoroj ĝisdatiĝos.
Antaŭ ol daŭrigi, ludu kun la aplikaĵo iom por generi trafikon. (ĝia ĉeesto estas necesa por klareco en postaj agoj - ĉ. trad.).
Kiali: observeblo
Por atingi la administran interfacon Kiali, rulu la jenan komandon:

…kaj malfermita http://localhost:20001/per ensaluto kiel administranto/administranto. Ĉi tie vi trovos multajn utilajn funkciojn, ekzemple, por kontroli la agordon de Istio-komponentoj, vidi servojn el informoj kolektitaj per kaptado de retaj petoj, ricevi respondojn al la demandoj "Kiu kontaktas kiun?", "Kiu versio de la servo spertas." malsukcesoj?” kaj tiel plu. Ĝenerale, esploru la eblecojn de Kiali antaŭ ol pluiri al bildigo de metrikoj kun Grafana.

Grafana: bildigo de metriko
La metrikoj kolektitaj en Istio finiĝas en Prometheus kaj estas bildigitaj kun Grafana. Por atingi la administran interfacon de Grafana, rulu la komandon sube, poste malfermu http://localhost:3000/:

Alklakante la menuon hejmo supre maldekstre kaj elektu Istio Servo Panelo en la supra maldekstra angulo, komencu per servo sa-web-apppor vidi la kolektitajn metrikojn:

Ĉi tie ni atendas malplenan kaj tute enuigan prezentadon - la administrado neniam aprobos tion. Ni kreu malgrandan ŝarĝon per la sekva komando:

Nun ni havas multe pli belajn grafikaĵojn, kaj krom ili, la mirindajn ilojn Prometheus por monitorado kaj Grafana por bildigi metrikojn, kiuj permesos al ni lerni pri rendimento, sano-stato, plibonigoj/degradoj en servoj laŭlonge de la tempo.
Fine, ni rigardu peton spuradon en servoj.
Jaeger: paŭsaĵo
Ni bezonos spuradon, ĉar ju pli da servoj ni havas, des pli malfacilas atingi la kaŭzon de la fiasko. Ni rigardu simplan kazon el la suba bildo:


Tipa ekzemplo de hazarda malsukcesa peto
Peto venas, falas - kio estas la kialo? Unua servo? Aŭ dua? Estas esceptoj en ambaŭ - ni rigardu la protokolojn de ĉiu. Kiom ofte vi kaptis vin farante tion? Nia laboro pli similas al programaraj detektivoj ol al programistoj...
Ĉi tio estas disvastigita problemo en mikroservoj kaj estas solvita per distribuitaj spursistemoj, en kiuj servoj pasas unikan kaplinion unu al la alia, post kio ĉi tiu informo estas redirektita al la spursistemo, kie ĝi estas komparata kun la petaj datumoj. Jen ilustraĵo:


TraceId estas uzata por identigi la peton
Istio uzas Jaeger Tracer, kiu efektivigas vendon-sendependan OpenTracing API-kadron. Vi povas aliri la uzantinterfacon de Jaeger per la sekva komando:

Nun iru al http://localhost:16686/ kaj elektu servon sa-web-app. Se la servo ne estas montrata en la falmenuo, montru/generu agadon sur la paĝo kaj ĝisdatigu la interfacon. Post tio alklaku la butonon Trovu spurojn, kiu montros la plej freŝajn spurojn - elektu iun ajn - aperos detalaj informoj pri ĉiuj spuroj:

Ĉi tiu spuro montras:

 La peto venas istio-ingressgateway (ĉi tio estas la unua interago kun unu el la servoj, kaj Trace ID estas generita por la peto), post kio la enirejo sendas la peton al la servo sa-web-app.
 En servo sa-web-app la peto estas prenita de la Envoy-kromveturilo, "infano" estas kreita en la interspaco (tial ni vidas ĝin en spuroj) kaj redirektita al la ujo sa-web-app. (interspaco - logika unuo de laboro en Jaeger, havanta nomon, la komencotempon de la operacio kaj ĝian daŭron. Spanoj povas esti nestitaj kaj ordigitaj. Direktita acikla grafeo de interspacoj formas spuron. - ĉ. traduk.)
 Ĉi tie la peto estas procesita per la metodo sentimentanalizo. Ĉi tiuj spuroj estas jam generitaj de la aplikaĵo, t.e. ili postulis kodŝanĝojn.
 De ĉi tiu momento, POST-peto estas komencita en sa-logiko. Trace ID devas esti plusendita de sa-web-app.
 ...

Примечание: En la paŝo 4, la aplikaĵo devus vidi la titolojn generitajn de Istio kaj transdoni ilin al postaj petoj, kiel montrite en la bildo sube:


(A) Header plusendado estas la respondeco de Istio; (B) Servoj respondecas pri kaplinioj
Istio faras la plej grandan parton de la laboro ĉar generas titolojn por alvenantaj petoj, kreas novajn interspacojn en ĉiu flankzorgo kaj plusendas ilin. Tamen, sen labori kun kaplinioj ene de servoj, la plena peta spurpado estos perdita.
La sekvaj kaplinioj devas esti konsiderataj (senditaj):

Ĉi tio estas simpla tasko, sed por simpligi ĝian efektivigon, jam ekzistas multaj bibliotekoj - ekzemple, en la sa-web-app-servo, la RestTemplate-kliento plusendas ĉi tiujn kapliniojn se vi simple aldonas la bibliotekojn Jaeger kaj OpenTracing al ĝiaj dependecoj.
Notu, ke la aplikaĵo Sentiment Analysis montras efektivigojn en Flask, Spring kaj ASP.NET Core.
Nun kiam estas klare, kion ni eliras el la skatolo (aŭ preskaŭ el la skatolo), ni rigardu fajnagordan vojigon, retan trafikan administradon, sekurecon kaj pli!
Notu. transl.: legu pri tio en la sekva parto de materialoj pri Istio de Rinor Maloku, kies tradukoj sekvos en nia blogo baldaŭ. UPDATE (14-a de marto): La dua parto jam publikigita.
PS de tradukisto
Legu ankaŭ en nia blogo:

 "Reen al mikroservoj kun Istio": parto 2 (vojigo, trafikkontrolo), parto 3 (konfirmo kaj rajtigo);
 «Conduit - malpeza servomaŝo por Kubernetes»;
 «Kio estas servomaŝo kaj kial mi bezonas ĝin [por nuba aplikaĵo kun mikroservoj]?»;
 «Ilustrita gvidilo al interkonektado en Kubernetes. Partoj 1 kaj 2»;
 «Kiel ĉi tiu kromĉarujo finiĝis ĉi tie [en Kubernetes]?".

fonto: www.habr.com