Terug naar microservices met Istio. Deel 1

Opmerking. vert.: Service meshes zijn zeker een relevante oplossing geworden in de moderne infrastructuur voor applicaties die een microservice-architectuur volgen. Hoewel Istio misschien op de radar staat van veel DevOps-ingenieurs, is het een vrij nieuw product dat, hoewel uitgebreid in termen van functies die het biedt, mogelijk een aanzienlijke leercurve vereist. De Duitse ingenieur Rinor Maloku, verantwoordelijk voor cloud computing voor grote klanten bij telecommunicatiebedrijf Orange Networks, heeft een prachtige reeks materialen geschreven waarmee je snel en diep in Istio kunt duiken. Hij begint zijn verhaal met wat Istio in het algemeen kan doen en hoe je dat snel met eigen ogen kunt zien.

Istio — Een Open Source-project ontwikkeld in samenwerking met teams van Google, IBM en Lyft. Het lost de complexiteit op die zich voordoet in op microservices gebaseerde applicaties, zoals:

• Verkeersmanagement: time-outs, nieuwe pogingen, taakverdeling;
• veiligheid: authenticatie en autorisatie van eindgebruikers;
• Waarneembaarheid: traceren, monitoren, loggen.

Dit alles kan op applicatieniveau worden opgelost, maar daarna is uw dienstverlening niet langer ‘micro’. Alle extra inspanningen om deze problemen op te lossen zijn een verspilling van bedrijfsmiddelen die direct voor bedrijfswaarde kunnen worden gebruikt. Laten we eens kijken naar een voorbeeld:

Projectmanager: Hoe lang duurt het om een ​​feedbackfunctie toe te voegen?
Ontwikkelaar: Twee sprints.

MP: Wat?.. Het is gewoon RUW!
R: CRUD doen is het makkelijke gedeelte, maar we moeten nog steeds gebruikers en services authenticeren en autoriseren. Omdat het netwerk onbetrouwbaar is, moet u herhaalde verzoeken implementeren, evenals patroon van stroomonderbrekers bij klanten. Om ervoor te zorgen dat het hele systeem niet crasht, hebt u ook time-outs nodig schotten (voor meer details over beide genoemde patronen, zie verderop in het artikel - ca. vert.), en om problemen op te sporen, monitoring, tracering, […]

MP: Oh, laten we deze functie dan gewoon in de Productservice invoegen.

Ik denk dat het idee duidelijk is: het aantal stappen en moeite dat nodig is om één dienst toe te voegen is enorm. In dit artikel zullen we bekijken hoe Istio alle hierboven genoemde complexiteit (die niet als bedrijfslogica is bedoeld) uit services verwijdert.

Noot: In dit artikel wordt ervan uitgegaan dat u praktische kennis van Kubernetes heeft. Anders raad ik aan om te lezen mijn kennismaking met Kubernetes en pas daarna verder met het lezen van dit materiaal.

Istio-idee

In een wereld zonder Istio doet de ene dienst directe verzoeken aan de andere, en in geval van een storing moet de dienst dit zelf afhandelen: een nieuwe poging doen, een time-out voorzien, een stroomonderbreker openen, enz.

Netwerkverkeer in Kubernetes

Istio biedt een gespecialiseerde oplossing, volledig gescheiden van services en functionerend door de netwerkcommunicatie te verstoren. En zo implementeert het:

• fout tolerantie: Op basis van de statuscode in het antwoord begrijpt het of het verzoek is mislukt en voert het het opnieuw uit.
• Kanarie-uitrol: stuurt slechts een vast percentage van de verzoeken door naar de nieuwe versie van de service.
• Monitoring en statistieken: Hoe lang duurde het voordat de service reageerde?
• Tracering en waarneembaarheid: Voegt speciale headers toe aan elke aanvraag en traceert deze door het hele cluster.
• veiligheid: Haalt JWT-token op, authenticeert en autoriseert gebruikers.

Dit zijn slechts enkele van de mogelijkheden (eigenlijk maar een paar!) om je te intrigeren. Laten we nu eens in de technische details duiken!

Istio-architectuur

Istio onderschept al het netwerkverkeer en past er een reeks regels op toe, waarbij een slimme proxy in de vorm van een zijspancontainer in elke pod wordt geplaatst. Proxy's die alle mogelijkheden activeren, vormen een Gegevensvlak, en ze kunnen dynamisch worden geconfigureerd met behulp van Controle vliegtuig.

Gegevensvlak

Door proxy's in pods te plaatsen, kan Istio gemakkelijk aan de vereisten voldoen die we nodig hebben. Laten we bijvoorbeeld de functies voor opnieuw proberen en de stroomonderbreker controleren.

Hoe nieuwe pogingen en circuitonderbreking worden geïmplementeerd in Envoy

Samenvattend:

1. Gezant (we hebben het over een proxy die zich in een zijspancontainer bevindt, die wordt gedistribueerd als afzonderlijk produkt — ca. vert.) verzendt een verzoek naar het eerste exemplaar van service B en mislukt.
2. Gezant Zijspan probeert het opnieuw (opnieuw proberen). (1)
3. Het verzoek mislukt en wordt teruggestuurd naar de proxy die het heeft aangeroepen.
4. Hierdoor wordt Circuit Breaker geopend en wordt de volgende service gebeld voor volgende verzoeken. (2)

Dit betekent dat u geen andere Retry-bibliotheek hoeft te gebruiken, dat u geen eigen implementatie van Circuit Breaking en Service Discovery in programmeertaal X, Y of Z hoeft te maken. Dit alles en nog veel meer is out-of-the-box beschikbaar in Istio en vereist niet geen wijzigingen in de code.

Geweldig! Nu wil je misschien met Istio op reis gaan, maar je hebt nog wat twijfels, open vragen. Als dit een universele oplossing is voor alle gelegenheden in het leven, dan heb je een natuurlijk vermoeden: al dergelijke oplossingen blijken immers in werkelijkheid voor elk geval ongeschikt te zijn.

En uiteindelijk vraag je: “Is het aanpasbaar?”

Nu je klaar bent voor de zeereis, laten we kennis maken met het Control Plane.

Controle vliegtuig

Het bestaat uit drie componenten: Piloot, Menger и Citadel, die samenwerken om Envoys te configureren om verkeer te routeren, beleid af te dwingen en telemetriegegevens te verzamelen. Schematisch ziet het er allemaal zo uit:

Interactie van besturingsvlak met datavlak

Envoys (dat wil zeggen datavlak) worden geconfigureerd met behulp van Kubernetes CRD (Aangepaste resourcedefinities) gedefinieerd door Istio en specifiek bedoeld voor dit doel. Wat dit voor u betekent, is dat ze gewoon een andere bron in Kubernetes lijken te zijn met een bekende syntaxis. Eenmaal aangemaakt, wordt deze hulpbron opgepikt door het controlevlak en toegepast op de gezanten.

Relatie van diensten met Istio

We hebben de relatie van Istio met diensten beschreven, maar niet andersom: hoe verhouden diensten zich tot Istio?

Eerlijk gezegd zijn de diensten zich net zo bewust van Istio's aanwezigheid als vissen van water als ze zich afvragen: "Wat is water eigenlijk?"

illustratie Victoria Dimitrakopoulos: - Hoe vind je het water? - Wat is water eigenlijk?

U kunt dus een werkend cluster nemen en na het implementeren van de Istio-componenten zullen de services die zich daarin bevinden blijven werken, en na het verwijderen van deze componenten zal alles weer in orde zijn. Het is duidelijk dat u in dit geval de mogelijkheden van Istio verliest.

Genoeg theorie - laten we deze kennis in de praktijk brengen!

Istio in de praktijk

Istio vereist een Kubernetes-cluster met minimaal 4 vCPU's en 8 GB RAM beschikbaar. Om snel een cluster op te zetten en de instructies uit het artikel te volgen, raad ik aan Google Cloud Platform te gebruiken, dat nieuwe gebruikers biedt gratis $ 300.

Nadat u een cluster hebt gemaakt en de toegang tot Kubernetes hebt geconfigureerd via het consolehulpprogramma, kunt u Istio installeren via Helm-pakketbeheer.

Helm installatie

Installeer de Helm-client op uw computer, zoals beschreven in officiële documentatie. We zullen dit gebruiken om sjablonen te genereren voor het installeren van Istio in de volgende sectie.

Istio installeren

Download Istio-bronnen van nieuwste uitgave (de originele auteurslink naar versie 1.0.5 is gewijzigd naar de huidige, d.w.z. 1.0.6 - ca. vert.), extraheer de inhoud in één map, die ik voortaan zal noemen [istio-resources].

Om Istio-bronnen gemakkelijk te identificeren, maakt u een naamruimte in het K8s-cluster istio-system:

$ kubectl create namespace istio-system

Voltooi de installatie door naar de map te gaan [istio-resources] en voer het commando uit:

$ 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

Met deze opdracht worden de belangrijkste componenten van Istio naar een bestand uitgevoerd istio.yaml. We hebben de standaardsjabloon naar eigen wens aangepast, met de volgende parameters:

• global.mtls.enabled geïnstalleerd false (d.w.z. mTLS-authenticatie is uitgeschakeld - ongeveer)om ons dateringsproces te vereenvoudigen;
• tracing.enabled omvat het traceren van verzoeken met behulp van Jaeger;
• kiali.enabled installeert Kiali in een cluster om services en verkeer te visualiseren;
• grafana.enabled installeert Grafana om verzamelde statistieken te visualiseren.

Laten we de gegenereerde bronnen gebruiken met de opdracht:

$ kubectl apply -f istio.yaml

De installatie van Istio op het cluster is voltooid! Wacht totdat alle peulen zich in de naamruimte bevinden istio-system zal kunnen Running of Completeddoor de onderstaande opdracht uit te voeren:

$ kubectl get pods -n istio-system

Nu zijn we klaar om verder te gaan in de volgende sectie, waar we de applicatie in gebruik zullen nemen.

Architectuur van de Sentimentanalyse-applicatie

Laten we het voorbeeld gebruiken van de Sentiment Analysis-microservicetoepassing die in het reeds genoemde wordt gebruikt Introductieartikel over Kubernetes. Het is complex genoeg om de capaciteiten van Istio in de praktijk te laten zien.

De applicatie bestaat uit vier microservices:

1. Dienst SA-frontend, dat de frontend van een Reactjs-applicatie bedient;
2. Dienst SA-WebApp, dat Sentimentanalyse-query's bedient;
3. Dienst SA-logica, die zichzelf uitvoert sentiment analyse;
4. Dienst SA-feedback, die feedback ontvangt van gebruikers over de nauwkeurigheid van de analyse.

In dit diagram zien we naast services ook de Ingress Controller, die in Kubernetes binnenkomende verzoeken routeert naar de juiste services. Istio gebruikt een soortgelijk concept binnen zijn Ingress Gateway, waarover meer details volgen.

Een applicatie uitvoeren met een proxy van Istio

Voor verdere bewerkingen die in het artikel worden genoemd, kloont u uw repository istio-meesterschap. Het bevat de applicatie en manifesten voor Kubernetes en Istio.

Zijspannen inbrengen

Inbrengen kan automatisch of handmatig. Om zijspancontainers automatisch in te voegen, moet u een label aan de naamruimte toevoegen istio-injection=enabled, wat gedaan wordt met het volgende commando:

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

Nu wordt elke pod die in de standaardnaamruimte wordt geïmplementeerd (default) krijgt zijn zijspancontainer. Om dit te verifiëren, gaan we de testapplicatie implementeren door naar de hoofdmap van de repository te gaan [istio-mastery] en voer het volgende commando uit:

$ 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

Nadat we de services hebben geïmplementeerd, gaan we controleren of de pods twee containers hebben (met de service zelf en zijn zijspan) door de opdracht uit te voeren kubectl get pods en zorg ervoor dat dit onder de kolom staat READY opgegeven waarde 2/2, wat symboliseert dat beide containers actief zijn:

$ 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 ziet het er als volgt uit:

Gezant-proxy in een van de pods

Nu de applicatie actief is, moeten we inkomend verkeer in de applicatie laten binnenkomen.

Toegangsgateway

De best practice om dit te bereiken (verkeer in het cluster toestaan) is voltooid Toegangsgateway in Istio, dat zich aan de ‘rand’ van het cluster bevindt en waarmee u Istio-functies kunt inschakelen, zoals routering, taakverdeling, beveiliging en monitoring van inkomend verkeer.

Het Ingress Gateway-onderdeel en de service die het extern doorstuurt, zijn tijdens de Istio-installatie in het cluster geïnstalleerd. Voer het volgende uit om het externe IP-adres van de service te achterhalen:

$ 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

We blijven toegang krijgen tot de applicatie met behulp van dit IP-adres (ik zal het EXTERNAL-IP noemen), dus voor het gemak zullen we de waarde in een variabele schrijven:

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

Als u nu via een browser toegang probeert te krijgen tot dit IP-adres, ontvangt u de foutmelding Service Unavailable, omdat standaard blokkeert Istio al het binnenkomende verkeer, Gateway is nog niet gedefinieerd.

Gateway-bron

Gateway is een CRD (Custom Resource Definition) in Kubernetes, gedefinieerd na het installeren van Istio in het cluster en het mogelijk maken van de mogelijkheid om de poorten, het protocol en de hosts te specificeren waarvoor we inkomend verkeer willen toestaan.

In ons geval willen we HTTP-verkeer op poort 80 toestaan ​​voor alle hosts. De taak wordt geïmplementeerd volgens de volgende definitie (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:
- "*"

Deze configuratie behoeft geen uitleg behalve de selector istio: ingressgateway. Met deze selector kunnen we opgeven op welke Ingress Gateway de configuratie moet worden toegepast. In ons geval is dit de Ingress Gateway-controller, die standaard in Istio werd geïnstalleerd.

De configuratie wordt toegepast door de volgende opdracht aan te roepen:

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

De gateway geeft nu toegang tot poort 80, maar heeft geen idee waar de verzoeken naartoe moeten worden gerouteerd. Hiervoor heb je nodig virtuele diensten.

VirtualService-bron

De VirtualService vertelt de Ingress Gateway hoe aanvragen moeten worden gerouteerd die binnen het cluster zijn toegestaan.

Verzoeken aan onze applicatie die via http-gateway binnenkomen, moeten naar de sa-frontend-, sa-web-app- en sa-feedback-services worden gestuurd:

Routes die moeten worden geconfigureerd met VirtualServices

Laten we eens kijken naar de verzoeken die naar SA-Frontend moeten worden verzonden:

• Exacte match onderweg / moet naar SA-Frontend worden gestuurd om index.html op te halen;
• Vooraf ingestelde paden /static/* moet naar SA-Frontend worden verzonden om statische bestanden te ontvangen die in de frontend worden gebruikt, zoals CSS en JavaScript;
• Paden die overeenkomen met reguliere expressies '^.*.(ico|png|jpg)$', moet naar SA-Frontend worden gestuurd, omdat Dit zijn de afbeeldingen die op de pagina worden weergegeven.

De implementatie wordt bereikt door de volgende configuratie (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

Belangrijke punten:

 Deze VirtualService verwijst naar aanvragen die binnenkomen http-gateway;
 В destination Er wordt bepaald naar welke dienst verzoeken worden verzonden.

Noot: De bovenstaande configuratie wordt opgeslagen in een bestand sa-virtualservice-external.yaml, dat ook instellingen bevat voor routing in SA-WebApp en SA-Feedback, maar hier in het artikel kortheidshalve is ingekort.
Laten we VirtualService toepassen door te bellen:

Noot: Wanneer we Istio-bronnen verbruiken, creëert de Kubernetes API Server een gebeurtenis die wordt ontvangen door het Istio Control Plane, en daarna wordt de nieuwe configuratie toegepast op de Envoy-proxy's van elke pod. En de Ingress Gateway-controller lijkt een andere Envoy te zijn die is geconfigureerd in het besturingsvlak. In het diagram ziet dit er allemaal zo uit:


Istio-IngressGateway-configuratie voor aanvraagroutering
De applicatie Sentimentanalyse is nu beschikbaar op http://{EXTERNAL-IP}/. Maak je geen zorgen als je de status Niet gevonden krijgt: Soms duurt het iets langer voordat de configuratie van kracht wordt en de Envoy-caches worden bijgewerkt.
Voordat u doorgaat, speelt u een beetje met de app om verkeer te genereren. (de aanwezigheid ervan is noodzakelijk voor de duidelijkheid bij volgende acties - ca. vert.).
Kiali: waarneembaarheid
Om naar de Kiali-beheerinterface te gaan, voert u de volgende opdracht uit:

... en geopend http://localhost:20001/, inloggen als admin/admin. Hier vindt u veel handige functies, bijvoorbeeld om de configuratie van Istio-componenten te controleren, services te visualiseren met behulp van informatie verzameld door het onderscheppen van netwerkverzoeken, antwoorden te krijgen op de vragen "Wie neemt contact op met wie?", "Welke versie van de service ervaart mislukkingen?” enzovoort. Ontdek in het algemeen de mogelijkheden van Kiali voordat u doorgaat met het visualiseren van statistieken met Grafana.

Grafana: visualisatie van metrische gegevens
Metrieken verzameld in Istio gaan naar Prometheus en worden gevisualiseerd met Grafana. Om naar de administratieve interface van Grafana te gaan, voert u de onderstaande opdracht uit en opent u vervolgens http://localhost:3000/:

Door op het menu te klikken Home linksboven en selecteren Istio-servicedashboard in de linkerbovenhoek, begin met service sa-web-appom de verzamelde statistieken te bekijken:

Wat ons hier te wachten staat is een lege en volkomen saaie voorstelling - het management zal dit nooit goedkeuren. Laten we een kleine belasting maken met de volgende opdracht:

Nu hebben we veel mooiere grafieken, en daarnaast prachtige Prometheus-tools voor monitoring en Grafana voor het visualiseren van statistieken waarmee we in de loop van de tijd meer kunnen leren over de prestaties, de gezondheid en de verbeteringen/degradatie van services.
Laten we tot slot eens kijken naar het traceren van verzoeken in services.
Jaeger: traceren
We zullen tracering nodig hebben, want hoe meer diensten we hebben, hoe moeilijker het is om de oorzaak van de storing te achterhalen. Laten we een eenvoudig geval bekijken op de onderstaande afbeelding:


Typisch voorbeeld van een willekeurig mislukt verzoek
Het verzoek komt, valt - wat is de reden? Eerste dienst? Of de tweede? Er zijn uitzonderingen in beide - laten we naar de logs van beide kijken. Hoe vaak heb je jezelf erop betrapt dat je dit doet? Ons werk lijkt meer op softwaredetectives dan op ontwikkelaars...
Dit is een veelvoorkomend probleem bij microservices en wordt opgelost door gedistribueerde traceringssystemen, waarbij services een unieke header aan elkaar doorgeven, waarna deze informatie wordt doorgestuurd naar het traceringssysteem, waar deze wordt vergeleken met de aanvraaggegevens. Hier is een illustratie:


TraceId wordt gebruikt om het verzoek te identificeren
Istio maakt gebruik van Jaeger Tracer, dat het leveranciersonafhankelijke OpenTracing API-framework implementeert. U krijgt toegang tot de Jaeger-gebruikersinterface met het volgende commando:

Ga nu naar http://localhost:16686/ en selecteer een dienst sa-web-app. Als de service niet in het vervolgkeuzemenu wordt weergegeven, toon/genereer dan activiteit op de pagina en update de interface. Klik daarna op de knop Vind sporen, die de nieuwste sporen zal tonen - selecteer er een - gedetailleerde informatie over alle sporen zal verschijnen:

Dit spoor laat zien:

 Het verzoek komt binnen istio-ingangsgateway (dit is de eerste interactie met een van de diensten, en voor het verzoek wordt een Trace ID gegenereerd), waarna de gateway het verzoek naar de dienst stuurt sa-web-app.
 In dienst sa-web-app het verzoek wordt opgepikt door de Envoy-zijspan, er wordt een “kind” aangemaakt in de spanwijdte (daarom zien we het in de sporen) en doorgestuurd naar de container sa-web-app. (Span - een logische werkeenheid in Jaeger, die een naam, starttijd van de operatie en de duur ervan heeft. Overspanningen kunnen worden genest en geordend. Een gerichte acyclische grafiek van overspanningen vormt een spoor. — ca. vert.)
 Hier wordt het verzoek verwerkt door de methode sentiment analyse. Deze sporen worden al door de applicatie gegenereerd, d.w.z. ze hadden codewijzigingen nodig.
 Vanaf dit moment wordt er een POST-verzoek geïnitieerd sa-logica. Trace-ID moet worden doorgestuurd van sa-web-app.
 ...

Noot: In stap 4 zou de applicatie de door Istio gegenereerde headers moeten zien en deze doorgeven aan volgende verzoeken, zoals weergegeven in de onderstaande afbeelding:


(A) Istio is verantwoordelijk voor het doorsturen van headers; (B) Services zijn verantwoordelijk voor headers
Istio doet het meeste werk omdat... genereert headers voor inkomende verzoeken, creëert nieuwe spans in elke sidecare en stuurt deze door. Als u echter niet met headers binnen services werkt, gaat het volledige traceringspad van de aanvraag verloren.
Er moet rekening worden gehouden met de volgende headers:

Dit is geen moeilijke taak, maar om de implementatie ervan te vereenvoudigen is er al veel bibliotheken - In de sa-web-app-service stuurt de RestTemplate-client deze headers bijvoorbeeld door als u eenvoudigweg de Jaeger- en OpenTracing-bibliotheken toevoegt aan zijn verslavingen.
Merk op dat de toepassing Sentimentanalyse implementaties in Flask, Spring en ASP.NET Core demonstreert.
Nu het duidelijk is wat we out-of-the-box (of bijna out-of-the-box) krijgen, gaan we eens kijken naar verfijnde routing, netwerkverkeersbeheer, beveiliging, enz.!
Opmerking. vert.: Lees hierover in het volgende deel van materiaal over Istio van Rinor Maloku, waarvan vertalingen in de nabije toekomst op onze blog zullen volgen. UPDATE (14 maart): Het tweede deel is al gepubliceerd.
PS van vertaler
Lees ook op onze blog:

 "Terug naar microservices met Istio": deel 2 (routing, verkeersleiding), deel 3 (authenticatie en autorisatie);
 «Conduit - lichtgewicht servicegaas voor Kubernetes";
 «Wat is een service mesh en waarom heb ik er een nodig [voor een cloudapplicatie met microservices]?";
 «Een geïllustreerde gids voor netwerken in Kubernetes. Deel 1 en 2";
 «Hoe is deze zijspancontainer hier [in Kubernetes] terechtgekomen?.

Bron: www.habr.com