Porównanie sieci usług Kubernetes

Omawiając architekturę mikrousług i konteneryzację, w ostatnich latach najwięcej uwagi przykuł jeden zestaw sprawdzonych w środowisku produkcyjnym narzędzi: siatka usług.

Rzeczywiście, architektura mikrousług i Kubernetes (często stylizowane na „K8”) szybko stały się normą dla skalowalnych aplikacji, przez co problem zarządzania komunikacją między usługami stał się gorącym tematem, a siatka usług atrakcyjnym rozwiązaniem. Sam używałem siatek serwisowych w produkcji, a konkretnie Linkerda, Istio i wcześniejszej formy Ambassadora. Ale co dokładnie robią siatki usługowe? Który jest najlepszy w użyciu? Skąd wiesz, czy w ogóle powinieneś go używać?

Aby odpowiedzieć na te pytania, warto zrozumieć, dlaczego opracowano siatki usług. Historycznie, tradycyjna infrastruktura IT miała aplikacje działające jako monolity. Jedna usługa działała na jednym serwerze; jeśli potrzebowała większej wydajności, rozwiązaniem było skalowanie jej w pionie przez zaopatrzenie w większą maszynę.

Osiągając granice tego podejścia, duże firmy technologiczne szybko przyjęły architekturę trójwarstwową, oddzielającą system równoważenia obciążenia od serwerów aplikacji i warstwy bazy danych. Chociaż ta architektura pozostała nieco skalowalna, postanowiono podzielić warstwę aplikacji na mikrousługi. Komunikacja między tymi usługami stała się krytyczna dla monitorowania i zabezpieczania w celu skalowania aplikacji.

Aby umożliwić komunikację między usługami, firmy te opracowały własne biblioteki: Finagle w Twitterze, Hystrix w Netflix i Stubby w Google (która w 2016 r. przekształciła się w gRPC). Biblioteki te miały na celu naprawienie problemów zgłaszanych przez architekturę mikrousług: bezpieczeństwo między usługami, opóźnienia, monitorowanie i równoważenie obciążenia. Jednak zarządzanie dużą biblioteką jako zależnością — w wielu językach — jest złożone i czasochłonne.

W końcu ten typ biblioteki został zastąpiony łatwiejszym w użyciu, lekkim proxy. Takie serwery proxy były zewnętrznie niezależne od warstwy aplikacji — potencjalnie przezroczyste dla aplikacji — i łatwiejsze do aktualizowania, konserwacji i wdrażania. Tak narodziła się siatka serwisowa.

Co to jest siatka usług?

Siatka usług to warstwa infrastruktury oprogramowania do kontrolowania komunikacji między usługami; składa się na ogół z dwóch elementów:

1. Płaszczyzna danych , która obsługuje komunikację w pobliżu aplikacji. Zazwyczaj jest to wdrażane z aplikacją jako zestaw sieciowych serwerów proxy, jak pokazano wcześniej.
2. Płaszczyzna kontroli, która jest „mózgiem” siatki usług. Płaszczyzna sterowania współdziała z serwerami proxy w celu wypychania konfiguracji, zapewniania wykrywania usług i scentralizowania obserwowalności.

Siatki usług mają trzy główne cele związane z komunikacją między usługami:

1. Łączność
2. Bezpieczeństwo
3. Obserwowalność

Łączność

Ten aspekt architektury siatki usług umożliwia odnajdywanie usług i routing dynamiczny. Obejmuje również odporność komunikacji , taką jak ponawianie prób, przekroczenie limitu czasu, przerywanie obwodu i ograniczanie szybkości.

Podstawową cechą siatek usług jest równoważenie obciążenia . Wszystkie usługi powiązane z serwerami proxy umożliwiają implementację zasad równoważenia obciążenia między usługami, takich jak round robin, random i less request. Te zasady są strategią używaną przez siatkę usługi do decydowania, która replika otrzyma oryginalne żądanie, tak jak w przypadku małych systemów równoważenia obciążenia przed każdą usługą.

Wreszcie siatki usług oferują kontrolę routingu w postaci przesuwania ruchu i dublowania.

Bezpieczeństwo

W tradycyjnej architekturze mikroserwisów usługi komunikują się między sobą ruchem nieszyfrowanym. Nieszyfrowany ruch wewnętrzny jest obecnie uważany za złą praktykę pod względem bezpieczeństwa, szczególnie w przypadku infrastruktury chmury publicznej i sieci o zerowym zaufaniu.

Oprócz ochrony prywatności danych klientów, gdy nie ma bezpośredniej kontroli nad sprzętem, szyfrowanie ruchu wewnętrznego dodaje mile widzianą warstwę dodatkowej złożoności w przypadku naruszenia systemu. W związku z tym wszystkie siatki usług używają wzajemnego szyfrowania TLS (mTLS) do komunikacji między usługami, tj. całej komunikacji między serwerami proxy.

Siatki usług mogą nawet wymuszać złożone macierze zasad autoryzacji , dopuszczając lub odrzucając ruch w oparciu o zasady ukierunkowane na określone środowiska i usługi.

Obserwowalność

Celem siatek usług jest zapewnienie widoczności komunikacji między usługami. Kontrolując sieć, siatka usług wymusza obserwowalność, dostarczając metryki warstwy siódmej , co z kolei pozwala na automatyczne alerty , gdy ruch osiągnie określony próg, który można dostosować.

Zwykle obsługiwane przez narzędzia lub wtyczki innych firm, takie jak Jaeger lub Zipkin, takie sterowanie umożliwia również śledzenie przez wstrzykiwanie nagłówków śledzenia HTTP .

Korzyści z siatki usług

Siatka usług została stworzona w celu zrównoważenia niektórych obciążeń operacyjnych tworzonych przez architekturę mikrousług. Osoby z doświadczeniem w architekturze mikroserwisów wiedzą, że ich codzienne działanie wymaga znacznego nakładu pracy. Pełne wykorzystanie potencjału mikrousług zwykle wymaga zewnętrznych narzędzi do obsługi między innymi scentralizowanego rejestrowania, zarządzania konfiguracją i skalowalności. Korzystanie z siatki usług standaryzuje te możliwości oraz ich konfigurację i integrację .

W szczególności obserwowalność siatki usług zapewnia niezwykle wszechstronne metody debugowania i optymalizacji. Dzięki szczegółowemu i pełnemu wglądowi w wymiany między usługami inżynierowie — zwłaszcza SRE — mogą szybciej rozwiązywać ewentualne błędy i błędną konfigurację systemu. Dzięki śledzeniu siatki usług mogą śledzić żądanie od jego wejścia do systemu (w systemie równoważenia obciążenia lub zewnętrznym serwerze proxy) aż do prywatnych usług wewnątrz stosu. Mogą używać rejestrowania do mapowania żądania i rejestrowania opóźnienia, jakie napotyka w każdej usłudze. Efekt końcowy: szczegółowy wgląd w wydajność systemu .

Zarządzanie ruchem zapewnia potężne możliwości przed wprowadzeniem pełnej wersji nowej wersji usługi:

1. Przekieruj niewielki procent żądań.
2. Co więcej, kopiuj żądania produkcyjne do nowej wersji, aby przetestować jej zachowanie z ruchem w czasie rzeczywistym.
3. Test A/B dowolnej usługi lub kombinacji usług.

Siatki usług usprawniają wszystkie powyższe scenariusze, ułatwiając unikanie i/lub łagodzenie wszelkich niespodzianek w środowisku produkcyjnym.

Porównanie sieci usług Kubernetes

Pod wieloma względami siatki usług są najlepszym zestawem narzędzi dla architektury mikrousług; wiele z nich działa na jednym z najlepszych narzędzi do orkiestracji kontenerów, Kubernetes. Wybraliśmy trzy z głównych sieci usług działających dziś na Kubernetes: Linkerd (v2), Istio i Consul Connect. Omówimy również kilka innych siatek usług: Kuma, Traefik Mesh i AWS App Mesh. Chociaż obecnie są mniej widoczne pod względem użytkowania i społeczności, są wystarczająco obiecujące, aby przejrzeć tutaj i ogólnie mieć na oku.

Krótka uwaga na temat serwerów proxy Sidecar

Nie wszystkie siatki usług Kubernetes stosują to samo podejście architektoniczne, ale powszechnym jest wykorzystanie wzorca sidecar. Wiąże się to z dołączeniem proxy (sidecar) do głównej aplikacji w celu przechwytywania i regulowania przychodzącego i wychodzącego ruchu sieciowego aplikacji. W praktyce odbywa się to w Kubernetes za pośrednictwem dodatkowego kontenera w każdym zasobniku aplikacji, który będzie podążał za cyklem życia kontenera aplikacji.

Istnieją dwie główne zalety podejścia z wózkiem bocznym do obsługi siatek:

• Serwery proxy Sidecar są niezależne od środowiska wykonawczego, a nawet języka programowania aplikacji.
  • Oznacza to, że łatwo jest włączyć wszystkie funkcje siatki usług, gdziekolwiek ma być używana, w całym stosie.
• Sidecar ma ten sam poziom uprawnień i dostępu do zasobów, co aplikacja.
  • Sidecar może pomóc w monitorowaniu zasobów używanych przez główną aplikację, bez konieczności integracji monitorowania z główną bazą kodu aplikacji.

Ale wózki boczne są mieszanym błogosławieństwem, ponieważ mają bezpośredni wpływ na aplikację:

• Inicjalizacja sidecar może zablokować mechanizm uruchamiania aplikacji.
• Serwery proxy Sidecar zwiększają potencjalne opóźnienie aplikacji.
• Serwery proxy Sidecar dodają również ślad zasobów, który może kosztować znaczną ilość pieniędzy na dużą skalę.

Biorąc pod uwagę te zalety i wady, podejście z wózkiem bocznym jest często przedmiotem debaty w społeczności serwisowej. To powiedziawszy, cztery z sześciu porównywanych tutaj siatek usług używają proxy sidecar Envoy, a Linkerd używa własnej implementacji sidecar; Traefik Mesh nie wykorzystuje w swojej konstrukcji wózków bocznych.

Recenzja linkera

Linkerd, który zadebiutował w 2017 roku, to najstarsza siatka serwisowa na rynku. Stworzony przez Buoyant (firmę założoną przez dwóch byłych inżynierów Twittera), Linkerd v1 był oparty na Finagle i Netty.

Linkerd v1 został opisany jako wyprzedzający swoje czasy, ponieważ był to kompletna, gotowa do produkcji siatka usług. Jednocześnie był nieco ciężki pod względem wykorzystania zasobów. Ponadto znaczne luki w dokumentacji utrudniały konfigurowanie i uruchamianie w produkcji.

Dzięki temu Buoyant miał szansę pracować z kompletnym modelem produkcyjnym, zdobyć na nim doświadczenie i zastosować tę mądrość. Rezultatem był Conduit, kompletna przeróbka Linkerda, wydana w 2018 roku i przemianowana na Linkerd v2 później w tym samym roku. Linkerd v2 przyniósł ze sobą kilka przekonujących ulepszeń; ponieważ aktywny rozwój Linkerd v1 przez firmę Buoyant ustał dawno temu, nasze wzmianki o „Linkerd” w dalszej części tego artykułu odnoszą się do wersji v2.

W pełni open source, Linkerd opiera się na domowej roboty proxy napisanym w Rust dla płaszczyzny danych i na kodzie źródłowym napisanym w Go dla płaszczyzny kontrolnej.

Łączność

Serwery proxy Linkerd mają funkcje ponawiania prób i limitów czasu, ale w chwili pisania tego tekstu nie mają przerywania obwodu ani wstrzykiwania opóźnień. Obsługa Ingress jest obszerna; Linkerd oferuje integrację z następującymi kontrolerami ruchu przychodzącego:

• Traefik
• Nginx
• GCE
• Ambasador
• Gloo
• Kontur
• Kong

Profile usług w Linkerd oferują rozszerzone możliwości routingu, dając metryki użytkownika, dostrajanie ponawiania i ustawienia limitu czasu, wszystko na podstawie trasy. Jeśli chodzi o równoważenie obciążenia, Linkerd oferuje automatyczne wstrzykiwanie proxy, własny pulpit nawigacyjny i natywne wsparcie dla Grafana.

Bezpieczeństwo

Obsługa mTLS w Linkerd jest wygodna, ponieważ jej początkowa konfiguracja jest automatyczna, podobnie jak automatyczna codzienna rotacja kluczy.

Obserwowalność

Po wyjęciu z pudełka statystyki i trasy Linkerd można obserwować za pomocą interfejsu wiersza polecenia. Po stronie GUI opcje obejmują gotowe pulpity nawigacyjne Grafana i natywny pulpit nawigacyjny Linkerd.

Linkerd może podłączyć się do instancji Prometheusa.

Śledzenie można włączyć za pomocą dodatku z OpenTelemetry (dawniej OpenCensus) jako kolektorem, a Jaeger sam wykonuje śledzenie.

Instalacja

Instalacja Linkerd odbywa się poprzez wstrzyknięcie pomocniczego proxy, co odbywa się poprzez dodanie adnotacji do zasobów w Kubernetes. Można to zrobić na dwa sposoby:

1. Korzystanie z wykresu Helm. (Dla wielu Helm jest głównym menedżerem konfiguracji i szablonów dla zasobów Kubernetes).
2. Instalowanie Linkerd CLI, a następnie użycie go do zainstalowania Linkerd w klastrze.

Druga metoda zaczyna się od pobrania i uruchomienia skryptu instalacyjnego:

 curl -sL https://run.linkerd.io/install | sh

Stamtąd narzędzie Linkerd CLI linkerd udostępnia przydatny zestaw narzędzi, który pomaga zainstalować resztę Linkerd i współdziałać z klastrem aplikacji i płaszczyzną sterowania.

linkerd check --pre uruchomi wszystkie wstępne sprawdzenia niezbędne do instalacji Linkerd, zapewniając jasne i precyzyjne logi wyjaśniające, dlaczego potencjalna instalacja Linkerd może jeszcze nie działać. Bez --pre polecenie to może być użyte do debugowania po instalacji.

Następnym krokiem jest zainstalowanie Linkerd w klastrze poprzez uruchomienie:

 linkerd install | kubectl apply -f -

Linkerd zainstaluje następnie wiele różnych komponentów przy bardzo niewielkim zużyciu zasobów; w związku z tym sami mają podejście mikroserwisowe:

• linkerd-controller , który zapewnia publiczny interfejs API, z którym współdziała CLI i pulpit nawigacyjny
• linkerd-identity , który zapewnia urząd certyfikacji do wdrożenia mTLS
• linkerd-proxy-injector , który obsługuje wstrzykiwanie proxy poprzez mutację konfiguracji pod
• linkerd-web , który obsługuje pulpit nawigacyjny umożliwiający monitorowanie wdrożeń i podów, a także wewnętrznych komponentów Linkerd

Linkerd opiera większość swojej konfiguracji na CustomResourceDefinitions (CRD). Jest to uważane za najlepszą praktykę podczas tworzenia oprogramowania dodatkowego Kubernetes — to tak, jakby trwała instalacja wtyczki w klastrze Kubernetes.

Dodanie rozproszonego śledzenia — które może, ale nie musi być tym, czego faktycznie szukają użytkownicy Linkerd, z powodu niektórych powszechnych mitów — wymaga kolejnego kroku z linkerd-collector i linkerd-jaeger. W tym celu najpierw stworzymy plik konfiguracyjny:

 cat >> config.yaml << EOF tracing: enabled: true EOF

Aby włączyć śledzenie, uruchomilibyśmy:

 linkerd upgrade --config config.yaml | kubectl apply -f -

Podobnie jak w przypadku każdej siatki usług opartej na serwerach proxy sidecar, konieczne będzie zmodyfikowanie kodu aplikacji, aby umożliwić śledzenie. Większość tego polega po prostu na dodaniu biblioteki klienta do propagowania nagłówków śledzenia; następnie należy go uwzględnić w każdej usłudze.

Funkcja podziału ruchu w Linkerd, ujawniona za pośrednictwem interfejsu API zgodnego z interfejsem Service Mesh (SMI), już pozwala na wydania kanaryjskie. Ale aby je zautomatyzować i zarządzać ruchem, będziesz potrzebować także zewnętrznych narzędzi, takich jak Flagger.

Flagger to narzędzie progresywnego dostarczania, które oceni to, co Linkerd nazywa „złotymi” wskaźnikami : „liczba żądań, wskaźnik sukcesu i rozkłady opóźnień”. (Pierwotnie Google SRE używało terminu złote sygnały i zawierało czwarty – nasycenie – ale Linkerd tego nie obejmuje, ponieważ wymagałoby to metryk, które nie są bezpośrednio dostępne, takich jak wykorzystanie procesora i pamięci). Flagger śledzi je podczas dzielenia ruchu za pomocą pętli sprzężenia zwrotnego; w związku z tym możesz wdrażać zautomatyzowane i uwzględniające metryki wydania kanarkowe.

Po zagłębieniu się w proces instalacji staje się jasne, że aby sieć usług Linkerd działała i wykorzystywała powszechnie pożądane możliwości, łatwo jest skończyć z co najmniej tuzinem uruchomionych usług. To powiedziawszy, więcej z nich jest dostarczanych przez Linkerd po instalacji niż w przypadku innych siatek usług.

Podsumowanie siatki usługi Linkerd

Zalety:

Linkerd korzysta z doświadczenia swoich twórców, dwóch byłych inżynierów Twittera, którzy pracowali nad wewnętrznym narzędziem Finagle, a później uczyli się z Linkerd v1. Jako jedna z pierwszych sieci usług, Linkerd ma dobrze prosperującą społeczność (jego Slack ma ponad 5000 użytkowników, a ponadto ma aktywną listę mailingową i serwer Discord) oraz obszerny zestaw dokumentacji i samouczków. Linkerd jest dojrzały dzięki wydaniu wersji 2.9, o czym świadczy jego przyjęcie przez wielkie korporacje, takie jak Nordstrom, eBay, Strava, Expedia i Subspace. Dla Linkerd dostępne jest płatne wsparcie klasy korporacyjnej od Buoyant.

Wady:

Korzystanie z siatek usług Linkerd w pełnym zakresie wymaga dość silnej krzywej uczenia się. Linkerd jest obsługiwany tylko w kontenerach Kubernetes (tj. nie ma trybu „uniwersalnego” opartego na maszynach wirtualnych). Serwer proxy usługi Linkerd nie jest serwerem Envoy. Chociaż pozwala to Buoyant na dostrojenie go według własnego uznania, usuwa nieodłączną rozszerzalność oferowaną przez Envoy. Oznacza to również, że Linkerd nie obsługuje przerywania obwodów, wstrzykiwania opóźnień i ograniczania prędkości. Żaden konkretny interfejs API nie jest narażony na łatwe sterowanie płaszczyzną sterowania Linkerd. (Możesz jednak znaleźć powiązanie interfejsu API gRPC).

Linkerd poczynił ogromne postępy od wersji v1 pod względem użyteczności i łatwości instalacji. Godnym uwagi przeoczeniem jest brak oficjalnie ujawnionego API. Ale dzięki dobrze przemyślanej dokumentacji, niestandardowa funkcjonalność w Linkerd jest łatwa do przetestowania.

Konsul Connect Recenzja

Consul Connect, nasz kolejny rywal usługi sieciowej, to wyjątkowa hybryda. Consul z HashiCorp jest lepiej znany ze swojego magazynu wartości klucza dla architektur rozproszonych, który istnieje od wielu lat. Po przekształceniu Consul w kompletny zestaw narzędzi serwisowych, HashiCorp zdecydował się zbudować na jego bazie sieć usług: Consul Connect.

Konkretnie mówiąc o jego hybrydowej naturze:

Płaszczyzna danych Consul Connect jest oparta na Envoy, napisanym w C++. Płaszczyzna sterowania Consul Connect jest napisana w Go. To jest część, która jest wspierana przez Consul KV, sklep z kluczami wartości.

Podobnie jak większość innych siatek usług, Consul Connect działa poprzez wstrzyknięcie pomocniczego proxy do poda aplikacji. Pod względem architektury Consul Connect opiera się na agentach i serwerach . Po wyjęciu z pudełka, Consul Connect ma mieć wysoką dostępność (HA) przy użyciu trzech lub pięciu serwerów jako StatefulSet określający antypowinowactwo pod. Antypowinowactwo podów polega na upewnianiu się, że pody rozproszonego systemu oprogramowania nie trafią do tego samego węzła (serwera), gwarantując w ten sposób dostępność w przypadku awarii dowolnego pojedynczego węzła.

Łączność

Niewiele wyróżnia Consul Connect w tym obszarze; zapewnia to, co robi każda siatka usług (co jest całkiem sporo), plus funkcje warstwy siódmej do routingu opartego na ścieżce, przesuwania ruchu i równoważenia obciążenia.

Bezpieczeństwo

Podobnie jak w przypadku innych siatek usług, Consul Connect zapewnia podstawowe możliwości mTLS. Posiada również natywną integrację między Consul i Vault (również przez HashiCorp), która może być używana jako dostawca CA do zarządzania i podpisywania certyfikatów w klastrze.

Obserwowalność

Consul Connect przyjmuje najbardziej popularne podejście do obserwacji, włączając Envoy jako pomocniczy serwer proxy, aby zapewnić możliwości warstwy siódmej. Skonfigurowanie interfejsu użytkownika aplikacji Consul Connect do pobierania metryk obejmuje zmianę wbudowanego pliku konfiguracyjnego, a także włączenie dostawcy metryk, takiego jak Prometheus. Możliwe jest również skonfigurowanie niektórych pulpitów nawigacyjnych Grafana, aby wyświetlać odpowiednie metryki specyficzne dla usługi.

Instalacja

Consul Connect jest instalowany w klastrze Kubernetes przy użyciu wykresu Helm:

 helm repo add hashicorp https://helm.releases.hashicorp.com

Będziesz musiał zmodyfikować domyślne values.yaml , jeśli chcesz włączyć interfejs użytkownika lub sprawić, by moduł Consul Connect wstrzyknął swój sidecar proxy:

 helm install -f consul-values.yml hashicorp hashicorp/consul

Aby skonsultować się z członkami i sprawdzić różne węzły, exec zaleca wykonanie w jednym z kontenerów, a następnie użycie narzędzia CLI consul .

Aby obsługiwać gotowy interfejs sieciowy, który zapewnia Consul, uruchom kubectl port-forward service/hashicorp-consul-ui 18500:80 .

Podsumowanie siatki usług Consul Connect

Zalety:

• Konsul jest wspierany przez HashiCorp; jako produkt freemium dostępna jest również wersja korporacyjna z dodatkowymi funkcjami, która oferuje wsparcie na poziomie korporacyjnym. Pod względem doświadczenia zespołu deweloperskiego Consul jest jednym z najstarszych narzędzi na rynku.
• Consul ma solidną społeczność korporacyjną i działa na infrastrukturze z 50 000 węzłów. Ponadto istnieje od 2014 roku, co czyni go dojrzałym produktem w stosunku do rynku.
• Consul Connect działa dobrze w maszynie wirtualnej dzięki natywnemu wsparciu.
• Dzięki Consul Connect można osiągnąć integrację aplikacji tak głęboką, jak implementacje siatki przed usługą w czołowych firmach technologicznych. Dzieje się tak dzięki udostępnieniu w pełni udokumentowanego API na poziomie biblioteki.

Wady:

• Consul Connect ma bardziej stromą krzywą uczenia się niż inne siatki usług i będzie wymagać więcej dostrojenia, aby uruchomić wizualne pulpity nawigacyjne i metryki.
• Dokumentacja HashiCorp nie jest prosta, pozostawiając użytkownikom kopanie i eksperymentowanie w celu poprawnej konfiguracji.
• Dokumentacja zarządzania ruchem jest trudna do znalezienia i składa się głównie z linków do dokumentacji Envoy, która nie zawiera szczegółowych informacji na temat zarządzania ruchem Consul Connect.
• Interfejs SMI Consul Connect jest nadal eksperymentalny.

Consul Connect może być bardzo dobrym wyborem dla tych, którzy poszukują produktu klasy korporacyjnej. HashiCorp jest znany z jakości swoich produktów, a Consul Connect nie jest wyjątkiem. Widzę tutaj dwie mocne zalety w porównaniu z innymi siatkami usług: silne wsparcie firmy w wersji Enterprise oraz narzędzie gotowe na wszystkie rodzaje architektur (nie tylko Kubernetes).

Istio Recenzja

W maju 2017 r. Google, IBM i Lyft ogłosiły Istio. Kiedy Istio wzięło udział w wyścigu narzędzi serwisowych, zyskało bardzo dobrą widoczność w przestrzeni technologicznej. Jego autorzy dodali funkcje oparte na opiniach użytkowników przez całą wersję 1.9.

Istio obiecał ważne nowe funkcje w porównaniu do swoich konkurentów w tym czasie: automatyczne równoważenie obciążenia, wstrzykiwanie błędów i wiele innych. To przysporzyło mu dużej uwagi społeczności, ale jak szczegółowo opiszemy poniżej, używanie Istio nie jest trywialne: Istio zostało uznane za szczególnie skomplikowane do wprowadzenia do produkcji.

Historycznie rzecz biorąc, projekt Istio często odbijał się od zmian w kodzie źródłowym. Po przyjęciu architektury mikrousług dla płaszczyzny sterowania Istio (od wersji 1.5) powrócił do architektury monolitycznej. Uzasadnieniem powrotu do centralizacji przez Istio było to, że operatorom trudno było monitorować mikrousługi, baza kodu była zbyt nadmiarowa, a projekt osiągnął dojrzałość organizacyjną — nie było już potrzeby, aby wiele małych zespołów pracowało w silosach.

Jednak po drodze Istio zyskał rozgłos z powodu posiadania jednego z największych wolumenów otwartych problemów na GitHubie. W chwili pisania tego tekstu liczba wynosi około 800 otwartych numerów i około 12 000 zamkniętych. Chociaż liczba problemów może być myląca, w tym przypadku stanowią one znaczną poprawę pod względem wcześniej uszkodzonych funkcji i niekontrolowanego wykorzystania zasobów.

Łączność

Istio jest dość silny w zarządzaniu ruchem w porównaniu do Consul Connect i Linkerd. Dzieje się tak dzięki szerokiej ofercie funkcji podrzędnych: routing żądań, wstrzykiwanie błędów, przesuwanie ruchu, limity czasu żądań, przerywanie obwodu oraz kontrolowanie ruchu przychodzącego i wychodzącego do siatki usług. Pojęcie usług wirtualnych i reguł miejsc docelowych jest bardzo kompletne pod względem zarządzania ruchem.

Jednak wszystkie te możliwości wiążą się z krzywą uczenia się oraz zarządzaniem nowymi zasobami w klastrze Kubernetes.

Bezpieczeństwo

Istio oferuje kompleksowy zestaw narzędzi związanych z bezpieczeństwem, z dwiema głównymi osiami: uwierzytelnianiem i autoryzacją. Istio może wymusić różne poziomy zasad w różnych zakresach: specyficzne dla obciążenia, w całej przestrzeni nazw lub w całym obszarze siatki. Wszystkimi takimi zasobami bezpieczeństwa zarządza się za pomocą Istio CRD, takich jak AuthorizationPolicy lub PeerAuthentication .

Oprócz standardowej obsługi mTLS, Istio można również skonfigurować do akceptowania lub odrzucania nieszyfrowanego ruchu.

Obserwowalność

Tutaj Istio jest dość zaawansowany po wyjęciu z pudełka, z kilkoma rodzajami telemetrii oferującymi solidny wgląd w siatkę usług. Metryki oparte są na czterech złotych sygnałach (opóźnienie, ruch, błędy i do pewnego stopnia nasycenie).

Warto zauważyć, że Istio zapewnia metryki dla samej płaszczyzny kontrolnej. Obsługuje również rozproszone ślady i logi dostępu, oferując wyraźną kompatybilność z Jaeger, Lightstep i Zipkin, aby umożliwić śledzenie.

Nie ma natywnego pulpitu nawigacyjnego, ale istnieje oficjalne wsparcie dla konsoli zarządzania Kiali.

Instalacja

Instalacja jest tak prosta, jak wykonanie oficjalnych kroków. Istio jest również natywnie zintegrowany z GKE jako funkcja beta, ale GKE używa Istio 1.4.X, starszej wersji mikroserwisów, w przeciwieństwie do najnowszej wersji monolitu.

Instalacja natywna rozpoczyna się od pobrania najnowszej wersji:

 curl -L https://istio.io/downloadIstio | sh -

Po dodaniu do nowo utworzonego folderu cd istio-* , możesz dodać go do swojej ścieżki, aby móc użyć narzędzia istioctl :

 export PATH=$PWD/bin:$PATH

Stamtąd możesz zainstalować Istio w swoim klastrze Kubernetes za pomocą istioctl :

 istioctl install

Spowoduje to zainstalowanie Istio z default profilem. Profile istioctl umożliwiają tworzenie różnych konfiguracji instalacji i przełączanie się między nimi w razie potrzeby. Ale nawet w scenariuszu z jednym profilem można głęboko dostosować instalację Istio, modyfikując niektóre CRD.

Zasoby Istio będą trudniejsze do zarządzania, ponieważ będziesz musiał zarządzać kilkoma rodzajami CRD — co najmniej VirtualService , DestinationRule i Gateway — aby upewnić się, że zarządzanie ruchem jest na miejscu.

• Zasób VirtualService to konfiguracja deklarująca usługę i różne reguły routingu stosowane do żądań.
• Zasób DestinationRule służy do grupowania i egzekwowania zasad ruchu specyficznych dla celu.
• Zasób Gateway jest tworzony w celu zarządzania przychodzącym i wychodzącym ruchem siatki usług (tj. dodatkowymi serwerami proxy Envoy, ale działającymi na krawędzi, a nie jako elementy boczne).

Szczegóły semantyczne wykraczają poza zakres tego przeglądu, ale spójrzmy na krótki przykład pokazujący, jak każda z nich działa razem. Załóżmy, że mamy witrynę e-commerce z usługą o nazwie products . Nasza VirtualService może wyglądać tak:

 apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: products-route namespace: ecommerce spec: hosts: - products # interpreted as products.ecommerce.svc.cluster.local http: - match: - uri: prefix: "/listv1" - uri: prefix: "/catalog" rewrite: uri: "/listproducts" route: - destination: host: products # interpreted as products.ecommerce.svc.cluster.local subset: v2 - route: - destination: host: products # interpreted asproducts.ecommerce.svc.cluster.local subset: v1

Odpowiednia Reguła DestinationRule może wtedy mieć postać:

 apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: products spec: host: products trafficPolicy: loadBalancer: simple: RANDOM # or LEAST_CONN or ROUND_ROBIN subsets: - name: v1 labels: version: v1 - name: v2 labels: version: v2 - name: v3 labels: version: v3

Wreszcie nasza Gateway :

 apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: cert-manager-gateway namespace: istio-system spec: selector: istio: ingressgateway servers: - port: number: 80 name: http protocol: HTTP hosts: - "*"

Mając te trzy pliki, instalacja Istio byłaby gotowa do obsługi podstawowego ruchu.

Podsumowanie siatki usług Istio

Zalety:

• Wśród różnych siatek usług, Istio jest tą, która ma największą społeczność online w chwili pisania tego tekstu. Z ponad 10 razy wyższymi wynikami Stack Overflow niż jeden z jego głównych konkurentów, jest to najczęściej omawiana siatka usług w sieci; jego współtwórcy GitHub są również o rząd wielkości poza tymi z Linkerd.
• Istio obsługuje zarówno tryby Kubernetes, jak i VM; ten ostatni jest w wersji beta od wersji 1.9.

Wady:

• Istio nie jest wolne w dwóch znaczeniach:
  • Jego wymagania są wysokie, jeśli chodzi o czas potrzebny na zapoznanie się z dokumentacją, skonfigurowanie jej, prawidłowe działanie i utrzymanie. W zależności od wielkości infrastruktury i liczby usług, Istio zajmie od kilku tygodni do kilku miesięcy pracy w pełnym wymiarze godzin, aby w pełni funkcjonować i zintegrować z produkcją.
  • Powoduje to również znaczne obciążenie zasobów: kontener Envoy zajmie 350 milikorów (mCPU) na 1000 żądań na sekundę (RPS). Nawet sama płaszczyzna sterowania może być zasobożerna. (Wcześniej trudno było przewidzieć użycie zasobów, ale po pewnym wysiłku istiod ustabilizował się, używając 1 vCPU i 1,5 GB pamięci.)
• Nie ma natywnego pulpitu administracyjnego, w przeciwieństwie do Linkerd.
• Istio wymaga użycia własnej bramy wejściowej.
• Płaszczyzna kontroli Istio jest obsługiwana tylko w kontenerach Kubernetes (tj. nie ma trybu maszyny wirtualnej, w przeciwieństwie do płaszczyzny danych Istio).

Istio jest doskonałym przykładem gigantów technologii, którzy łączą siły, aby stworzyć projekt open-source, aby sprostać wyzwaniu, przed którym wszyscy stoją. Zajęło trochę czasu, zanim projekt Istio jako całość ustrukturyzował się (przywołując zmianę architektury z mikrousług na monolit) i rozwiązał wiele początkowych problemów. Dziś Istio robi absolutnie wszystko, czego można oczekiwać od siatki usług i można ją znacznie rozszerzyć. Ale wszystkie te możliwości wiążą się z wysokimi wymaganiami w zakresie wiedzy, godzin pracy i zasobów obliczeniowych, aby wspierać ich wykorzystanie w środowisku produkcyjnym.

Szybki przegląd Kumy

Stworzona przez Kong, a następnie open-source, Kuma osiągnęła 1.0 pod koniec 2020 roku. Do pewnego stopnia została stworzona w odpowiedzi na pierwsze siatki usług, które były dość ciężkie i trudne w obsłudze.

Jego lista funkcji sugeruje, że jest bardzo modułowy; Ideą Kumy jest ukierunkowanie jej na integrację z aplikacjami już działającymi na Kubernetes lub innej infrastrukturze.

• W obszarze zarządzania ruchem Kuma oferuje typowe funkcje siatki usług, takie jak wstrzykiwanie usterek i przerywanie obwodu.
• Poza szyfrowaniem międzyusługowym mTLS wymiana między płaszczyzną danych a płaszczyzną sterowania jest zabezpieczona w Kuma za pomocą tokena proxy płaszczyzny danych .
• Obserwowalność jest definiowana w Kuma za pomocą różnych zasad ruchu dotyczących metryk, śledzenia i rejestrowania.
• Wykrywanie usług jest dostępne za pośrednictwem firmy Kuma dzięki własnemu programowi rozpoznawania nazw DNS działającemu na porcie 5653 płaszczyzny kontrolnej.
• Kuma kładzie duży nacisk na funkcjonalność multimesh : możesz łatwo połączyć kilka klastrów Kubernetes lub środowisk maszyn wirtualnych we wspólny klaster Kuma z jego typem wdrożenia wielostrefowego.
• Kuma łatwo integruje się z Kong Gateway dla istniejących użytkowników Kong.

Uniwersalna (nie Kubernetes) wersja Kumy wymaga PostgreSQL jako zależności, a CTO Konga był szczególnie przeciwny wspieraniu SMI. Ale Kuma została opracowana z myślą o wdrożeniach multicloud i multicluster od samego początku, a jej pulpit nawigacyjny odzwierciedla to.

Chociaż Kuma jest wciąż młody w przestrzeni serwisowej siatki, z kilkoma jak dotąd przypadkami użycia produkcyjnego, jest interesującym i obiecującym pretendentem.

Szybki przegląd siatki Traefik

Pierwotnie nazwany Maesh, Traefik Mesh (przez Traefik Labs) jest kolejnym nowicjuszem w wyścigu oprzyrządowania siatki usługowej. Misją projektu jest demokratyzacja sieci usług poprzez ułatwienie jej użytkowania i konfiguracji; doświadczenie deweloperów z dobrze przemyślanym programem Traefik Proxy postawiło ich w doskonałej pozycji, aby to osiągnąć.

• Funkcje zarządzania ruchem w Traefik Mesh obejmują przerywanie obwodów i ograniczanie prędkości.
• Jeśli chodzi o obserwowalność , Traefik Mesh oferuje natywną obsługę OpenTracing i gotowe metryki (standardowa instalacja automatycznie obejmuje Prometheus i Grafana), co pozwala zaoszczędzić czas konfiguracji.
• Ze względów bezpieczeństwa — poza mTLS — specyfikacje są zgodne z SMI, a Traefik Mesh umożliwia precyzyjne dostosowanie uprawnień ruchu poprzez kontrolę dostępu.

Traefik Mesh wymaga zainstalowania w klastrze CoreDNS. (Podczas gdy platforma Azure domyślnie korzysta z CoreDNS od wersji 1.12, GKE domyślnie korzysta z kube-dns w momencie pisania tego tekstu, co oznacza, że ​​w tym przypadku występuje znaczący dodatkowy krok). Brakuje również możliwości obsługi wielu klastrów.

To powiedziawszy, Traefik Mesh jest wyjątkowy w naszej usłudze porównywania siatek, ponieważ nie używa wstrzykiwania sidecar. Zamiast tego jest wdrażany jako zestaw DaemonSet na wszystkich węzłach, aby działać jako proxy między usługami, dzięki czemu jest nieinwazyjny. Ogólnie rzecz biorąc, Traefik Mesh jest prosty w instalacji i obsłudze.

Szybki przegląd siatki aplikacji AWS

W świecie dostawców usług w chmurze AWS jest pierwszym, który wdrożył natywną usługę mesh, która jest podłączana do Kubernetes (w szczególności EKS), ale także z innymi swoimi usługami. AWS App Mesh został wydany w listopadzie 2018 roku i od tego czasu AWS go iteruje. Główną zaletą AWS App Mesh jest istniejący wcześniej ekosystem AWS i pozycja rynkowa; duża społeczność stojąca za AWS będzie nadal napędzać jego użycie i użyteczność.

• Zarządzanie ruchem w AWS App Mesh obejmuje przerywanie obwodów oprócz typowych funkcji.
• Since AWS App Mesh is hosted by AWS, it's a fully managed service , which means not having to worry about resource usage or control plane availability.
• Observability in AWS App Mesh can be done through Prometheus or AWS X-Ray.

The project is not open source, doesn't support SMI, and there's not much info online about HA standards for the control plane. AWS App Mesh is more complex to set up than other Kubernetes-native service meshes and has very little community online (24 answers on Stack Overflow, 400 stars on GitHub) but that's because users are meant to benefit from AWS support.

AWS App Mesh has native integration with AWS, starting with EKS and extending to other AWS services like ECS (Fargate) and EC2. Unlike Traefik Mesh, it has multicluster support. Plus, like most service meshes, it's based on injecting Envoy, the battle-tested sidecar proxy.

Kubernetes Service Mesh Comparison Tables

The six Kubernetes service mesh options presented here have a few things in common:

• Protocol support : They all work with HTTP, HTTP/2, gRPC, TCP, and WebSockets.
• They all have basic security in the form of mTLS between proxies by default.
• Service meshes, by design, provide some form of load balancing .
• These six, at least, also include a request retrying option among their traffic management features.
• Lastly, service discovery is a core feature of any service mesh.

But there are certainly differences worth highlighting when it comes to service mesh infrastructure, traffic management, observability, deployment, and other aspects.

Infrastruktura

Traffic Management

Observability

* OpenCensus and OpenTracing merged into OpenTelemetry in 2019, but you might find Linkerd articles referring to OpenCensus, as well as Istio and Traefik Mesh articles referring to OpenTracing.

Zastosowanie

Other Service Mesh Considerations

Should We Use a Kubernetes Service Mesh?

Now that we have seen what service meshes are, how they work, and the multitude of differences between them, we can ask: Do we need a service mesh?

That's the big question for SREs and cloud engineers these past few years. Indeed, microservices bring operational challenges in network communication that a service mesh can solve. But service meshes, for the most part, bring their own challenges when it comes to installation and operation.

One problem we can see emerging in many projects is that with service meshes, there is a gap between the proof-of-concept stage and the production stage. That is, it's unfortunately rare for companies to achieve staging environments that are identical to production in every aspect; with service meshes involving crucial infrastructure, scale- and edge-related effects can bring deployment surprises.

Service meshes are still under heavy development and improvement. This could actually be attractive for teams with high deployment velocities—those who have mastered “the art of staying state-of-the-art” and can closely follow the development cycle of cloud-native tools.

For others, though, the pace of service mesh evolution could be more of a pitfall. It would be easy enough to set up a service mesh but then forget about the need to maintain it. Security patches may go unapplied or, even if remembered, may carry with them unplanned issues in the form of deprecated features or a modified set of dependencies.

There's also a notable cost in terms of manpower to set up a service mesh in production. It would be a sensible goal for any team to evaluate this and understand if the benefits from a service mesh would outweigh the initial setup time. Service meshes are hard, no matter what the “easy” demo installations show.

In short, service meshes can solve some of the problems typical to projects deployed at scale but may introduce others, so be prepared to invest time and energy. In a hypothetical infrastructure involving 25 microservices and load of five queries per second, I would recommend having at least one person (preferably two) dedicated for at least a month to preparing a proof of concept and validating key aspects before thinking about running it in production. Once it's set up, anticipate the need for frequent upgrades—they will impact a core component of your infrastructure, namely network communications.

Kubernetes Service Meshes: A (Complex) Evolution in Scalable App Architecture

We've seen what service meshes are: a suite of tooling to answer new challenges introduced by microservices architecture. Through traffic management, observability, service discovery, and enhanced security, service meshes can reveal deep insights into app infrastructure.

There are multiple actors on the market, sometimes promoted by GAFAM et al., that have in some cases open-sourced or promoted their own internal tooling. Despite two different implementation types, service meshes will always have a control plane—the brain of the system—and a data plane, made of proxies that will intercept the requests of your application.

Reviewing the three biggest service meshes (Linkerd, Consul Connect, and Istio) we have seen the different strategies they've chosen to implement and the advantages they bring. Linkerd, being the oldest service mesh on the market, benefits from its creators' experience at Twitter. HashiCorp, for its part, offers the enterprise-ready Consul Connect, backed by a high level of expertise and support. Istio, which initially garnered ample attention online, has evolved into a mature project, delivering a feature-complete platform in the end.

But these actors are far from being the only ones, and some less-talked-about service meshes have emerged: Kuma, Traefik Mesh, and AWS App Mesh, among others. Kuma, from Kong, was created with the idea of making the service mesh idea “simple” and pluggable into any system, not just Kubernetes. Traefik Mesh benefited from experience with the preexisting Traefik Proxy and made the rare decision to eschew sidecar proxies. Last but not least, AWS decided to develop its own version of the service mesh, but one that relies on the dependable Envoy sidecar proxy.

In practice, service meshes are still hard to implement. Although service mesh benefits are compelling, their impact, critically, cuts both ways: Failure of a service mesh could render your microservices unable to communicate with each other, possibly bringing down your entire stack. A notorious example of this: Incompatibility between a Linkerd version and a Kubernetes version created a complete production outage at Monzo, an online bank.

Nonetheless, the whole industry is structuring itself around Kubernetes and initiatives like the Microsoft-spearheaded SMI, a standard interface for service meshes on Kubernetes. Among numerous other projects, the Cloud Native Computing Foundation (CNCF) has the Envoy-based Open Service Mesh (OSM) initiative, which was also originally introduced by Microsoft. The service mesh ecosystem remains abuzz, and I predict a champion emerging in the coming years, the same way Kubernetes became the de facto container orchestration tool.