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