Истио и Кубернетес у производњи. Парт 2. Трацинг

У последњих Чланак Погледали смо основне компоненте Сервице Месх Истио-а, упознали се са системом и одговорили на главна питања која се обично јављају када почнемо да радимо са Истио-ом. У овом делу ћемо погледати како да организујемо прикупљање информација о праћењу преко мреже.

Прва ствар која пада на памет многим програмерима и систем администраторима када чују речи Сервице Месх ис трацинг. Заиста, додајемо посебан проки сервер сваком мрежном чвору кроз који пролази сав ТЦП саобраћај. Чини се да је сада могуће лако слати информације о свим мрежним интеракцијама на мрежи. Нажалост, у стварности постоји много нијанси које треба узети у обзир. Хајде да их погледамо.

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

У ствари, релативно бесплатно, можемо добити само чворове нашег система повезане стрелицама и брзину преноса података између услуга (у ствари, само број бајтова по јединици времена). Међутим, у већини случајева, наше услуге комуницирају преко неке врсте протокола слоја апликације, као што су ХТТП, гРПЦ, Редис и тако даље. И, наравно, желимо да видимо информације о праћењу посебно за ове протоколе; желимо да видимо стопу захтева, а не брзину података. Желимо да разумемо кашњење захтева користећи наш протокол. На крају, желимо да видимо пуну путању коју захтева захтева од пријављивања на наш систем до добијања одговора од корисника. Овај проблем више није тако лако решити.

Прво, погледајмо како изгледа слање распона праћења са архитектонске тачке гледишта у Истио-у. Као што се сећамо из првог дела, Истио има засебну компоненту која се зове Миксер за прикупљање телеметрије. Међутим, у тренутној верзији 1.0.*, слање се врши директно са прокси сервера, односно са проксија изасланика. Енвои проки подржава слање распона праћења помоћу зипкин протокола из кутије. Могуће је повезати и друге протоколе, али само преко додатка. Са Истио-ом одмах добијамо састављени и конфигурисани проки проки, који подржава само зипкин протокол. Ако желимо да користимо, на пример, Јаегер протокол и шаљемо распоне праћења преко УДП-а, онда ћемо морати да направимо сопствену истио-прокси слику. Постоји подршка за прилагођене додатке за истио-проки, али је и даље у алфа верзији. Стога, ако желимо да прођемо без великог броја прилагођених подешавања, смањује се опсег технологија које се користе за чување и пријем распона праћења. Од главних система, заправо, сада можете да користите сам Зипкин или Јаегер, али све тамо шаљете користећи протокол компатибилан са зипкин-ом (који је много мање ефикасан). Сам зипкин протокол укључује слање свих информација о праћењу сакупљачима преко ХТТП протокола, што је прилично скупо.

Као што сам већ рекао, желимо да пратимо протоколе на нивоу апликације. То значи да прокси сервери који стоје поред сваке услуге морају да разумеју каква се интеракција сада дешава. Подразумевано, Истио конфигурише све портове да буду обични ТЦП, што значи да се трагови неће слати. Да би се трагови слали, морате прво да омогућите ову опцију у главној конфигурацији мреже и, што је веома важно, да именујете све портове ентитета кубернетес сервиса у складу са протоколом који се користи у сервису. То је, на пример, овако:

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

Такође можете користити сложена имена попут хттп-магиц (Истио ће видети хттп и препознати тај порт као хттп крајњу тачку). Формат је: прото-екстра.

Да не бисте закрпили велики број конфигурација за одређивање протокола, можете користити прљаво решење: закрпите Пилот компоненту у тренутку када је само врши логику дефиниције протокола. На крају, наравно, биће потребно променити ову логику у стандардну и прећи на конвенцију именовања за све портове.

Да бисте разумели да ли је протокол заиста исправно дефинисан, потребно је да уђете у било који од бочних контејнера са проки-јем изасланика и упутите захтев на админ порт интерфејса изасланика са локацијом /цонфиг_думп. У резултујућој конфигурацији, потребно је да погледате оперативно поље жељене услуге. Користи се у Истио-у као идентификатор за место где је захтев направљен. Да бисте прилагодили вредност овог параметра у Истио-у (тада ћемо га видети у нашем систему за праћење), потребно је навести сервицеЦлустер заставицу у фази покретања бочног контејнера. На пример, може се израчунати овако из варијабли добијених из кубернетес АПИ-ја надоле:

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

Добар пример за разумевање како функционише праћење у енвои-у овде.

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

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

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

Чињеница је да да би истио-проки могао да разуме кореспонденцију долазних захтева ка сервису са онима који напуштају исту услугу, није довољно једноставно пресрести сав саобраћај. Морате имати неку врсту идентификатора комуникације. ХТТП проки изасланик користи посебна заглавља, помоћу којих изасланик разуме који специфични захтев за услугу генерише специфичне захтеве за друге услуге. Листа таквих заглавља:

• к-рекуест-ид,
• к-б3-трацеид,
• к-б3-спанид,
• к-б3-парентспанид,
• к-б3-узорковано,
• к-б3-заставе,
• к-от-спан-цонтект.

Ако имате једну тачку, на пример, основни клијент, у који можете да додате такву логику, онда је све у реду, само треба да сачекате да се ова библиотека ажурира за све клијенте. Али ако имате веома хетероген систем и нема уједињења у преласку са услуге на услугу преко мреже, онда ће то највероватније бити велики проблем. Без додавања такве логике, све информације о праћењу биће само „на једном нивоу“. Односно, примићемо све интеракције између служби, али оне неће бити залепљене у јединствене ланце проласка кроз мрежу.

Закључак

Истио пружа згодан алат за прикупљање информација о праћењу преко мреже, али морате разумети да ћете за имплементацију морати да прилагодите свој систем и да узмете у обзир карактеристике Истио имплементације. Као резултат тога, потребно је решити две главне тачке: дефинисање протокола на нивоу апликације (који мора бити подржан од проксија изасланика) и подешавање прослеђивања информација о повезивању захтева са сервисом из захтева из сервиса (помоћу заглавља). , у случају ХТТП протокола). Када се ови проблеми реше, имамо моћан алат који нам омогућава да транспарентно прикупљамо информације са мреже, чак иу веома хетерогеним системима написаним на много различитих језика и оквира.

У следећем чланку о Сервице Месх-у, погледаћемо један од највећих проблема са Истио-ом – велику потрошњу РАМ-а од стране сваког бочног прокси контејнера и разговараћемо о томе како можете да се носите са тим.

Извор: ввв.хабр.цом