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

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

История на dotCloud

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

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

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

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

HTTP крайни точки динамично добавен към конфигурацията на клъстера за балансиране на натоварването Хипаче. Това е подобно на това, което ресурсите правят днес Влизане в Kubernetes и балансьор на натоварването като Траефик.

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

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. Но малък брой услуги от ниско ниво (особено тези, които прилагат тази мрежа за маршрутизиране) се нуждаеха от нещо по-просто, с по-малко зависимости (тъй като не можеха да разчитат на себе си, за да работят - добрият стар проблем с кокошката и яйцето).

Тези критични за мисията услуги на ниско ниво бяха разгърнати чрез стартиране на контейнери директно на няколко ключови възела. В този случай не са използвани стандартни услуги на платформата: линкер, планировчик и бегач. Ако искате да сравните с модерни контейнерни платформи, това е като да управлявате контролна равнина с docker run директно на възлите, вместо да делегирате задачата на Kubernetes. Доста е сходен като концепция статични модули (pods), които използва 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 може да се контролира конф, което ви позволява да съхранявате бекенд информация в etcd или Consul и автоматично да изпращате актуализирана конфигурация към HAProxy, когато е необходимо.

До голяма степен така работи Istio! Но с някои разлики:

• Употреби Пълномощник на пратеника вместо HAProxy.
• Съхранява бекенд конфигурация чрез Kubernetes API вместо etcd или Consul.
• Услугите са разпределени адреси във вътрешната подмрежа (IP адреси на Kubernetes Cluster) вместо 127.0.0.0/8.
• Има допълнителен компонент (Citadel) за добавяне на взаимно TLS удостоверяване между клиента и сървърите.
• Поддържа нови функции като прекъсване на веригата, разпределено проследяване, разгръщане на Canary и др.

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

Пълномощник на пратеника

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

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

Но Envoy също може да работи като равнина на данни (равнина на данни) за сервизната мрежа. Това означава, че Envoy вече е конфигуриран за тази услуга контролна равнина (контролна равнина).

Контролен самолет

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

Между това и тогава: Лично намирам това за полезно Описание на 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 load balancers, в зависимост от това как е конфигуриран), за да пренапише целевите 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 също така осигурява криптиране от край до край и удостоверяване чрез mTLS (взаимен TLS). Компонент, наречен Цитадела.

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

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

Разработете или купете

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

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

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

Трябва ли да избера Istio, Linkerd или Consul Connect?

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

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

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

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

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

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