🥇Истио и Кубернетес во производство. Дел 2. Следење

Во последниот Член Ги разгледавме основните компоненти на Service Mesh Istio, се запознавме со системот и одговоривме на главните прашања кои обично се појавуваат при започнување со работа со Istio. Во овој дел ќе погледнеме како да се организира собирање на информации за следење преку мрежа.

Првото нешто што им паѓа на ум на многу програмери и системски администратори кога ќе ги слушнат зборовите Service Mesh is tracing. Навистина, додаваме специјален прокси-сервер на секој мрежен јазол низ кој минува целиот TCP сообраќај. Се чини дека сега е можно лесно да се испраќаат информации за сите мрежни интеракции на мрежата. За жал, во реалноста има многу нијанси што треба да се земат предвид. Ајде да ги погледнеме.

Заблуда број еден: можеме да добиеме онлајн податоци за планинарење бесплатно.

Всушност, релативно бесплатно, можеме да ги добиеме само јазлите на нашиот систем поврзани со стрелки и брзината на податоци што поминува помеѓу услугите (всушност, само бројот на бајти по единица време). Меѓутоа, во повеќето случаи, нашите услуги комуницираат преку некој вид протокол на апликациски слој, како што се HTTP, gRPC, Redis итн. И, се разбира, сакаме да видиме информации за следење специјално за овие протоколи; сакаме да ја видиме стапката на барање, а не стапката на податоци. Сакаме да ја разбереме доцнењето на барањата користејќи го нашиот протокол. Конечно, сакаме да ја видиме целосната патека што ја поминува барањето од најавување во нашиот систем до добивање одговор од корисникот. Овој проблем веќе не е толку лесно да се реши.

Прво, да погледнеме како изгледаат распоните за следење на испраќање од архитектонска гледна точка во Истио. Како што се сеќаваме од првиот дел, Istio има посебна компонента наречена Mixer за собирање телеметрија. Меѓутоа, во тековната верзија 1.0.*, испраќањето се врши директно од прокси-сервери, имено, од прокси-пренесувач. Проксито Envoy поддржува испраќање распони за следење со помош на протоколот zipkin надвор од кутијата. Можно е да се поврзат и други протоколи, но само преку приклучок. Со Istio веднаш добиваме монтирано и конфигурирано envoy proxy, кое го поддржува само протоколот zipkin. Ако сакаме да го користиме, на пример, протоколот Jaeger и да испратиме распони за следење преку UDP, тогаш ќе треба да изградиме сопствена istio-proxy слика. Има поддршка за сопствени приклучоци за istio-proxy, но сè уште е во алфа верзија. Затоа, ако сакаме да работиме без голем број приспособени поставки, опсегот на технологии што се користат за складирање и примање распони за следење е намален. Од главните системи, всушност, сега можете да го користите самиот Zipkin, или Jaeger, но да испратите сè таму користејќи го протоколот компатибилен со zipkin (кој е многу помалку ефикасен). Самиот протокол zipkin вклучува испраќање на сите информации за следење до собирачите преку протоколот HTTP, што е прилично скапо.

Како што веќе реков, сакаме да ги следиме протоколите на ниво на апликација. Ова значи дека прокси-серверите што стојат до секоја услуга мора да разберат каква интеракција се случува сега. Стандардно, Istio ги конфигурира сите порти да бидат обичен TCP, што значи дека нема да се испраќаат траги. За да се испратат трагите, прво мора да ја овозможите оваа опција во конфигурацијата на главната мрежа и, што е многу важно, да ги именувате сите порти на услужните субјекти на kubernetes во согласност со протоколот што се користи во услугата. Тоа е, на пример, вака:

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

Можете исто така да користите сложени имиња како http-magic (Istio ќе го види http и ќе ја препознае таа порта како http крајна точка). Форматот е: прото-екстра.

За да не се закрпи огромен број конфигурации за да се одреди протоколот, можете да користите валкано решение: закрпете ја Pilot компонентата во моментот кога е само врши логика за дефинирање на протокол. На крајот, се разбира, ќе биде неопходно да се промени оваа логика во стандардна и да се префрли на конвенција за именување за сите пристаништа.

За да разберете дали протоколот навистина е правилно дефиниран, треба да отидете во кој било од контејнерите на страничната кара со прокси-пренесувач и да поднесете барање до административната порта на интерфејсот на пратеникот со локација /config_dump. Во добиената конфигурација, треба да го погледнете полето за работа на саканата услуга. Се користи во Istio како идентификатор за местото каде што е поднесено барањето. За да се приспособи вредноста на овој параметар во Istio (потоа ќе го видиме во нашиот систем за следење), неопходно е да го наведете знамето на услугата Кластер во фазата на лансирање на контејнерот на страничната кола. На пример, може да се пресмета вака од променливите добиени од надолното kubernetes API:

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

Добар пример за да се разбере како функционира следењето во пратеникот тука.

Самата крајна точка за испраќање распони за следење, исто така, мора да биде наведена во знаменцата за лансирање на прокси-пренесувачот, на пример: --zipkinAddress tracing-collector.tracing:9411

Заблуда број два: ефтино можеме да добиеме целосни траги на барања преку системот надвор од кутијата

За жал, не е. Комплексноста на имплементацијата зависи од тоа како веќе сте ја имплементирале интеракцијата на услугите. Зошто е тоа?

Факт е дека за да може istio-proxy да ја разбере кореспонденцијата на дојдовните барања до услугата со оние што ја напуштаат истата услуга, не е доволно едноставно да се пресретне целиот сообраќај. Треба да имате некаков идентификатор за комуникација. HTTP envoy proxy користи специјални заглавија, со кои envoy разбира кое конкретно барање до услугата генерира конкретни барања до други услуги. Список на такви заглавија:

x-барање-ид,
x-b3-traceid,
x-b3-шпанско,
x-b3-parentspanid,
x-b3-примерок,
x-b3-знамиња,
x-ot-span-context.

Ако имате една точка, на пример, основен клиент, во кој можете да додадете таква логика, тогаш сè е во ред, само треба да почекате оваа библиотека да се ажурира за сите клиенти. Но, ако имате многу хетероген систем и нема обединување во движењето од услуга до услуга преку мрежата, тогаш ова најверојатно ќе биде голем проблем. Без додавање на таква логика, сите информации за следење ќе бидат само „едно нивоа“. Односно, ќе ги добиеме сите интер-сервисни интеракции, но тие нема да бидат залепени во единечни синџири на премин низ мрежата.

Заклучок

Istio обезбедува удобна алатка за собирање информации за следење преку мрежа, но мора да разберете дека за имплементација ќе треба да го прилагодите вашиот систем и да ги земете предвид карактеристиките на имплементацијата на Istio. Како резултат на тоа, треба да се решат две главни точки: дефинирање на протоколот за ниво на апликација (кој мора да биде поддржан од полномошникот) и поставување на препраќање информации за поврзувањето на барањата до услугата од барањата од услугата (со користење на заглавија , во случај на протоколот HTTP). Кога овие прашања ќе се решат, имаме моќна алатка која ни овозможува транспарентно да собираме информации од мрежата, дури и во многу хетерогени системи напишани на многу различни јазици и рамки.

Во следната статија за Service Mesh, ќе го разгледаме еден од најголемите проблеми со Istio - големата потрошувачка на RAM меморија од секој контејнер за прокси од страната и ќе разговараме за тоа како можете да се справите со тоа.

Извор: www.habr.com