Kubernetes е отличен инструмент за стартиране на Docker контейнери в клъстеризирана производствена среда. Въпреки това, има задачи, които Kubernetes не може да реши. При честото разгръщане в работна среда, ние се нуждаем от напълно автоматизиран Blue/Green deployment, за да избегнем престои в този процес, при който също е необходимо да обработваме външни 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, но потребителските библиотеки значително ще улеснят живота ви. Моят екип е написала 2 такива библиотеки: една за Java / OSGi и една за Go. Втората не се използва често, но все пак имате на разположение тези полезни неща. Те представляват частично лицензиран open-source проект. Има много такива библиотеки за различни езици, така че можете да изберете най-подходящите.
Така че, преди да започнете автоматизация на внедряването, е необходимо да се уверите, че този процес няма да бъде изложен на никакви простоеве. Например, нашият екип извършва продукционно внедряване по време на деня, когато хората максимално използват приложенията, така че е много важно да се избегнат забавяния в този процес. За да се избегнат простоеве, се използват 2 метода: 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 с помощта на инструменти с отворен код.
И така, първото, което прави Deployer, е да създаде контролер за репликация (RC), използвайки Kubernetes API. Този 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) за конфигуриране на разгръщането, съхранява историята на разгръщанията и съдържа уебхукове за обратни повиквания от трети страни и разработчици. Можете да не използвате UI, тъй като самият Amdatu Deployer е REST API, но този интерфейс може значително да улесни разгръщането без необходимост от привличане на какъвто и да е API. Deploymentctl е написан на OSGi/Vertx, използвайки Angular 2.
Сега ще демонстрирам казаното на екрана, използвайки предварително направен запис, така че да не се налага да чакате. Ще разгръщаме просто приложение на Go. Не се тревожете, ако преди не сте работили с Go, това е много просто приложение, така че всичко трябва да ви бъде ясно.
Тук създаваме HTTP-сървър, който отговаря само на /health, така че това приложение единствено проверява работоспособността и нищо повече. Ако проверката е успешна, се активира показаната по-долу JSON структура. Тя съдържа версията на приложението, което ще бъде разгръщано от деплойвера, съобщението, което виждате в горната част на файла, и логическият тип данни boolean — работи ли нашето приложение или не.
С последната редица малко се схитрих, защото поставих в горната част на файла фиксирано логическо значение, което по-късно ще ми помогне да разгръщам дори „нездраво“ приложение. По-късно ще се занимаем с това.
Нека да започнем. Първо проверяваме наличието на запуснати подове с командата ~ kubectl get pods и по отсъствието на отговор от URL на фронтенда се уверяваме, че в момента не се извършват разгръщания.
След това на екрана виждате интерфейса Deploymentctl, който задава параметрите на разгръщането: пространство от имена, име на приложението, версия на разгръщането, брой реплики, фронтенд-URL, име на контейнера, образ, лимити на ресурсите, номер на порта за проверка на работоспособността и т.н. Лимитите на ресурсите са много важни, тъй като позволяват да се използва максимално възможното количество „желязо“. Тук може да прегледате и дневника на разгръщането Deployment log.
Ако сега повторим командата ~ kubectl get pods, ще видим, че системата „замръзва“ за 20 секунди, в процеса на които се извършва реконфигурация на ha-proxy. След това подът стартира и нашата реплика може да бъде видяна в дневника на разгръщането.
Изрязах 20-секундното чакаме от видеото и сега виждате на екрана, че първата версия на приложението е разгръщена. Всичко това беше направено само с помощта на UI.
Сега нека да опитаме втората версия. За целта променям съобщението на приложението от „Hello, Kubernetes!“ на „Hello, Deployer!“, системата създава този образ и го поставя в Docker регистъра, след което просто отново натискаме бутона „Deploy“ в прозореца Deploymentctl. При това автоматично се стартира дневникът на разгръщането точно както при разгръщането на първата версия на приложението.
Командата ~ kubectl get pods показва, че в момента са стартирани 2 версии на приложението, обаче фронтендът показва, че все още работи версия 1.
Балансирът на натоварването очаква, докато бъде проведена проверка на работоспособността, след което ще пренасочи трафика към новата версия. След 20 секунди преминаваме на curl и виждаме, че сега имаме разгръщане на 2 версия на приложението, а първата е изтрита.
Това беше разгръщането на „здраво“ приложение. Нека да видим какво ще се случи, ако за новата версия на приложението променя стойността на параметъра Healthy от true на false, т.е. опитам да разгръщам нездраво приложение, което не е преминало проверката за работоспособност. Това може да се случи, ако на етапа на разработка в приложението са направени някакви конфигурационни грешки и то в такъв вид е изпратено в продукция.
Както виждате, разгръщането преминава всички изброени етапи и командата ~ kubectl get pods показва, че и двата пода са стартирани. Но в противовес на предишното разгръщане, логовете показват състояние timeout. Това означава, че поради неуспешната проверка на здравословното състояние, новата версия на приложението не може да бъде разгръщана. В резултат на това виждате, че системата се е върнала към старата версия на приложението, а новата версия е била просто премахната.
Хубавото е, че дори и да имате огромно количество паралелни заявки, идващи в приложението, те дори няма да забележат прекъсването по време на изпълнението на процедурата по разгръщане. Ако тествате това приложение с помощта на фреймворка Gatling, който му изпраща максимално количество заявки, нито една от тези заявки няма да бъде отхвърлена. Това означава, че нашите потребители дори няма да забележат обновленията на версиите в реално време. Ако нещо не върви, работата продължава със старата версия; ако е успешно – потребителите преминават на новата версия.
Съществува само едно нещо, което може да доведе до неуспех – ако проверката на здравословното състояние е успешна, а приложението се провали, веднага щом получи работната натовареност, тогава колапсът ще настъпи само след приключване на разгръщането. В този случай ще трябва ръчно да се върнете на старата версия. И така, разгледахме как да използвате Kubernetes с предназначените за него open-source инструменти. Процедурата по разгръщане ще протича много по-лесно, ако интегрирате тези инструменти в конвейери за създаване/разгръщане Build/Deploy pipelines. За стартиране на разгръщането можете да използвате както потребителски интерфейс, така и напълно да автоматизирате този процес, като приложите, например, commit to master.
Нашият сървър за изграждане Build Server ще създаде Docker образ, ще го постави в Docker Hub или в друг регистър, който ползвате. Docker Hub поддържа webhook, така че можем да стартираме отдалечено разгръщане чрез Deployer по описания по-горе начин. По този начин може да се автоматизира напълно разгръщането на приложението в потенциална производствена среда.
Нека да разгледаме следващата тема – мащабиране на Kubernetes клъстери. Искам да подчертая, че командата kubectl е инструмент за мащабиране. С нея можем лесно да увеличим броя на репликите в наличния ни клъстер. Въпреки това, в практиката обикновено искаме да увеличаваме броя на нодовете, а не на подовете.
През работното време може да е необходимо увеличение, а през нощта, за да се намалят разходите на Amazon – намаление на броя на активните инстанции на приложението. Това не означава, че е достатъчно да се мащабира само броя на подовете, защото дори ако един от нодовете е празен, все пак ще трябва да плащате за него на Amazon. Тоест заедно с мащабирането на подовете, ще ни е нужно да направим и мащабиране на броя на използваните машини.
Това може да създаде затруднения, защото независимо дали използваме Amazon или друг облачен сервис, Kubernetes не знае нищо за броя на използваните машини. Няма инструмент, който да позволява мащабиране на системата на ниво нодовете.
Така че ще трябва да се погрижим за нодовете и подовете. Можем лесно да мащабираме стартирането на нови нодове чрез AWS API и машинни групи за мащабиране за настройка на броя работещи узли в Kubernetes. Също така можем да използваме cloud-init или подобен скрипт за регистрация на нодовете в Kubernetes клъстера.
Новата машина стартира в група за мащабиране, инициира се като нод, регистрира се в мастър регистъра и започва работа. След това можете да увеличите броя на репликите, за да се възползвате от новосъздадените ноди. Намаляването на мащаба изисква повече усилия, тъй като е необходимо да се уверите, че тази стъпка няма да доведе до унищожаване на вече работещите приложения след изключването на "ненужните" машини. За да предотвратите такъв сценарий, е нужно да доведете нодовете до статус "unschedulable". Това означава, че планировчикът по подразбиране при планиране на подове DaemonSet ще игнорира тези ноди. Планировчикът няма да изтрива нищо от тези сървъри, но няма да стартира нови контейнери. Следващата стъпка е да се извърши дренаж на нода, т.е. да се прехвърлят работещите подове на друга машина или други ноди с достатъчен капацитет за това. След като се уверите, че на тези ноди няма повече контейнери, те могат да бъдат изтрити от 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 за визуализация на мониторинга.
Зададе се въпросът, защо да използваме HAProxy за балансировка на натоварването с Kubernetes. Добър въпрос, защото в момента съществуват два нива на балансировка на натоварването. Сервизите на Kubernetes все още са на виртуални IP адреси. Не можете да ги използвате за портовете на външни хост-машини, защото ако Amazon презареди своя облачен хост, адресът ще се промени. Затова поставяме HAProxy пред сервизите — за да създадем по-статична структура за непрекъсната работа на трафика с Kubernetes.
Още един добър въпрос – как можем да се справим с промените в схемата на базата данни при blue/green deployment? Истината е, че независимо от използването на Kubernetes, промяната на схемата на базата данни е сложна задача. Трябва да осигурите съвместимост между старата и новата схема, след което можете да обновите базата данни и след това самите приложения. Можете да извършите "гореща смяна" на базата данни, а след това да aktualizirate приложенията. Зная за хора, които са зареждали съвсем нов клъстер на базата данни с нова схема, това е вариант, ако разполагате с 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
