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

Notatka. przeł.: Siatki usług zdecydowanie stały się odpowiednim rozwiązaniem w nowoczesnej infrastrukturze dla aplikacji zgodnych z architekturą mikroserwisową. Choć Istio może być na ustach wielu inżynierów DevOps, jest to dość nowy produkt, który choć wszechstronny pod względem zapewnianych przez niego możliwości, może wymagać znacznej ilości czasu na zapoznanie się z nim. Niemiecki inżynier Rinor Maloku, który jest odpowiedzialny za przetwarzanie w chmurze dla dużych klientów w firmie telekomunikacyjnej Orange Networks, napisał wspaniałą serię materiałów, które pozwalają szybko i dogłębnie zanurzyć się w Istio. Swoją historię zaczyna od tego, co w ogóle potrafi Istio i jak szybko można to zobaczyć na własne oczy.

Podobnie — Projekt Open Source opracowany we współpracy z zespołami Google, IBM i Lyft. Rozwiązuje złożoności pojawiające się w aplikacjach opartych na mikrousługach, takie jak:

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

Wszystko to można rozwiązać na poziomie aplikacji, ale wtedy Twoje usługi nie będą już „mikro”. Cały dodatkowy wysiłek mający na celu rozwiązanie tych problemów jest marnowaniem zasobów firmy, które można wykorzystać bezpośrednio w celu uzyskania wartości biznesowej. Spójrzmy na przykład:

Kierownik projektu: Ile czasu zajmuje dodanie funkcji opinii?
Deweloper: Dwa sprinty.

MP: Co?.. To po prostu CRUD!
R: Wykonanie CRUD jest łatwą częścią, ale nadal musimy uwierzytelniać i autoryzować użytkowników i usługi. Ponieważ sieć jest zawodna, będziesz musiał także wdrożyć powtarzające się żądania wzór wyłącznika w klientach. Ponadto, aby mieć pewność, że cały system się nie zawiesi, będziesz potrzebować limitów czasu i grodzie (więcej szczegółów na temat obu wspomnianych wzorców w dalszej części artykułu – ok. tł.)oraz w celu wykrycia problemów, monitorowania, śledzenia, […]
MP: Och, w takim razie wstawmy tę funkcję do usługi Produktu.

Myślę, że pomysł jest jasny: ilość kroków i wysiłku potrzebnego do dodania jednej usługi jest ogromna. W tym artykule przyjrzymy się, jak Istio usuwa całą wspomnianą powyżej złożoność (która nie ma być logiką biznesową) z usług.

Operacja: W tym artykule założono, że masz praktyczną wiedzę na temat Kubernetes. W przeciwnym razie polecam przeczytać moje wprowadzenie do Kubernetesa i dopiero potem kontynuuj czytanie tego materiału.

Pomysł Istio

W świecie bez Istio jedna usługa wysyła bezpośrednie żądania do drugiej, a w przypadku awarii usługa musi sama sobie z tym poradzić: podjąć nową próbę, ustawić limit czasu, otworzyć wyłącznik itp.

Ruch sieciowy w Kubernetesie

Istio oferuje specjalistyczne rozwiązanie, całkowicie oddzielone od usług i funkcjonujące poprzez ingerencję w komunikację sieciową. I w ten sposób realizuje:

tolerancja błędów: Na podstawie kodu stanu w odpowiedzi sprawdza, czy żądanie nie powiodło się, i wykonuje je ponownie.
Wdrożenia Kanaryjskie: przekierowuje tylko określony procent żądań do nowej wersji usługi.
Monitorowanie i metryki: Jak długo trzeba było czekać na odpowiedź serwisu?
Śledzenie i obserwowalność: Dodaje specjalne nagłówki do każdego żądania i śledzi je w klastrze.
bezpieczeństwo: pobiera token JWT, uwierzytelnia i autoryzuje użytkowników.

To tylko kilka z możliwości (naprawdę tylko kilka!), które mogą Cię zaintrygować. Przejdźmy teraz do szczegółów technicznych!

Architektura Istio

Istio przechwytuje cały ruch sieciowy i stosuje do niego zestaw reguł, umieszczając w każdym podzespole inteligentne proxy w formie kontenera bocznego. Serwery proxy, które aktywują wszystkie możliwości, tworzą a Płaszczyzna danychi można je dynamicznie konfigurować za pomocą Sterowanie samolotem.

Płaszczyzna danych

Serwery proxy wstawione do podów pozwalają Istio z łatwością spełnić nasze wymagania. Sprawdźmy na przykład funkcje ponownej próby i wyłącznika automatycznego.

Jak w Envoy realizowane są ponowne próby i przerywanie obwodów

Podsumowując:

Wysłannik (mówimy o proxy znajdującym się w kontenerze bocznym, który jest dystrybuowany jako osobny produkt - około. tłumacz.) wysyła żądanie do pierwszej instancji usługi B i kończy się niepowodzeniem.
Envoy Sidecar próbuje ponownie (spróbować ponownie). (1)
Żądanie kończy się niepowodzeniem i jest zwracane do serwera proxy, który je wywołał.
Spowoduje to otwarcie programu Circuit Breaker i wywołanie następnej usługi w przypadku kolejnych żądań. (2)

Oznacza to, że nie musisz korzystać z innej biblioteki Retry, nie musisz tworzyć własnej implementacji Circuit Breaking i Service Discovery w języku programowania X, Y lub Z. Wszystko to i wiele więcej jest dostępne od razu po wyjęciu z pudełka w Istio i nie wymaga nie zmiany w kodzie.

Świetnie! Być może chcesz teraz wyruszyć w podróż z Istio, ale nadal masz wątpliwości, otwarte pytania. Jeśli jest to rozwiązanie uniwersalne na każdą okazję w życiu, to można mieć naturalne podejrzenia: w końcu wszystkie takie rozwiązania w rzeczywistości okazują się nieodpowiednie w żadnym przypadku.

I na koniec pytasz: „Czy można to dostosować?”

Teraz jesteś gotowy na podróż morską, zapoznajmy się z Samolotem Kontrolnym.

Sterowanie samolotem

Składa się z trzech elementów: Pilot, Mikser и Cytadela, które współpracują w celu skonfigurowania Envoyów do kierowania ruchu, egzekwowania zasad i zbierania danych telemetrycznych. Schematycznie wszystko wygląda tak:

Interakcja płaszczyzny sterowania z płaszczyzną danych

Wysłanników (tj. płaszczyznę danych) konfiguruje się za pomocą CRD Kubernetesa (Niestandardowe definicje zasobów) zdefiniowane przez Istio i specjalnie przeznaczone do tego celu. Oznacza to dla Ciebie to, że wydają się być kolejnym zasobem w Kubernetesie o znanej składni. Po utworzeniu zasób ten zostanie odebrany przez płaszczyznę kontroli i zastosowany wobec wysłanników.

Związek usług z Istio

Opisaliśmy związek Istio z usługami, ale nie odwrotnie: w jaki sposób usługi odnoszą się do Istio?

Szczerze mówiąc, służby są tak samo świadome obecności Istio jak ryby wody, kiedy zadają sobie pytanie: „Co to w ogóle jest woda?”

Ilustracja Wiktoria Dimitrakopoulos: - Jak ci się podoba woda? - Czym w ogóle jest woda?

Można zatem wziąć działający klaster i po wdrożeniu komponentów Istio zlokalizowane w nim usługi będą nadal działać, a po usunięciu tych komponentów wszystko znowu będzie dobrze. Oczywiste jest, że w tym przypadku stracisz możliwości oferowane przez Istio.

Dość teorii – zastosujmy tę wiedzę w praktyce!

Istio w praktyce

Istio wymaga klastra Kubernetes z co najmniej 4 procesorami vCPU i 8 GB pamięci RAM. Aby szybko skonfigurować klaster i postępować zgodnie z instrukcjami z artykułu, polecam skorzystać z Google Cloud Platform, która oferuje nowym użytkownikom darmowe 300 dolarów.

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

Instalacja steru

Zainstaluj klienta Helm na swoim komputerze, jak opisano w oficjalna dokumentacja. Wykorzystamy to do wygenerowania szablonów do instalacji Istio w następnej sekcji.

Instalowanie Istio

Pobierz zasoby Istio z Najnowsze wydanie (oryginalny autorski link do wersji 1.0.5 został zmieniony na aktualny, tj. 1.0.6 - ok. przeł.), wyodrębnij zawartość do jednego katalogu, który odtąd będę nazywał [istio-resources].

Aby łatwo zidentyfikować zasoby Istio, utwórz przestrzeń nazw w klastrze K8s istio-system:

$ kubectl create namespace istio-system

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

$ 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 wyświetli kluczowe komponenty Istio w pliku istio.yaml. Zmodyfikowaliśmy standardowy szablon pod własne potrzeby, określając następujące parametry:

global.mtls.enabled zainstalowany w false (tj. uwierzytelnianie mTLS jest wyłączone – w przybliżeniu)aby uprościć nasz proces randkowy;
tracing.enabled obejmuje śledzenie żądań za pomocą Jaegera;
kiali.enabled instaluje Kiali w klastrze w celu wizualizacji usług i ruchu;
grafana.enabled instaluje Grafanę w celu wizualizacji zebranych wskaźników.

Wykorzystajmy wygenerowane zasoby za pomocą polecenia:

$ kubectl apply -f istio.yaml

Instalacja Istio w klastrze została zakończona! Poczekaj, aż wszystkie zasobniki znajdą się w przestrzeni nazw istio-system będzie zdolny do Running lub Completeduruchamiając poniższe polecenie:

$ kubectl get pods -n istio-system

Teraz możemy przejść do następnej sekcji, w której zajmiemy się uruchomieniem aplikacji.

Architektura aplikacji Analiza Sentymentu

Posłużmy się przykładem aplikacji mikroserwisowej Sentiment Analysis zastosowanej we wspomnianym już Artykuł wprowadzający do Kubernetes. Jest na tyle skomplikowany, że pozwala pokazać możliwości Istio w praktyce.

Aplikacja składa się z czterech mikroserwisów:

Platforma SA-Frontend, który służy jako frontend aplikacji Reactjs;
Platforma Aplikacja internetowa SA, który obsługuje zapytania analizy nastrojów;
Platforma SA-Logika, który wykonuje się sam analiza nastrojów;
Platforma SA-Opinia, który otrzymuje informację zwrotną od użytkowników na temat dokładności analizy.

Na tym diagramie oprócz usług widzimy także Ingress Controller, który w Kubernetesie kieruje przychodzące żądania do odpowiednich usług. Istio wykorzystuje podobną koncepcję w swojej bramce Ingress Gateway, więcej szczegółów wkrótce.

Uruchamianie aplikacji za pomocą proxy z Istio

Aby wykonać dalsze operacje wspomniane w artykule, sklonuj swoje repozytorium istio-mistrzostwo. Zawiera aplikację i manifesty dla Kubernetes i Istio.

Wkładanie wózków bocznych

Można dokonać wstawienia automatycznie lub ręcznie. Aby automatycznie wstawiać kontenery przyczepki bocznej, musisz ustawić etykietę dla przestrzeni nazw istio-injection=enabled, co odbywa się za pomocą następującego polecenia:

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

Teraz każdy pod, który zostanie wdrożony w domyślnej przestrzeni nazw (default) otrzyma kontener z wózkiem bocznym. Aby to zweryfikować, wdróżmy aplikację testową przechodząc do katalogu głównego repozytorium [istio-mastery] i uruchomienie następującego polecenia:

$ 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 pody mają dwa kontenery (z samą usługą i jej przyczepką), uruchamiając polecenie kubectl get pods i upewniając się, że pod kolumną READY określona wartość 2/2, symbolizujący, że oba kontenery są uruchomione:

$ 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 wygląda to tak:

Serwer proxy Envoy w jednym z zasobników

Teraz, gdy aplikacja jest już uruchomiona, musimy zezwolić na ruch przychodzący do aplikacji.

Brama wejściowa

Najlepszą praktyką, aby to osiągnąć (zezwolić na ruch w klastrze), jest przejście Brama wejściowa w Istio, które znajduje się na „krawędzi” klastra i umożliwia włączenie funkcji Istio, takich jak routing, równoważenie obciążenia, bezpieczeństwo i monitorowanie ruchu przychodzącego.

Komponent Ingress Gateway i usługa przekazująca go na zewnątrz zostały zainstalowane w klastrze podczas instalacji Istio. Aby poznać zewnętrzny adres IP usługi, uruchom:

$ 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 nadal uzyskiwać dostęp do aplikacji przy użyciu tego adresu IP (będę go nazywał ZEWNĘTRZNYM-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śli spróbujesz teraz uzyskać dostęp do tego adresu IP za pośrednictwem przeglądarki, pojawi się błąd Usługa niedostępna, ponieważ domyślnie Istio blokuje cały ruch przychodzący, Brama nie została jeszcze zdefiniowana.

Zasób bramy

Gateway to CRD (Custom Resource Definition) w Kubernetesie, definiowany po zainstalowaniu Istio w klastrze i włączeniu możliwości określenia portów, protokołów i hostów, dla których chcemy zezwalać na ruch przychodzący.

W naszym przypadku chcemy zezwolić na ruch HTTP na porcie 80 dla wszystkich hostów. Zadanie jest realizowane według poniższej definicji (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:
- "*"

Konfiguracja ta nie wymaga objaśnień, z wyjątkiem selektora istio: ingressgateway. Za pomocą tego selektora możemy określić, do której bramy wejściowej zastosować konfigurację. W naszym przypadku jest to kontroler Ingress Gateway, który został domyślnie zainstalowany w Istio.

Konfigurację stosuje się wywołując następującą komendę:

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

Brama umożliwia teraz dostęp do portu 80, ale nie ma pojęcia, dokąd kierować żądania. Do tego będziesz potrzebować Usługi wirtualne.

Zasób usługi wirtualnej

Usługa wirtualna informuje bramę przychodzącą, jak kierować żądania dozwolone w klastrze.

Żądania do naszej aplikacji przechodzące przez bramkę http muszą być wysyłane do usług sa-frontend, sa-web-app i sa-feedback:

Trasy, które należy skonfigurować za pomocą usług wirtualnych

Przyjrzyjmy się żądaniom, które należy wysłać do SA-Frontend:

Dokładne dopasowanie po drodze / należy wysłać do SA-Frontend w celu pobrania pliku Index.html;
Wstępnie ustawione ścieżki /static/* należy przesłać do SA-Frontend, aby otrzymać pliki statyczne używane w frontendzie, takie jak CSS i JavaScript;
Ścieżki dopasowane za pomocą wyrażenia regularnego '^.*.(ico|png|jpg)$', należy wysłać do SA-Frontend, ponieważ To są zdjęcia wyświetlane na stronie.

Implementację osiąga się poprzez następującą konfigurację (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
Ważne punkty:

Ta usługa wirtualna odnosi się do przychodzących żądań bramka http;
В destination Określana jest usługa, do której wysyłane są żądania.

Operacja: Powyższa konfiguracja jest zapisana w pliku sa-virtualservice-external.yaml, który zawiera również ustawienia routingu w SA-WebApp i SA-Feedback, ale został w tym artykule skrócony dla zwięzłości.

Zastosujmy VirtualService wywołując:

Operacja: Kiedy zużywamy zasoby Istio, serwer API Kubernetes tworzy zdarzenie odbierane przez płaszczyznę kontroli Istio, a następnie nowa konfiguracja jest stosowana do serwerów proxy Envoy każdego poda. Kontroler bramy wejściowej wydaje się być innym Envoyem skonfigurowanym w płaszczyźnie sterowania. Wszystko wygląda tak jak na schemacie:

Konfiguracja Istio-IngressGateway na potrzeby routingu żądań

Aplikacja Analiza nastrojów jest już dostępna na http://{EXTERNAL-IP}/. Nie martw się, jeśli otrzymasz status Nie znaleziono: Czasami zastosowanie konfiguracji i aktualizacja pamięci podręcznej Envoy zajmuje trochę więcej czasu.

Zanim przejdziesz dalej, pobaw się trochę aplikacją, aby wygenerować ruch. (jego obecność jest konieczna dla przejrzystości w późniejszych działaniach – ok. tłum.).

Kiali: obserwowalność

Aby dostać się do interfejsu administracyjnego Kiali, uruchom następującą komendę:

... i otwarte http://localhost:20001/, logując się jako admin/admin. Znajdziesz tutaj wiele przydatnych funkcji, m.in. do sprawdzenia konfiguracji komponentów Istio, wizualizacji usług przy użyciu informacji zebranych z przechwytywania żądań sieciowych, uzyskania odpowiedzi na pytania „Kto się z kim kontaktuje?”, „Która wersja usługi jest aktualnie testowana? niepowodzenia?” i tak dalej. Ogólnie rzecz biorąc, zapoznaj się z możliwościami Kiali, zanim przejdziesz do wizualizacji metryk za pomocą Grafany.

Grafana: wizualizacja metryk

Metryki zebrane w Istio trafiają do Prometheusa i są wizualizowane za pomocą Grafany. Aby dostać się do interfejsu administracyjnego Grafana, uruchom poniższe polecenie, a następnie otwórz http://localhost:3000/:

Kliknięcie menu Strona główna w lewym górnym rogu i wybierz Panel usług Istio w lewym górnym rogu zacznij od serwisu sa-aplikacja internetowaaby spojrzeć na zebrane dane:

Czeka nas tutaj pusty i zupełnie nudny spektakl, na co kierownictwo nigdy nie zaakceptuje. Utwórzmy mały ładunek za pomocą następującego polecenia:

Teraz mamy znacznie ładniejsze wykresy, a oprócz nich wspaniałe narzędzia Prometheus do monitorowania i Grafana do wizualizacji metryk, które pozwolą nam dowiedzieć się o wydajności, kondycji, ulepszeniach/degradacjach usług w czasie.

Na koniec przyjrzyjmy się śledzeniu żądań w usługach.

Jaeger: śledzenie

Będziemy potrzebować śledzenia, bo im więcej mamy usług, tym trudniej jest dotrzeć do przyczyny awarii. Spójrzmy na prosty przypadek z poniższego obrazka:

Typowy przykład losowego, nieudanego żądania

Prośba przychodzi, spada - jaki jest powód? Pierwszy serwis? Albo drugi? W obu przypadkach są wyjątki - spójrzmy na logi każdego z nich. Jak często przyłapałeś się na tym? Nasza praca przypomina bardziej detektywów oprogramowania niż programistów...

Jest to częsty problem w mikroserwisach i rozwiązywany jest przez rozproszone systemy śledzenia, w których usługi przekazują sobie nawzajem unikalny nagłówek, po czym informacja ta przekazywana jest do systemu śledzącego, gdzie jest porównywana z danymi żądania. Oto ilustracja:

TraceId służy do identyfikacji żądania

Istio korzysta z Jaeger Tracer, który implementuje niezależną od dostawcy platformę OpenTracing API. Dostęp do interfejsu użytkownika Jaeger można uzyskać za pomocą następującego polecenia:

Teraz przejdź do http://localhost:16686/ i wybierz usługę sa-aplikacja internetowa. Jeśli usługa nie jest widoczna w rozwijanym menu, pokaż/wygeneruj aktywność na stronie i zaktualizuj interfejs. Następnie kliknij przycisk Znajdź ślady, który pokaże najnowsze ślady - wybierz dowolny - pojawią się szczegółowe informacje o wszystkich śladach:

Ten ślad pokazuje:

Przychodzi prośba istio-ingressgateway (jest to pierwsza interakcja z jedną z usług, dla żądania generowany jest Trace ID), po czym brama wysyła żądanie do usługi sa-aplikacja internetowa.
Czynny sa-aplikacja internetowa żądanie jest odbierane przez sidecar Envoy, w spanie tworzony jest „dziecko” (dlatego widzimy to w śladach) i kierowane do kontenera sa-aplikacja internetowa. (Przęsło - logiczna jednostka pracy w Jaeger, która ma nazwę, czas rozpoczęcia operacji i czas jej trwania. Przęsła można zagnieżdżać i porządkować. Ukierunkowany acykliczny wykres rozpiętości tworzy ślad. - około. tłumacz.)
Tutaj żądanie jest przetwarzane przez metodę Analiza sentymentów. Te ślady są już generowane przez aplikację, tj. wymagali zmian w kodzie.
Od tego momentu inicjowane jest żądanie POST sa-logika. Identyfikator śledzenia musi zostać przesłany z sa-aplikacja internetowa.
...

Operacja: W kroku 4 aplikacja powinna zobaczyć nagłówki wygenerowane przez Istio i przekazać je kolejnym żądaniom, jak pokazano na obrazku poniżej:

(A) Istio jest odpowiedzialny za przekazywanie nagłówków; (B) Usługi są odpowiedzialne za nagłówki

Istio wykonuje większość pracy, ponieważ... generuje nagłówki dla przychodzących żądań, tworzy nowe zakresy w każdym sidecare i przekazuje je dalej. Jednak bez pracy z nagłówkami wewnątrz usług pełna ścieżka śledzenia żądania zostanie utracona.

Należy wziąć pod uwagę następujące nagłówki:

Nie jest to trudne zadanie, ale uproszczenie jego realizacji już istnieje wiele bibliotek - na przykład w usłudze sa-web-app klient RestTemplate przekazuje te nagłówki, jeśli po prostu dodasz biblioteki Jaeger i OpenTracing do jego uzależnienia.

Należy pamiętać, że aplikacja Analiza nastrojów demonstruje implementacje w Flask, Spring i ASP.NET Core.

Teraz, gdy jest już jasne, co otrzymujemy od razu po wyjęciu z pudełka (lub prawie po wyjęciu z pudełka), przyjrzyjmy się dopracowanemu routingowi, zarządzaniu ruchem sieciowym, bezpieczeństwu itp.!

Notatka. przeł.: O tym przeczytacie w dalszej części materiałów o Istio od Rinora Maloku, których tłumaczenia ukażą się w najbliższym czasie na naszym blogu. Aktualizacja (14 marca): Część druga został już opublikowany.

PS od tłumacza

Przeczytaj także na naszym blogu:

„Powrót do mikroserwisów z Istio”: część 2 (trasowanie, sterowanie ruchem), część 3 (uwierzytelnianie i autoryzacja);
«Conduit - lekka siatka serwisowa dla Kubernetes";
«Co to jest siatka usług i dlaczego jej potrzebuję [do aplikacji w chmurze z mikroserwisami]?";
«Ilustrowany przewodnik po sieci w Kubernetesie. Części 1 i 2";
«Jak ten kontener z wózkiem bocznym znalazł się tutaj [w Kubernetesie]?".

Źródło: www.habr.com