Rozpoczynamy serię postów, w których zaprezentujemy niektóre z wielu możliwości siatki usług Istio Service Mesh w połączeniu z Red Hat OpenShift i Kubernetes.
Część pierwsza, dzisiejsza:
- Wyjaśnimy koncepcję kontenerów sidecar w Kubernetes i sformułujemy leitmotiv tej serii postów: „nie musisz nic zmieniać w swoim kodzie”.
- Przedstawimy podstawową rzecz Istio – zasady routingu. Na nich opierają się wszystkie inne możliwości Istio, ponieważ to właśnie zasady umożliwiają kierowanie ruchem do mikrousług, wykorzystując do tego pliki YAML, które są zewnętrzne w odniesieniu do kodu usług. Omówimy również schemat wdrożenia Canary Deployment. Noworoczny bonus – 10 interaktywnych zajęć z Istio.
Część druga, która wkrótce się pojawi, opowie o:
- Jak Istio realizuje Pool Ejection w połączeniu z Circuit Breaker i pokaże, jak Istio pozwala usunąć z schematu równoważenia nie działający lub źle działający pod.
- Zajmiemy się również tematem Circuit Breaker z pierwszego posta, aby sprawdzić, jak można tutaj wykorzystać Istio. Pokażemy, jak bez najmniejszych zmian w kodzie usług kierować ruchem i obsługiwać błędy sieciowe za pomocą plików konfiguracyjnych YAML i poleceń terminala.
Część trzecia:
- Opowieść o śledzeniu i monitorowaniu, które są już wbudowane lub łatwo dodawane do Istio. Pokażemy, jak korzystać z takich narzędzi jak Prometheus, Jaeger i Grafana w połączeniu ze skalowaniem OpenShift, aby bez wysiłku zarządzać architekturą mikrousług.
- Przechodzimy od monitorowania i obsługi błędów do wprowadzania ich do systemu celowo. Innymi słowy, uczymy się, jak przeprowadzać fault injection bez zmiany kodu źródłowego, co jest bardzo ważne z perspektywy testowania — ponieważ modyfikacja samego kodu wiąże się z ryzykiem wprowadzenia nowych błędów.
W końcu, w finálnym poście po Istio Service Mesh:
- Przejdziemy na Ciemną Stronę. Dokładniej, nauczymy się korzystać z schematu Dark Launch, kiedy kod jest wdrażany i testowany bezpośrednio na danych produkcyjnych, ale nie wpływa na działanie systemu. Umiejętność Istio w zakresie dzielenia ruchu przydaje się w tym przypadku. Możliwość przeprowadzania testów na żywych danych produkcyjnych, nie wpływając na działanie systemu produkcyjnego, to najskuteczniejszy sposób weryfikacji.
- W oparciu o Dark Launch, pokażemy, jak wykorzystać model wdrożenia Canary, aby zminimalizować ryzyko i uprościć wprowadzenie nowego kodu. Samo wdrożenie Canary to nie nowość, ale Istio umożliwia realizację tego schematu jedynie przy pomocy prostych plików YAML.
- Na koniec pokażemy, jak za pomocą Istio Egress udostępnić usługi tym, którzy znajdują się poza twoimi klastrami, aby wykorzystać możliwości Istio w pracy z internetem.
No to zaczynamy...
Narzędzia do monitorowania i zarządzania Istio – wszystko, co potrzebne do koordynacji mikrousług w sieci usługowej .
Czym jest sieć usługowa Istio
Sieć usługowa realizuje dla grupy usług takie funkcje, jak monitorowanie ruchu, kontrola dostępu, odkrywanie, bezpieczeństwo, odporność na awarie oraz inne przydatne funkcje. Istio pozwala na to wszystko bez jakichkolwiek zmian w kodzie samych usług. Jaki jest sekret tego czarodzieja? Istio do każdego serwisu dołącza swój proxy w postaci kontenera sidecar (sidecar - przyczepka motocyklowa), a następnie cały ruch do tego serwisu przechodzi przez proxy, które, kierując się ustalonymi politykami, decyduje, jak, kiedy i czy w ogóle ten ruch ma dotrzeć do serwisu. Istio umożliwia również wdrażanie zaawansowanych technik DevOps, takich jak wdrożenia canary, obwody przeciążeniowe, wstrzykiwanie błędów i wiele innych.
Jak Istio działa z kontenerami i Kubernetes
Sieć usługowa Istio to realizacja sidecarowa wszystkiego, co konieczne do tworzenia i zarządzania mikrousługami: monitorowanie, śledzenie, obwody przeciążeniowe, routowanie, równoważenie obciążenia, wstrzykiwanie błędów, ponowienia, time-outy, lustrzane odbicie, kontrola dostępu, ograniczenie prędkości i wiele więcej. I chociaż dzisiaj istnieje wiele bibliotek, by realizować te funkcje bezpośrednio w kodzie, dzięki Istio możesz otrzymać to wszystko, nic nie zmieniając w swoim kodzie.
Zgodnie z modelem sidecar, Istio działa w kontenerze Linux, który znajduje się w tym samym -podzie co kontrolowana usługa i wprowadza (inject) oraz wydobywa (extract) funkcjonalność i informacje zgodnie z określoną konfiguracją. Podkreślamy, że to twoja własna konfiguracja i żyje ona poza twoim kodem. Dlatego kod staje się znacznie prostszy i krótszy.
Co jeszcze ważne, operacyjna część mikroserwisów nie jest w żaden sposób związana z samym kodem, co oznacza, że ich eksploatację można spokojnie powierzyć specjalistom IT. W rzeczy samej, dlaczego programista miałby odpowiadać za circuit breaker’y i fault injection? Reagować – tak, ale przetwarzać je i tworzyć? Jeśli usuniemy to wszystko z kodu, programiści będą mogli skoncentrować się na aplikacyjnym funkcjonale. A sam kod stanie się krótszy i prostszy.
Sieć serwisowa
Istio, realizując funkcje zarządzania mikroserwisami poza ich kodem – to właśnie koncepcja sieci serwisowej Service Mesh. Innymi słowy, to skoordynowana grupa jednego lub kilku binarnych plików, które tworzą siatkę funkcji sieciowych.
Jak Istio współpracuje z mikroserwisami
Tak wygląda praca kontenerów sidecar w połączeniu z i z lotu ptaka: uruchamiasz instancję Minishift, tworzysz projekt dla Istio (nazwijmy go „istio-system”), instalujesz i uruchamiasz wszystkie związane z Istio komponenty. Następnie, w miarę tworzenia projektów i pod’ów, dodajesz informacje konfiguracyjne do swoich deployment’ów, a twoje pod’y zaczynają korzystać z Istio. Uproszczony diagram wygląda tak:
Teraz można zmieniać ustawienia Istio, aby na przykład zorganizować fault injection, wsparcie lub inne możliwości Istio – i to wszystko bez potrzeby ruszania samego kodu aplikacji. Powiedzmy, że chcesz przekierować cały ruch internetowy od użytkowników swojego największego klienta (Foo Corporation) na nową wersję strony. Wystarczy stworzyć zasadę routingu Istio, która będzie wyszukiwać @foocorporation.com w identyfikatorze użytkownika i wykonywać odpowiednie przekierowanie. Dla wszystkich innych użytkowników nic się nie zmieni. A ty w tym czasie będziesz spokojnie testować nową wersję strony. I zauważ, że do tego wcale nie trzeba angażować deweloperów.
A to będzie drogie?
Niekoniecznie. Istio działa dość szybko, jest napisane w I tworzy zaledwie niewielkie obciążenie. Co więcej, możliwa utrata wydajności online jest kompensowana wzrostem wydajności pracy programistów. Przynajmniej teoretycznie: nie zapominaj, że czas programistów jest drogi. Jeśli chodzi o koszty oprogramowania, Istio to oprogramowanie o otwartym kodzie źródłowym, dlatego można je bezpłatnie uzyskać i używać.
Opanuj to samodzielnie
Zespół Red Hat Developer Experience opracował głębokie praktyczne na temat Istio (w języku angielskim). Działa na systemach Linux, MacOS i Windows, a kod jest dostępny w wersjach na Java i Node.js.
10 interaktywnych zajęć na temat Istio
Blok 1 — Dla początkujących
Wprowadzenie do Istio
30 minut
Poznajemy Service Mesh, uczymy się instalować Istio w klastrze Kubernetes na OpenShift.
Wdrażanie mikrousług w Istio
30 minut
Używamy Istio, aby wdrożyć trzy mikrousługi z Spring Boot i Vert.x.
Blok 2 – średni poziom
Monitoring i śledzenie w Istio
60 minut
Poznajemy wbudowane narzędzia monitorowania Istio, konfigurowalne metryki oraz OpenTracing przez Prometheus i Grafana.
Prosta routingu w Istio
60 minut
Uczymy się zarządzać routingiem w Istio za pomocą prostych reguł.
Zaawansowane reguły routingu
60 minut
Poznajemy inteligentne routowanie w Istio, zarządzanie dostępem, równoważenie obciążenia i ograniczenie przepustowości.
Blok 3 – zaawansowany użytkownik
Wstrzykiwanie błędów w Istio
60 minut
Poznajemy scenariusze obsługi awarii w rozproszonych aplikacjach, tworząc błędy HTTP i opóźnienia sieciowe, uczymy się stosować inżynierię chaosu do odbudowy środowiska.
Circuit Breaker w Istio
30 minut
Instalujemy Siege do testowania obciążenia stron i uczymy się zapewniać odporność backendu za pomocą powtórzeń, circuit breaker i odrzucania puli.
Egress i Istio
10 minut
Używamy tras Egress, aby tworzyć reguły interakcji wewnętrznych usług z zewnętrznymi API i usługami.
Istio i Kiali
15 minut
Uczymy się korzystać z Kiali, aby uzyskać ogólny obraz siatki usług i zbadać przepływy zapytań i danych.
Mutual TLS w Istio
15 minut
Tworzymy Istio Gateway i VirtualService, a następnie szczegółowo badamy mutual TLS (mTLS) i jego ustawienia.
Blok 3.1 — Głębokie zanurzenie: Istio Service Mesh dla mikrousług
O czym jest ta książka:
- Co to jest siatka usług service mesh.
- System Istio i jego rola w architekturze mikrousług.
- Wykorzystanie Istio w następujących zadaniach:
- Odporność na awarie;
- Routing;
- Testowanie chaosu;
- Bezpieczeństwo;
- Zbieranie telemetrii z wykorzystaniem śledzenia, metryk i Grafany.
Seria artykułów o sieciach serwisowych i Istio
Spróbuj samodzielnie
Celem tej serii wpisów nie jest głębokie zanurzenie się w świat Istio. Chcemy tylko zapoznać Cię z samą koncepcją i może zainspirować do samodzielnego wypróbowania Istio. Można to zrobić całkowicie za darmo, a Red Hat udostępnia wszystkie niezbędne narzędzia, aby zacząć pracować z OpenShift, Kubernetes, kontenerami Linux i Istio, a mianowicie: , i innymi zasobami na naszym . Nie czekaj, zacznij już dziś!
Reguły routingu Istio: kierujemy zapytania serwisowe tam, gdzie należy
i świetnie radzą sobie z kierowaniem do odpowiednich pod’ów. To jeden z celów istnienia Kubernetes – routing i równoważenie obciążenia. A co, jeśli potrzebujesz bardziej subtelnego i wyrafinowanego routingu? Na przykład, aby jednocześnie korzystać z dwóch wersji mikroserwisu. Jak mogą w tym pomóc reguły routingu Istio?
Reguły routingu to zasady, które określają wybór ścieżki. Przy każdym poziomie złożoności systemu ogólna zasada działania tych reguł pozostaje prosta: zapytania są kierowane na podstawie określonych parametrów i wartości nagłówków HTTP.
Zobaczmy na przykładach:
Kubernetes domyślnie: trywialne „50 na 50”
W naszym przykładzie pokażemy, jak jednocześnie używać w OpenShift dwóch wersji mikroserwisu, nazwanych v1 i v2. Każda wersja działa w swoim własnym pod’zie Kubernetes, a domyślnie tutaj działa równoważony cykliczny routing (evenly balanced round robin routing). Każdy pod otrzymuje swoją część zapytań, w zależności od liczby jego instancji mikroserwisu, mówiąc inaczej, replik. Istio pozwala jednak ręcznie zmienić ten balans.
Załóżmy, że wdrożyliśmy w OpenShift dwie wersje naszego serwisu rekomendacji, recommendation-v1 i recommendation-v2.
Na rys. 1 widać, że gdy każdy serwis jest reprezentowany w jednej instancji, zapytania równomiernie przeplatają się między nimi: 1-2-1-2-… Tak właśnie działa routing Kubernetes domyślnie:
Waży dystrybucję między wersjami
Na rys. 2 pokazano, co się stanie, jeśli zwiększymy liczbę replik usługi v2 z jednej do dwóch (to wykonuje się poleceniem oc scale —replicas=2 deployment/recommendation-v2). Jak widać, żądania między v1 a v2 teraz dzielą się w stosunku «jeden do trzech»: 1-2-2-1-2-2-…:
Ignorowanie wersji z pomocą Istio
Istio umożliwia łatwe zmienianie rozkładu żądań w pożądany przez nas sposób. Na przykład, aby wysłać cały ruch tylko do recommendation-v1 przy użyciu poniższego pliku yaml Istio:
Tu należy zwrócić uwagę na to, że pod’y są wybierane według etykiet. W naszym przykładzie używana jest etykieta v1. Parametr «weight: 100» oznacza, że 100% ruchu będzie kierowane do wszystkich pod’ów usługi, które mają etykietę v1.
Zarządzanie rozkładem między wersjami (Canary Deployment)
Następnie, wykorzystując parametr weight, można kierować ruch do obu pod’ów, ignorując liczbę instancji mikrousług uruchomionych w każdej z nich. Na przykład, tutaj kierujemy 90% ruchu na v1 i 10% – na v2:
Osobne kierowanie ruchu dla użytkowników mobilnych
Na zakończenie pokażemy, jak wymuszać kierowanie ruchu użytkowników mobilnych do usługi v2, a wszystkich innych do v1. W tym celu analizujemy wartość user-agent w nagłówku żądania przy pomocy wyrażeń regularnych:
Teraz twoja kolej
Przykład z wyrażeniami regularnymi do analizy nagłówków powinien zmotywować cię do poszukiwania własnych zastosowań reguł kierowania Istio. Tym bardziej, że możliwości są bardzo rozległe, ponieważ wartości nagłówków można formować w kodzie źródłowym aplikacji.
I pamiętaj, że Opr., a nie Dev
Wszystko, co pokazaliśmy w powyższych przykładach, odbywa się bez jakichkolwiek zmian w kodzie źródłowym, poza przypadkami, gdy trzeba formować specjalne nagłówki żądań. Istio przyda się zarówno programistom, którzy mogą go stosować na etapie testowania, jak i specjalistom od eksploatacji systemów IT, którym znacznie pomoże w produkcji.
Tak więc powtórzmy leitmotiv tej serii artykułów: nie musisz nic zmieniać w swoim kodzie. Nie trzeba budować nowych obrazów ani uruchamiać nowych kontenerów. Wszystko to realizowane jest poza kodem.
Użyj wyobraźni
Wyobraź sobie, jakie możliwości otwiera analiza nagłówków za pomocą wyrażeń regularnych. Chcesz skierować swojego największego klienta na specjalną wersję swojego ? Легко! Нужна отдельная версия для браузера Chrome? Не проблема! Вы можете маршрутизировать трафик практически по любой его характеристике.
Spróbuj samodzielnie
Czytanie o Istio, Kubernetes i OpenShift to jedno, ale dlaczego nie spróbować wszystkiego samemu? Zespół przygotował szczegółowy przewodnik (w języku angielskim), który pomoże Ci jak najszybciej opanować te technologie. Przewodnik jest również w 100% open source, więc jest dostępny publicznie. Plik działa na macOS, Linux i Windows, a kod źródłowy jest dostępny w wersjach na Java i node.js (wkrótce będą wersje w innych językach). Po prostu otwórz w swojej przeglądarce odpowiednie repozytorium git .
W następnym poście: rozwiązujemy problemy w sposób atrakcyjny
Dziś zobaczyłeś, co potrafią reguły routingu Istio. A teraz wyobraź to sobie w kontekście obsługi błędów. O tym właśnie opowiemy w następnym poście.
Źródło: habr.com
