Istio i nie tylko: interfejs Service Mesh platformy Azure

Nowoczesne, oparte na chmurze tworzenie aplikacji, przynajmniej na platformie Azure, stało się prawie zależne od Kubernetes. Technologie takie jak Virtual Kubelets, AKS (Azure Kubernetes Service) i Azure Service Fabric Mesh są kluczem do tworzenia skalowalnych aplikacji rozproszonych na platformie Azure przy użyciu kontenerów do wdrażania mikrousług i zarządzania nimi.

Patrząc na narzędzia Kubernetes platformy Azure, widać wyraźnie, że firma Microsoft wykonuje dużo pracy w ramach Cloud Native Computing Foundation i wokół niej, pracując nad wszystkimi aspektami platformy open source. Nie powinniśmy być zaskoczeni; Microsoft zatrudnił jednego z założycieli projektu Kubernetes, a następnie przejął Deis, znaczącego dostawcę. Zespół Deis stoi za jednym z najnowszych wkładów platformy Azure w ekosystem Kubernetes, interfejsem Service Mesh Interface (SMI).

Przedstawiamy siatki usług

Być może najlepiej najpierw wyjaśnić, czym jest siatka usług i dlaczego jest ważna dla każdej aplikacji opartej na Kubernetes.

W nowoczesnych architekturach IT chodzi o abstrakcję. Dzięki usługom w chmurze nie musimy już myśleć o podstawowym sprzęcie. Jeśli używamy IaaS, definiujemy maszyny wirtualne do hostowania naszego kodu. Dzięki PaaS jesteśmy jeszcze dalej od sprzętu, korzystając z usług i interfejsów API, które wybraliśmy, wybierając odpowiedni poziom wydajności dla naszych aplikacji i budżetów. W przypadku architektur opartych na kontenerach, takich jak Kubernetes, jesteśmy w punkcie gdzieś pomiędzy nimi: używając usług takich jak AKS możemy zdefiniować podstawowe maszyny wirtualne, które następnie hostują nasze zasobniki kontenerów i skalują się w poziomie ze zmianami w obliczeniach i pamięci (i teraz z KEDA (oparte na Kubernetes automatyczne skalowanie sterowane zdarzeniami), po otrzymaniu zdarzeń).

To tylko jeden aspekt abstrakcji. Mikrousługi Kubernetes są w istocie bezstanowe; używają zewnętrznej pamięci masowej i siedzą na szczycie sieci fizycznej lub wirtualnej. Jest to aspekt sieciowy związany z uruchomieniem Kubernetes, który jest prawdopodobnie najtrudniejszy: ponieważ usługi skalują się i zmniejszają, musisz zmodyfikować sieć, aby dopasować zmiany do aplikacji. Ale jak zapewnić łączność usług, gdy front-end i zaplecze aplikacji mogą skalować się w różnym tempie?

Tu właśnie wkraczają siatki usług. Stanowią nową warstwę abstrakcji, która przenosi Twój kod z dala od podstawowej sieci, wykorzystując możliwości nowoczesnej sieci definiowanej programowo. Działając jako zestaw sieciowych serwerów proxy, które są wdrażane wraz z kodem, siatka usług zarządza komunikacją między usługami bez konieczności posiadania przez kod wiedzy o sieci bazowej. Możesz myśleć o siatce usług jako zautomatyzowanej płaszczyźnie kontroli dla sieci aplikacji, zarządzającej podstawową płaszczyzną sterowania, gdy Kubernetes skaluje kod w górę iw dół.

Sieć zdefiniowana programowo dla mikrousług

Być może najlepiej pomyśleć o sposobie wdrożenia inteligentnego, uwzględniającego opóźnienia, skalowalnego równoważenia obciążenia wraz z wykrywaniem usług, siatka usług to w zasadzie rozproszony router z dynamicznymi regułami routingu, które są zarządzane w ramach wdrożenia Kubernetes. Możesz zdefiniować dodatkowe reguły; na przykład oddzielenie systemów produkcyjnych i testowych lub obsługa wdrażania nowej wersji i zmiany między wersjami kontenerów. Każdy moduł w aplikacji ma instancję siatki usług działającą jako wózek pomocniczy z wykrywaniem usług i innymi elementami stanowymi działającymi poza usługami.

Dzięki siatce usług przenosisz inteligencję do nowej warstwy sieci, więc nie musisz umieszczać jej w swoich mikrousługach. Chcesz zaszyfrować połączenie? To zadanie dla Twojej siatki usług. Chcesz autoryzować klientów? Kolejne zadanie dla siatki serwisowej.

Za dużo oczek

Połączenie wdrożenia Kubernetes z siatką usług ma wiele sensu. Jest jednak jeszcze jeden duży problem: którego używasz? Wysłannik? Istio? Linkerd? Siatka Aspen? Jeśli wybrałeś jedną, co powstrzymuje zespół programistów w innej części Twojej firmy przed wyborem innej? Co się stanie, jeśli Twoja firma zdecyduje się na standaryzację na określonej platformie?

To jest problem, który firma Microsoft zamierza rozwiązać za pomocą interfejsu Service Mesh. Zamiast każdej siatki usług, która ma własny zestaw interfejsów API, SMI jest sposobem na wdrożenie wspólnych interfejsów API, które działają w różnych sieciach usług, zarządzając tą nową inteligentną siecią. Zamiast blokować kod w określonej siatce usług i jej interfejsach API, możesz napisać kod, który dotyczy większości typowych przypadków użycia, za pośrednictwem wspólnego interfejsu API. Jeśli musisz zamienić siatkę usług - jeśli zmienisz dostawców lub znajdziesz takiego, który działa lepiej - nie ma potrzeby zmiany kodu, o ile siatka usług implementuje SMI. Wszystko, co musisz zrobić, to zmienić wózki boczne usługi mesh i ponownie wdrożyć kod.

SMI: wspólne interfejsy API siatki usług

Współpracując z firmami zajmującymi się ekosystemem Kubernetes, takimi jak Hashicorp i Buoyant, firma Microsoft definiuje kluczowe funkcje SMI, które obsługują typowe żądania klientów. W pierwszej wersji koncentrował się na trzech obszarach: polityce ruchu, telemetrii ruchu i zarządzaniu ruchem. Te trzy obszary są kontrolowane przez większość siatek usług, a celem jest uczynienie z tej specyfikacji łatwej do zaimplementowania bez zmiany podstawowej aplikacji.

Tworząc SMI jako zestaw standardowych interfejsów API, nic nie stoi na przeszkodzie, aby dostawcy siatki usług nadal oferowali własne interfejsy API lub dodatkowe funkcje poza określonymi. Alternatywnie nie muszą dokonywać żadnych zmian; strony trzecie mogą tworzyć warstwy tłumaczeń, które znajdują się pomiędzy interfejsami API SMI i zastrzeżonymi interfejsami API usług. Nie będziesz też potrzebować nowej wersji Kubernetes, ponieważ interfejsy API SMI są zaimplementowane jako serwery API rozszerzeń i niestandardowe definicje zasobów. Możesz śmiało zainstalować je w dowolnym klastrze, korzystając z istniejących narzędzi do zarządzania. Powinno to ułatwić korzystanie z SMI na platformie Azure i innych usługach Kubernetes hostowanych w chmurze w celu wbudowania ich w istniejące zarządzane usługi Kubernetes.

Niezależnie od tego, czy chcesz używać Linkerd, Aspen Mesh, czy NSX Service Mesh firmy VMware, dzięki SMI będziesz mógł wybrać tę, którą wolisz, poprawiając przenośność kodu i unikając uzależnienia od określonych usług w chmurze. Następnie istnieje możliwość przełączania siatek usług bez wpływu na kod. Jeśli nowa siatka usług zapewnia lepszą wydajność, wszystko, co musisz zrobić, to zmienić potok kompilacji, aby używał nowej siatki, a następnie wdrożyć zaktualizowaną aplikację.

Ciekawie jest widzieć, jak Microsoft przejmuje inicjatywę w takim projekcie, pracując z szeroką częścią społeczności Kubernetes. Przyjmując podejście, które wyraźnie nie koncentruje się na tworzeniu siatki usług, platforma Azure może oferować różne siatki usług w ramach konfigurowania AKS, umożliwiając wybór odpowiedniego narzędzia bez konieczności zmiany kodu.