Cześć, Habr! Przedstawiam wam tłumaczenie artykułu „Płaszczyzna danych service mesh vs płaszczyzna kontrolna“ autora Matt Klein.

Tym razem „zachciałem i przetłumaczyłem” opis obu komponentów service mesh, płaszczyny danych i płaszczyny kontrolnej. Uważam, że ten opis jest najjaśniejszy i najbardziej interesujący, a przede wszystkim prowadzi do zrozumienia „Czy naprawdę jest to potrzebne?”.

Ponieważ pomysł „Service mesh” staje się coraz bardziej popularny w ciągu ostatnich dwóch lat (oryginalny artykuł z 10 października 2017), a liczba uczestników w tej dziedzinie wzrosła, zauważyłem proporcjonalny wzrost zamieszania w całej społeczności technicznej w odniesieniu do porównywania i przeciwstawiania różnych rozwiązań.

Sytuację najlepiej opisują następujące serie tweetów, które napisałem w lipcu:

Zamieszanie z service mesh nr 1: Linkerd ~ = Nginx ~ = Haproxy ~ = Envoy. Żaden z nich nie jest równy Istio. Istio to coś zupełnie innego. 1 /

Pierwsze to tylko płaszczyzny danych. Same w sobie nic nie robią. Muszą być skonfigurowane z czymś więcej. 2 /

Istio jest przykładem płaszczyzny kontrolnej, która łączy części razem. To inna warstwa. / koniec

W poprzednich tweetach wymieniono kilka różnych projektów (Linkerd, NGINX, HAProxy, Envoy i Istio), ale co ważniejsze, wprowadzono ogólne pojęcia płaszczyzny danych, service mesh i płaszczyzny kontrolnej. W tym poście zamierzam cofnąć się i wyjaśnić, co mam na myśli, mówiąc o terminach „płaszczyzna danych” i „płaszczyzna kontrolna” na bardzo ogólnym poziomie, a następnie wyjaśnię, jak te terminy odnoszą się do projektów wymienionych w tweetach.

Czym jest naprawdę service mesh?

Rysunek 1: Przegląd service mesh

Rysunek 1 ilustruje koncepcję service mesh na najbardziej podstawowym poziomie. Istnieją cztery klastry serwisowe (A-D). Każdy egzemplarz usługi jest połączony z lokalnym serwerem proxy. Cały ruch sieciowy (HTTP, REST, gRPC, Redis itd.) z poszczególnego egzemplarza aplikacji przechodzi przez lokalny serwer proxy do odpowiednich zewnętrznych klastrów serwisowych. W ten sposób egzemplarz aplikacji nie zna całej sieci, a jedynie swój lokalny serwer proxy. Faktycznie, sieć systemu rozproszonego została oddzielona od usługi.

Płaszczyzna danych

W service mesh lokalny serwer proxy dla aplikacji wykonuje następujące zadania:

Odkrywanie usług (Service discovery). Jakie usługi/serwisy/aplikacje są dostępne dla Twojej aplikacji?
Sprawdzanie stanu (Health checking). Czy instancje usług zwrócone przez odkrywanie usług (service discovery) są sprawne i gotowe do przyjmowania ruchu sieciowego? Może to obejmować zarówno aktywne (np. sprawdzanie odpowiedzi/healthcheck), jak i pasywne (np. wykorzystanie 3 kolejnych błędów 5xx jako oznaczenie niezdrowego stanu usługi) sprawdzenie stanu.
Routing (Routing)Po otrzymaniu żądania REST do "\/foo", do którego klastra serwisowego należy wysłać to żądanie?
Rozkład obciążenia (Load balancing). Po wyborze klastra usługi podczas routingu, do której instancji usługi powinno być wysłane zapytanie? Z jakim czasem oczekiwania? Z jakimi ustawieniami przerywania (circuit breaking)? Jeśli zapytanie nie powiedzie się, czy powinno zostać powtórzone?
Uwierzytelnianie i autoryzacja (Authentication and authorization). Czy dla nadchodzących zapytań, wywołująca usługa może być kryptograficznie zidentyfikowana/zaautoryzowana za pomocą mTLS lub innego mechanizmu? Jeśli jest zidentyfikowana/zaautoryzowana, czy ma prawo wywołać żądaną operację (endpoint) w usłudze, czy powinien zostać zwrócony nieautoryzowany odpowiedź?
Obserwowalność (Observability). Dla każdego zapytania powinny być generowane szczegółowe dane statystyczne, logi oraz dane o śledzeniu rozproszonym, aby operatorzy mogli zrozumieć rozproszony przepływ ruchu i problemy z debugowaniem w miarę ich powstawania.

Za wszystkie poprzednie punkty w sieci usług (service mesh) odpowiada płaszczyzna danych (data plane). W istocie lokalny dla usługi (sidecar) proxy jest płaszczyzną danych (data plane). Innymi słowy, płaszczyzna danych (data plane) odpowiada za warunkową translację, przesyłanie i obserwację każdego pakietu sieciowego, który jest przesyłany do usługi lub z niej przesyłany.

Płaszczyzna sterująca (The control plane)

Abstrakcja sieci, którą zapewnia lokalny proxy w płaszczyźnie danych (data plane), jest magiczna (?). Niemniej jednak, jak proxy faktycznie dowiaduje się o trasie "\/foo" do serwisu B? Jak mogą być wykorzystane dane o odkrywaniu serwisów (service discovery), które są wypełniane przez żądania proxy? Jak są skonfigurowane parametry równoważenia obciążenia, limitu czasu (timeout), przerywania obwodu (circuit breaking) itd.? Jak odbywa się wdrożenie aplikacji z wykorzystaniem metody niebieskiej/zielonej (blue/green) lub metody stopniowego przekazywania ruchu? Kto konfiguruje parametry ogólnej systemowej autoryzacji i uwierzytelniania?

Wszystkie powyższe punkty są w gestii płaszczyzny zarządzania (control plane) sieci serwisowej (service mesh). Płaszczyzna zarządzania (control plane) przyjmuje zestaw izolowanych proxy-serwerów bez stanów i przekształca je w rozproszony system.

Myślę, że powód, dla którego wielu technologów uważa podzielone pojęcia płaszczyzny danych (data plane) i płaszczyzny zarządzania (control plane) za mylące, polega na tym, że płaszczyzna danych jest znana większości ludzi, podczas gdy płaszczyzna zarządzania jest obca/niezrozumiała. Od dawna pracujemy z fizycznymi routerami sieciowymi i przełącznikami. Rozumiemy, że pakiety/zapytania muszą podróżować z punktu A do punktu B i że możemy do tego używać sprzętu i oprogramowania. Nowa generacja proxy programowych to po prostu modne wersje narzędzi, które używaliśmy od dłuższego czasu.

Rysunek 2: Ludzka płaszczyzna zarządzania (Human control plane)

Jednak od dawna używamy płaszczyzn zarządzania (control plane), chociaż większość operatorów sieciowych może nie kojarzyć tej części systemu z jakimkolwiek komponentem technologicznym. Powód jest prosty:
Większość dzisiejszych płaszczyzn zarządzania (control plane) to… my.

Na rysunków 2 pokazano to, co nazywam „Ludzką płaszczyzną zarządzania (Human control plane)”. W tym typie wdrożenia, które nadal występuje bardzo często, człowiek-operator, prawdopodobnie zrzędliwy, tworzy statyczne konfiguracje — potencjalnie za pomocą skryptów — i wdraża je przy użyciu jakiegoś specjalnego procesu na wszystkich serwerach proxy. Następnie proxy zaczynają korzystać z tej konfiguracji i rozpoczynają przetwarzanie płaszczyzny danych (data plane) przy użyciu zaktualizowanych ustawień.

Rysunek 3: Rozszerzona płaszczyzna zarządzania siecią usług (Advanced service mesh control plane)

Na rysunku 3 pokazana „rozszerzona” płaszczyzna zarządzania (control plane) sieci usług (service mesh). Składa się ona z następujących części:

Człowiek (The human): Nadal jest człowiek (mam nadzieję, że mniej zły), który podejmuje decyzje na wysokim poziomie dotyczące całego systemu jako całości.
Interfejs użytkownika płaszczyzny zarządzania (Control plane UI): Człowiek wchodzi w interakcję z jakimś typem interfejsu użytkownika w celu zarządzania systemem. Może to być portal internetowy, aplikacja linii komend (CLI) lub inny interfejs. Dzięki interfejsowi użytkownika operator ma dostęp do takich globalnych parametrów konfiguracji systemu jak:
- Zarządzanie wdrożeniem, niebieski/zielony (blue/green) oraz/lub stopniowe przekazywanie ruchu
- Opcje uwierzytelniania i autoryzacji
- Specyfikacje tabeli routingu, na przykład, gdy aplikacja A żąda informacji o "\/foo", co się dzieje?
- Ustawienia balancera obciążenia, takie jak czasy oczekiwania (timeouts), ponowne próby (retries), parametry przerywania połączeń (circuit breaking) itp.
Harmonogram obciążenia (Workload scheduler): Usługi są uruchamiane w infrastrukturze przez system planowania/orkiestracji określonego typu, na przykład Kubernetes lub Nomad. Harmonogram odpowiada za uruchomienie usługi wraz z jej lokalnym serwerem proxy.
Odkrywanie usługi (Service discovery). Gdy harmonogram uruchamia i zatrzymuje instancje usługi, informuje o stanie sprawności w systemie odkrywania usługi.
API konfiguracji lokalnego serwera proxy (Sidecar proxy configuration APIs) : Lokalne serwery proxy dynamicznie pozyskują stan z różnych komponentów systemu według modelu „spójności w końcu” (eventually consistent) bez udziału operatora. Cały system, składający się z wszystkich aktualnie uruchomionych instancji usług i lokalnych serwerów proxy, ostatecznie zbiega się w jeden ekosystem. API uniwersalnej płaszczyzny danych (data plane) w Envoy jest jednym z przykładów, jak to działa w praktyce.

W zasadzie celem płaszczyzny zarządzania (control plane) jest ustalenie polityki, która ostatecznie zostanie przyjęta przez płaszczyznę danych (data plane). Bardziej zaawansowane płaszczyzny zarządzania (control plane) usuną od operatora więcej szczegółów niektórych systemów i będą wymagać mniej ręcznego zarządzania, pod warunkiem, że będą działać poprawnie!..

Płaszczyzna danych i płaszczyzna zarządzania. Podsumowanie (Data plane vs. control plane summary)

Płaszczyzna danych sieci usługowej (Service mesh data plane): dotyczy każdego pakietu / żądania w systemie. Odpowiada za odkrywanie aplikacji / usług, sprawdzanie ich dostępności, trasowanie, równoważenie obciążenia, uwierzytelnianie / autoryzację oraz obserwowalność.
Płaszczyzna zarządzania sieci usługowej (Service mesh control plane): zapewnia politykę i konfigurację dla wszystkich działających płaszczyzn danych w obrębie sieci usługowej. Nie ingeruje w żadne pakiety / żądania w systemie. Płaszczyzna zarządzania przekształca wszystkie płaszczyzny danych w rozproszony system.

Aktualny stan projektu (Current project landscape)

Po zrozumieniu powyższego wyjaśnienia, przyjrzyjmy się aktualnemu stanowi projektu „sieci usługowej (service mesh)”.

Płaszczyzny danych (Data planes): Linkerd, NGINX, HAProxy, Envoy, Traefik
Płaszczyzny zarządzania (Control planes): Istio, Nelson, SmartStack

Zamiast przeprowadzać szczegółową analizę każdego z powyższych rozwiązań, krótko omówię niektóre punkty, które, moim zdaniem, powodują największą część zamieszania w ekosystemie obecnie.

Na początku 2016 roku Linkerd był jednym z pierwszych serwerów proxy w warstwie danych dla sieci usług (service mesh) i wykonał fantastyczną pracę, aby zwiększyć świadomość oraz zwrócić uwagę na model projektowania «sieć usług» (service mesh). Około 6 miesięcy później Envoy dołączył do Linkerd (choć pracował w Lyft od końca 2015 roku). Linkerd i Envoy to dwa projekty, które są najczęściej wspominane w dyskusjach na temat sieci usług (service mesh).

Istio ogłoszono w maju 2017 roku. Cele projektu Istio są bardzo podobne do rozszerzonej warstwy zarządzania (control plane), pokazanej na rysunku 3. Envoy dla Istio jest domyślnym serwerem proxy. W ten sposób Istio stanowi warstwę zarządzania (control plane), a Envoy warstwę danych (data plane). W krótkim czasie Istio wzbudziło wiele emocji, a inne warstwy danych (data plane) zaczęły integrować się jako alternatywa dla Envoy (zarówno Linkerd, jak i NGINX zademonstrowały integrację z Istio). Fakt, że w jednej warstwie zarządzania (control plane) można używać różnych warstw danych (data plane), oznacza, że warstwa zarządzania (control plane) i warstwa danych (data plane) nie muszą być ściśle powiązane. Taki API jak uniwersalny API warstwy danych (data plane) Envoy może tworzyć most między dwiema częściami systemu.

Nelson i SmartStack pomagają dodatkowo zilustrować podział między warstwą zarządzania (control plane) a warstwą danych (data plane). Nelson wykorzystuje Envoy jako swój serwer proxy i buduje niezawodną warstwę zarządzania (control plane) siecią usług (service mesh) na bazie stosu HashiCorp, tj. Nomad itp. SmartStack stał się chyba pierwszym z nowej fali sieci usług (service mesh). SmartStack tworzy warstwę zarządzania (control plane) wokół HAProxy lub NGINX, demonstrując możliwość odłączenia warstwy zarządzania (control plane) od sieci usług (service mesh) i warstwy danych (data plane).

Architektura mikrousługowa z siecią serwisową (service mesh) zyskuje coraz większe zainteresowanie (słusznie!), a coraz więcej projektów i dostawców zaczyna pracować w tym kierunku. W ciągu najbliższych kilku lat zobaczymy wiele innowacji zarówno w płaszczyznach danych (data plane), jak i w płaszczyznach zarządzania (control plane), a także dalsze mieszanie różnych komponentów. Ostatecznie architektura mikrousługowa powinna stać się bardziej przejrzysta i magiczna (?) dla operatora.
Mam nadzieję, że wszystko staje się coraz mniej irytujące.

Kluczowe punkty (Key takeaways)

Sieć serwisowa (service mesh) składa się z dwóch różnych części: płaszczyzny danych (data plane) i płaszczyzny zarządzania (control plane). Oba komponenty są niezbędne, a bez nich system nie będzie działać.
Wszyscy znają płaszczyznę zarządzania (control plane), a obecnie płaszczyzną zarządzania (control plane) możesz być Ty!
Wszystkie płaszczyzny danych (data plane) konkurują ze sobą w zakresie funkcji, wydajności, konfigurowalności i rozbudowy.
Wszystkie płaszczyzny zarządzania (control plane) konkurują ze sobą w zakresie funkcji, konfigurowalności, rozbudowy i łatwości użycia.
Jedna płaszczyzna zarządzania (control plane) może zawierać odpowiednie abstrakcje i interfejsy API, aby można było wykorzystać wiele płaszczyzn danych (data plane).

Źródło: habr.com