Istio и Kubernetes в производство. Част 2. Проследяване

В последния Статия Разгледахме основните компоненти на Service Mesh Istio, запознахме се със системата и отговорихме на основните въпроси, които обикновено възникват при започване на работа с Istio. В тази част ще разгледаме как да организираме събирането на информация за проследяване в мрежа.

Първото нещо, което идва на ум на много разработчици и системни администратори, когато чуят думите Service Mesh, е трасирането. Наистина, ние добавяме специален прокси сървър към всеки мрежов възел, през който преминава целият TCP трафик. Изглежда, че вече е възможно лесно да се изпраща информация за всички мрежови взаимодействия в мрежата. За съжаление, в действителност има много нюанси, които трябва да се вземат предвид. Нека да ги разгледаме.

Погрешно схващане номер едно: можем да получим онлайн данни за туризъм безплатно.

Всъщност сравнително безплатно можем да получим само възлите на нашата система, свързани със стрелки, и скоростта на данни, която преминава между услугите (всъщност само броя байтове за единица време). В повечето случаи обаче нашите услуги комуникират по някакъв вид протокол на приложния слой, като HTTP, gRPC, Redis и т.н. И, разбира се, искаме да видим информация за проследяване специално за тези протоколи; искаме да видим скоростта на заявка, а не скоростта на данни. Искаме да разберем закъснението на заявките, използващи нашия протокол. И накрая, искаме да видим пълния път, който изминава една заявка от влизане в нашата система до получаване на отговор от потребителя. Този проблем вече не е толкова лесен за решаване.

Първо, нека да разгледаме как изглежда проследяването на изпращане от архитектурна гледна точка в Istio. Както си спомняме от първата част, Istio има отделен компонент, наречен Mixer за събиране на телеметрия. Въпреки това, в текущата версия 1.0.*, изпращането се извършва директно от прокси сървъри, а именно от envoy proxy. Envoy proxy поддържа изпращане на участъци за проследяване с помощта на протокола zipkin веднага. Има възможност за свързване на други протоколи, но само чрез плъгин. С Istio веднага получаваме сглобен и конфигуриран прокси сървър, който поддържа само протокола zipkin. Ако искаме да използваме, например, протокола Jaeger и да изпратим участъци за проследяване чрез UDP, тогава ще трябва да изградим наш собствен istio-прокси образ. Има поддръжка за персонализирани добавки за 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 крайна точка). Форматът е: proto-extra.

За да не кръпвате огромен брой конфигурации, за да определите протокола, можете да използвате мръсно заобиколно решение: кръпете компонента Pilot в момента, когато е просто изпълнява логика за дефиниране на протокол. В крайна сметка, разбира се, ще е необходимо тази логика да се промени на стандартна и да се премине към конвенция за именуване на всички портове.

За да разберете дали протоколът наистина е дефиниран правилно, трябва да влезете в някой от страничните контейнери с envoy proxy и да направите заявка към администраторския порт на envoy интерфейса с местоположение /config_dump. В получената конфигурация трябва да погледнете работното поле на желаната услуга. Използва се в Istio като идентификатор за това къде е направена заявката. За да персонализирате стойността на този параметър в Istio (след това ще го видим в нашата система за проследяване), е необходимо да посочите флага serviceCluster на етапа на стартиране на контейнера с кош. Например, може да се изчисли по следния начин от променливи, получени от низходящия API на kubernetes:

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

Добър пример за разбиране как работи проследяването в envoy е тук.

Самата крайна точка за изпращане на участъци за проследяване също трябва да бъде посочена в флаговете за стартиране на прокси сървър на envoy, например: --zipkinAddress tracing-collector.tracing:9411

Погрешно схващане номер две: можем евтино да получим пълни следи от заявки чрез системата веднага

За съжаление не е така. Сложността на внедряването зависи от това как вече сте внедрили взаимодействието на услугите. Защо така?

Факт е, че за да може istio-proxy да разбере кореспонденцията на входящи заявки към услуга с тези, които напускат същата услуга, не е достатъчно просто да прихване целия трафик. Трябва да имате някакъв вид комуникационен идентификатор. HTTP envoy proxy използва специални заглавки, чрез които envoy разбира коя конкретна заявка към услугата генерира конкретни заявки към други услуги. Списък на такива заглавки:

• x-заявка-id,
• x-b3-traceid,
• x-b3-spanid,
• x-b3-parentspanid,
• x-b3-извадка,
• x-b3-знамена,
• x-ot-span-контекст.

Ако имате една точка, например основен клиент, в който можете да добавите такава логика, тогава всичко е наред, просто трябва да изчакате тази библиотека да се актуализира за всички клиенти. Но ако имате много хетерогенна система и няма унификация при преминаване от услуга към услуга през мрежата, тогава това най-вероятно ще бъде голям проблем. Без добавяне на такава логика цялата информация за проследяване ще бъде само на „едно ниво“. Тоест, ние ще получим всички взаимодействия между услугите, но те няма да бъдат залепени в единични вериги на преминаване през мрежата.

Заключение

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

В следващата статия за Service Mesh ще разгледаме един от най-големите проблеми с Istio – голямото потребление на RAM от всеки прокси контейнер на sidecar и ще обсъдим как можете да се справите с него.

Източник: www.habr.com