Мы пачынаем серыю пастоў, у якой прадэманструем некаторыя са мноства магчымасцяў сэрвіснай сеткі Istio Service Mesh у спалучэнні з Red Hat OpenShift і Kubernetes.
Частка першая, сённяшняя:
- Растлумачым канцэпцыю sidecar-кантэйнераў Kubernetes і сфармулюем лейтматыў гэтай серыі пастоў: "вам не трэба нічога мяняць у сваім кодзе".
- Прадстаўляльны асноватворную рэч Istio – правілы маршрутызацыі. На іх будуюцца ўсе астатнія магчымасці Istio, паколькі менавіта правілы дазваляюць накіроўваць трафік да мікрасэрвісаў, выкарыстаючы для гэтага вонкавыя па стаўленні да кода сэрвісаў файлы YAML. Таксама разглядаем схему разгортвання Canary Deployment. Навагодні бонус - 10 інтэрактыўных заняткаў па Istio
Частка другая, якая хутка выйдзе, раскажа вам:
- Як Istio рэалізуе Pool Ejection у спалучэнні з Circuit Breaker і прадэманструе, як Istio дазваляе прыбраць са схемы балансавання непрацуючы або дрэнна які працуе pod.
- А яшчэ мы разгледзім тэму Circuit Breaker з першай пасады на прадмет таго, як тут можна задзейнічаць Istio. Пакажам, як без найменшых змен у кодзе сэрвісаў маршрутызаваць трафік і апрацоўваць сеткавыя памылкі з дапамогай канфігурацыйных файлаў YAML і каманд тэрмінала.
Частка трэцяя:
- Аповяд аб трасіроўцы і маніторынгу, якія ўжо ўбудаваны ці лёгка дадаюцца ў Istio. Пакажам, як выкарыстоўваць такія прылады, як Prometheus, Jaeger і Grafana у спалучэнні з маштабаваннем OpenShift, каб без лішніх намаганняў кіраваць мікрасэрвіснай архітэктурай.
- Пераходзім ад маніторынгу і апрацоўкі памылак да таго, каб уносіць іх у сістэму наўмысна. Інакш кажучы, вучымся рабіць fault injection без змены зыходнага кода, што вельмі важна з пункту гледжання тэсціравання - паколькі калі змяняць для гэтага сам код, гэта значыць рызыка ўнесці дадатковыя памылкі.
Нарэшце, у фінальным пасце па Istio Service Mesh:
- Пяройдзем на Цёмны Бок. Дакладней, будзем вучыцца выкарыстоўваць схему Dark Launch, калі код разгортваецца і тэстуецца прама на прадакшн-дадзеных, але ніяк не закранае працу сістэмы. Тут вельмі дарэчы даводзіцца ўменне Istio падзяляць трафік. А магчымасць выконваць тэставанне на жывых прадакшн-дадзеных, ніяк не ўплываючы на працу баявой сістэмы, - гэта самы пераканаўчы спосаб праверкі.
- Адштурхваючыся ад Dark Launch, пакажам, як выкарыстоўваць мадэль Canary Deployment, каб скараціць рызыкі і спрасціць увод у строй новага кода. Сама па сабе Canary Deployment - далёка не навіна, але Istio дазваляе рэалізаваць гэтую схему ўсяго толькі з дапамогай нескладаных YAML-файлаў.
- У заключэнне пакажам, як з дапамогай Istio Egress даць доступ да сэрвісаў тым, хто знаходзіцца па-за вашымі кластарамі, каб задзейнічаць магчымасці Istio пры працы з інтэрнэтам.
Такім чынам, панеслася…
Інструментарый маніторынгу і кіравання Istio - усё неабходнае для каардынацыі мікрасэрвісаў у сэрвіснай сетцы .
Што такое сэрвісная сетка Istio
Сэрвісная сетка рэалізуе для групы сэрвісаў такія функцыі, як маніторынг трафіку, кантроль доступу, выяўленне, бяспека, адмоваўстойлівасць і іншыя карысныя рэчы. Istio дазваляе зрабіць усё гэта без найменшых змен у кодзе саміх сэрвісаў. У чым сакрэт чараўніцтва? Istio чапляе да кожнага сэрвісу свой проксі ў выглядзе sidecar-кантэйнера (sidecar - матацыклетны вазок), пасля чаго ўвесь трафік да гэтага сэрвісу ідзе праз проксі, які, кіруючыся зададзенымі палітыкамі, вырашае як, калі і ці павінен наогул гэты трафік дайсці да сэрвісу. Istio таксама дае магчымасць рэалізаваць прасунутыя тэхнікі DevOps, такія як canary deployments, circuit breakers, fault injection і многія іншыя.
Як Istio працуе з кантэйнерамі і Kubernetes
Сэрвісная сетка Istio – гэта sidecar'ная рэалізацыя ўсяго таго, што патрабуецца для стварэння і кіравання мікрасэрвісамі: маніторынг, трасіроўка, circuit breakers, маршрутызацыя, балансіроўка нагрузкі, fault injection, паўторы, тайм-аўты, люстраванне, кантроль доступу, абмежаванне хуткасці і шматлікае іншае. І хоць сёння ёсць маса бібліятэк, каб рэалізаваць гэтыя функцыі непасрэдна ў кодзе, з Istio вы можаце атрымаць усё тое ж самае, нічога не мяняючы ў сваім кодзе.
Паводле sidecar'най мадэлі, Istio выконваецца ў Linux-кантэйнеры, які размяшчаецца ў адным -pod'е з кантраляваным сэрвісам і ўкараняе (inject) і здабывае (extract) функцыянальнасць і інфармацыю паводле зададзенай канфігурацыі. Падкрэслім, гэта ваша ўласная канфігурацыя, і яна жыве па-за вашым кодам. Таму код становіцца значна прасцей і карацей.
Што яшчэ важна, аперацыйная складнік мікрасэрвісаў пры гэтым аказваецца ніяк не злучана з самім кодам, а значыць іх эксплуатацыю можна спакойна перадаць ІТ-адмыслоўцам. На самай справе, чаму распрацоўшчык павінен адказваць за circuit breaker'ы і fault injection? Рэагаваць - так, але апрацоўваць іх і ствараць? Калі прыбраць усё гэтага з кода, праграмісты змогуць поўнасцю засяродзіцца на прыкладным функцыянале. Ды і сам код стане карацейшым і прасцейшым.
Сэрвісная сетка
Istio, які рэалізуе функцыі кіравання мікрасэрвісамі па-за іх кодам – гэта і ёсць канцэпцыя сэрвіснай сеткі Service Mesh. Інакш кажучы, гэта скаардынаваная група з аднаго ці некалькіх бінарнікаў, якія ўтвараюць сетку сеткавых функцый.
Як Istio працуе з мікрасэрвісамі
Вось як выглядае праца sidecar-кантэенраў з звязку з и з вышыні птушынага палёту: запускаеце асобнік Minishift, ствараеце праект для Istio (назавём яго "istio-system"), усталёўваеце і запускаеце ўсе злучаныя з Istio кампаненты. Затым, па меры стварэння праектаў і pod'ов, дадаеце канфігурацыйныя звесткі ў свае deployment''ы, і вашы pod'ы пачынаюць выкарыстоўваць Istio. Спрошчана дыяграма выглядае так:
Цяпер можна змяняць наладкі Istio, каб, напрыклад, арганізаваць fault injection, падтрымку або іншыя магчымасці Istio - і ўсё гэта зусім не чапаючы код саміх прыкладанняў. Дапушчальны, вы жадаеце перанакіраваць увесь вэб-трафік ад карыстачоў свайго найбуйнага кліента (Foo Corporation) на новую версію сайта. Для гэтага дастаткова стварыць правіла маршрутызацыі Istio, якое будзе шукаць @foocorporation.com у ідэнтыфікатары карыстальніка і выконваць адпаведнае перанакіраванне. Для ўсіх астатніх карыстальнікаў нічога не зменіцца. А вы тым часам будзеце спакойна тэсціраваць новую версію сайта. І заўважце, для гэтага зусім не трэба прыцягваць распрацоўшчыкаў.
І дорага за гэта давядзецца заплаціць?
Зусім не. Istio працуе даволі хутка, ён напісаны на і стварае зусім невялікі оверхед. Акрамя таго, магчымы пройгрыш у анлайн-прадукцыйнасці кампенсуецца прыростам прадукцыйнасці працы распрацоўшчыкаў. Прынамсі, у тэорыі: не забывайце, што час распрацоўшчыкаў каштуе дорага. Што тычыцца затрат на ПЗ, то Istio - гэта софт з адкрытым кодам, таму атрымаць і выкарыстоўваць яго можна бясплатна.
Асвойце самі
Каманда Red Hat Developer Experience Team распрацавала паглыбленае практычнае па Istio (на англійскай). Яно працуе на Linux, MacOS і Windows, а код прадстаўлены ў варыянтах на Java і Node.js.
10 інтэрактыўных заняткаў па Istio
Блок 1 - Для пачаткоўцаў
Увядзенне ў Istio
30 хвілін
Знаёмімся з Service Mesh, вучымся ўсталёўваць Istio у Kubernetes кластары OpenShift.
Разгортванне мікрасэрвісаў у Istio
30 хвілін
Выкарыстоўваны Istio, каб разгарнуць тры мікрасэрвісы з Spring Boot і Vert.x.
Блок 2 - сярэдні ўзровень
Маніторынг і трасіроўка ў Istio
60 хвілін
Вывучаем убудаваныя сродкі маніторынгу Istio, якія наладжваюцца метрыкі, а таксама OpenTracing праз Prometheus і Grafana.
Простая маршрутызацыя ў Istio
60 хвілін
Вучымся кіраваць маршрутызацыяй у Istio з дапамогай простых правілаў.
Пашыраныя правілы маршрутызацыі
60 хвілін
Знаёмімся з разумнай маршрутызацыяй у Istio, кіраваннем доступам, балансаваннем нагрузкі і абмежаваннем хуткасці.
Блок 3 - дасведчаны карыстач
Fault Injection у Istio
60 хвілін
Вывучаем сцэнары апрацоўкі адмоў у размеркаваных прыкладанняў, ствараючы памылкі HTTP і сеткавыя затрымкі, вучымся ўжываць хаос-інжынірынгу для аднаўлення асяроддзя.
Circuit Breaker у Istio
30 хвілін
Усталёўваны Siege для стрэс-тэставанні сайтаў і вучымся забяспечыць адмоваўстойлівасць бэкенда з дапамогай паўтораў, circuit breaker і pool ejection.
Egress і Istio
10 хвілін
Выкарыстоўваны маршруты Egress для стварэння правіл узаемадзеяння ўнутраных сэрвісаў з вонкавымі API і сэрвісамі.
Istio і Kiali
15 хвілін
Вучымся выкарыстоўваць Kiali для атрымання агульнай карціны сэрвіснай сеткі і вывучэння патокаў запытаў і даных.
Mutual TLS у Istio
15 хвілін
Ствараем Istio Gateway і VirtualService, затым падрабязна вывучаем mutual TLS (mTLS) і яго налады.
Блок 3.1 - Глыбокае апусканне: Istio Service Mesh для мікрасэрвісаў
Пра што кніга:
- Што такое сэрвісная сетка Service Mesh.
- Сістэма Istio і яе роля ў мікрасэрвіснай архітэктуры.
- Выкарыстанне Istio пры рашэнні наступных задач:
- адмоваўстойлівасць;
- Маршрутызацыя;
- Хаос-тэставанне;
- бяспека;
- Збор тэлеметрыі сродкамі трасіроўкі, метрык і Grafana.
Серыя артыкулаў па сэрвісных сетках і Istio
паспрабуйце самі
Гэтая серыя пастоў не ставіць за мэту забяспечыць глыбокае апусканне ў свет Istio. Мы проста жадаем пазнаёміць вас з самай канцэпцыяй і, можа быць, натхніць самастойна паспрабаваць Istio. Гэта можна зрабіць цалкам бясплатна, і Red Hat дае ўсе неабходныя прылады, каб пачаць асвойваць OpenShift, Kubernetes, Linux-кантэйнеры і Istio, а менавіта: , і іншыя рэсурсы на нашым . Не варта адкладаць, пачніце прама сёння!
Правілы маршрутызацыі Istio: накіроўваем сэрвіс-запыты туды, куды трэба
и выдатна спраўляюцца з тым, каб звароты да маршрутызаваліся да патрэбных пад'ём. У гэтым і ёсць адна з мэт існавання Kubernetes – маршрутызацыя і балансаванне нагрузкі. А што, калі вам патрэбна больш тонкая і дасканалая маршрутызацыя? Напрыклад, каб адначасова выкарыстоўваць дзве версіі мікрасэрвісу. Як тут дапамогуць правілы маршрутызацыі Istio Route Rules?
Правілы маршрутызацыі - гэта правілы, якія, уласна, задаюць выбар маршруту. Пры любым узроўні складанасці сістэмы агульны прынцып працы гэтых правіл застаецца простым: запыты маршрутызуюцца на аснове вызначаных параметраў і значэнняў загалоўкаў HTTP.
Паглядзім на прыкладах:
Kubernetes змаўчанні: трывіяльнае «50 на 50»
У нашым прыкладзе мы пакажам, як адначасова выкарыстоўваць у OpenShift дзве версіі мікрасэрвісу, назавем іх v1 і v2. Кожная версія запускаецца ва ўласным pod'і Kubernetes, і па змаўчанні тут працуе раўнамерна збалансаваная цыклічная маршрутызацыя (evenly balanced round robin routing). Кожны pod атрымлівае сваю долю запытаў па колькасці яго асобнікаў мікрасэрвісу, інакш кажучы, рэплік. Istio жа дазваляе памяняць гэты баланс уручную.
Дапусцім, мы разгарнулі на OpenShift дзве версіі нашага рэкамендацыйнага сэрвісу, recommendation-v1 і recommendation-v2.
На мал. 1 відаць, што, калі кожны сэрвіс прадстаўлены ў адным асобніку, запыты раўнамерна чаргуюцца паміж імі: 1-2-1-2-… Менавіта так маршрутызацыя Kubernetes працуе па змаўчанні:
Узважанае размеркаванне паміж версіямі
На мал. 2 паказана, што будзе, калі павялічыць колькасць рэплік сэрвісу v2 з адной да двух (гэта робіцца камандай oc scale -replicas=2 deployment/recommendation-v2). Як бачым, запыты паміж v1 і v2 зараз дзеляцца ў стаўленні «адзін да трох»: 1-2-2-1-2-2-…:
Ігнор версіі з дапамогай Istio
Istio дазваляе лёгка змяніць размеркаванне запытаў патрэбнай нам выявай. Напрыклад, адпраўляць увесь трафік толькі на recommendation-v1 з дапамогай наступнага yaml-файла Istio:
Тут трэба звярнуць увагу вось на што: pod'ы выбіраюцца паводле пазнакаў. У нашым прыкладзе выкарыстоўваецца пазнака v1. Параметр "weight: 100" азначае, што 100% трафіку будзе маршрутызавацца на ўсе pod'ы сэрвісу, у якіх ёсць пазнака v1.
Дырэктыўнае размеркаванне паміж версіямі (Canary Deployment)
Далей, выкарыстоўваючы параметр weight, можна накіроўваць трафік да абодвух pod'ам, ігнаруючы колькасць асобнікаў мікрасэрвісаў, запушчаных у кожным з іх. Напрыклад, тут мы дырэктыўна накіроўваем 90% трафіку на v1 і 10% - на v2:
Асобная маршрутызацыя мабільных карыстальнікаў
У заключэнне пакажам, як прымусова маршрутызаваць трафік мабільных карыстальнікаў на сэрвіс v2, а ўсіх астатніх - на v1. Для гэтага мы дапамогай рэгулярных выразаў аналізуем значэнне user-agent у загалоўку запыту:
Цяпер ваша чарга
Прыклад з рэгулярнымі выразамі для аналізу загалоўкаў павінен матываваць вас на пошук уласных варыянтаў ужывання правіл маршрутызацыі Istio. Тым больш што магчымасці тут адчыняюцца вельмі шырокія, паколькі значэнні загалоўкаў можна фармаваць у зыходным кодзе прыкладанняў.
І памятайце, што Ops, а не Dev
Усё, што мы паказалі ў прыкладах вышэй, робіцца без найменшых змен у зыходным кодзе, ну за выключэннем тых выпадкаў, калі трэба фармаваць адмысловыя загалоўкі запытаў. Istio спатрэбіцца як распрацоўнікам, якія, напрыклад, змогуць ужываць яго на этапе тэставанні, так і адмыслоўцам па эксплуатацыі ІТ-сістэм, якім ён моцна дапаможа ў прадакшне.
Так што паўторым лейтматыў гэтай серыі пастоў: вам не трэба нічога мяняць у сваім кодзе. Не трэба збіраць новыя выявы або запускаць новыя кантэйнеры. Усё гэта рэалізуецца па-за кодам.
Уключыце ўяўленне
Толькі ўявіце, якія перспектывы адкрывае аналіз загалоўкаў з дапамогай рэгулярных выразаў. Жадаеце перанакіроўваць вашага найбуйнага кліента на адмысловую версію сваіх ? Лёгка! Патрэбна асобная версія для браўзэра Chrome? Не праблема! Вы можаце маршрутызаваць трафік практычна па любой яго характарыстыцы.
паспрабуйце самі
Чытаць пра Istio, Kubernetes і OpenShift - гэта адно, але чаму б не памацаць усё сваімі рукамі? Каманда падрыхтавала падрабязнае кіраўніцтва (на англійскай), якое дапаможа вам максімальна хутка асвоіць гэтыя тэхналогіі. Кіраўніцтва таксама 100% open source, таму яно размешчана ў адкрытым доступе. Файл працуе на macOS, Linux і Windows, а зыходны код ёсць у варыянтах на Java і node.js (хутка будуць версіі і на іншых мовах). Проста адкрыйце ў сваім браўзэры адпаведны git-рэпазітар .
У наступным пасце: адпрацоўваем праблемы прыгожа
Сёння вы ўбачылі, на што здольныя правілы маршрутызацыі Istio. А зараз прадстаўце ўсё тое ж самае, але толькі ў дачыненні да апрацоўкі памылак. Менавіта пра гэта мы і раскажам у наступным пасце.
Крыніца: habr.com