В интернетa много статиите о сервизни мрежи (service mesh), и ето още една. Ура! Но защо? Защото искам да изразя мнението си, че е щяло да бъде по-добре, ако сервизните мрежи бяха се появили преди 10 години, преди появата на контейнерни платформи, като Docker и Kubernetes. Не твърдя, че моята гледна точка е по-добра или по-лоша от другите, но тъй като сервизните мрежи са доста сложни структури, множеството гледни точки ще помогне за тяхното по-добро разбиране.

Ще разкажа за платформата dotCloud, която беше изградена на базата на повече от стотина микросервизи и поддържаше хиляди приложения в контейнери. Ще обясня проблемите, с които се сблъскахме при разработката и пускането ѝ, и как сервизните мрежи биха могли да помогнат (или не).

Историята на dotCloud

Вече пишех за историята на dotCloud и избора на архитектура за тази платформа, но малко разказвах за мрежовия слой. Ако не искате да се гмуркате в четенето предишна статия за dotCloud, накратко ето същността: това е платформа като услуга PaaS, позволяваща на клиентите да стартират широк спектър от приложения (Java, PHP, Python…) с поддръжка на широки спектър от бази данни (MongoDB, MySQL, Redis…) и работен процес като този на Heroku: качвате своя код на платформата, тя изгражда образи на контейнери и ги разгръща.

Ще разкажа как минаваше трафикът на платформата dotCloud. Не защото това беше особено забележително (въпреки че за своето време системата работеше добре!), а преди всичко защото с помощта на съвременните инструменти такъв дизайн може лесно да бъде реализиран за кратко време от скромен екип, ако им е нужен начин за маршрутизиране на трафика между много микросервизи или много приложения. По този начин може да се сравнят вариантите: какво се получава, ако разработите всичко сами или използвате съществуваща сервизна мрежа. Стандартният избор: да направите сами или да купите.

Маршрутизация на трафика за хоствани приложения

Приложенията на dotCloud могат да предоставят HTTP и TCP крайни точки.

HTTP крайни точки динамично се добавят в конфигурацията на кластера от балансировачи на натоварването Hipache. Това е подобно на това, което днешния ресурс Ingress постига в Kubernetes и балансировачите на натоварването като Traefik.

Клиентите се свързват с HTTP крайни точки през съответните домейни, при условие че домейното име указва на балансировачите на натоварването на dotCloud. Нищо особено.

TCP крайни точки свързани с номера на порта, който след това се предава на всички контейнери в този стек чрез променливи на средата.

Клиентите могат да се свързват с TCP крайни точки, използвайки съответното име на хоста (нещо като gateway-X.dotcloud.com) и номер на порта.

Това име на хост се резолва на клъстера от сървъри “nats“ (няма отношение към NATS), които ще маршрутизират входящите TCP връзки към правилния контейнер (или, в случай на услуги с балансировка на натоварването, към правилните контейнери).

Ако сте запознати с Kubernetes, вероятно това ще ви напомни на услугите NodePort.

На платформата dotCloud нямаше аналог на услугите ClusterIP: за улеснение достъпът до услугите се извършваше по един и същ начин отвътре и отвън на платформата.

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

Обширен рефакторинг на съществуващия код не беше необходим. По-специално, 12-факторни приложения могат директно да използват адреса, получен чрез променливи на средата.

Какво се различава от съвременната сервисна мрежа?

Ограничена обзорност. Ние изобщо нямахме никакви метрики за TCP маршрутизацията. Що се отнася до HTTP маршрутизацията, в по-късни версии се появиха подробни HTTP метрики с кодове за грешка и време на отговор, но съвременните сервисни мрежи отиват още по-далеч, осигурявайки интеграция с системите за събиране на метрики, като Prometheus, например.

Обзорността е важна не само от оперативна гледна точка (за да помага при отстраняване на проблеми), но и при пускането на нови функции. Става дума за безопасен синьо-зелен деплой и деплой на канарейки.

Ефективност на маршрутизацията също е ограничена. В мрежата за маршрутизиране на dotCloud целият трафик трябваше да преминава през клъстер от специализирани маршрутизиращи възли. Това означаваше потенциално пресичане на няколко граници на AZ (зони на достъпност) и значително увеличение на забавянето. Помня, как отстранявах проблеми с код, който правеше над сто SQL запитвания на страница и за всяко запитване отваряше ново свързване с SQL сървъра. При локален запуск страницата зареждаше мигновено, но в dotCloud зареждането отнема няколко секунди, защото за всяко TCP свързване (и последващо SQL запитване) са необходими десетки милисекунди. В този конкретен случай проблемът беше решен с постоянни връзки.

Съвременните сервисни мрежи се справят по-добре с такива проблеми. На първо място, те проверяват, че връзките са маршрутизирани в източника. Логическият поток остава същият: клиент → мрежа → услуга, но сега мрежата работи локално, а не на отдалечени възли, така че връзката клиент → мрежа е локална и много бърза (микросекунди вместо милисекунди).

Съвременните сервисни мрежи също реализират по-интелигентни алгоритми за разпределение на натоварването. Като следят работоспособността на бекендовете, те могат да изпращат повече трафик към по-бързи бекенди, което води до повишаване на общата производителност.

Сигурност също е по-добра. Мрежата за маршрутизиране на dotCloud работеше изцяло на EC2 Classic и не криптираше трафика (на предположението, че ако някой успее да инсталира шпион на мрежовия трафик на EC2, вече имате големи проблеми). Съвременните сервисни мрежи прозрачно защитават целия наш трафик, например, с взаимна TLS аутентификация и последващо криптиране.

Маршрутизиране на трафика за платформените услуги

Добре, обсъдихме трафика между приложенията, но какво за самата платформа dotCloud?

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

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

Тези ниско ниво, важни услуги бяха разгръщани чрез стартиране на контейнери директно на няколко ключови възела. При това не бяха ангажирани стандартни услуги на платформата: компоновчик, планировчик и runner. Ако искате да сравните с модерни контейнерни платформи, това е подобно на стартиране на управленския панел с docker run директно на възлите, вместо да делегирате задачата на Kubernetes. Това е доста подобно на концепцията за статични модули (подове), които използва kubeadm или bootkube при стартиране на автономен клъстер.

Тези услуги бяха експонирани по прост и груб начин: имената и адресите им бяха изброени в YAML файл; а всеки клиент трябваше да вземе копие на този YAML файл за разгръщане.

От една страна, това е изключително надеждно, тъй като не изисква поддръжка на външно хранилище с ключове/стойности, като Zookeeper (не забравяйте, по това време все още не съществуваха etcd или Consul). От друга страна, това затрудняваше преместването на услугите. Всеки път при преместване, всички клиенти трябваше да получат актуализиран YAML файл (и потенциално да се презаредят). Не е много удобно!

По-късно започнахме да внедряваме нова схема, в която всеки клиент се свързваше с локален прокси-сървър. Вместо адреса и порта, му беше достатъчно да знае само номера на порта на услугата и да се свърже чрез localhost. Локалният прокси-сървър обработва това свързване и го насочва към действителния сървър. Сега при премест с бекенда на друга машина или мащабиране вместо актуализиране на всички клиенти, е нужно само да се актуализират всички тези локални проксита; и презареждането вече не е нужно.

(Също така беше планирано да се инкапсулира трафика в TLS връзки и да се постави допълнителен прокси-сървър на приемната страна, а също така да се проверяват сертификатите TLS без участието на приемащата услуга, която е настроена да приема връзки само на localhost).

Това много прилича на SmartStack от Airbnb, но съществената разлика е, че SmartStack е реализиран и внедрен в продукция, докато вътрешната система за маршрутизиране на dotCloud беше прибрана, когато dotCloud се превърна в Docker.

Лично аз смятам SmartStack за един от предшествениците на такива системи като Istio, Linkerd и Consul Connect, тъй като всички те следват един и същ шаблон:

• Стартиране на прокси на всеки възел.
• Клиентите се свързват с прокси.
• Контролната равнина обновява конфигурацията на прокси-сървъра при промяна на бекендите.
• … Печалба!

Съвременна реализация на сервис-решетката

Ако днес трябва да реализираме подобна мрежа, можем да използваме сходни принципи. Например, да настроим вътрешна DNS зона, съпоставяйки имената на услугите с адреси в пространството 127.0.0.0/8. След това да стартираме HAProxy на всеки възел в клъстера, приемайки връзки на всеки адрес на услугата (в тази подсистема 127.0.0.0/8) и пренасочвайки/блажайки натоварването на съответните бекенди. Конфигурацията на HAProxy може да се управлява confd, позволяваща съхранение на информация за бекенда в etcd или Consul и автоматично изпращане на обновената конфигурация на HAProxy, когато е необходимо.

Приблизително така работи Istio! Но с някои разлики:

• Използва Envoy Proxy вместо HAProxy.
• Запазва конфигурацията на бекенда чрез Kubernetes API вместо etcd или Consul.
• На услугите се присвояват адреси във вътрешната подсистема (адреси на Kubernetes ClusterIP) вместо 127.0.0.0/8.
• Има допълнителен компонент (Citadel) за добавяне на взаимна проверка на TLS между клиента и сървърите.
• Поддържа нови функции, като прекъсване на веригата (circuit breaking), разпределено проследяване, внедряване на канарейки и др.

Нека накратко разгледаме някои от разликите.

Envoy Proxy

Envoy Proxy е написан от компания Lyft [конкурент на Uber на пазара на таксита — бел. ред.]. Той е много подобен на другите проксита (например HAProxy, Nginx, Traefik…), но Lyft създаде свой, защото им трябваха функции, които липсват в другите проксита, и по-уместно беше да направят нов, отколкото да разширяват съществуващия.

Envoy може да се използва самостоятелно. Ако имам конкретна услуга, която трябва да се свърже с други услуги, мога да я настройвам да се свързва с Envoy и след това динамично да конфигурирам и пренастройвам Envoy с местоположението на другите услуги, получавайки много отлични допълнителни функции, например относно наблюдението. Вместо персонализирана клиентска библиотека или внедряване на код за проследяване на заявки, насочваме трафика към Envoy, а той събира метрики за нас.

Но Envoy също така може да работи като данъчна равнина (data plane) за сервис меша. Това означава, че сега за този сервис меш Envoy се настройва управляваща равнина (control plane).

Управляваща равнина

В управленската равнина Istio разчита на Kubernetes API. Това не е много различно от използването на confd, което разчита на etcd или Consul за извличане на набор от ключове от хранилището на данни. Istio преглежда набора от ресурси на Kubernetes чрез Kubernetes API.

Междувременно: на мен лично ми се видя полезно това описание на Kubernetes API, което гласи:

Сървърът на Kubernetes API е "глупав сървър", който предлага съхранение, управление на версии, проверка, актуализиране и семантика на API ресурсите.

Istio е проектиран да работи с Kubernetes; и ако искате да го използвате извън Kubernetes, ще трябва да стартирате екземпляр на сървър на Kubernetes API (и помощна служба etcd).

Адреси на услуги

Istio разчита на адресите ClusterIP, които предоставя Kubernetes, така че услугите на Istio получават вътрешен адрес (не в диапазона 127.0.0.0/8).

Трафикът към адреса ClusterIP за конкретна услуга в клъстера Kubernetes без Istio се прихваща от kube-proxy и се изпраща към сървърната част на този прокси. Ако се интересувате от технически подробности, kube-proxy задава правила iptables (или балансировчици на натоварването IPVS, в зависимост от начина, по който е настроен), за да пренапише целевите IP адреси на връзките, които минават по адреса ClusterIP.

След инсталирането на Istio в клъстера Kubernetes нищо не се променя, докато не бъде явно активирано за конкретен клиент или дори за цялото пространство на имена, чрез въвеждане на контейнер sidecar в персонализирани подове. Този контейнер ще стартира екземпляр на Envoy и ще зададе редица правила iptables за прихващане на трафика, който идва към други услуги, и пренасочване на този трафик към Envoy.

При интегриране с Kubernetes DNS, това означава, че нашият код може да се свързва по име на услуга и всичко "просто работи". С други думи, нашият код генерира запитвания от тип http://api/v1/users/4242, тогава api резолвира запитването на 10.97.105.48, правилата на iptables улавят свързванията от 10.97.105.48 и ги пренасочват към локалния прокси Envoy, а този локален прокси насочва запитването към действителния бекенд на API. Уф!

Допълнителни детайли

Istio също така осигурява end-to-end шифроване и удостоверяване чрез mTLS (взаимно TLS). За това отговаря компонент, наречен Citadel.

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

И, разбира се, споменахме наблюдаемостта: Envoy събира огромно количество метрики, осигурявайки разпределено проследяване. В архитектурата на микросервиси, ако едно API запитване трябва да премине през микросервиси A, B, C и D, то при влизането в системата разпределеното проследяване добавя уникален идентификатор към запитването и запазва този идентификатор през подзапитванията към всички тези микросервиси, позволявайки проследяване на всички свързани извиквания, техните забавяния и т.н.

Да разработим или да купим

Istio има репутацията на сложна система. В противовес на това, изграждането на маршрутизираща мрежа, която описах в началото на тази публикация, е относително просто с помощта на съществуващите инструменти. Така че, има ли смисъл вместо това да създадем собствен сервис mesh?

Ако имаме скромни нужди (не се нуждаем от наблюдаемост, прекъсвачи и други детайли), то идват мисли за разработване на собствен инструмент. Но ако използваме Kubernetes, той може дори да не е нужен, тъй като Kubernetes вече предоставя основни инструменти за откритие на услуги и разпределение на натоварването.

Но ако имаме напреднали изисквания, то "покупката" на сервис mesh изглежда далеч по-добър вариант. (Това не винаги е именно "покупка", тъй като Istio е с отворен код, но все пак трябва да инвестираме инженерно време, за да се запознаем с начина му на работа, да го внедрим и управляваме).

Какво да изберем: Istio, Linkerd или Consul Connect?

Досега говорихме само за Istio, но това не е единственият service mesh. Популярна алтернатива е Linkerd, а има и още Consul Connect.

Какво да изберем?

Честно казано, не знам. В момента не се смятам за достатъчно компетентен, за да отговоря на този въпрос. Има няколко интересни статиите сравнения на тези инструменти и дори бенчмаркове.

Един от перспективните подходи е да се използва инструмент, подобен на SuperGloo. Той реализира слой на абстракция за опростяване и унификация на API, предоставяни от service mesh-овете. Вместо да изучаваме конкретни (и, според мен, сравнително сложни) API на различни service mesh-а, можем да използваме по-прости конструкции SuperGloo и лесно да преминаваме от един на друг, сякаш имаме междинен формат на конфигурация, описващ HTTP интерфейси и бекенди, способен да генерира действителна конфигурация за Nginx, HAProxy, Traefik, Apache...

Малко поиграх с Istio и SuperGloo, а в следващата статия искам да покажа как да добавим Istio или Linkerd в съществуващ клъстер с помощта на SuperGloo и колко добре се справя последният, тоест как ни позволява да преминаваме от един service mesh на друг без да презаписваме конфигурации.

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