Przyp. tłum.: autor tego artykułu (Luc Perkins) — rzecznik deweloperów w organizacji CNCF, która jest domem dla takich projektów Open Source jak Linkerd, SMI (Service Mesh Interface) i Kuma (przy okazji, zastanawiałeś się, dlaczego w tej liście nie ma Istio?..). Po raz kolejny starając się przynieść do społeczności DevOps lepsze zrozumienie modnego szumu zwanego „service mesh”, przedstawia 16 charakterystycznych funkcji, które oferują takie rozwiązania.
Dziś — jeden z najgorętszych tematów w obszarze inżynierii oprogramowania (i słusznie!). Uważam tę technologię za niezwykle obiecującą i marzę o tym, aby być świadkiem jej szerokiego wdrożenia (oczywiście, gdy ma to sens). Niemniej jednak, wciąż otacza ją aura tajemniczości dla większości ludzi. Nawiasem mówiąc, nawet ci, którzy dobrze się z nią zapoznali często mają trudności z sformułowaniem jej zalet i tego, czym ona właściwie jest (wliczając w to również mnie). W artykule postaram się wyjaśnić sytuację, wymieniając różne scenariusze użycia „sieci usługowych”*.
* Przyp. tłum.: w tym artykule stosowane będzie właśnie takie tłumaczenie („sieć usługowa”) dla wciąż nowego terminu service mesh.
Ale najpierw chciałbym poczynić kilka uwag:
- Nigdy nie pracowałem z sieciami usługowymi i nie stosowałem ich poza projektami, które miałem na celu własnej edukacji. Z drugiej strony, to właśnie ja napisałem mnóstwo dokumentacji dla wewnętrznej sieci usługowej firmy Twitter w 2015 roku (wówczas nawet nie nazywała się jeszcze „siecią usługową”) i brałem udział w opracowywaniu strony internetowej i dokumentacji dla , więc coś to znaczy.
- Moja lista jest przybliżona i niepełna. Mogą występować znane mi scenariusze użycia, a z biegiem czasu zapewne pojawią się nowe opcje, w miarę rozwoju technologii i wzrostu jej popularności.
- Jednocześnie nie każda istniejąca implementacja service mesh obsługuje wszystkie wymienione przypadki użycia. Dlatego moje sformułowania typu „service mesh może…” należy rozumieć jako „poszczególne, a być może wszystkie popularne implementacje service mesh mogą…”.
- Kolejność przykładów nie ma żadnego znaczenia.
Krótka lista:
- odkrywanie usług;
- szyfrowanie;
- uwierzytelnianie i autoryzacja;
- równoważenie obciążenia;
- przerwanie obwodu;
- automatyczna skala;
- wdrożenia kanaryjne;
- wdrożenia blue-green;
- sprawdzanie stanu;
- zrzut obciążenia;
- lustrzane odbicie ruchu;
- izolacja;
- ograniczenie częstotliwości zapytań, próby ponowne i timeouty;
- telemetria;
- audyt;
- wizualizacja.
1. Wykrywanie usług
TL;DR: Podłączaj się do innych usług w sieci za pomocą prostych nazw.
Usługi powinny być w stanie automatycznie "znajdować" się nawzajem za pomocą odpowiednich nazw – na przykład, service.api.production, pets/staging lub cassandra. Chmurowe środowiska wyróżniają się swoją elastycznością i za jedną nazwą może się kryć wiele instancji usługi. Oczywiste jest, że w takiej sytuacji fizycznie niemożliwe jest zakodowanie wszystkich adresów IP.
Dodatkowo, gdy jedna usługa znajduje drugą, musi mieć możliwość wysyłania do niej zapytań, nie obawiając się, że trafią do nie działającej instancji. Innymi słowy, service mesh musi monitorować dostępność wszystkich instancji usług i utrzymywać listę hostów w jak najbardziej aktualnym stanie.
Każda service mesh implementuje mechanizm wykrywania usług na swój sposób. Aktualnie najpowszechniejszym sposobem jest delegowanie tego zadania zewnętrznym procesom, takim jak DNS Kubernetes. W przeszłości w Twitterze używaliśmy do tych celów systemu nazw . Ponadto technologia service mesh umożliwia pojawienie się niestandardowych mechanizmów nazewnictwa (choć jeszcze nie spotkałem żadnej implementacji SM z taką funkcjonalnością).
2. Szyfrowanie
TL;DR: Pozbądź się nieszyfrowanego ruchu między usługami i niech ten proces będzie automatyzowany i skalowalny.
Miło wiedzieć, że hakerzy nie mogą przeniknąć do twojej wewnętrznej sieci. Zapory sieciowe doskonale sobie z tym radzą. Ale co się stanie, jeśli haker jednak dostanie się do środka? Czy będzie mógł robić wszystko z wewnętrznym ruchem usług? Miejmy nadzieję, że do tego nie dojdzie. Aby zapobiec takiemu scenariuszowi, należy wdrożyć sieć z zerowym zaufaniem (zero-trust), w której cały ruch między usługami jest szyfrowany. Większość współczesnych sieci usługowych osiąga to za pomocą wzajemnego (mutual TLS, mTLS). W niektórych przypadkach mTLS działa w całych chmurach i klastrach (myślę, że komunikacja międzyplanetarna też kiedyś będzie tak zorganizowana).
Oczywiście, dla mTLS service mesh nie jest obowiązkowaKażda usługa może sama zadbać o swój TLS, ale oznacza to, że trzeba znaleźć sposób na generowanie certyfikatów, dystrybucję ich po hostach usługi oraz dołączenie do aplikacji kodu, który będzie ładował te certyfikaty z plików. Tak, nie zapomnij również o aktualizacji tych certyfikatów w określonych odstępach czasu. Siatki serwisowe automatyzują mTLS za pomocą systemów takich jak , które z kolei automatyzują proces wydawania i rotacji certyfikatów.
3. Uwierzytelnianie i autoryzacja
TL;DR: Ustal, kto jest inicjatorem żądania i określ, co ma prawo robić, zanim żądanie dotrze do usługi.
Usługi często chcą wiedzieć, kto kto wykonuje żądanie (uwierzytelnienie), a następnie wykorzystując te informacje decydują, co co temu podmiotowi jest dozwolone (autoryzacja). W tym przypadku za zaimkiem „kto” mogą kryć się:
- Inne usługi. To nazywa się „uwierzytelnieniem peer’a”. Na przykład, usługa
webchce uzyskać dostęp do usługidb. Siatki serwisowe zwykle rozwiązują podobne problemy za pomocą mTLS: certyfikaty w tym przypadku pełnią rolę niezbędnego identyfikatora. - Niektórzy użytkownicy. To nazywa się „uwierzytelnieniem żądania”. Na przykład, użytkownik
haxor69chce kupić nową lampę. Siatki serwisowe oferują różne mechanizmy, na przykład, .Wielu z nas musiało to robić w kodzie aplikacji. Przybywa żądanie, przeglądamy tabelę
users, znajdujemy użytkownika i porównujemy hasło, a następnie sprawdzamy kolumnępermissionsitd. W przypadku siatki serwisowej dzieje się to jeszcze przed dotarciem żądania do usługi.
Po ustaleniu, od kogo pochodzi żądanie, trzeba określić, co temu podmiotowi wolno robić. Niektóre siatki serwisowe pozwalają na definiowanie podstawowych polityk (dotyczących tego, kto i co może robić) w postaci plików YAML lub w wierszu poleceń, podczas gdy inne oferują integrację z frameworkami takimi jak . Ostatecznym celem jest osiągnięcie tego, aby Twoje usługi przyjmowały wszelkie żądania, zakładając, że pochodzą one z zaufanego źródła i działanie to jest dozwolone.
4. Rozkładanie obciążenia
TL;DR: Rozkładaj obciążenie na instancje usługi według określonego wzoru.
„Serwis” w ramach sektora usługowego często składa się z wielu identycznych egzemplarzy. Na przykład, dzisiaj serwis pamięć podręczna składa się z 5 kopii, a jutro ich liczba może wzrosnąć do 11. Zapytania kierowane do pamięć podręczna, muszą być rozdzielane w zależności od określonego celu. Na przykład, aby zminimalizować opóźnienie lub zmaksymalizować prawdopodobieństwo trafienia na działający egzemplarz. Najczęściej stosowany jest algorytm okrężnego rozdzielania (Round-robin), ale istnieje wiele innych — na przykład metoda ważonych (weighted) zapytania (można wybrać preferowane cele), zapisywanie w (ring) haszowaniu (użycie spójnego haszowania dla upstream-hostów) lub metoda najmniejszej liczby zapytań (preferencja dla egzemplarza z najmniejszą liczbą zapytań).
Klasyczne balancery mają również inne funkcje, takie jak cache'owanie HTTP i ochrona przed DDoS, ale nie są one zbyt istotne dla ruchu typu east-west (tj. dla ruchu wewnątrz centrum danych — przyp. tłum.), co jest typowym obszarem zastosowania service mesh. Oczywiście, nie jest konieczne używanie service mesh do równoważenia obciążenia, jednak umożliwia ona ustalanie i kontrolowanie polityk równoważenia dla każdego serwisu z centralnej warstwy zarządzania, eliminując tym samym potrzebę uruchamiania i konfigurowania osobnych balancerów w stosie sieciowym.
5. Łamanie łańcucha (circuit breaking)
TL;DR: Zatrzymuj ruch do problematycznego serwisu i kontroluj straty w najgorszych scenariuszach.
Jeśli z jakiegoś powodu serwis nie radzi sobie z ruchem, service mesh oferuje kilka opcji rozwiązania tego problemu (o innych będzie mowa w odpowiednich sekcjach). Circuit breaking to najostrzejsza opcja odłączenia serwisu od ruchu. Jednak sama w sobie nie ma sensu — potrzebny jest plan awaryjny. Może być przewidziane przeciwdziałanie () na serwisy, które wykonują zapytania (tylko nie zapomnij skonfigurować swojej service mesh w tym celu!), lub na przykład zabarwienie strony statusowej na czerwono i przekierowanie użytkowników na alternatywną stronę z „spadającym wielorybem” („Twitter jest niedostępny”).
Service mesh pozwala nie tylko określić, kiedy nastąpi odłączenie i co To follow this, 'when' can include any combination of specified parameters: total number of requests over a certain period, number of parallel connections, pending requests, active retries, etc.
You are unlikely to want to abuse circuit breaking, but it's nice to know there is a backup plan just in case.
6. Autoscaling
TL;DR: Increase or decrease the number of service instances based on specified criteria.
Service meshes are not schedulers, so they do not perform scaling on their own. However, they can provide the information upon which schedulers will make decisions. Since service meshes have access to all traffic between services, they have extensive information about what is happening: which services are facing issues, which are underloaded (the allocated resources are wasted), etc.
For instance, Kubernetes scales services based on CPU and memory usage of pods (see our report '” — przyp. tłum.)', but if you decide to scale based on any other metric (in our case, traffic-related), a specific metric will be needed. A guide shows how to do it with , i , but the process itself is quite complex. We would like the service mesh to simplify it by allowing you to simply set conditions like 'increase the number of service instances auth, if the number of pending requests exceeds the threshold for a minute'.
7. Canary deployments
TL;DR: Test new features or versions of a service on a subset of users.
Powiedzmy, że opracowujesz jakiś produkt SaaS i zamierzasz wypuścić jego nową, świetną wersję. Przetestowałeś ją w środowisku stagingowym i działa świetnie. Jednak nadal masz pewne obawy co do jej działania w rzeczywistych warunkach. Innymi słowy, musisz przetestować nową wersję na rzeczywistych zadaniach, nie ryzykując zaufaniem użytkowników. Wdrażania canary doskonale nadają się do tego. Umożliwiają one pokazanie nowej funkcji pewnej grupie użytkowników. Ta grupa może składać się z najlojalniejszych użytkowników lub tych, którzy korzystają z bezpłatnej wersji produktu, albo z użytkowników, którzy wyrazili chęć bycia „królikami doświadczalnymi”.
Service mesh umożliwiają to, pozwalając określić kryteria, które definiują, kto i jaką wersję aplikacji zobaczy, a następnie odpowiednio kierując ruch. Przy tym dla samych usług nic się nie zmienia. Wersja 1.0 usługi zakłada, że wszystkie żądania pochodzą od użytkowników, którzy powinni ją zobaczyć, a wersja 1.1 ma takie samo założenie w odniesieniu do swoich użytkowników. A Ty, tymczasem, możesz zmieniać procent ruchu między starą a nową wersją, przekierowując rosnącą liczbę użytkowników na nową, jeśli działa stabilnie i Twoi „króliki doświadczalne” dają zielone światło.
8. Wdrażania blue-green
TL;DR: Wypuść nową fajną funkcję, ale bądź gotowy do natychmiastowego przywrócenia wszystkiego z powrotem.
Sens polega na wypuszczeniu nowego „niebieskiego” serwisu, uruchamiając go równolegle z byłym, „zielonym”. Jeśli wszystko pójdzie gładko i nowy serwis sprawdzi się dobrze, to stary można będzie stopniowo wyłączyć. (Niestety, kiedyś ten nowy „niebieski” serwis też podzieli los „zielonego” i zniknie…) Wdrażania blue-green różnią się od canary tym, że nowa funkcja obejmuje natychmiast wszystkich użytkowników (a nie część); sens polega na tym, by mieć gotową „zapasową przystań”, jeśli coś pójdzie nie tak.
Service mesh oferują bardzo wygodny sposób testowania „niebieskiej” usługi oraz natychmiastowe przełączanie na działającą „zieloną” w przypadku awarii. Nie wspominając o tym, że równocześnie dostarczają wiele informacji (patrz punkt „Telemetria” poniżej) na temat działania „niebieskiej”, które pomagają zrozumieć, czy jest ona gotowa do pełnego wdrożenia.
Przyp. tłum.: Więcej na temat różnych strategii wdrażania w Kubernetes (w tym wspomnianych canary, blue/green i innych) można przeczytać w .
9. Kontrola stanu
TL;DR: Monitoruj, które instancje usług są sprawne, i reaguj na te, które przestają być sprawne.
Kontrola stanu (health check) pomaga podjąć decyzję, czy instancje usługi są gotowe do przyjmowania i przetwarzania ruchu. Na przykład w przypadku usług HTTP kontrola stanu może wyglądać jak zapytanie GET do endpointu /health. Odpowiedź 200 OK oznacza, że instancja jest zdrowa, a każda inna oznacza, że nie jest gotowa do przyjmowania ruchu. Service mesh pozwala określić, w jaki sposób będzie sprawdzana sprawność, oraz częstotliwość, z jaką ta kontrola będzie przeprowadzana. Informacje te można następnie wykorzystać do innych celów – na przykład do obciążenia rozkładu i circuit breaking.
Zatem kontrola stanu nie jest samodzielnym scenariuszem użycia, ale zazwyczaj jest używana w celu osiągnięcia innych celów. Ponadto, w zależności od wyników health checków, mogą być wymagane działania zewnętrzne (w odniesieniu do innych celów sieci serwisowych): na przykład aktualizacja strony stanu, tworzenie błędu na GitHubie lub wypełnianie zgłoszenia JIRA. A service mesh oferuje wygodny mechanizm do automatyzacji tego wszystkiego.
10. Przełączanie obciążenia (load shedding)
TL;DR: Przekierowuj ruch w odpowiedzi na chwilowy wzrost użycia.
Jeśli jakiś serwis zostaje przeciążony ruchem, możesz tymczasowo przekierować część tego ruchu w inne miejsce (czyli „odrzucić”, „przelać” (shed) go tam). Na przykład do zapasowej usługi lub centrum danych, lub do stałego Temat. W rezultacie usługa będzie kontynuować przetwarzanie części żądań zamiast całkowicie przestać działać. Zmniejszanie obciążenia jest preferowane w porównaniu do przerwania łańcucha, ale nadal nie należy z tym przesadzać. Pomaga to zapobiegać awariom kaskadowym, które powodują, że awarii ulegają usługi downstream.
11. Równoległe przesyłanie/mirrorowanie ruchu
TL;DR: Wysyłaj jedno żądanie jednocześnie do wielu miejsc.
Czasami zachodzi potrzeba wysłania żądania (lub pewnego zestawu żądań) jednocześnie do wielu usług. Typowy przykład to wysłanie części ruchu produkcyjnego do usługi stagingowej. Główny serwer WWW produkcji wysyła żądanie do niżej poziomej usługi produkty.produkcja i tylko do niej. A sieć usług inteligentnie kopiuje to żądanie i wysyła je do produkty.staging, o czym serwer WWW nawet nie ma pojęcia.
Inny powiązany scenariusz użycia sieci usług, który można zaimplementować na podstawie równoległego przesyłania ruchu, to . Zakłada to wysyłanie tych samych żądań do różnych wersji usługi i sprawdzanie, czy wszystkie wersje zachowują się identycznie. Dotychczas nie spotkałem implementacji sieci usług z wbudowanym systemem testowania regresyjnego, takim jak , ale sama idea wydaje się obiecująca.
12. Izolacja
TL;DR: Dziel swoją sieć usług na mini-sieci.
Znana również jako segmentacja, izolacja to sztuka dzielenia sieci usług na logicznie odseparowane segmenty, które nic o sobie nie wiedzą. Izolacja jest trochę podobna do tworzenia wirtualnych sieci prywatnych. Zasadnicza różnica polega na tym, że wciąż możesz korzystać ze wszystkich korzyści płynących z sieci usług (takich jak wykrywanie usług), ale z dodatkowym bezpieczeństwem. Na przykład, jeśli napastnik dostanie się do usługi w jednej z podsieci, nie będzie mógł zobaczyć, jakie usługi są uruchomione w innych podsieciach ani przechwycić ich ruchu.
Ponadto korzyści mogą być także organizacyjne. Może warto byłoby podzielić usługi na podsieci w zależności od struktury firmy i uwolnić programistów od obciążenia poznawczego, które wiąże się z koniecznością trzymania w pamięci całej sieci usług.
13. Ograniczanie częstotliwości żądań, ponowne próby i limitowanie czasowe
TL;DR: Nie ma potrzeby włączania pilnych zadań związanych z zarządzaniem zapytaniami do bazy kodu.
Wszystkie te kwestie można by traktować jako odrębne przypadki użycia, ale zdecydowałem się je połączyć ze względu na jedną wspólną cechę: przejmują one zadania związane z zarządzaniem cyklem życia zapytań, zazwyczaj realizowane przez biblioteki aplikacji. Jeśli rozwijasz serwer webowy w Ruby on Rails (niezintegrowany z service mesh), który wysyła zapytania do usług backendowych przez , aplikacja sama musi podejmować decyzje, co zrobić, jeśli N zapytań zakończy się niepowodzeniem. Trzeba również ustalić, jaką ilość ruchu mogą obsłużyć te usługi i 'hardcodować' te parametry za pomocą specjalnej biblioteki. Dodatkowo, aplikacja musi decydować, kiedy należy się poddać i pozwolić zapytaniu wygasnąć (przez timeout). Aby zmienić dowolny z powyższych parametrów, serwer webowy będzie musiał zostać zatrzymany, skonfigurowany na nowo i uruchomiony.
Przekazanie tych zadań do service mesh oznacza nie tylko to, że deweloperzy usług nie muszą o nich myśleć, ale także że mogą być one postrzegane w bardziej globalny sposób. Jeśli używana jest skomplikowana łańcuch usług, powiedzmy, A -> B -> C -> D -> E, należy uwzględnić cały cykl życia zapytania. Jeśli zachodzi potrzeba wydłużenia timeoutów w usłudze C, logiczne jest, aby zrobić to wszystko jednocześnie, a nie po częściach: aktualizując kod usługi i czekając, aż pull request zostanie zaakceptowany, a system CI wdroży zaktualizowaną usługę.
14. Telemetria
TL;DR: Zbieraj wszystkie potrzebne (i nie do końca) informacje od usług.
Telemetria to ogólny termin, który obejmuje metryki, śledzenie rozproszone i logi. Service meshy oferują mechanizmy do zbierania i przetwarzania wszystkich trzech typów danych. Tu sprawy stają się nieco niejasne, ponieważ liczba możliwych wariantów jest zbyt duża. Do zbierania metryk są i inne narzędzia, do zbierania logów można użyć , , itd. (na przykład, ClickHouse z naszym dla K8s — przyp. tłum.), do śledzenia rozproszonego są itp. Każda service mesh może wspierać niektóre narzędzia, a innych nie. Interesujące będzie zobaczyć, czy projekt zapewni pewną konwergencję.
W tym przypadku zaletą technologii service mesh jest to, że kontenery sidecar mogą zasadniczo zbierać wszystkie wymienione dane ze swoich usług. Innymi słowy, otrzymujesz jednolity system zbierania telemetrii, a service mesh może przetwarzać wszystkie te informacje na różne sposoby. Na przykład:
- obrabiać logi z jakiejś usługi w CLI;
- śledzić ilość zapytań z panelu monitorowania service mesh;
- zbierać rozproszone ślady i przesyłać je do systemu takiego jak Jaeger.
Uwaga, subiektywna opinia: Ogólnie telemetria to obszar, w który silne ingerencje sieci usługowej są niepożądane. Zbieranie podstawowych informacji i na bieżąco śledzenie niektórych 'złotych metryk', takich jak procent udanych zapytań i opóźnienia, jest w porządku, ale miejmy nadzieję, że nie będziemy świadkami pojawienia się takich Frankesteinowych stosów, które próbują zastąpić wyspecjalizowane systemy, z których niektóre już doskonale się sprawdziły i są dobrze zbadane.
15. Audyt
TL;DR: Kto zapomina lekcje historii, jest skazany na ich powtarzanie.
Audyt to sztuka obserwacji ważnych wydarzeń w systemie. W przypadku service mesh może to oznaczać śledzenie, kto wysyłał zapytania do konkretnych końcowych punktów określonych usług lub ile razy w ostatnim miesiącu miało miejsce jakieś zdarzenie związane z bezpieczeństwem.
Oczywiście audyt jest ściśle związany z telemetrią. Różnica polega na tym, że telemetria zazwyczaj kojarzy się z takimi rzeczami jak wydajność i techniczna sprawność, podczas gdy audyt może dotyczyć kwestii prawnych i innych zagadnień wykraczających poza stricte techniczną sferę (np. zgodność z RODO - Ogólnym rozporządzeniem o ochronie danych osobowych UE).
16. Wizualizacja
TL;DR: Niech żyje React.js - niewyczerpane źródło dziwacznych interfejsów.
Może jest bardziej odpowiedni termin, ale go nie znam. Chodzi mi po prostu o graficzne przedstawienie service mesh lub jej niektórych komponentów. Te wizualizacje mogą zawierać wskaźniki, takie jak średnie opóźnienia, informacje o konfiguracji kontenerów sidecar, wyniki kontroli zdrowia i powiadomienia.
Praca w środowisku zorientowanym na usługi jest związana z znacznie większym obciążeniem poznawczym w porównaniu do Jego Królewskiej Mości Monolitu. Dlatego też należy obniżać obciążenie poznawcze za wszelką cenę. Prosty interfejs graficzny dla service mesh, który umożliwia kliknięcie przycisku i uzyskanie oczekiwanego rezultatu, może mieć kluczowe znaczenie dla wzrostu popularności tej technologii.
Nie zostały uwzględnione w liście
Początkowo zamierzałem dodać do listy kilka dodatkowych zastosowań, ale postanowiłem tego nie robić. Oto one wraz z powodami mojej decyzji:
- Multi-datacenter. W moim przekonaniu to nie tyle zastosowanie, co wąski i konkretny obszar zastosowania service mesh lub pewnego zestawu funkcji, takich jak wykrywanie usług.
- Ingress i egress. To powiązana dziedzina, ale ograniczyłem się (może sztucznie) do zastosowania "ruch east-west". Ingress i egress zasługują na osobny artykuł.
Podsumowanie
Na tym na razie wszystko! Jeszcze raz, ta lista jest dość umowna i prawdopodobnie niepełna. Jeśli masz wrażenie, że coś pominąłem lub się pomyliłem, skontaktuj się ze mną na Twitterze (). Proszę, zachowuj zasady kultury.
P.S. od tłumacza
Jako podstawę dla głównej ilustracji do artykułu wykorzystano obrazek z artykułu „” (autor — Gregory MacKinnon). Przedstawia on, jak część funkcjonalności aplikacji (zielony kolor) przeszła do service mesh, która zapewnia połączenia między nimi (niebieski kolor).
Przeczytaj także na naszym blogu:
- «»;
- «»;
- «».
Źródło: habr.com
