Istio и Kubernetes в продукция. Част 2. Трейсинг.

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

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

Мит номер едно: можем да получим данни за мрежовите пътувания безплатно.

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

Първо, нека разгледаме как изглежда изпращането на tracing span-ове от архитектурна гледна точка в Istio. Както си спомняме от първата част, за събиране на телеметрия Istio разполага с отделен компонент, наречен Mixer. Обаче, в текущата версия 1.0.* изпращането се извършва директно от проксито сървъри, а именно, от envoy proxy. Envoy proxy поддържа изпращането на tracing span-ове по протокола zipkin в базовия си вариант. Други протоколи могат да бъдат добавени, но само чрез плъгин. С Istio получаваме готов и конфигуриран envoy proxy, който поддържа само zipkin протокола. Ако искаме да използваме например протокола Jaeger и да изпращаме tracing span-ове по UDP, ще трябва да изградим собствен образ на istio-proxy. Поддръжката на персонализирани плъгини за istio-proxy е налична, но все още е в alpha версия. Затова, ако искаме да избягаме от множество персонализирани настройки, кръгът на използваните технологии за съхранение и прием на tracing span-ове намалява. От основните системи в момента можем да използваме само Zipkin или Jaeger, но да изпращаме всичко по zipkin съвместимия протокол (което е значително по-малко ефективно). Самият zipkin протокол предвижда изпращането на всяка tracing информация на колекторите по HTTP протокол, което е доста скъпо.

Както вече казах, искаме да трасираме протоколите на приложния слой. А това означава, че проксито сървъри, които стоят до всеки сервис, трябва да разбират какво точно взаимодействие се случва сега. По подразбиране, Istio настройва за всички портове plain TCP тип, което означава, че не ще се изпращат никакви трейсове. За да се изпращат трейсовете, първо трябва да включим такава опция в основния mesh config и, което е много важно, да именуваме всички портове на service сущностите в Kubernetes в съответствие с протокола, който се използва в сервиза. Тоест, например, по следния начин:

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

Може също да използвате съставни имена, например http-magic (Istio ще разпознае http и ще идентифицира този порт като http endpoint). Форматът е: proto-extra.

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

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

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

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

Самият endpoint за изпращане на tracing span-ове също трябва да бъде зададен в флаговете за стартиране на envoy proxy, например: --zipkinAddress tracing-collector.tracing:9411

Мит номер две: можем да получим напълно проследяване на заявките в системата на ниска цена по подразбиране.

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

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

• x-request-id,
• x-b3-traceid,
• x-b3-spanid,
• x-b3-parentspanid,
• x-b3-sampled,
• x-b3-flags,
• x-ot-span-context.

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

Заключение

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

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

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