🥇Torna als microserveis amb Istio. Part 1

Nota. transl.: Les malles de servei s'han convertit definitivament en un tema candent a la infraestructura actual per a aplicacions que segueixen l'arquitectura de microserveis. Tot i que Istio pot estar al radar de molts enginyers de DevOps, és un producte força nou que, tot i que és complex pel que fa a les funcions que ofereix, pot trigar una gran quantitat de temps a conèixer-lo. L'enginyer alemany Rinor Maloku, que s'encarrega de la computació en núvol per a grans clients de l'empresa de telecomunicacions Orange Networks, ha escrit una meravellosa sèrie de materials que permeten submergir-se ràpida i profundament a Istio. Comença la seva història amb què pot fer Istio i com pots veure-ho ràpidament amb els teus propis ulls.

Istio — Projecte de codi obert, desenvolupat en col·laboració amb equips de Google, IBM i Lyft. Soluciona les complexitats que sorgeixen en aplicacions basades en microserveis, per exemple, com:

gestió del trànsit: temps d'espera, reintents, equilibri de càrrega;
Безопасность: autenticació i autorització de l'usuari final;
observabilitat: seguiment, seguiment, registre.

Tots es poden resoldre a nivell d'aplicació, però després d'això els vostres serveis deixaran de ser "micro". Tot l'esforç addicional per abordar aquests problemes és un malbaratament de recursos de l'empresa que es podrien utilitzar directament per obtenir valor comercial. Considereu un exemple:

Gestor de projectes: quant de temps es triga a afegir una funció de comentaris?
Desenvolupador: dos sprints.

MP: Què?... És CRUD!
R: Fer CRUD és la part fàcil de la tasca, però encara hem d'autenticar i autoritzar usuaris i serveis. Com que la xarxa no és fiable, haureu d'implementar sol·licituds repetides, així com patró d'interruptors en clients. A més, per assegurar-se que tot el sistema no es va bloquejar, els temps d'espera i mampares (Vegeu més endavant a l'article per obtenir més detalls sobre els dos patrons esmentats.), i per detectar problemes, seguiment, traça, […]
MP: Ah, posem aquesta característica al servei de Producte.

Crec que la idea és clara: la quantitat de passos i esforços necessaris per afegir un únic servei és enorme. En aquest article, veurem com Istio elimina tota la complexitat esmentada anteriorment (no orientada per la lògica empresarial) dels serveis.

Nota: l'article pressuposa que teniu coneixements pràctics de Kubernetes. En cas contrari, recomano la lectura la meva introducció a Kubernetes i només llavors continueu llegint aquest material.

Istio idea

En un món sense Istio, un servei fa peticions directes a un altre i, en cas de fallada, el servei s'ha de gestionar per si mateix: fer un nou intent, preveure un temps d'espera, obrir un interruptor, etc.

Trànsit de xarxa a Kubernetes

Istio, d'altra banda, ofereix una solució especialitzada completament separada dels serveis i funcions en interferir amb la interacció de la xarxa. I així implementa:

falta de tolerància: segons el codi d'estat de la resposta, entén si la sol·licitud ha fallat i la torna a enviar.
Desplegaments de Canàries: redirigeix només un percentatge fix de sol·licituds a la nova versió del servei.
Monitorització i mètriques: quant de temps va trigar el servei a respondre?
Traçat i observabilitat: afegeix capçaleres especials a cada sol·licitud i les rastreja al clúster.
Безопасность: recupera un testimoni JWT, autentica i autoritza els usuaris.

Aquestes són només algunes de les possibilitats (en realitat només algunes!) per intrigar-vos. Ara endinsem-nos en els detalls tècnics!

Arquitectura

Istio intercepta tot el trànsit de la xarxa i li aplica un conjunt de regles, inserint un proxy intel·ligent en forma de contenidor sidecar a cada pod. Els servidors intermediaris que activen totes les possibilitats formen a Pla de dades, i es poden ajustar dinàmicament amb Plànol de control.

Pla de dades

Els proxies que s'insereixen als pods permeten a Istio assolir fàcilment els requisits que necessitem. Per exemple, comprovem els reintents i les funcions de l'interruptor.

Com s'implementen els reintents i la interrupció del circuit a Envoy

Resumint:

Enviat (estem parlant d'un proxy situat en un contenidor sidecar, que es distribueix i com producte separat -aprox. trad.) envia una sol·licitud a la primera instància del servei B i falla.
Envoy Sidecar ho torna a provar (torna a provar). (1)
La sol·licitud fallida es retorna al servidor intermediari que l'ha cridat.
Això obre el Circuit Breaker i truca al següent servei per a les sol·licituds posteriors. (2)

Això vol dir que no cal que utilitzeu la propera biblioteca de Reintentar, no cal que feu la vostra pròpia implementació de Circuit Breaking i Service Discovery en el llenguatge de programació X, Y o Z. Tot això i més està disponible des del caixa a Istio i no requereix no canvis de codi.

Genial! Ara potser voldreu fer un viatge amb Istio, però encara queden alguns dubtes, preguntes obertes. Si aquesta és una solució universal per a totes les ocasions de la vida, llavors teniu una sospita legítima: al cap i a la fi, totes aquestes solucions no són adequades per a cap cas.

I finalment et preguntes: "És personalitzable?"

Ara esteu preparats per a un viatge per mar i familiaritzem-nos amb Control Plane.

Plànol de control

Consta de tres components: Pilot, Mesclador и Ciutadella, que conjuntament configuren Envoys per encaminar el trànsit, aplicar polítiques i recopilar dades de telemetria. Esquemàticament, tot es veu així:

Interacció del pla de control amb el pla de dades

Els enviats (és a dir, l'avió de dades) es configuren amb Kubernetes CRD (Definicions de recursos personalitzades) definides per Istio i dissenyades específicament per a aquest propòsit. El que això significa per a vostè és que són només un recurs més a Kubernetes amb una sintaxi familiar. Un cop creat, aquest recurs serà recollit pel pla de control i aplicat als enviats.

Relació de serveis amb Istio

Hem descrit la relació d'Istio amb els serveis, però no al revés: com es relacionen els serveis amb Istio?

Per ser sincers, els serveis coneixen la presència d'Istio, així com els peixos saben de l'aigua, quan es pregunten: "Què és l'aigua de totes maneres?".

Il·lustració Victòria Dimitrakopoulos: Com t'agrada l'aigua? - Què és l'aigua de totes maneres?

Així, podeu agafar un clúster de treball i, després de desplegar els components Istio, els serveis que hi continguin continuaran funcionant i, després d'eliminar aquests components, tot tornarà a estar bé. És evident que en aquest cas perdràs les oportunitats que ofereix Istio.

Prou teoria: posem aquests coneixements en pràctica!

Istio a la pràctica

Istio requereix un clúster Kubernetes amb almenys 4 vCPU i 8 GB de RAM disponibles. Per augmentar ràpidament el clúster i seguir les instruccions de l'article, recomano utilitzar Google Cloud Platform, que ofereix nous usuaris 300 $ gratis.

Després de crear el clúster i configurar l'accés a Kubernetes mitjançant la utilitat de la consola, podeu instal·lar Istio mitjançant el gestor de paquets Helm.

Instal·lació del timó

Instal·leu el client Helm al vostre ordinador tal com es descriu a documentació oficial. L'utilitzarem per generar plantilles per instal·lar Istio a la següent secció.

Instal·lació

Baixeu els recursos d'Istio de últim llançament (l'enllaç de l'autor original a la versió 1.0.5 s'ha canviat a l'actual, és a dir, 1.0.6 - traducció aprox.), extreu el contingut a un sol directori, al qual em referiré com a [istio-resources].

Per identificar fàcilment els recursos d'Istio, creeu un espai de noms al clúster K8s istio-system:

$ kubectl create namespace istio-system

Completeu la instal·lació navegant al directori [istio-resources] i executant l'ordre:

$ 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

Aquesta ordre mostrarà els components clau d'Istio en un fitxer istio.yaml. Hem modificat la plantilla estàndard per nosaltres mateixos especificant els paràmetres següents:

global.mtls.enabled instal·lat a false (és a dir, l'autenticació mTLS està desactivada - traducció aprox.)per simplificar el nostre procés de cites;
tracing.enabled activa el seguiment de sol·licituds amb Jaeger;
kiali.enabled instal·la Kiali en un clúster per visualitzar serveis i trànsit;
grafana.enabled instal·la Grafana per visualitzar les mètriques recopilades.

Apliqueu els recursos generats amb l'ordre:

$ kubectl apply -f istio.yaml

La instal·lació d'Istio al clúster s'ha completat! Espereu fins que tots els pods a l'espai de noms istio-system serà capaç Running o Completedexecutant l'ordre següent:

$ kubectl get pods -n istio-system

Ara estem preparats per continuar a la següent secció, on crearem i executarem l'aplicació.

Arquitectura d'aplicacions d'anàlisi de sentiments

Utilitzem l'exemple de l'aplicació de microservei d'anàlisi de sentiments que s'utilitza en el ja esmentat Article d'introducció a Kubernetes. És prou complex per mostrar les possibilitats d'Istio a la pràctica.

L'aplicació consta de quatre microserveis:

Servei SA-Frontend, que serveix a l'aplicació frontal a Reactjs;
Servei Aplicació web SA, que serveix consultes d'anàlisi de sentiments;
Servei SA Lògicaque es realitza per si mateix anàlisi de sentiments;
Servei Comentaris de SA, que rep comentaris dels usuaris sobre l'exactitud de l'anàlisi realitzada.

En aquest diagrama, a més dels serveis, també veiem el Controlador d'entrada, que a Kubernetes encamina les peticions entrants als serveis corresponents. Istio utilitza un concepte similar com a part de l'Ingress Gateway, els detalls del qual seguiran.

Llançament d'una aplicació amb un proxy d'Istio

Per a més operacions esmentades a l'article, cloneu el vostre dipòsit istio-mestratge. Conté l'aplicació i els manifests per a Kubernetes i Istio.

Inserció de sidecars

Es pot fer la inserció automàticament o a mà. Per inserir automàticament contenidors de sidecar, heu d'establir l'etiqueta a l'espai de noms istio-injection=enabled, que es fa amb l'ordre següent:

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

Ara cada pod que es desplegarà a l'espai de noms predeterminat (default) rebrà el seu contenidor sidecar. Per verificar-ho, despleguem una aplicació de prova anant al directori arrel del dipòsit [istio-mastery] i executant l'ordre següent:

$ 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

Després d'haver desplegat els serveis, comproveu que els pods tinguin dos contenidors (amb el propi servei i el seu sidecar) executant l'ordre kubectl get pods i assegurant-se que sota la columna READY valor especificat 2/2, que simbolitza que els dos contenidors estan funcionant:

$ 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

Visualment es veu així:

Proxy enviat en un dels pods

Ara que l'aplicació està en funcionament, hem de permetre que el trànsit entrant entri a l'aplicació.

Gateway d'entrada

La millor pràctica per aconseguir-ho (permetre el trànsit al clúster) és via Gateway d'entrada a Istio, que es troba a la "punta" del clúster i us permet habilitar funcions d'Istio com ara l'encaminament, l'equilibri de càrrega, la seguretat i la supervisió del trànsit entrant.

El component Ingress Gateway i el servei que el reenvia cap a fora es van instal·lar al clúster durant la instal·lació d'Istio. Per esbrinar l'adreça IP externa d'un servei, executeu:

$ 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

Continuarem accedint a l'aplicació mitjançant aquesta IP (l'anomenaré IP-EXTERNA), així que per comoditat, escriurem el valor en una variable:

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

Si intenteu accedir a aquesta IP mitjançant un navegador ara, obtindreu un error de servei no disponible, perquè per defecte Istio bloqueja tot el trànsit entrantfins que es defineixi el Gateway.

Recurs de passarel·la

Gateway és un CRD (Custom Resource Definition) a Kubernetes, definit després d'instal·lar Istio en un clúster i permetre la possibilitat d'especificar ports, protocols i amfitrions per als quals volem permetre el trànsit entrant.

En el nostre cas, volem permetre el trànsit HTTP al port 80 per a tots els amfitrions. El problema es concreta amb la següent definició (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:
- "*"

Aquesta configuració no necessita cap explicació excepte pel selector istio: ingressgateway. Amb aquest selector, podem especificar a quina passarel·la d'entrada aplicar la configuració. En el nostre cas, es tracta del controlador Ingress Gateway, que es va instal·lar per defecte a Istio.

La configuració s'aplica cridant l'ordre següent:

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

La passarel·la ara permet l'accés al port 80, però no té ni idea d'on dirigir les sol·licituds. Per això necessitareu Serveis virtuals.

Recurs del servei virtual

El VirtualService indica a la passarel·la d'entrada com encaminar les sol·licituds que es permeten dins del clúster.

Les sol·licituds a la nostra aplicació que arribin a través de la passarel·la http s'han d'enviar als serveis sa-frontend, sa-web-app i sa-feedback:

Rutes a configurar amb VirtualServices

Considereu les sol·licituds que s'han d'enviar a SA-Frontend:

Coincidència exacta al llarg del camí / s'ha d'enviar a SA-Frontend per obtenir index.html;
Camins amb prefix /static/* s'hauria d'enviar a SA-Frontend per obtenir fitxers estàtics utilitzats al frontend, com ara CSS i JavaScript;
Camins que coincideixen amb l'expressió regular '^.*.(ico|png|jpg)$', s'ha d'enviar a SA-Frontend, perquè Aquestes són les imatges que es mostren a la pàgina.

La implementació s'aconsegueix mitjançant la configuració següent (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
punts importants:

Aquest Servei Virtual fa referència a les sol·licituds que arriben http-gateway;
В destination defineix el servei al qual s'envien les sol·licituds.

Nota: La configuració anterior s'emmagatzema en un fitxer sa-virtualservice-external.yaml, que també conté paràmetres per a l'encaminament a SA-WebApp i SA-Feedback, però s'ha escurçat aquí a l'article per a la brevetat.

Aplica VirtualService trucant a:

Nota: Quan apliquem recursos Istio, el servidor API de Kubernetes activa un esdeveniment que rep el pla de control Istio i, després d'això, la nova configuració s'aplica als servidors intermediaris d'Envoy de cada pod. I el controlador Ingress Gateway sembla ser un altre Envoy configurat al pla de control. Tot això es veu així al diagrama:

Configuració d'Istio-IngressGateway per a l'encaminament de sol·licituds

L'anàlisi de sentiments ja està disponible a http://{EXTERNAL-IP}/. No us preocupeu si obteniu l'estat No trobat: de vegades triga una mica més perquè la configuració tingui efecte i que les memòries cau d'Envoy s'actualitzin.

Abans de continuar, juga una mica amb l'aplicació per generar trànsit. (la seva presència és necessària per a la claredat en accions posteriors - trad. aprox.).

Kiali: observabilitat

Per accedir a la interfície d'administració de Kiali, executeu l'ordre següent:

...i obert http://localhost:20001/iniciant sessió com a admin/admin. Aquí trobareu moltes funcions útils, per exemple, per comprovar la configuració dels components d'Istio, visualitzar els serveis a partir de la informació recollida mitjançant la interceptació de sol·licituds de xarxa, obtenir respostes a les preguntes "Qui es posa en contacte amb qui?", "Quina versió del servei està experimentant fracassos?” etcètera. En general, exploreu les possibilitats de Kiali abans de passar a visualitzar mètriques amb Grafana.

Grafana: visualització de mètriques

Les mètriques recollides a Istio acaben a Prometeu i es visualitzen amb Grafana. Per accedir a la interfície d'administració de Grafana, executeu l'ordre següent i, a continuació, obriu http://localhost:3000/:

Fent clic al menú Home superior esquerra i seleccioneu Tauler de servei d'Istio a la cantonada superior esquerra, comenceu amb el servei sa-web-appper veure les mètriques recollides:

Aquí estem esperant una actuació buida i completament avorrida: la direcció no ho aprovarà mai. Creem una petita càrrega amb l'ordre següent:

Ara tenim gràfics molt més bonics, i a més d'ells, les meravelloses eines Prometheus per al seguiment i Grafana per visualitzar mètriques, que ens permetran conèixer el rendiment, l'estat de salut, les millores/degradació dels serveis al llarg del temps.

Finalment, mirem el seguiment de sol·licituds als serveis.

Jaeger: rastreig

Necessitarem un rastreig, perquè com més serveis tinguem, més difícil serà arribar a la causa de la fallada. Vegem un cas senzill de la imatge següent:

Exemple típic d'una sol·licitud fallida aleatòria

La petició arriba, cau - quin és el motiu? Primer servei? O segon? Hi ha excepcions en tots dos: mirem els registres de cadascun. Quantes vegades t'has sorprès fent això? La nostra feina s'assembla més a detectius de programari que a desenvolupadors...

Aquest és un problema molt estès en els microserveis i es resol mitjançant sistemes de traça distribuïts, en què els serveis es passen una capçalera única entre si, després d'això aquesta informació es redirigeix al sistema de traça, on es compara amb les dades de la sol·licitud. Aquí teniu una il·lustració:

TraceId s'utilitza per identificar la sol·licitud

Istio utilitza Jaeger Tracer, que implementa un marc d'API OpenTracing independent del proveïdor. Podeu accedir a la interfície d'usuari de Jaeger amb l'ordre següent:

Ara aneu a http://localhost:16686/ i seleccioneu un servei sa-web-app. Si el servei no es mostra al menú desplegable, mostra/genera activitat a la pàgina i actualitza la interfície. Després d'això, feu clic al botó Busca rastres, que mostrarà les traces més recents - seleccioneu qualsevol - apareixerà informació detallada sobre totes les traces:

Aquest rastre mostra:

La petició arriba istio-ingressgateway (aquesta és la primera interacció amb un dels serveis i es genera un ID de rastreig per a la sol·licitud), després de la qual la passarel·la envia la sol·licitud al servei sa-web-app.
En servei sa-web-app la petició és recollida pel sidecar d'Envoy, es crea un "fill" al span (per això ho veiem en rastres) i es redirigeix al contenidor sa-web-app. (Lapse - una unitat lògica de treball a Jaeger, amb un nom, l'hora d'inici de l'operació i la seva durada. Els trams es poden niuar i ordenar. Un gràfic acíclic dirigit de trams forma una traça. -aprox. trad.)
Aquí la sol·licitud es processa pel mètode Anàlisi de sentiments. Aquests rastres ja els genera l'aplicació, és a dir. requerien canvis de codi.
A partir d'aquest moment, s'inicia una sol·licitud POST sa-lògica. L'identificador de traça s'ha de reenviar des de sa-web-app.
...

Nota: Al pas 4, l'aplicació hauria de veure les capçaleres generades per Istio i passar-les a les peticions posteriors, tal com es mostra a la imatge següent:

(A) El reenviament de la capçalera és responsabilitat d'Istio; (B) Els serveis són responsables de les capçaleres

Istio fa la major part de la feina perquè genera capçaleres per a les sol·licituds entrants, crea nous intervals a cada atenció lateral i els reenvia. Tanmateix, sense treballar amb les capçaleres dins dels serveis, es perdrà el camí de traça de la sol·licitud completa.

Les capçaleres següents s'han de tenir en compte (reenviades):

Aquesta és una tasca senzilla, però per simplificar la seva implementació, ja n'hi ha moltes biblioteques - per exemple, al servei sa-web-app, el client RestTemplate reenvia aquestes capçaleres si simplement afegiu les biblioteques Jaeger i OpenTracing a les seves dependències.

Tingueu en compte que l'aplicació d'anàlisi de sentiments demostra implementacions a Flask, Spring i ASP.NET Core.

Ara que està clar què estem sortint de la caixa (o gairebé fora de la caixa), mirem l'ajustament de l'encaminament, la gestió del trànsit de xarxa, la seguretat i molt més!

Nota. transl.: llegiu-ne a la següent part de materials sobre Istio de Rinor Maloku, les traduccions dels quals seguiran al nostre bloc en un futur proper. ACTUALITZACIÓ (14 de març): Segona part ja publicat.

PS del traductor

Llegeix també al nostre blog:

"Torna als microserveis amb Istio": part 2 (encaminament, control de trànsit), part 3 (autenticació i autorització);
«Conduit: malla de servei lleugera per a Kubernetes»;
«Què és una malla de servei i per què la necessito [per a una aplicació al núvol amb microserveis]?»;
«Una guia il·lustrada per a la creació de xarxes a Kubernetes. Parts 1 i 2»;
«Com va acabar aquest contenidor de sidecar aquí [a Kubernetes]?».

Font: www.habr.com