„Опасността е моето второ име“, казваше Остин Пауърс, човекът-мистерия с международно значение. Но това, което е високо ценено от суперапентите и тайните служби, съвсем не е подходящо за компютърните служби, където скуката е много по-добра от опасностите.
Istio, заедно с OpenShift и Kubernetes, превръщат разгръщането на микросервизи в наистина скучен и предсказуем процес – и това е прекрасно. За това и много други теми ще говорим в четвъртата и последна част от серията за Istio.
Когато скуката е правилна
В нашия случай скуката възниква само в крайната фаза, когато остава само да седите и наблюдавате процеса. Но за това трябва всичко предварително да бъде настроено, и тук ви очаква много интересно.
При разгръщането на нова версия на вашия софтуер е важно да разгледате всички варианти за минимизиране на рисковете. Работата в паралелен режим е много мощен и проверен начин за тестване, а Istio позволява да се използва „тайната служба“ (скрита от любопитни очи версия на вашия микросервис) без намеса в работата на продукционната система. За това дори има специален термин – „Тайно стартиране“ (Dark Launch), което от своя страна се активира чрез функция с не по-малко шпионско име – „зеркалене на трафика“.
Обърнете внимание, че в първото изречение на предишния абзац се използва терминът „разгръщане“ (deploy), а не „стартиране“ (release). Вие наистина трябва да имате възможност да разгръщате – и, разбира се, да използвате – вашия микросервис колкото често пожелаете. Този сервис трябва да бъде способен да приема и обработва трафик, да предоставя резултати и да записва в логовете и да се мониторира. Но самият този сервис съвсем не е задължително да се пуска в продукция. Разгръщането и пускането на софтуер не са винаги едно и също. Можете да извършвате разгръщания всеки път, когато пожелаете, но пускането – само когато сте окончателно готови.
Организацията на скуката е интересна
Погледнете следното правило за маршрутизиране на Istio, което насочва всички HTTP заявки към микросервиза recommendation v1 (всички примери са взети от ), докато едновременно ги зеркалира на микросервиза recommendation v2:
Обърнете внимание на етикета mirror: в долната част на екрана – именно той задава зеркалирането на трафика. Да, толкова е просто!
Резултатът от работата на това правило ще бъде, че вашата продукционна система (v1) ще продължи да обработва входящите заявки, но самите заявки ще бъдат асинхронно отразявани на v2, тоест там ще се изпращат техни пълни дубликати. Така ще можете да тествате работата на v2 в реални условия – на действителни данни и трафик, без да се намесвате в работата на продукционната система. Превръща ли това организацията на тестването в скука? Да, определено. Но се прави по интересен начин.
Да добавим драма
Обърнете внимание, че в кода на v2 трябва да се предвиди ситуация, при която входящите заявки могат да доведат до промяна на данните. Самите заявки се отразяват лесно и прозрачно, но начинът на обработка в тестовата версия остава за вас – а това е вече малко вълнуващо.
Да повторим важния момент
Тайният запуск с отразяване на трафика (Dark Launch/Request Mirroring) може да се извърши, без да се засяга кода.
Храна за размисъл
А какво ще стане, ако вместо да отразявате заявките, част от тях изпратите не на v1, а на v2? Например, един процент от всички заявки или само заявки от определена група потребители. И след това, като видите как работи v2, постепенно да прехвърлите на новата версия всички заявки. Или обратно, да върнете всичко на v1, ако нещо с v2 не върви както трябва. Изглежда, че това се нарича Canary Deployment ("канарейково разгръщане" – термин , и ако имаше руско произход, вероятно щеше да съдържа препратка към ), и сега ще го разгледаме по-подробно.
Canary Deployment в Istio: опростяване на внедряването
Внимателно и постепенно
Същността на модела на разгръщане Canary Deployment е изключително проста: при стартиране на нова версия на софтуера си (в нашия случай – микросервиз) първо давате достъп до нея на малка група потребители. Ако всичко върви нормално, бавно увеличавате тази група, докато новата версия не започне да показва проблеми, или – ако това не се случва – накрая прехвърляте всички потребители на нея. Внимателно и постепенно въвеждайки новата версия и контролирано прехвърляйки на нея потребители, можете да намалите рисковете и максимизирате обратната връзка.
Разбира се, Istio опростява Canary Deployment, предлагайки няколко добри опции за интелигентно маршрутизиране на заявки. И да, всичко това може да бъде направено, без да докосвате изходния код.
Филтрираме браузера
Един от най-простите критерии за маршрутизиране е пренасочването в зависимост от браузера. Да предположим, че искате v2 да получават само заявки от браузери Safari. Ето как става:
Ще приложим това правило за маршрутизиране и след това с командата curl ще симулираме реални заявки към микросервиза в цикъл. Както се вижда на скрийншота, всички те отиват на v1:
А къде е трафикът към v2? Тъй като в нашия пример всички заявки идваха само от нашия команден ред, просто го няма. Но обърнете внимание на долните редове на скрина по-горе: това е реакцията на изпълнения заявка от браузера Safari, който от своя страна издаде следното:
Неограничена власт
Вече писахме, че регулярните изрази предоставят много мощни възможности за маршрутизиране на заявки. Погледнете следния пример (мислим, че сами разбирате какво прави):
Сега вероятно вече имате представа какво могат регулярните изрази.
Действайте умно
Умното маршрутизиране, в частност обработката на заглавия на пакети с помощта на регулярни изрази, позволява да управлявате трафика така, както желаете. И това значително опростява внедряването на нов код - по-просто е, не изисква промяна в самия код и при необходимост всичко може бързо да се върне обратно.
Заинтересовани ли сте?
Запалени ли сте по експериментирането с Istio, Kubernetes и OpenShift на вашия компютър? Екипът подготви отличен по тази тема и публикува всичките свързани файлове. Така че напред, не се колебайте.
Istio Egress: изход през сувенирния магазин
Прилагането на Istio заедно с Red Hat OpenShift и Kubernetes може значително да улесни работата с микросервизите. Сервизната мрежа Istio е вградена в Kubernetes подовете, а вашият код се изпълнява (предимно) изолирано. Производителността, лекотата на промени, трасировката и други – всичко това е лесно за използване именно благодарение на приложението на sidecar контейнери. Но какво да правите, ако вашият микросервис трябва да комуникира с други услуги, които се намират извън вашата система OpenShift-Kubernetes?
Тук на помощ идва Istio Egress. Накратко, той просто позволява достъп до ресурси (чети: „сервизи“), които не са част от вашата система с Kubernetes подове. Ако не извършите допълнителни настройки, в средата на Istio Egress трафикът се маршрутизира единствено вътре в кластера от подове и между такива клъстери, базирайки се на вътрешните IP таблици. И това кукиране работи перфектно, докато не ви потрябва достъп до сервизи извън.
Egress позволява да се заобиколят гореспоменатите IP таблици, или на база на правила Egress, или за диапазон от IP адреси.
Да кажем, че имаме Java програма, която извършва GET заявка към httpbin.org/headers.
(httpbin.org – това е просто удобен ресурс за тестване на изходящи сервизни заявки.)
Ако въведем в командния ред curl http://httpbin.org/headers, ще видим следното:
Или можем да отворим този адрес в браузъра:
Както виждаме, разположеният там сервиз просто връща предадените му заглавия.
Импортозаместяме направо
Сега ще вземем Java кода на този външен сервиз относно нашата система и ще го стартираме у нас, където, припомняме, има Istio. (Можете да направите това сами, като се обърнете към .) След като съберем съответния образ и го стартираме на платформата OpenShift, ще извикаме този сервиз с команда curl egresshttpbin-istioegress.$(minishift ip).nip.io, след което ще видим на екрана следното:
Опа, какво стана? Всичко работеше току-що. Какво означава Not Found? Току-що го направихме за него. curl.
Разширяваме IP таблиците за целия интернет
Трябва да се винят (или благодарят) за това на Istio. В крайна сметка Istio съществува просто като sidecar контейнери, които отговарят за откритие и маршрутизиране (и за много други неща, за които говорихме по-рано). Поради тази причина IP таблиците знаят само за това, което е вътре в системата на вашите клъстери. А httpbin.org е разположен навън и следователно е недостъпен. И тук на помощ идва Istio Egress – без никакви промени в вашия изходен код.
Следното Egress правило кара Istio да търси (ако е необходимо, и в целия интернет) нужния сервиз, в случая httpbin.org. Както се вижда от този файл (egress_httpbin.yml), функционалността тук е доста проста:
Остава само да приложим това правило:
istioctl create -f egress_httpbin.yml -n istioegress
Можете да прегледате правилата Egress с команда istioctl get egressrules:
И накрая, отново стартираме командата curl – и виждаме, че всичко работи:
Мислим открито
Както виждате, Istio позволява организирането на взаимодействие и с външния свят. С други думи, все още можете да създавате услуги OpenShift и да ги управлявате чрез Kubernetes, държейки всичко в pod’ове, които могат да се мащабират нагоре-надолу при необходимост. И по този начин спокойно можете да се обръщате към външни за вашата среда услуги. И да, отново да подчертаем, че всичко това можете да правите, без да засягате вашия код.
Това беше последният пост от серията за Istio. Останете с нас – предстои много интересно!
Източник: habr.com
