Kubernetes е отличен инструмент за стартиране на Docker контейнери в клъстеризирана производствена среда. Въпреки това, съществуват задачи, които Kubernetes не може да реши. При често разгръщане в работна среда, ние имаме нужда от напълно автоматизирано Blue/Green разгръщане, за да избегнем престои в този процес, при който също трябва да обработваме външни HTTP заявки и да изпълняваме износа на SSL. Това изисква интеграция с балансировчик на натоварването, такъв като ha-proxy. Другата задача е полуавтоматично мащабиране на самия клъстер Kubernetes, когато работим в облачна среда, например частично намаляване на мащаба на клъстера през нощта.
Въпреки че Kubernetes няма тези функции право «от кутията», той предоставя API, чрез който може да се справим с подобни задачи. Инструменти за автоматизирано Blue/Green разгръщане и мащабиране на клъстера Kubernetes бяха разработени в рамките на проекта Cloud RTI, който беше създаден на базата на open-source.
В тази статия, въз основа на видео, се описва как да настроите Kubernetes заедно с други компоненти с отворен код, за да получите производствена среда, която без престои приема код от git commit.
И така, след като получите достъп до приложенията си от външния свят, можете да преминете към пълна настройка на автоматизацията, тоест да я доведете до фаза, в която можете да изпълните git commit и да се уверите, че този git commit завършва в производството. Естествено, при реализацията на тези стъпки, при осъществяване на разгръщането, не искаме да имаме престои. Така, всяка автоматизация в Kubernetes започва с API.
Kubernetes не е инструмент, който можете да използвате продуктивно «направо от кутията». Разбира се, можете да го правите, да използвате kubectl и така нататък, но все пак API е най-интригуващата и полезна част на тази платформа. Чрез използването на API като набор от функции, можете да получите достъп до почти всичко, което искате да направите в Kubernetes. Самият kubectl също използва REST API.
Това е REST, така че можете да използвате всякакви езици и инструменти, за да работите с този API, но персонализираните библиотеки значително ще улеснят живота ви. Моят екип написа две такива библиотеки: едната за Java / OSGi и едната за Go. Втората не се използва често, но все пак разполагате с тези полезни неща. Те представляват частично лицензиран open-source проект. Има много такива библиотеки за различни езици, така че можете да изберете най-подходящите.
И така, преди да започнете автоматизацията на разгръщането, трябва да се уверите, че този процес няма да бъде подложен на никакви забавяния. Например, нашият екип извършва production разгръщане в средата на деня, когато хората най-много използват приложенията си, затова е много важно да избегнем забавянето в този процес. За да избегнем прекъсвания, се използват два метода: blue/green разгръщане или rolling update. В последния случай, ако имате 5 реплики на приложението, те се обновяват последователно една след друга. Този метод работи чудесно, но не е подходящ, ако по време на разгръщането имате активни различни версии на приложението. В такъв случай можете да обновите потребителския интерфейс, докато бекендът работи със стара версия, и работата на приложението ще спре. Поради това, от програмна гледна точка, работата в такива условия е доста трудна.
Това е една от причините, поради които предпочитаме да използваме blue/green разгръщане за автоматизация на разгръщането на нашите приложения. При този метод трябва да се уверите, че в определен момент активна е само една версия на приложението.
Механизмът на blue/green разгръщането изглежда по следния начин. Получаваме трафик за нашите приложения през ha-proxy, който го насочва към активни реплики на приложението със същата версия.
Когато се извършва ново разширение, използваме Deployer, който получава нови компоненти, след което той извършва внедряването на новата версия. Внедряването на новата версия на приложението означава, че нов набор от реплики се „вдига“, след което тези реплики на новата версия се стартират в отделен, нов под. Въпреки това, ha-proxy не знае нищо за тях и засега не насочва към тях никаква работна натовареност.
Затова на първо място е необходимо да извършим проверка на работоспособността на новите версии чрез health checking, за да се уверим, че репликите са готови да обслужват натоварването.
Всички компоненти на разширението трябва да поддържат някаква форма на health check. Това може да бъде съвсем проста проверка чрез HTTP повикване, когато получавате код със статус 200, или по-дълбока проверка, при която проверявате свързаността на репликите с базата данни и другите услуги, устойчивостта на връзките в динамичната среда, и дали всичко се стартира и работи по правилния начин. Този процес може да бъде доста сложен.
След като системата се увери в работоспособността на всички актуализирани реплики, Deployer ще обнови конфигурацията и ще предаде правилния confd, който ще пренастрои ha-proxy.
Само след това трафикът ще бъде насочен към пода с реплики на новата версия, а старият под ще изчезне.
Т този механизъм не е особеност на Kubernetes. Концепцията за Blue/green deployment съществува от доста време и винаги е използвала балансировчик на натоварването. Първо насочвате целия трафик към старата версия на приложението, а след обновлението напълно го прехвърляте на новата версия. Този принцип се използва не само в Kubernetes.
Сега ще ви представя новия компонент за разширение – Deployer, който извършва проверка на работоспособността, ре-конфигурира проксито и така нататък. Това е концепт, който не е свързан с външния свят и съществува вътре в Kubernetes. Ще покажа как можете да създадете собствен концепт Deployer с помощта на open-source инструменти.
И така, първото нещо, което Deployer прави, е да създаде контролер за репликация RC, използвайки API на Kubernetes. Този API създава подове и услуги за последващо разгръщане, т.е. създава напълно нов клъстер за нашите приложения. След като RC се убеди, че репликите са стартирали, той извършва проверка на работоспособността им (Health check). За това в Deployer се използва команда GET /health. Тя стартира съответните компоненти на проверката и проверява всички елементи, осигуряващи функционирането на клъстера.
След като всички подове потвърдят своето „здраве“, Deployer създава нов елемент от конфигурацията – разпределено хранилище etcd, което се използва в Kubernetes, включително за съхранение на конфигурацията на балансировщика на натоварването. Записваме данни в etcd, а малкият инструмент confd следи etcd за появата на нови данни.
Ако установи някакви промени в началната конфигурация, генерира нов файл с настройки и го предава на ha-proxy. В този случай ha-proxy се рестартира без загуба на каквито и да било съединения и адресира натоварването на новите услуги, които осигуряват работата на новата версия на нашите приложения.
Както виждате, въпреки множество компоненти, тук няма нищо сложно. Просто трябва да обърнете повече внимание на API и etcd. Искам да ви разкажа за open-source деплойера, който ние сами използваме – Amdatu Kubernetes Deployer.
Това е инструмент за оркестрация на разгръщания в Kubernetes, който предлага следните функции:
- разгръщане Blue/Green deployment;
- настройка на външен балансировщик на натоварването;
- управление на дескриптори за разгръщане;
- управление на действителното разгръщане;
- проверка на работоспособността (Health checks) по време на разгръщането;
- внедряване на променливи среди в подовете.
Този Deployer е създаден върху Kubernetes API и предоставя REST API за управление на дескриптори и разгръщания, както и Websocket API за стрийминг на логове по време на разгръщането.
Той поставя данните за конфигурация на балансировщика на натоварването в etcd, така че можете да не използвате ha-proxy с поддръжка „направо от кутията“, а лесно да използвате своя собствен файл с конфигурация на балансировщика. Amdatu Deployer е написан на Go, както и самият Kubernetes, и е лицензирани Apache.
Преди да започна да използвам тази версия на деплойера, приложих следния дескриптор за разгръщане, в който са посочени нужните ми параметри.
Един от важните параметри на този код е активирането на флага "useHealthCheck". Трябва да посочим, че по време на разгръщането трябва да се извършва проверка на работоспособността. Този параметър може да бъде деактивиран, когато в разгръщането се използват контейнери на трети страни, които не е необходимо да се проверяват. В този дескриптор също е посочен брой на репликите и URL на фронтенда, който е необходим за ha-proxy. В края е посочен флагът на спецификацията на пода "podspec", който се обръща към Kubernetes за информация относно настройките на портовете, образа и т.н. Това е достатъчно прост дескриптор в JSON формат.
Още един инструмент, който е част от open-source проекта Amdatu, е Deploymentctl. Той има потребителски интерфейс UI за конфигуриране на разгръщането, съхранява историята на разгръщането и включва webhook-и за обратни повиквания от трети потребители и разработчици. Можете да не използвате UI, тъй като самият Amdatu Deployer е REST API, но този интерфейс може значително да улесни разгръщането без нужда от конкретно API. Deploymentctl е написан на OSGi/Vertx, използвайки Angular 2.
Сега ще демонстрирам казаното по-горе на екрана, използвайки предварително записано видео, така че да не трябва да чакате. Ще разгръщаме просто приложение на Go. Не се безпокойте, ако не сте работили с Go преди, това е много просто приложение, така че всичко ще ви е ясно.
Тук създаваме HTTP-сървър, който отговаря само на "/health", така че това приложение проверява само работоспособността на health check и нищо повече. Ако проверката е успешна, се активира JSON структурата, показана по-долу. Тя съдържа версията на приложението, което ще бъде разгръщано от деплойера, съобщението, което виждате в горната част на файла, и булевия тип данни — работоспособно ли е нашето приложение.
С последния ред се поизлъгах малко, тъй като поставих в горната част на файла фиксирана стойност булеан, която по-късно ще ми помогне да разгръщам дори "нездраво" приложение. По-късно ще се справим с това.
Така че, нека да започнем. Първо проверяваме за наличието на активни подове с командата ~ kubectl get pods и при липсата на отговор от URL на фронтенда се уверяваме, че в момента няма разгръщания.
На екрана виждате лавния интерфейс Deploymentctl, в който се задават параметрите за разгръщане: пространство от имена, име на приложението, версия на разгръщането, брой реплики, фронтенд-URL, име на контейнера, образ, лимити на ресурсите, номер на порта за проверка на health check и т.н. Лимитите на ресурсите са много важни, тъй като позволяват максимално използване на наличното „железо“. Тук можете също да прегледате журнала на разгръщането Deployment log.
Ако сега повторим командата ~ kubectl get pods, е видно, че системата „замръзва“ за 20 секунди, в процеса на които се извършва реконфигурация на ha-proxy. След това подът се стартира и можем да видим нашата реплика в журнала на разгръщането.
Изрязах 20-секундното изчакване от видеото и сега на екрана виждате, че първата версия на приложението е разгръщена. Всичко това беше извършено само с помощта на потребителския интерфейс.
Сега нека да опитаме втората версия. За това променям съобщението на приложението от „Hello, Kubernetes!“ на „Hello, Deployer!“, системата създава този образ и го поставя в Docker регистъра, след което просто отново натискаме бутона „Deploy“ в прозореца на Deploymentctl. При това автоматично се стартира дневника на разгръщането, точно както стана при разгръщането на първата версия на приложението.
Командата ~ kubectl get pods показва, че в момента работят 2 версии на приложението, но фронтендът показва, че все още работи версия 1.
Балансирът на натоварването изчаква, докато бъде извършена проверка на здравето, след което ще пренасочи трафика към новата версия. След 20 секунди преминаваме на curl и виждаме, че сега е разгръщена версия 2 на приложението, а първата е изтрита.
Това беше разгръщането на „здраво“ — healthy — приложение. Нека да видим какво ще се случи, ако променя стойността на параметъра Healthy за новата версия на приложението от true на false, тоест ще опитам да разгръщам нездраво приложение, което не е преминало проверката за работоспособност. Това може да се случи, ако в етапа на разработване в приложението са допуснати някои конфигурационни грешки и то по такъв начин е изпратено в продукция.
Както виждате, разгръщането преминава през всички горепосочени етапи и ~ kubectl get pods показва, че и двете пода са активни. Но в противоречие на предишното разгръщане, логовете показват състояние timeout. Тоест, поради факта, че проверката на health check не е преминала, новата версия на приложението не може да бъде разгръщена. В резултат на това виждате, че системата е върната обратно на старата версия на приложението, а новата версия е била просто премахната.
Добрата новина е, че дори и да имате огромно количество паралелни заявки, постъпващи в приложението, те дори не ще усетят забавяне по време на разгръщането. Ако тествате това приложение с помощта на фреймуърка Gatling, който изпраща максимално възможно количество заявки, нито една от тези заявки няма да бъде отхвърлена. Това означава, че нашите потребители дори няма да забележат актуализациите на версиите в реално време. Ако актуализацията се провали, работата ще продължи на старата версия, а ако е успешна – потребителите ще преминат на новата версия.
Съществува само едно нещо, което може да доведе до провал – ако проверката на health check е преминала успешно, а приложението се провали, когато получи работна натовареност, т.е. колапсът ще настъпи само след завършването на разгръщането. В този случай ще трябва ръчно да се върнете на старата версия. И така, разгледахме как да използваме Kubernetes с предназначените за него open-source инструменти. Процедурата по разгръщане ще протече много по-лесно, ако интегрирате тези инструменти в конвейерите за Build/Deploy. При това можете да използвате както потребителския интерфейс, така и напълно да автоматизирате този процес, например, чрез commit to master.
Нашият Build Server ще създаде Docker изображение, ще го качи в Docker Hub или в друг регистър, който използвате. Docker Hub поддържа webhook, така че можем да стартираме дистанционно разгръщане чрез Deployer, както описахме по-горе. По този начин е възможно напълно да автоматизирате разгръщането на приложението в потенциален продукционен режим.
Да преминем към разглеждане на следващата тема - мащабиране на Kubernetes клъстера. Забелязвам, че командата kubectl е команда за мащабиране. С нея е лесно да увеличите броя на репликите в нашия съществуващ клъстер. Въпреки това, на практика обикновено искаме да увеличим броя на нодовете, а не на подовете.
През работното време може да ви е необходимо увеличаване, а през нощните часове, за намаляване на разходите за услуги на Amazon - намаляване на броя на активните инстанции на приложението. Това не означава, че е достатъчно да мащабирате само броя на подовете, защото дори ако един от нодовете е незает, все пак ще трябва да плащате за него на Amazon. Тоест, наред с мащабирането на подовете, ще се наложи да мащабирате и броя на използваните машини.
Това може да създаде трудности, защото независимо дали използваме Amazon или друга облачна услуга, Kubernetes не знае колко машини се използват. В него липсва инструмент, който позволява мащабиране на системата на ниво нодов.
Така че ще трябва да се погрижим и за нодовете, и за подовете. Можем лесно да мащабируеме стартирането на нови нодовe чрез AWS API и машините от групата за мащабиране на Scaling group за настройване на броя на работните узли на Kubernetes. Може също да се използва cloud-init или подобен скрипт за регистрация на нодовете в Kubernetes клъстера.
Новата машина стартира в групата за мащабиране, инициира се като нод, регистрира се в майсторския регистър и започва работа. След това можете да увеличите броя на репликите за използване на образувалите се ноди. Намаляването на мащаба изисква повече усилия, тъй като е необходимо да се уверите, че подобна стъпка няма да доведе до унищожаване на вече работещи приложения след изключването на "непотребни" машини. За предотвратяване на такъв сценарий е нужно да се поставят нодите в статус "unschedulable". Това означава, че планировчикът по подразбиране при планирането на подовете DaemonSet ще игнорира тези ноди. Планировчикът няма да премахне нищо от тези сървъри, но и няма да стартира нови контейнери на тях. Следващата стъпка е изтласкването на узела drain node, тоест преносът на работещите подове от него на друга машина или на други ноди, които разполагат с достатъчен капацитет. Убедили се, че на тези нодове вече няма контейнери, те могат да бъдат премахнати от Kubernetes. След това за Kubernetes те просто ще престанат да съществуват. Следва да използвате AWS API за изключване на ненужните ноди или машини.
Можете да използвате Amdatu Scalerd — още един open-source инструмент за мащабиране, аналогичен на AWS API. Той предоставя CLI за добавяне или премахване на ноди в клъстера. Интересна черта е възможността за конфигуриране на планировчика с помощта на следния json-файл.
Изображеният код наполовина намалява капацитета на клъстера през нощния период. В него е настроено както текущото количество реплики, така и желаната капацитет на класта Amazon. Използването на този планировчик автоматично ще намали броя на узелите през нощта и ще ги увеличи сутринта, позволявайки спестяване на разходите за използването на нодове в облачната услуга на Amazon. Тази функция не е вградена в Kubernetes, но използването на Scalerd ще ви позволи да мащабирате тази платформа по какъвто и да е начин.
Искам да насоча вниманието ви към факта, че много хора ми казват: «Всичко това звучи добре, но какво да кажем за моята база данни, която обикновено е в статично състояние?» Как можем да стартираме нещо подобно в динамичната среда на Kubernetes? Според мен, не трябва да го правите, не трябва да се опитвате да организирате работата на хранилището на данни в Kubernetes. Технически е възможно, и в интернет има ръководства за това, но това значително ще усложни живота ви.
Да, в Kubernetes съществува концепция за постоянни хранилища, и можете да се опитате да стартирате такива хранилища на данни като Mongo или MySQL, но това е доста трудоемка задача. Това се дължи на факта, че хранилищата на данни не напълно поддържат взаимодействието с динамична среда. Повечето бази данни изискват значителна конфигурация, включително ръчна настройка на кластера, не обичат автоматично мащабиране и други подобни неща.
Затова не усложнявайте живота си, опитвайки се да стартирате хранилище на данни в Kubernetes. Организирайте работата им по традиционен начин, използвайки обичайните услуги и просто предоставете на Kubernetes възможността да ги използва.
В заключение на темата искам да ви запозная с платформата Cloud RTI на база Kubernetes, върху която работи моят екип. Тя осигурява централизирано водене на логове, мониторинг на приложения и клъстери и разполага с много други полезни функции, които ще ви бъдат от полза. В нея се използват различни open-source инструменти, като Grafana за визуализиране на мониторинга.
Постъпи въпрос, защо да използваме балансировчик на натоварването ha-proxy с Kubernetes. Добър въпрос, защото в момента съществуват два слоя на балансировка на натоварването. Услугите на Kubernetes все още са на виртуални IP адреси. Не можете да ги използвате за портове на външни хост-машини, защото ако Amazon презареди своя облачен хост, адресът ще се промени. Затова разположихме ha-proxy пред услугите — за да създадем по-статична структура за безпроблемно взаимодействие на трафика с Kubernetes.
Още един добър въпрос – как да се погрижим за промяната на схемата на базата данни при извършване на blue/green deployment? Факт е, че независимо от използването на Kubernetes, променянето на схемата на базата данни е сложна задача. Нужно е да осигурите съвместимост между старата и новата схема, след което можете да актуализирате базата данни и след това самите приложения. Можете да извършите "гореща смяна" на базата данни и след това да актуализирате приложенията. Знам хора, които са зареждали съвсем нов клъстер на базата данни с нова схема; това е опция, ако разполагате със schemeless база данни като Mongo, но каквато и да е ситуацията, това не е лесна задача. Ако нямате повече въпроси, благодаря за вниманието!
Малко реклама 🙂
Благодаря, че оставате с нас. Харесвате ли нашите статии? Искате ли да видите повече интересни материали? Подкрепете ни, като направите поръчка или я препоръчате на познати, , уникален аналог на entry-level сървъри, създаден от нас за Вас: (налични опции с RAID1 и RAID10, до 24 ядра и до 40GB DDR4).
Dell R730xd два пъти по-евтин в дата-центъра Equinix Tier IV в Амстердам? Само при нас в Нидерландия! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — от $99! Четете за това
Източник: habr.com
