🥇Powrót do mikroserwisów z Istio. Część 1

Przyp. tłum.: Service mesh stały się aktualnym rozwiązaniem w nowoczesnej infrastrukturze aplikacji opartych na mikrousługach. Choć Istio jest znane wielu inżynierom DevOps, to wciąż stosunkowo nowy produkt, który, będąc kompleksowym w zakresie dostępnych możliwości, może wymagać znacznego czasu na zaznajomienie się z nim. Niemiecki inżynier Rinor Maloku, odpowiedzialny za obliczenia w chmurze dla dużych klientów w telekomunikacyjnej firmie Orange Networks, napisał znakomity cykl materiałów, który pozwala szybko i dokładnie zanurzyć się w Istio. Swoją opowieść zaczyna od tego, co właściwie potrafi Istio i jak można to szybko zobaczyć na własne oczy.

Istio to projekt Open Source, opracowany we współpracy zespołów z Google, IBM i Lyft. Rozwiązuje problemy, które występują w aplikacjach opartych na mikrousługach, na przykład takie jak:

Zarządzanie ruchem: timeouty, ponowne próby, równoważenie obciążenia;
Bezpieczeństwo: uwierzytelnianie i autoryzacja użytkownika końcowego;
Obserwowalność: śledzenie, monitorowanie, logowanie.

Wszystkie te problemy można rozwiązać na poziomie aplikacji, jednak wtedy twoje usługi przestaną być ‚mikro’. Wszelkie dodatkowe wysiłki na rzecz rozwiązania tych problemów to zbędny wydatek zasobów firmy, które mogłyby być przeznaczone na wartości biznesowe. Rozważmy przykład:

Kierownik projektu: Jak długo zajmie dodanie funkcji informacji zwrotnej?
Programista: Dwa sprinty.
KP: Co?.. To przecież tylko CRUD!
P: Stworzenie CRUD to łatwa część zadania, ale będziemy musieli również uwierzytelnić i autoryzować użytkowników oraz usługi. Ponieważ sieć jest zawodna, potrzebne będą ponowne próby oraz wzorzec circuit breaker w klientach. A także, aby upewnić się, że cały system nie padł, potrzebne będą timeouty oraz bulkheads (więcej na temat obu wymienionych wzorców zobacz dalej w artykule — przyp. tłum.), a żeby wykrywać problemy, potrzebny będzie monitoring, śledzenie, […]
KP: Och, w takim razie po prostu dodajmy tę funkcję do usługi Produkt.

Myślę, że pomysł jest jasny: zakres kroków i wysiłków potrzebnych do dodania jednej usługi jest ogromny. W tym artykule przyjrzymy się, jak Istio eliminuje wszystkie wcześniej wymienione trudności (niezwiązane z logiką biznesową) z usług.

Uwaga: Artykuł zakłada, że masz praktyczną wiedzę na temat Kubernetes. W przeciwnym razie polecam przeczytać moje wprowadzenie do Kubernetes i dopiero potem kontynuować czytanie tego materiału.

Idea Istio

W świecie bez Istio jedna usługa wykonuje bezpośrednie zapytania do drugiej, a w przypadku awarii usługa musi sama zająć się tym: ponowić próbę, przewidzieć limit czasowy, otworzyć circuit breaker itp.

Ruch sieciowy w Kubernetes

Istio oferuje specjalizowane rozwiązanie, całkowicie oddzielone od usług, które działa poprzez ingerencję w interakcje sieciowe. I w ten sposób realizuje:

Odporność na awarie: w oparciu o kod statusu w odpowiedzi rozumie, czy wystąpiła awaria w zapytaniu i wykonuje je ponownie.
Canary releases: przekierowuje do nowej wersji usługi jedynie ustaloną procentowo liczbę zapytań.
Monitorowanie i metryki: w jakim czasie usługa odpowiedziała?
Śledzenie i obserwowalność: dodaje specjalne nagłówki do każdego zapytania i śledzi je w klastrze.
Bezpieczeństwo: wydobywa token JWT, autoryzując użytkowników.

To tylko niektóre z możliwości (naprawdę tylko niektóre!), aby wzbudzić Twoje zainteresowanie. A teraz zanurzmy się w szczegóły techniczne!

Architektura Istio

Istio przechwytuje cały ruch sieciowy i stosuje do niego zestaw reguł, wstawiając do każdego poda inteligentny proxy w postaci sidecar kontenera. Proksy, które aktywują wszystkie możliwości, tworzą Data Plane, a ich konfiguracja może być dynamicznie dostosowywana za pomocą Control Plane.

Data Plane

Wstawiane do podów proksy pozwalają Istio łatwo osiągnąć wymagane przez nas cele. Na przykład, sprawdźmy funkcje powtórnych prób i circuit breaker.

Jak są realizowane retries i circuit breaking w Envoy

Podsumowując:

Envoy (mówimy o proksy w sidecarze, który jest również rozpowszechniany jako oddzielny produkt — przyp. tłum.) wysyła zapytanie do pierwszego egzemplarza usługi B i następuje awaria.
Envoy Sidecar podejmuje ponowną próbę (retry). (1)
Zapytanie z awarią wraca do wywołującego go proksy.
Tak Circuit Breaker zostaje otwarty i następuje wywołanie kolejnej usługi dla następnych żądań. (2)

Oznacza to, że nie musisz korzystać z kolejnej biblioteki Retry, nie musisz implementować Circuit Breaking i Service Discovery w językach programowania X, Y lub Z. To wszystko i wiele więcej jest dostępne prosto z pudełka w Istio i nie wymaga żadnych zmian w kodzie.

Świetnie! Teraz możesz chcieć wyruszyć w podróż z Istio, ale nadal masz jakieś wątpliwości i otwarte pytania. Jeśli to uniwersalne rozwiązanie na każdą okazję, to pojawia się zasadnicze pytanie: czy takie rozwiązania w rzeczywistości nie okazują się nieodpowiednie w żadnej sytuacji.

I w końcu zapytasz: "Czy to można skonfigurować?"

Teraz jesteś gotowy na morską podróż — a teraz poznajmy Control Plane.

Control Plane

Składa się z trzech komponentów: Pilot, Mixer i Citadel, które wspólnie konfigurują Envoy’e do routingu ruchu, stosują polityki i zbierają dane telemetryczne. Schematycznie wygląda to tak:

Interakcja Control Plane z Data Plane

Envoy’e (tj. data plane) są konfigurowane za pomocą Kubernetes CRD (Definicje Zasobów Niestandardowych), określonych przez Istio i stworzonych specjalnie do tego celu. Dla Ciebie oznacza to, że są przedstawiane jako kolejny zasób w Kubernetes z dobrze znaną składnią. Po utworzeniu ten zasób zostanie wybrany przez control plane i zastosowany do Envoy’ów.

Relacja usług do Istio

Opisaliśmy relację Istio do usług, ale nie odwrotnie: jak usługi odnoszą się do Istio?

Szczerze mówiąc, o obecności Istio usługi wiedzą tak dobrze, jak ryby o wodzie, gdy zadają sobie pytanie: "Czym właściwie jest woda?".

Ilustracja Victoria Dimitrakopoulos: — Jak smakuje woda? — Czym właściwie jest woda?

Tak więc możesz wziąć działający klaster, a po wdrożeniu komponentów Istio usługi w nim nadal będą działać, a po usunięciu tych komponentów znów wszystko będzie dobrze. Oczywiście, że w tym przypadku stracisz możliwości, które oferuje Istio.

Dość teorii — przełóżmy tę wiedzę na praktykę!

Istio w praktyce

Istio wymaga klastra Kubernetes, w którym dostępne są przynajmniej 4 vCPU i 8 GB RAM. Aby szybko uruchomić klaster i podążać za instrukcjami z artykułu, polecam skorzystać z Google Cloud Platform, która oferuje nowe konto użytkownikom. darmowe $300.

Po utworzeniu klastra i skonfigurowaniu dostępu do Kubernetes za pomocą narzędzia konsolowego można zainstalować Istio za pomocą menedżera pakietów Helm.

Instalacja Helm

Zainstaluj klienta Helm na swoim komputerze, zgodnie z instrukcjami w oficjalnej dokumentacji. Będziemy go używać do generowania szablonów do instalacji Istio w następnej sekcji.

Instalacja Istio

Pobierz zasoby Istio z najnowszego wydania (oryginalny link do wersji 1.0.5 zmieniono na aktualny, tj. 1.0.6 — przyp. tłum.), wyodrębnij zawartość do jednego katalogu, który dalej będę nazywał [istio-resources].

Dla ułatwienia identyfikacji zasobów Istio utwórz w klastrze K8s przestrzeń nazw istio-system:

$ kubectl create namespace istio-system

Zakończ instalację, przechodząc do katalogu [istio-resources] i wykonując polecenie:

$ 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

To polecenie wyprowadzi kluczowe komponenty Istio do pliku istio.yaml. Zmieniliśmy standardowy szablon zgodnie z naszymi potrzebami, określając następujące parametry:

global.mtls.enabled ustawione na false (tj. uwierzytelnianie mTLS jest wyłączone — przyp. tłum.), aby uprościć nasz proces zapoznania się;
tracing.enabled włącza śledzenie zapytań za pomocą Jaeger;
kiali.enabled instaluje Kiali w klastrze do wizualizacji usług i ruchu;
grafana.enabled instaluje Grafana do wizualizacji zebranych metryk.

Zastosujemy wygenerowane zasoby poleceniem:

$ kubectl apply -f istio.yaml

Instalacja Istio w klastrze zakończona! Poczekaj, aż wszystkie pod’y w przestrzeni nazw istio-system będą w stanie Running lub Completed, wykonując poniższe polecenie:

$ kubectl get pods -n istio-system

Teraz jesteśmy gotowi przejść do następnej sekcji, gdzie uruchomimy aplikację.

Architektura aplikacji Sentiment Analysis

Skorzystamy z przykładu mikrousługowej aplikacji Sentiment Analysis, wykorzystanej w już wspomnianym artykuł wprowadzający do Kubernetes. Jest na tyle złożona, aby pokazać możliwości Istio w praktyce.

Aplikacja składa się z czterech mikrousług:

Serwis SA-Frontend, który obsługuje frontend aplikacji w Reactjs;
Serwis SA-WebApp, który obsługuje zapytania Sentiment Analysis;
Serwis SA-Logic, który przeprowadza sam analizę sentymentu;
Serwis SA-Feedback, który zbiera od użytkowników informację zwrotną na temat dokładności przeprowadzonej analizy.

Na tym schemacie, oprócz usług, widzimy także Ingress Controller, który w Kubernetes kieruje przychodzące żądania do odpowiednich usług. W Istio stosuje się podobną koncepcję w ramach Ingress Gateway, szczegóły pojawią się wkrótce.

Uruchamianie aplikacji z proxy Istio

Aby przeprowadzić dalsze operacje wymienione w artykule, sklonuj swój repozytorium istio-mastery. Zawiera ono aplikację oraz manifesty dla Kubernetes i Istio.

Wstawianie sidecarów

Wstawienie może być wykonane automatycznie lub ręcznie. Aby automatycznie wstawić kontenery sidecar, należy ustawić etykietę dla przestrzeni nazw istio-injection=enabled, co można zrobić za pomocą następującej komendy:

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

Teraz każdy pod, który będzie wdrażany w przestrzeni nazw domyślnej (default) otrzyma swój kontener sidecar. Aby się o tym upewnić, zainstalujmy aplikację testową, przechodząc do głównego katalogu repozytorium [istio-mastery] i wykonując następującą komendę:

$ 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

Po wdrożeniu usług, sprawdźmy, czy pod’y mają po dwa kontenery (z samą usługą i jej sidecarem), wykonując komendę kubectl get pods i upewnijmy się, że pod kolumną READY podano wartość 2/2, co oznacza, że oba kontenery działają:

$ 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

Wizualnie przedstawia się to tak:

Proxy Envoy w jednym z pod’ów

Teraz, gdy aplikacja jest uruchomiona i działa, musimy zezwolić na przychodzący ruch do aplikacji.

Ingress Gateway

Najlepszą praktyką w celu osiągnięcia tego (zezwolenia na ruch w klastrze) jest użycie Ingress Gateway w Istio, który znajduje się na „granicy” klastra i umożliwia włączenie dla przychodzącego ruchu takich funkcji Istio, jak routowanie, równoważenie obciążenia, bezpieczeństwo i monitorowanie.

Komponent Ingress Gateway i usługa, która przesyła go na zewnątrz, zostały zainstalowane w klastrze podczas instalacji Istio. Aby poznać zewnętrzny adres IP usługi, wykonaj:

$ 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

Będziemy się odwoływać do aplikacji przez ten IP, a dalej (będę się do niego odnosił jako EXTERNAL-IP), dlatego dla wygody zapiszemy wartość w zmiennej:

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

Jeżeli spróbujesz teraz wejść na ten IP przez przeglądarkę, otrzymasz błąd Service Unavailable, ponieważ domyślnie Istio blokuje cały przychodzący ruch, dopóki nie zostanie zdefiniowane Gateway.

Zasób Gateway

Gateway — to CRD (Custom Resource Definition) w Kubernetes, definiowany po zainstalowaniu Istio w klastrze, aktywujący możliwość wskazania portów, protokołów i hostów, dla których chcemy zezwolić na przychodzący ruch.

W naszym przypadku chcemy zezwolić na ruch HTTP na porcie 80 dla wszystkich hostów. Zadanie to realizuje następująca definicja (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:
- "*"

Taka konfiguracja nie wymaga wyjaśnień, z wyjątkiem selektora istio: ingressgateway. Dzięki temu selektorowi możemy wskazać, do którego Ingress Gateway zastosować konfigurację. W naszym przypadku jest to kontroler Ingress Gateway, który został domyślnie zainstalowany w Istio.

Konfiguracja jest stosowana wywołaniem następującego polecenia:

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

Teraz brama zezwala na dostęp do portu 80, ale nie ma informacji, dokąd kierować żądania. W tym celu potrzebne będą Virtual Services.

Zasób VirtualService

VirtualService wskazuje Ingress Gateway, jak kierować żądania, które są dozwolone wewnątrz klastra.

Żądania do naszej aplikacji, przychodzące przez http-gateway, powinny być skierowane do usług sa-frontend, sa-web-app i sa-feedback:

Trasy, które należy skonfigurować z VirtualServices

Rozważmy żądania, które powinny być kierowane do SA-Frontend:

Dokładne dopasowanie do ścieżki / powinno być kierowane do SA-Frontend w celu uzyskania index.html;
Ścieżki z prefiksem /static/* powinny być kierowane do SA-Frontend w celu uzyskania statycznych plików, używanych w frontendzie, takich jak CSS i JavaScript;
Ścieżki, które pasują do wyrażenia regularnego '^.*.(ico|png|jpg)$', powinny być kierowane do SA-Frontend, ponieważ są to obrazy wyświetlane na stronie.

Realizacja osiągnięta jest poprzez następującą konfigurację (sa-virtualservice-external.yaml):

rodzaj: VirtualService meta: nazwa: sa-external-services spec: hosty: - "*" bramy: - http-gateway # 1 http: - dopasowanie: - uri: dokładnie: \ - uri: dokładnie: \/callback - uri: prefix: \/static - uri: regex: '^.*.(ico|png|jpg) Ważne punkty: Ten VirtualService dotyczy żądań przychodzących przez http-gateway; W destination określany jest serwis, do którego wysyłane są zapytania. Uwaga: Konfiguracja powyżej jest przechowywana w pliku sa-virtualservice-external.yaml, który zawiera również ustawienia do routingu w SA-WebApp i SA-Feedback, ale został tutaj skrócony w artykule dla zwięzłości. Zastosujmy VirtualService przy użyciu: $ kubectl apply -f resource-manifests/istio/sa-virtualservice-external.yaml virtualservice.networking.istio.io/sa-external-services utworzony Uwaga: Gdy stosujemy zasoby Istio, serwer API Kubernetes tworzy zdarzenie, które odbiera kontroler Istio, a dopiero potem nowa konfiguracja jest stosowana do serwerów proxy Envoy każdego poda. A kontroler Ingress Gateway jest przedstawiany jako kolejny Envoy, skonfigurowany w Control Plane. Wszystko to na diagramie wygląda tak: Konfiguracja Istio-IngressGateway dla routingu zapytań Aplikacja Sentiment Analysis jest dostępna pod adresem http://{EXTERNAL-IP}/. Nie martw się, jeśli otrzymujesz status Not Found: czasami wymaga to nieco więcej czasu, aby konfiguracja weszła w życie i pamięci podręczne Envoy zostały zaktualizowane. Zanim kontynuujesz, spędź trochę czasu z aplikacją, aby wygenerować ruch (jest on konieczny do wizualizacji w kolejnych działaniach — przyp. tłum.). Kiali: obserwowalność Aby uzyskać dostęp do interfejsu administracyjnego Kiali, wykonaj następujące polecenie: $ kubectl port-forward $(kubectl get pod -n istio-system -l app=kiali -o jsonpath='{.items[0].metadata.name}') -n istio-system 20001 … i otwórz http://localhost:20001/, logując się jako admin/admin. Tutaj znajdziesz wiele przydatnych funkcjonalności, np. do sprawdzania konfiguracji komponentów Istio, wizualizacji serwisów na podstawie danych zebranych podczas przechwytywania zapytań sieciowych, uzyskiwania odpowiedzi na pytania "Kto do kogo się odzywa?", "W której wersji serwisu występują błędy?" itp. Ogólnie rzecz biorąc, przeanalizuj możliwości Kiali przed przejściem dalej — do wizualizacji metryk z Grafany. Grafana: wizualizacja metryk Metryki zebrane w Istio trafiają do Prometheus i są wizualizowane za pomocą Grafany. Aby uzyskać dostęp do interfejsu administracyjnego Grafany, wykonaj poniższe polecenie, a następnie otwórz 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 Kliknij w menu Home w lewym górnym rogu i wybierz Istio Service Dashboard w lewym górnym rogu, zacznij od serwisu sa-web-app, aby zobaczyć zebrane metryki: Czeka na nas pusty i zupełnie nudny widok — przewodnik nigdy by tego nie zatwierdził. Stwórzmy zatem małe obciążenie za pomocą następującego polecenia: $ while true; do curl -i http://$EXTERNAL_IP/sentiment -H "Content-type: application/json" -d '{"sentence": "Kocham yogobella"}'; sleep .8; done Teraz mamy znacznie ładniejsze wykresy, a do tego świetne narzędzia Prometheus do monitorowania i Grafana do wizualizacji metryk, które pozwolą nam poznać wydajność, stan zdrowia oraz poprawy/pogorszenia w działaniu serwisów w czasie. Na koniec przyjrzyjmy się śledzeniu zapytań w serwisach. Jaeger : śledzenie Śledzenie jest potrzebne, ponieważ im więcej mamy serwisów, tym trudniej dotrzeć do przyczyny awarii. Przyjrzyjmy się prostemu przypadkowi z poniższego obrazka: Typowy przykład losowego nieudanego zapytania Zapytanie przychodzi, zawodzi — jakie mogą być przyczyny? Pierwszy serwis? A może drugi? Wyjątki pojawiają się w obu — przyjrzyjmy się logom każdego z nich. Jak często łapaliście się na tym zajęciu? Nasza praca przypomina bardziej detektywów oprogramowania niż programistów… To powszechny problem w mikrousługach, który rozwiązuje się za pomocą rozproszonych systemów śledzenia, w których serwisy przekazują sobie unikalny nagłówek, a następnie te informacje są przekazywane do systemu śledzenia, gdzie łączą się z danymi zapytania. Oto ilustracja: Identyfikator zapytania używa TraceId W Istio używany jest Jaeger Tracer, który implementuje niezależny od dostawcy framework OpenTracing API. Uzyskać dostęp do interfejsu użytkownika Jaeger można następującą komendą: $ kubectl port-forward -n istio-system $(kubectl get pod -n istio-system -l app=jaeger -o jsonpath='{.items[0].metadata.name}') 16686 Teraz wejdź na http://localhost:16686/ i wybierz serwis sa-web-app. Jeśli serwis nie pojawia się na rozwijanej liście — zrób/swój aktywność na stronie i zaktualizuj interfejs. Następnie kliknij przycisk Find Traces, który pokaże najnowsze ślady — wybierz dowolny — pojawi się szczegółowa informacja o wszystkich śladach: Ten ślad pokazuje: Zapytanie przychodzi do istio-ingressgateway (to pierwsza interakcja z jednym z serwisów, a dla zapytania generuje się Trace ID), a następnie brama kieruje zapytanie do serwisu sa-web-app. W serwisie sa-web-app zapytanie jest przechwytywane przez Envoy sidecar'a, tworzy się "dziecko" w spanie (dlatego widzimy to w śladach) i jest przekazywane do kontenera sa-web-app. (Span — logiczna jednostka pracy w Jaeger, posiadająca nazwę, czas rozpoczęcia operacji oraz jej długość. Span'y mogą być zagnieżdżone i uporządkowane. Ukierunkowany acykliczny graf z span'ów tworzy trace. — przyp. tłum.) Tutaj zapytanie jest przetwarzane metodą sentimentAnalysis. Te ślady zostały już wygenerowane przez aplikację, to znaczy, że wymagały zmian w kodzie. Od tego momentu inicjowane jest zapytanie POST do sa-logic. Trace ID musi być przekazywane z sa-web-app. … Uwaga: Na 4 kroku aplikacja powinna zobaczyć nagłówki wygenerowane przez Istio i przekazać je w kolejnych zapytaniach, jak pokazano na poniższym obrazku: (A) Przekazywanie nagłówków obsługuje Istio; (B) Za nagłówki odpowiadają usługi Istio wykonuje główną pracę, ponieważ generuje nagłówki dla przychodzących zapytań, tworzy nowe span'y w każdym sidecarze i przekazuje je. Jednak bez obsługi nagłówków wewnątrz usług pełna ścieżka śledzenia zapytania zostanie utracona. Należy uwzględnić (przekazywać) następujące nagłówki: x-request-id x-b3-traceid x-b3-spanid x-b3-parentspanid x-b3-sampled x-b3-flags x-ot-span-context To nie jest trudne zadanie, jednak dla uproszczenia jego realizacji istnieje już wiele bibliotek — na przykład w usłudze sa-web-app klient RestTemplate przekazuje te nagłówki, jeśli po prostu doda biblioteki Jaeger i OpenTracing do swoich zależności. Zauważ, że aplikacja Sentiment Analysis demonstruje implementacje w Flask, Spring oraz ASP.NET Core. Teraz, kiedy stało się jasne, co otrzymujemy z pudełka (lub prawie „z pudełka”), rozważmy pytania związane z precyzyjnym routingiem, zarządzaniem ruchem sieciowym, bezpieczeństwem itd.! Przyp. tłum.: o tym przeczytacie w następnej części materiałów o Istio autorstwa Rinora Maloku, których tłumaczenia pojawią się w naszym blogu w najbliższym czasie. UPDATE (14 marca): Druga część już została opublikowana. P.S. od tłumacza Przeczytaj także na naszym blogu: „Powrót do mikroserwisów z Istio”: część 2 (routing, zarządzanie ruchem), część 3 (uwierzytelnianie i autoryzacja); «Conduit — lekki service mesh dla Kubernetes»; «Czym jest service mesh i dlaczego go potrzebuję [dla aplikacji w chmurze z mikroserwisami]?»; «Ilustrowany przewodnik po architekturze sieci w Kubernetes. Części 1 i 2»; «Jak ten kontener sidecar trafił tutaj [w Kubernetes]?». Źródło: habr.com route: - destination: host: sa-frontend # 2 port: number: 80
Ważne kwestie:

Ten VirtualService dotyczy żądań przychodzących przez http-gateway;
W destination określany jest serwis, do którego wysyłane są zapytania.

Uwaga: Konfiguracja powyżej jest przechowywana w pliku sa-virtualservice-external.yaml, który również zawiera ustawienia dla routingu w SA-WebApp i SA-Feedback, ale został tutaj skrócony w artykule dla zwięzłości.

Zastosowanie VirtualService przy wywołaniu:

Uwaga: Gdy stosujemy zasoby Istio, serwer API Kubernetes generuje zdarzenie, które przekazuje kontrolerowi Istio Control Plane, a następnie nowa konfiguracja jest stosowana do serwerów proxy Envoy każdego pod’a. A kontroler bramy Ingress jest kolejnym Envoy, skonfigurowanym w Control Plane. Na schemacie wygląda to tak:

Konfiguracja Istio-IngressGateway dla routingu zapytań

Aplikacja Sentiment Analysis jest dostępna pod adresem http://{EXTERNAL-IP}/. Nie martw się, jeśli otrzymujesz status Not Found: czasami wymaga to nieco więcej czasu, aby konfiguracja weszła w życie i pamięci podręczne Envoy zostały zaktualizowane.

Zanim kontynuujesz, spędź trochę czasu z aplikacją, aby wygenerować ruch (jest on konieczny do wizualizacji w kolejnych działaniach — przyp. tłum.).

Kiali: obserwowalność

Aby uzyskać dostęp do interfejsu administracyjnego Kiali, wykonaj następujące polecenie:

… i otwórz http://localhost:20001/, logując się jako admin/admin. Tutaj znajdziesz wiele przydatnych funkcjonalności, np. do sprawdzania konfiguracji komponentów Istio, wizualizacji serwisów na podstawie danych zebranych podczas przechwytywania zapytań sieciowych, uzyskiwania odpowiedzi na pytania "Kto do kogo się odzywa?", "W której wersji serwisu występują błędy?" itp. Ogólnie rzecz biorąc, przeanalizuj możliwości Kiali przed przejściem dalej — do wizualizacji metryk z Grafany.

Grafana: wizualizacja metryk

Metryki zebrane w Istio trafiają do Prometheus i są wizualizowane za pomocą Grafany. Aby uzyskać dostęp do interfejsu administracyjnego Grafany, wykonaj poniższe polecenie, a następnie otwórz http://localhost:3000/:

Kliknij w menu Home w lewym górnym rogu i wybierz Istio Service Dashboard w lewym górnym rogu, zacznij od serwisu sa-web-app, aby zobaczyć zebrane metryki:

Czeka na nas pusty i zupełnie nudny widok — przewodnik nigdy by tego nie zatwierdził. Stwórzmy zatem małe obciążenie za pomocą następującego polecenia:

Teraz mamy znacznie ładniejsze wykresy, a do tego świetne narzędzia Prometheus do monitorowania i Grafana do wizualizacji metryk, które pozwolą nam poznać wydajność, stan zdrowia oraz poprawy/pogorszenia w działaniu serwisów w czasie.

Na koniec przyjrzyjmy się śledzeniu zapytań w serwisach.

Jaeger : śledzenie

Śledzenie jest potrzebne, ponieważ im więcej mamy serwisów, tym trudniej dotrzeć do przyczyny awarii. Przyjrzyjmy się prostemu przypadkowi z poniższego obrazka:

Typowy przykład losowego nieudanego zapytania

Zapytanie przychodzi, zawodzi — jakie mogą być przyczyny? Pierwszy serwis? A może drugi? Wyjątki pojawiają się w obu — przyjrzyjmy się logom każdego z nich. Jak często łapaliście się na tym zajęciu? Nasza praca przypomina bardziej detektywów oprogramowania niż programistów…

To powszechny problem w mikrousługach, który rozwiązuje się za pomocą rozproszonych systemów śledzenia, w których serwisy przekazują sobie unikalny nagłówek, a następnie te informacje są przekazywane do systemu śledzenia, gdzie łączą się z danymi zapytania. Oto ilustracja:

Identyfikator zapytania używa TraceId

W Istio używany jest Jaeger Tracer, który implementuje niezależny od dostawcy framework OpenTracing API. Uzyskać dostęp do interfejsu użytkownika Jaeger można następującą komendą:

Teraz wejdź na http://localhost:16686/ i wybierz serwis sa-web-app. Jeśli serwis nie pojawia się na rozwijanej liście — zrób/swój aktywność na stronie i zaktualizuj interfejs. Następnie kliknij przycisk Find Traces, który pokaże najnowsze ślady — wybierz dowolny — pojawi się szczegółowa informacja o wszystkich śladach:

Ten ślad pokazuje:

Zapytanie przychodzi do istio-ingressgateway (to pierwsza interakcja z jednym z serwisów, a dla zapytania generuje się Trace ID), a następnie brama kieruje zapytanie do serwisu sa-web-app.
W serwisie sa-web-app żądanie jest przechwytywane przez Envoy sidecar, tworzy się "dziecko" w span’ie (dlatego widzimy to w śladach) i jest przekierowywane do kontenera sa-web-app. (Span — logiczna jednostka pracy w Jaeger, mająca nazwę, czas rozpoczęcia operacji i jej czas trwania. Spany mogą być zagnieżdżone i uporządkowane. Ukierunkowany acykliczny graf ze span’ów tworzy ślad. — przyp. tł.
Tutaj zapytanie jest przetwarzane metodą sentimentAnalysis. Te ślady zostały już wygenerowane przez aplikację, to znaczy, że wymagały zmian w kodzie.
Od tego momentu inicjowane jest zapytanie POST do sa-logic. Trace ID musi być przekazywane z sa-web-app.
…

Uwaga: Na 4 kroku aplikacja powinna zobaczyć nagłówki wygenerowane przez Istio i przekazać je w kolejnych zapytaniach, jak pokazano na poniższym obrazku:

(A) Przekazywanie nagłówków obsługuje Istio; (B) Za nagłówki odpowiadają usługi

Istio wykonuje główną pracę, generując nagłówki dla przychodzących żądań, tworzy nowe spany w każdym sidecarze i przekazuje je. Jednak bez pracy z nagłówkami wewnątrz usług, pełna ścieżka śledzenia żądania będzie utracona.

Należy uwzględnić (przekazywać) następujące nagłówki:

To nie jest trudne zadanie, jednak dla uproszczenia jego realizacji istnieje już wiele bibliotek — na przykład w usłudze sa-web-app klient RestTemplate przekazuje te nagłówki, jeśli po prostu doda biblioteki Jaeger i OpenTracing do swoich zależności.

Zauważ, że aplikacja Sentiment Analysis demonstruje implementacje w Flask, Spring oraz ASP.NET Core.

Teraz, kiedy stało się jasne, co otrzymujemy z pudełka (lub prawie „z pudełka”), rozważmy pytania związane z precyzyjnym routingiem, zarządzaniem ruchem sieciowym, bezpieczeństwem itd.!

Przyp. tłum.: o tym przeczytacie w następnej części materiałów o Istio autorstwa Rinora Maloku, których tłumaczenia pojawią się w naszym blogu w najbliższym czasie. UPDATE (14 marca): Druga część już została opublikowana.