Nowe projekty, które działają pod kontrolą klastrów obliczeniowych, są tworzone na zasadzie mikroserwisów. Architektura ta, jakkolwiek bardzo elastyczna i umożliwiająca wprowadzanie wielu zmian w aplikacji w tym samym czasie, ma też swoje ciemne strony. Monitoring, śledzenie zmian czy odnajdywanie miejsc sprawiających problemy spędzają sen z powiek wielu programistom i administratorom takich systemów.

Wszędzie, gdzie jest problem, znajdzie się też rozwiązanie. Przez lata rozwijania aplikacji rozproszonych, powstało wiele takich, które wspomagają monitoring i śledzenie zmian. Obok nich pojawił się również sposób zarządzania taką aplikacją, a mianowicie service mesh (siatka serwisów). Najpopularniejszym projektem, który wspomaga ten sposób zarządzania aplikacjami rozproszonymi jest Istio (istio.io).

Istio to projekt Open Source, co znaczy że kod źródłowy tego rozwiązania jest publiczny. Powstał on ze współpracy trzech firm: Google, IBM i Lyft. Istio realizuje wszystkie założenia siatki serwisów i jest na tyle elastyczny, że działa na wielu różnych platformach, nie tylko w klastrze Kubernetes. Ponadto mamy możliwość zintegrowania Istio z działającą już rozproszoną aplikacją.

> Elementy składowe Istio

W bardzo ogólnym kontekście Istio składa się z warstwy danych (ang. data plane) i warstwy kontroli (ang. control plane). Warstwa danych odpowiada za komunikację między serwisami – bez używania siatki serwisów sieć nie rozumie kontekstu, w jakim odbywa się komunikacja między serwisami ani nie potrafi podejmować żadnych akcji na podstawie typu komunikacji odbywającego się między nimi. Dopiero uruchomienie Istio sprawia, że przy każdym z serwisów działa proxy (Envoy proxy), który przechwytuje cały ruch do i z serwera, co pozwala na większą kontrolę nad ruchem (również do i z klastra lub między klastrami) oraz daje dodatkowe możliwości monitoringu i podwyższenia poziomu bezpieczeństwa.

Warstwa kontroli natomiast pozwala na dynamiczną zmianę konfiguracji wszystkich proxy w naszej aplikacji, zgodnie z naszymi oczekiwaniami. Warstwa ta dba też o to, aby konfiguracja była aktualizowana od razu po wystąpieniu zmian w infrastrukturze.

> Data plane

Warstwa danych składa się z trzech komponentów podzielonych na kompetencje w zakresie zarządzania: konfiguracja, autoryzacja i bezpieczeństwo. Komponent odpowiedzialny za zarządzanie konfiguracją i monitoringiem – Mixer – zbiera informacje o aktualnej konfiguracji proxy (którym jest Envoy) i udostępnia API pozwalające na dokonywanie zmian we własnym zakresie lub przy użyciu innych aplikacji (do monitorowania, logowania, autoryzacji itp). Mixer zarządza również autoryzacją pomiędzy serwerami proxy za pomocą mTLS (ang. mutual TLS). Jest to protokół, który umożliwia wzajemną autoryzację dwóch serwisów przy użyciu certyfikatów w bardzo podobny sposób, jak nasza przeglądarka weryfikuje, czy certyfikat strony jest prawidłowy.

Komponent, który jest odpowiedzialny za konfigurację proxy nazwano Pilot. Pilnuje on, aby konfiguracja zmieniała się tylko w określonych okolicznościach, na przykład kiedy dopuścimy ruch z innego klastra bądź otworzymy któryś port na ruch sieciowy.

Cytadela zapewnia warstwę bezpieczeństwa do zarządzania uwierzytelnianiem i sekretami dzielonymi przez serwisy Envoy. Komponent ten również zarządza certyfikatami w siatce serwisów.

> Dodatkowe możliwości Istio

Dzięki opisanej wcześniej architekturze i użyciu Envoy proxy, możemy uzyskać dużą elastyczność konfiguracji i kilka dodatkowych możliwości, które wcześniej musielibyśmy implementować w głównej aplikacji:

• zapewnione utrzymywanie sesji HTTPS;
• kontrola nad tym, które serwisy mogą komunikować się z innymi – dzięki politykom bezpieczeństwa;
• automatyczna obsługa problemów po stronie sieci lub komunikacji między serwisami (ang. circuit breaking), w celu ochrony ogólnej stabilności systemu;
• balansowanie ruchem z możliwością kierowania zapytań do serwisów mniej obciążonych w danym momencie;
• balansowanie ruchem z możliwością kierowania zapytań do serwisów z mniejszą liczbą oczekujących klientów;
• kierowanie ruchu do różnych serwisów poprzez inspekcję nagłówków HTTP;
• zbieranie wielu metryk w celu lepszego zrozumienia, jak działa nasza aplikacja.

Dodatkowo mamy możliwość używania Istio w różnych środowiskach – wiele klastrów Kubernetes lub klasyczne serwery. Konfiguracja w wielu klastrach oznacza dla nas również konieczność zadbania o takie komponenty jak łączność sieciowa i DNS między klastrami.

> Instalacja i weryfikacja instalacji

Istio możemy zainstalować, używając klienta konsolowego istioctl lub przy użyciu Helm – narzędzia konsolowego do zarządzania aplikacjami w Kubernetes. Oba sposoby są dość intuicyjne, a wybór zależy od preferencji naszego zespołu czy organizacji.

W tym przypadku użyjemy istioctl, a Istio zainstalujemy, wybierając instancję Kubernetes minikube. Dokumentacja zaleca uruchomienie minikube z większym zasobem pamięci (16 GB) i czterema procesorami. Możemy tego dokonać, wykonując poniższą komendę:

minikube start --memory=16384 --cpus=4

Jeśli mamy już działający klaster minikube, będziemy zmuszeni go usunąć, wykonując komendę minikube delete.

Oprócz minikube i istioctl na pewno przyda nam się w systemie zainstalowana aplikacja do kontroli Kubernetes z linii komend – kubectl:

$ kubectl get pods -A
NAMESPACE     NAME                                                 READY     STATUS      RESTARTS                 AGE
kube-system   coredns-64897985d-nhv94                 1/1       Running               0                         2m16s
kube-system   etcd-minikube                                         1/1       Running               0                         2m28s
kube-system   kube-apiserver-minikube                     1/1       Running               0                         2m28s
kube-system   kube-controller-manager-minikube   1/1       Running               0                         2m31s
kube-system   kube-proxy-b8p8z                                  1/1        Running               0                         2m16s
kube-system   kube-scheduler-minikube                   1/1        Running               0                         2m28s
kube-system   storage-provisioner                              1/1        Running               1 (106s ago)    2m26s

Istio zainstalujmy z domyślnymi ustawieniami:

❯ istioctl install
This will install the Istio 1.13.0 default profile with ["Istio core" "Istiod" "Ingress gateways"] components into the cluster. Proceed? (y/N) y
✔ Istio core installed
✔ Istiod installed
✔ Ingress gateways installed
✔ Installation complete

Making this installation the default for injection and validation.

Thank you for installing Istio 1.13.  Please take a few minutes to tell us about your install/upgrade experience!  https://forms.gle/pzWZpAvMVBecaQ9h9

Aby sprawdzić, co zostało uruchomione na naszym serwerze, należy wpisać:

❯ kubectl -n istio-system get deploy
NAME                               READY     UP-TO-DATE   AVAILABLE       AGE
istio-ingressgateway       1/1                   1                      1               2m12s
istiod                                   1/1                   1                      1               2m22s

Jeśli zdecydujemy się na usunięcie Istio z naszego klastra, wystarczy że wykonamy następujące polecenie:

istioctl x uninstall --purge

[...]

Autor jest doświadczonym inżynierem systemów. Specjalizuje się w automatyzacji procesów i monitoringu aplikacji rozproszonych. Propagator ruchu open source. Organizator wydarzeń związanych z IT. Freelancer w wolnych chwilach tworzący fantastykę i fantastykę naukową.