🥇Istio i Kubernetes w środowisku produkcyjnym. Część 2. Śledzenie

W przeszłości Artykuł Przyjrzeliśmy się podstawowym komponentom Service Mesh Istio, zapoznaliśmy się z systemem i odpowiedzieliśmy na główne pytania, które zwykle pojawiają się rozpoczynając pracę z Istio. W tej części przyjrzymy się, jak zorganizować gromadzenie informacji o śledzeniu w sieci.

Pierwszą rzeczą, która przychodzi na myśl wielu programistom i administratorom systemów, gdy słyszą słowa Service Mesh, jest śledzenie. Rzeczywiście, do każdego węzła sieci, przez który przechodzi cały ruch TCP, dodajemy specjalny serwer proxy. Wydaje się, że możliwe jest teraz łatwe przesyłanie informacji o wszystkich interakcjach sieciowych w sieci. Niestety w rzeczywistości istnieje wiele niuansów, które należy wziąć pod uwagę. Przyjrzyjmy się im.

Błędne przekonanie numer jeden: możemy uzyskać dane dotyczące pieszych wędrówek online za darmo.

Tak naprawdę za stosunkowo darmo możemy jedynie połączyć węzły naszego systemu za pomocą strzałek i przepływność danych pomiędzy usługami (właściwie tylko liczbę bajtów na jednostkę czasu). Jednak w większości przypadków nasze usługi komunikują się za pośrednictwem pewnego rodzaju protokołu warstwy aplikacji, takiego jak HTTP, gRPC, Redis i tak dalej. I oczywiście chcemy zobaczyć informacje o śledzeniu specjalnie dla tych protokołów; chcemy zobaczyć częstotliwość żądań, a nie szybkość transmisji danych. Chcemy zrozumieć opóźnienie żądań korzystających z naszego protokołu. Na koniec chcemy zobaczyć pełną ścieżkę, jaką przebywa żądanie od zalogowania się do naszego systemu do otrzymania odpowiedzi od użytkownika. Ten problem nie jest już tak łatwy do rozwiązania.

Najpierw przyjrzyjmy się, jak wygląda wysyłanie zakresów śledzenia z architektonicznego punktu widzenia w Istio. Jak pamiętamy z pierwszej części, Istio posiada osobny komponent o nazwie Mixer służący do zbierania danych telemetrycznych. Jednakże w aktualnej wersji 1.0.* wysyłanie odbywa się bezpośrednio z serwerów proxy, czyli z serwera proxy typu envoy. Serwer proxy Envoy obsługuje wysyłanie zakresów śledzenia przy użyciu standardowego protokołu zipkin. Możliwe jest podłączenie innych protokołów, ale tylko poprzez wtyczkę. Dzięki Istio od razu otrzymujemy zmontowany i skonfigurowany proxy proxy, który obsługuje tylko protokół zipkin. Jeżeli będziemy chcieli wykorzystać np. protokół Jaeger i wysyłać zakresy śledzenia poprzez UDP, wówczas będziemy musieli zbudować własny obraz istio-proxy. Istnieje obsługa niestandardowych wtyczek dla istio-proxy, ale nadal jest ona w wersji alfa. Dlatego jeśli chcemy obejść się bez dużej liczby ustawień niestandardowych, zakres technologii stosowanych do przechowywania i odbierania rozpiętości śledzenia jest ograniczony. Właściwie z głównych systemów możesz teraz używać samego Zipkina lub Jaegera, ale wysyłaj tam wszystko za pomocą protokołu kompatybilnego z zipkinem (który jest znacznie mniej wydajny). Sam protokół zipkin polega na wysyłaniu wszystkich informacji o śledzeniu do kolektorów za pośrednictwem protokołu HTTP, który jest dość drogi.

Jak już powiedziałem, chcemy śledzić protokoły na poziomie aplikacji. Oznacza to, że serwery proxy stojące obok każdej usługi muszą rozumieć, jaki rodzaj interakcji ma teraz miejsce. Domyślnie Istio konfiguruje wszystkie porty jako zwykły protokół TCP, co oznacza, że nie będą wysyłane żadne ślady. Aby ślady mogły być wysyłane należy najpierw włączyć tę opcję w głównej konfiguracji mesh i co bardzo ważne nadać wszystkim portom podmiotów usługi kubernetes nazwy zgodne z protokołem używanym w usłudze. Czyli na przykład tak:

apiVersion: v1
kind: Service
metadata:
  name: nginx
spec:
  ports:
  - port: 80
    targetPort: 80
    name: http
  selector:
    app: nginx

Możesz także użyć nazw złożonych, takich jak http-magic (Istio zobaczy http i rozpozna ten port jako punkt końcowy http). Format to: proto-extra.

Aby nie łatać ogromnej liczby konfiguracji w celu ustalenia protokołu, możesz zastosować brudne obejście: łatać komponent Pilot w momencie, gdy jest on po prostu realizuje logikę definicji protokołu. Na koniec oczywiście trzeba będzie zmienić tę logikę na standardową i przejść na konwencję nazewnictwa dla wszystkich portów.

Aby zrozumieć, czy protokół jest naprawdę poprawnie zdefiniowany, musisz wejść do dowolnego kontenera bocznego za pomocą envoy proxy i wysłać żądanie do portu administratora interfejsu envoy z lokalizacją /config_dump. W powstałej konfiguracji należy przyjrzeć się polu działania żądanej usługi. Jest używany w Istio jako identyfikator miejsca, w którym składane jest żądanie. Aby dostosować wartość tego parametru w Istio (zobaczymy go wtedy w naszym systemie śledzenia), konieczne jest określenie flagi serviceCluster na etapie uruchamiania kontenera sidecar. Na przykład można to obliczyć w ten sposób na podstawie zmiennych uzyskanych z API Kubernetes w dół:

--serviceCluster ${POD_NAMESPACE}.$(echo ${POD_NAME} | sed -e 's/-[a-z0-9]*-[a-z0-9]*$//g')

Dobrym przykładem zrozumienia działania śledzenia w programie envoy jest tutaj.

Sam punkt końcowy do wysyłania zakresów śledzenia musi być również określony we flagach uruchamiania proxy serwera proxy, na przykład: --zipkinAddress tracing-collector.tracing:9411

Błędne przekonanie numer dwa: możemy niedrogo uzyskać pełne ślady żądań za pośrednictwem systemu od razu po wyjęciu z pudełka

Niestety, tak nie jest. Złożoność wdrożenia zależy od tego, jak już zaimplementowałeś interakcję usług. Dlaczego?

Faktem jest, że aby istio-proxy było w stanie zrozumieć zgodność przychodzących żądań do usługi z tymi, które opuszczają tę samą usługę, nie wystarczy po prostu przechwycić cały ruch. Musisz mieć jakiś identyfikator komunikacyjny. Serwer proxy wysłannika HTTP używa specjalnych nagłówków, dzięki którym wysłannik rozumie, które konkretne żądanie skierowane do usługi generuje określone żądania do innych usług. Lista takich nagłówków:

id-żądania x,
x-b3-traceid,
x-b3-spanid,
x-b3-rodzicespanid,
próbka x-b3,
flagi x-b3,
kontekst-x-ot-span.

Jeśli masz jeden punkt, np. podstawowy klient, w którym możesz dodać taką logikę, to wszystko jest w porządku, wystarczy tylko poczekać, aż ta biblioteka zostanie zaktualizowana dla wszystkich klientów. Jeśli jednak masz bardzo heterogeniczny system i nie ma ujednolicenia w przechodzeniu od usługi do usługi przez sieć, najprawdopodobniej będzie to duży problem. Bez dodania takiej logiki wszystkie informacje dotyczące śledzenia będą jedynie „jednopoziomowe”. Oznacza to, że otrzymamy wszystkie interakcje między usługami, ale nie zostaną one sklejone w pojedyncze łańcuchy przejścia przez sieć.

wniosek

Istio zapewnia wygodne narzędzie do zbierania informacji o śledzeniu w sieci, ale musisz zrozumieć, że do wdrożenia będziesz musiał dostosować swój system i wziąć pod uwagę funkcje implementacji Istio. W rezultacie należy rozwiązać dwa główne punkty: zdefiniować protokół na poziomie aplikacji (który musi być obsługiwany przez proxy proxy) i skonfigurować przekazywanie informacji o połączeniu żądań do usługi z żądań z usługi (za pomocą nagłówków w przypadku protokołu HTTP). Kiedy te problemy zostaną rozwiązane, otrzymamy potężne narzędzie, które pozwala nam w przejrzysty sposób zbierać informacje z sieci, nawet w bardzo heterogenicznych systemach napisanych w wielu różnych językach i frameworkach.

W następnym artykule na temat Service Mesh przyjrzymy się jednemu z największych problemów Istio – dużemu zużyciu pamięci RAM przez każdy kontener proxy sidecar i omówimy, jak sobie z tym poradzić.

Źródło: www.habr.com