🥇Vissza a mikroszolgáltatásokhoz az Istio-val. 1. rész

Jegyzet. ford.: A szervizhálók határozottan felkapott témává váltak a mikroszolgáltatási architektúrát követő alkalmazások mai infrastruktúrájában. Noha az Istio sok DevOps mérnök látókörébe kerül, egy meglehetősen új termékről van szó, amelynek megismerése, bár a nyújtott funkciókat tekintve összetett, jelentős időt vehet igénybe. A német mérnök, Rinor Maloku, aki az Orange Networks távközlési vállalat nagyügyfeleinek felhőalapú számítástechnikájáért felelős, egy csodálatos anyagsorozatot írt, amely lehetővé teszi, hogy gyorsan és mélyre merüljön az Istioban. Történetét azzal kezdi, hogy Istio mire képes, és hogyan láthatja ezt gyorsan a saját szemével.

Azonos — Nyílt forráskódú projekt, amelyet a Google, az IBM és a Lyft csapataival együttműködésben fejlesztettek ki. Megoldja a mikroszolgáltatásokon alapuló alkalmazásokban felmerülő bonyolultságokat, például:

forgalomirányítás: időtúllépések, újrapróbálkozások, terheléselosztás;
biztonság: végfelhasználói hitelesítés és engedélyezés;
megfigyelhetőség: nyomkövetés, megfigyelés, naplózás.

Mindegyik alkalmazás szinten megoldható, utána azonban már nem lesznek "mikro" szolgáltatásai. Az ezeknek a problémáknak a megoldására irányuló minden extra erőfeszítés a vállalati erőforrások pazarlása, amelyeket közvetlenül üzleti értékként lehetne felhasználni. Vegyünk egy példát:

Projektmenedzser: Mennyi ideig tart egy visszajelzési funkció hozzáadása?
Fejlesztő: Két sprint.

MP: Micsoda?.. Ez csak NAGY!
R: A CRUD végrehajtása a feladat egyszerű része, de továbbra is hitelesítenünk és engedélyeznünk kell a felhasználókat és a szolgáltatásokat. Mivel a hálózat nem megbízható, ismételt kéréseket kell végrehajtania, valamint megszakító minta az ügyfelekben. Továbbá, hogy megbizonyosodjon arról, hogy az egész rendszer nem omlott össze, időtúllépések és a válaszfalak (A két említett mintáról bővebben a cikk későbbi részében olvashat.), valamint a problémák felderítése érdekében monitorozás, nyomon követés, […]
MP: Ó, akkor tegyük be ezt a funkciót a Termékszolgáltatásba.

Azt hiszem, az ötlet egyértelmű: hatalmas lépések és erőfeszítések szükségesek egyetlen szolgáltatás hozzáadásához. Ebben a cikkben megnézzük, hogyan távolítja el az Istio a fent említett (az üzleti logika által nem célzott) összes bonyolultságot a szolgáltatásokból.

Megjegyzés: A cikk feltételezi, hogy rendelkezik a Kubernetes gyakorlati ismereteivel. Ellenkező esetben ajánlom elolvasásra bemutatkozásom a Kuberneteshez és csak ezután folytassa ennek az anyagnak az olvasását.

Istio ötlet

Egy Istio nélküli világban az egyik szolgáltatás közvetlen kéréseket küld a másiknak, és hiba esetén a szolgáltatásnak magának kell kezelnie: új kísérletet kell tennie, időtúllépést kell biztosítania, megszakítót nyitnia stb.

Hálózati forgalom a Kubernetesben

Az Istio ezzel szemben egy speciális megoldást kínál, amely teljesen elkülönül a szolgáltatásoktól és funkcióktól azáltal, hogy zavarja a hálózati interakciót. És így valósítja meg:

hibatűrés: a válaszban szereplő állapotkód alapján megérti, ha a kérés sikertelen volt, és újra elküldi.
Canary Rollouts: a kéréseknek csak egy meghatározott százalékát irányítja át a szolgáltatás új verziójára.
Monitoring és mérőszámok: mennyi időbe telt, mire a szolgáltatás válaszolt?
Nyomon követés és megfigyelhetőség: Speciális fejléceket ad hozzá minden kéréshez, és nyomon követi őket a fürtön keresztül.
biztonság: Lekér egy JWT tokent, hitelesíti és engedélyezi a felhasználókat.

Ez csak néhány lehetőség (valójában csak néhány!), hogy felkeltse az érdeklődésed. Most merüljünk el a technikai részletekben!

Építészet

Az Istio elfogja az összes hálózati forgalmat, és szabályokat alkalmaz rá, minden egyes podba egy oldalkocsis konténer formájában intelligens proxyt illesztve. Az összes lehetőséget aktiváló proxy a Adat sík, és ezek segítségével dinamikusan állíthatók Irányító sík.

Adat sík

A podokba behelyezett proxyk lehetővé teszik az Istio számára, hogy könnyedén teljesítse a szükséges követelményeket. Például ellenőrizzük az újrapróbálkozásokat és a megszakító funkciókat.

Az újrapróbálkozások és az áramkör-megszakítás megvalósítása az Envoy-ban

Összefoglalva:

Követ (egy oldalkocsis konténerben elhelyezett proxyról beszélünk, ami és hogyan kerül elosztásra külön termék - kb. fordítás.) kérést küld a B szolgáltatás első példányának, és meghiúsul.
Envoy Sidecar újra próbálkozik (próbálja újra). (1)
A sikertelen kérés visszakerül az azt hívó proxyhoz.
Ez megnyitja a Circuit Breaker-t, és felhívja a következő szolgáltatást a további kérésekhez. (2)

Ez azt jelenti, hogy nem kell használnia a következő Retry könyvtárat, nem kell saját maga implementálnia a Circuit Breaking and Service Discovery-t X, Y vagy Z programozási nyelven. Mindez és még sok más elérhető a doboz Istioban, és nem igényel bármilyen kód megváltozik.

Nagy! Most lehet, hogy szeretne kirándulni Istioval, de még mindig vannak kétségek, nyitott kérdések. Ha ez egy univerzális megoldás az élet minden alkalomra, akkor jogos a gyanúja: elvégre minden ilyen megoldás nem alkalmas semmilyen esetre.

És végül megkérdezi: "Testreszabható?"

Most már készen áll egy tengeri utazásra – és ismerkedjünk meg a Control Plane-el.

Irányító sík

Három összetevőből áll: Pilóta, Keverő и Fellegvár, amelyek együttesen konfigurálják a Küldötteket a forgalom irányítására, házirendek alkalmazására és telemetriai adatok gyűjtésére. Sematikusan az egész így néz ki:

A vezérlősík és az adatsík kölcsönhatása

A küldöttek (azaz adatsík) a következővel vannak konfigurálva Kubernetes CRD (Egyéni erőforrás-meghatározások) az Istio által meghatározott és kifejezetten erre a célra tervezett. Ez azt jelenti számodra, hogy ezek csak egy másik erőforrás a Kubernetesben, ismerős szintaxissal. A létrehozás után ezt az erőforrást felveszi a vezérlősík, és alkalmazza a Küldöttekre.

A szolgáltatások kapcsolata Istióval

Leírtuk az Istio szolgáltatásokhoz való viszonyát, de nem fordítva: hogyan viszonyulnak a szolgáltatások az Istióhoz?

Őszintén szólva, a szolgálatok éppúgy tudnak Istio jelenlétéről, mint a halak a vízről, amikor felteszik maguknak a kérdést: „Mégis mi a víz?”.

ábra Dimitrakopulosz Viktória: Hogy tetszik a víz? - Amúgy mi az a víz?

Így vehetsz egy működő fürtöt, és az Istio komponensek telepítése után a benne lévő szolgáltatások tovább működnek, és ezen összetevők eltávolítása után minden újra rendben lesz. Nyilvánvaló, hogy ebben az esetben elveszíti az Istio nyújtotta lehetőségeket.

Elég az elméletből – ültessük át ezt a tudást a gyakorlatba!

Istio a gyakorlatban

Az Istiohoz Kubernetes-fürtre van szükség, legalább 4 vCPU-val és 8 GB RAM-mal. A fürt gyors emeléséhez és a cikkben található utasítások követéséhez javaslom a Google Cloud Platform használatát, amely új felhasználókat kínál ingyenes 300 dollár.

A fürt létrehozása és a Kuberneteshez való hozzáférés beállítása után a konzolsegédprogramon keresztül telepítheti az Istio-t a Helm csomagkezelőn keresztül.

Sisak beszerelés

Telepítse a Helm klienst a számítógépére a leírás szerint hivatalos dokumentáció. A következő részben sablonok létrehozására fogjuk használni az Istio telepítéséhez.

Telepítés

Töltse le az Istio forrásait innen legutolsó kiadás (az eredeti szerző linkje az 1.0.5-ös verzióra módosult a jelenlegire, azaz 1.0.6-ra – kb. fordítás.), bontsa ki a tartalmat egyetlen könyvtárba, amelyre így fogok hivatkozni [istio-resources].

Az Istio-erőforrások egyszerű azonosítása érdekében hozzon létre egy névteret a K8s-fürtben istio-system:

$ kubectl create namespace istio-system

Fejezze be a telepítést a könyvtárba navigálással [istio-resources] és futtassa a parancsot:

$ 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

Ez a parancs az Istio kulcsfontosságú összetevőit egy fájlba írja ki istio.yaml. A standard sablont saját magunknak módosítottuk a következő paraméterek megadásával:

global.mtls.enabled beépítve false (azaz az mTLS hitelesítés le van tiltva – kb. fordítás.)randevúzási folyamatunk egyszerűsítésére;
tracing.enabled lehetővé teszi a kérések nyomon követését a Jaegerrel;
kiali.enabled a Kialit egy klaszterbe telepíti a szolgáltatások és a forgalom megjelenítéséhez;
grafana.enabled telepíti a Grafanát az összegyűjtött mutatók megjelenítéséhez.

Alkalmazza a generált erőforrásokat a következő paranccsal:

$ kubectl apply -f istio.yaml

Az Istio telepítése a fürtben befejeződött! Várja meg, amíg a névtérben található összes sor istio-system képes lesz arra Running vagy Completedaz alábbi parancs futtatásával:

$ kubectl get pods -n istio-system

Most készen állunk arra, hogy folytassuk a következő részre, ahol felhozzuk és futtatjuk az alkalmazást.

Sentiment Analysis Application Architecture

Használjuk a már említettekben használt Sentiment Analysis mikroszolgáltatási alkalmazás példáját Bevezető cikk a Kuberneteshez. Elég összetett ahhoz, hogy a gyakorlatban is megmutassa az Istio lehetőségeit.

Az alkalmazás négy mikroszolgáltatásból áll:

Szolgáltatás SA-Frontend, amely a Reactjs előtér-alkalmazását szolgálja ki;
Szolgáltatás SA Web App, amely hangulatelemzési lekérdezéseket szolgál ki;
Szolgáltatás SA Logicamely teljesíti magát hangulatelemzés;
Szolgáltatás SA Visszajelzés, amely visszajelzést kap a felhasználóktól az elvégzett elemzés pontosságáról.

Ezen a diagramon a szolgáltatások mellett a Belépés-vezérlőt is látjuk, amely Kubernetesben a bejövő kéréseket a megfelelő szolgáltatásokhoz irányítja. Az Istio hasonló koncepciót használ az Ingress Gateway részeként, ennek részletei a továbbiakban.

Alkalmazás indítása az Istio proxyjával

A cikkben említett további műveletekhez klónozza a tárat istio-mesterség. Tartalmazza a Kubernetes és az Istio alkalmazását és manifesztjeit.

Oldalkocsik behelyezése

A beillesztés elvégezhető automatikusan vagy kézzel. Az oldalkocsis tárolók automatikus beillesztéséhez be kell állítania a címkét a névtérre istio-injection=enabled, amely a következő paranccsal történik:

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

Most minden egyes pod, amely az alapértelmezett névtérben lesz telepítve (default) kapja meg oldalkocsis konténerét. Ennek ellenőrzéséhez telepítsünk egy tesztalkalmazást a lerakat gyökérkönyvtárába lépve [istio-mastery] és futtassa a következő parancsot:

$ 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

A szolgáltatások üzembe helyezése után a parancs futtatásával ellenőrizze, hogy a podoknak van-e két-két tárolója (magával a szolgáltatással és oldalkocsijával) kubectl get pods és ügyelve arra, hogy az oszlop alatt READY meghatározott értéket 2/2, ami azt jelzi, hogy mindkét tároló fut:

$ 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

Vizuálisan így néz ki:

Envoy proxy az egyik podban

Most, hogy az alkalmazás működik, engedélyeznünk kell a bejövő forgalom belépését az alkalmazásba.

Ingress Gateway

Ennek eléréséhez (forgalom engedélyezése a fürtben) a legjobb módszer a következőn keresztül Ingress Gateway az Istio-ban, amely a fürt „szélén” található, és lehetővé teszi az Istio olyan funkcióinak engedélyezését, mint az útválasztás, a terheléselosztás, a biztonság és a bejövő forgalom figyelése.

Az Ingress Gateway összetevő és az azt kifelé továbbító szolgáltatás az Istio telepítése során került a fürtre. Egy szolgáltatás külső IP-címének megtudásához futtassa:

$ 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

Továbbra is ezen az IP-n keresztül fogjuk elérni az alkalmazást (KÜLSŐ IP-címen fogom hivatkozni), ezért a kényelem kedvéért az értéket egy változóba írjuk:

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

Ha most megpróbálja elérni ezt az IP-t egy böngészőn keresztül, akkor a Szolgáltatás elérhetetlen hibaüzenet jelenik meg, mert alapértelmezés szerint az Istio blokkolja az összes bejövő forgalmatamíg meg nem határozzák az átjárót.

Átjáró erőforrás

Az átjáró egy CRD (Custom Resource Definition) a Kubernetesben, amelyet az Istio fürtbe történő telepítése után határoznak meg, és lehetővé teszi a portok, protokollok és gazdagépek megadását, amelyekhez engedélyezni akarjuk a bejövő forgalmat.

Esetünkben minden gazdagép számára engedélyezni akarjuk a HTTP-forgalmat a 80-as porton. A probléma a következő definícióval valósul meg (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:
- "*"

Ez a konfiguráció nem szorul magyarázatra, kivéve a választót istio: ingressgateway. Ezzel a választóval megadhatjuk, hogy melyik Belépési átjáróra alkalmazzuk a konfigurációt. Esetünkben ez az Ingress Gateway vezérlő, amely alapértelmezés szerint telepítve volt az Istióban.

A konfiguráció a következő parancs meghívásával kerül alkalmazásra:

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

Az átjáró most lehetővé teszi a hozzáférést a 80-as porthoz, de fogalma sincs, hová irányítsa a kéréseket. Ehhez szüksége lesz Virtuális szolgáltatások.

Virtuális szolgáltatás erőforrás

A VirtualService megmondja a Belépési átjárónak, hogyan irányítsa a fürtön belül engedélyezett kéréseket.

Az alkalmazásunkhoz a http-gateway-n keresztül érkező kéréseket az sa-frontend, sa-web-app és sa-feedback szolgáltatásokhoz kell eljuttatni:

A VirtualServices szolgáltatással konfigurálandó útvonalak

Fontolja meg azokat a kéréseket, amelyeket el kell küldeni az SA-Frontendnek:

Pontos meccs az úton / el kell küldeni az SA-Frontendnek, hogy megkapja az index.html-t;
Útvonalak előtaggal /static/* el kell küldeni az SA-Frontendnek, hogy megkapja a frontendben használt statikus fájlokat, mint például a CSS és a JavaScript;
A reguláris kifejezésnek megfelelő utak '^.*.(ico|png|jpg)$', SA-Frontendnek kell küldeni, mert Ezek az oldalon megjelenő képek.

A megvalósítás a következő konfigurációval érhető el (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
Fontos pontok:

Ez a virtuális szolgáltatás a beérkező kérésekre vonatkozik http-átjáró;
В destination meghatározza azt a szolgáltatást, amelyhez a kéréseket küldik.

Megjegyzés: A fenti konfiguráció egy fájlban van tárolva sa-virtualservice-external.yaml, amely az SA-WebApp és az SA-Feedback útválasztási beállításait is tartalmazza, de itt a cikkben lerövidítettük a rövidség kedvéért.

Jelentkezzen a VirtualService telefonszámon:

Megjegyzés: Amikor Istio-erőforrásokat alkalmazunk, a Kubernetes API-kiszolgáló aktivál egy eseményt, amelyet az Istio vezérlősík kap, majd ezt követően az új konfigurációt alkalmazza minden egyes pod Envoy proxyjára. És úgy tűnik, hogy az Ingress Gateway vezérlő egy másik, a Vezérlősíkon konfigurált Envoy. Mindez így néz ki a diagramon:

Istio-IngressGateway konfiguráció a kérés útválasztásához

A hangulatelemzés már elérhető itt: http://{EXTERNAL-IP}/. Ne aggódjon, ha a Nem található állapotot kapja: néha egy kicsit tovább tart, amíg a konfiguráció életbe lép, és az Envoy gyorsítótárak frissülnek.

Mielőtt folytatná, játsszon egy kicsit az alkalmazással, hogy forgalmat generáljon (jelenléte szükséges az egyértelműség érdekében a következő műveleteknél - kb. ford.).

Kiali: megfigyelhetőség

A Kiali adminisztrációs felület eléréséhez futtassa a következő parancsot:

…és kinyitni http://localhost:20001/admin/adminként bejelentkezve. Itt számos hasznos funkciót találhat, például az Istio komponensek konfigurációjának ellenőrzéséhez, a szolgáltatások megjelenítéséhez a hálózati kérések lehallgatásával gyűjtött információkból, választ kaphat a „Ki kivel lép kapcsolatba?”, „A szolgáltatás melyik verziója tapasztalható” kérdésekre. kudarcok?” stb. Általában fedezze fel a Kiali lehetőségeit, mielőtt a metrikák Grafana segítségével történő megjelenítéséhez kezdene.

Grafana: metrikák megjelenítése

Az Istio-ban összegyűjtött mutatók a Prometheusba kerülnek, és a Grafana segítségével jelenítik meg őket. A Grafana adminisztrációs felületének eléréséhez futtassa az alábbi parancsot, majd nyissa meg http://localhost:3000/:

A menüre kattintva Kezdőlap bal felső sarokban, és válassza ki Istio Service Dashboard a bal felső sarokban kezdje a szervizzel sa-web-appaz összegyűjtött mutatók megtekintéséhez:

Itt egy üres és teljesen unalmas előadásra várunk - a vezetőség ezt soha nem fogja helyeselni. Hozzunk létre egy kis terhelést a következő paranccsal:

Most sokkal szebb grafikonok állnak rendelkezésünkre, és rajtuk kívül a csodálatos Prometheus monitorozási és Grafana a mérőszámok megjelenítéséhez, amelyek segítségével megismerhetjük a teljesítményt, az egészségi állapotot, a szolgáltatások fejlődését/romlását az idő múlásával.

Végül nézzük a kérések nyomon követését a szolgáltatásokban.

Jaeger: nyomkövetés

Szükségünk lesz a nyomon követésre, mert minél több szolgáltatásunk van, annál nehezebb a hiba okához eljutni. Nézzünk egy egyszerű esetet az alábbi képről:

Tipikus példa egy véletlenszerű sikertelen kérésre

Jön a kérés, esik - mi az ok? Első szervíz? Vagy második? Mindkettőben vannak kivételek – nézzük meg mindegyik naplóját. Milyen gyakran kaptad magad ezen? A mi munkánk inkább szoftvernyomozók, mint fejlesztők…

Ez egy elterjedt probléma a mikroszolgáltatásokban, és elosztott nyomkövetési rendszerekkel oldják meg, amelyekben a szolgáltatások egyedi fejlécet adnak át egymásnak, majd ezt az információt átirányítják a nyomkövető rendszerbe, ahol összehasonlítják a kérési adatokkal. Íme egy illusztráció:

A TraceId a kérés azonosítására szolgál

Az Istio a Jaeger Tracert használja, amely a gyártótól független OpenTracing API keretrendszert valósítja meg. A Jaeger felhasználói felületet a következő paranccsal érheti el:

Most menjen ide http://localhost:16686/ és válasszon egy szolgáltatást sa-web-app. Ha a szolgáltatás nem jelenik meg a legördülő menüben, mutasson/generáljon tevékenységet az oldalon, és frissítse a felületet. Ezt követően kattintson a gombra Nyomokat találni, amely a legfrissebb nyomokat mutatja - válasszon bármilyen - részletes információk jelennek meg az összes nyomról:

Ez a nyom mutatja:

Bejön a kérés istio-belépési átjáró (ez az első interakció az egyik szolgáltatással, és egy nyomkövetési azonosító generálódik a kéréshez), amely után az átjáró elküldi a kérést a szolgáltatásnak sa-web-app.
Szolgálatban sa-web-app a kérést az Envoy oldalkocsi felveszi, a spanban létrehoz egy "gyermeket" (ezért látjuk nyomokban) és átirányítja a konténerbe sa-web-app. (Span - egy logikai munkaegység a Jaegerben, amelynek neve, a művelet kezdési időpontja és időtartama van. A fesztávok egymásba ágyazhatók és rendezhetők. Az ívek irányított aciklikus gráfja nyomvonalat alkot. - kb. fordítás.)
Itt a kérés feldolgozása a metódus szerint történik érzelemelemzés. Ezeket a nyomokat már az alkalmazás generálja, pl. kódmódosítást igényeltek.
Ettől a pillanattól kezdve a POST kérés elindul sa-logika. A nyomkövetési azonosítót innen kell továbbítani sa-web-app.
...

Megjegyzés: A 4. lépésben az alkalmazásnak látnia kell az Istio által generált fejléceket, és át kell adnia azokat a következő kéréseknek, amint az az alábbi képen látható:

(A) A fejléc továbbítása az Istio feladata; (B) A szolgáltatások felelősek a fejlécekért

Istio elvégzi a munka nagy részét, mert fejléceket generál a bejövő kérésekhez, új spanokat hoz létre minden egyes mellékszolgáltatásban, és továbbítja azokat. A szolgáltatásokon belüli fejlécekkel való munka nélkül azonban a teljes kérés nyomkövetési útvonala elvész.

A következő fejléceket kell figyelembe venni (továbbítani):

Ez egy egyszerű feladat, de a végrehajtás egyszerűsítése érdekében már van sok könyvtár - például az sa-web-app szolgáltatásban a RestTemplate kliens továbbítja ezeket a fejléceket, ha egyszerűen hozzáadja a Jaeger és az OpenTracing könyvtárakat a függőségei.

Vegye figyelembe, hogy a Sentiment Analysis alkalmazás bemutatja a Flask, Spring és ASP.NET Core implementációit.

Most, hogy világossá vált, mit hozunk ki a dobozból (vagy majdnem ki a dobozból), nézzük meg a finomhangolást az útválasztást, a hálózati forgalomkezelést, a biztonságot és még sok mást!

Jegyzet. ford.: erről olvashatsz Rinor Maloku Istio-ról szóló anyagainak következő részében, amelyek fordításai a közeljövőben követik majd a blogunkat. UPDATE (március 14.): A második rész már megjelent.

PS a fordítótól

Olvassa el blogunkon is:

"Vissza a mikroszolgáltatásokhoz az Istióval": 2. rész (útválasztás, forgalomirányítás), 3. rész (hitelesítés és engedélyezés);
«Csővezeték - könnyű szervizháló a Kubernetes számára";
«Mi az a szolgáltatásháló, és miért van szükségem rá [mikroszolgáltatásokkal rendelkező felhőalkalmazásokhoz]?";
«Illusztrált útmutató a Kubernetes hálózatépítéshez. 1. és 2. rész";
«Hogyan került ide [Kubernetesbe] ez az oldalkocsis konténer?".

Forrás: will.com