🥇Kubernetes: open source срещу лицензиран

Здравейте, казвам се Дмитрий Краснов. Вече близо пет години се занимавам с администриране на Kubernetes клъстери и изграждане на сложни микросервизни архитектури. В началото на тази година стартирахме услуга за управление на Kubernetes клъстери на базата на Containerum. Възползвайки се от възможността, ще разкажа какво представлява самият Kubernetes и с какво интеграцията с доставчик се различава от open source.

Първо, какво е Kubernetes. Това е система за управление на контейнери на голям брой хостове. На гръцки, между другото, се превежда като "пилот" или "рулевой". Първоначално разработен от Google, след което като технологичен принос беше предаден на Cloud Native Computing Foundation, международна неправителствена организация, която обединява водещите разработчици в света, крайни потребители и доставчици на контейнерни технологии.

Да управляваш голям брой контейнери

Сега да разберем какво представляват тези контейнери. Това е приложение с цялата му среда - главно библиотеките, от които зависи работата на програмата. Всичко това е опаковано в архиви и представено под формата на образ, който може да се стартира независимо от операционната система, да се тества и много други. Но има проблем - управлението на контейнери на голям брой хостове е много сложно. Затова беше създаден Kubernetes.

Образът на контейнера представлява приложение плюс неговите зависимости. Приложението, зависимостите му и образът на файловата система на ОС са разположени в различни части на образа, така наречените слоеве. Слойте могат да се преизползват за различни контейнери. Например, за всички приложения в компанията може да се използва базовият слой на Ubuntu. При стартиране на контейнерите няма нужда да се съхраняват на хоста множество копия на един и същ базов слой. Това позволява оптимизиране на съхранението и доставката на образи.

Когато искаме да стартираме приложение от контейнер, нужните слоеве се наслагват един върху друг и образуват overlay файлова система. Отгоре се наслагва слой за запис, който при спирането на контейнера се изтрива. Това гарантира, че при стартиране на контейнера приложението винаги ще има еднаква среда, която не може да бъде променена. Това осигурява воспроизводимост на средата на различни хостови ОС. Дали ще е Ubuntu или CentOS, - средата винаги ще е еднаква. Освен това контейнерът е изолиран от хоста чрез вградените в ядрото на Linux механизми. Приложенията в контейнера не виждат файловете, процесите на хоста и съседните контейнери. Тази изолация на приложенията от хостовата ОС предоставя допълнителен слой защита.

За управление на контейнерите на хоста съществуват множество инструменти. Най-популярният от тях е Docker. Той позволява да се осигури пълен жизнен цикъл на работа на контейнерите. Въпреки това той работи само на един хост. Когато е необходимо управление на контейнерите на множество хостове, Docker може да превърне живота на инжинерите в ад. Затова и беше създаден Kubernetes.

Търсеността на Kubernetes е точно обусловена от възможността да се управляват групи контейнерi на множество хостове като едно цяло. Популярността на системата осигурява възможност за изграждане на DevOps или Development Operations, в които Kubernetes се използва за стартиране на процесите на самия DevOps.

Рисунок 1. Схематично изображение на принципа на работа на Kubernetes.

Пълна автоматизация

DevOps, по същество, представлява автоматизация на процеса на разработка. Грубо казано, разработчиците пишат код, който се качва в хранилище. След това този код може автоматично да бъде компилиран в контейнер с всички библиотеки, тестван и "випускан" на следващия етап – Staging, а след това веднага и на Production.

Заедно с Kubernetes, DevOps позволява автоматизация на този процес, така че да протича почти без участието на самите разработчици. Това значително ускорява сборката, тъй като разработчикът не трябва да се занимава с това на своя компютър — той просто пише част от кода, качва кода в репозитория, след което се стартира pipeline, който може да включва процес на сборка, тестиране, внедряване. И така се случва с всяко комитване, поради което тестовете се извършват постоянно.

В същото време използването на контейнера гарантира, че цялата среда на тази програма ще излезе в продукция именно в същия вид, в който е била тествана. Тоест, няма да възникнат проблеми от рода на "на теста имаше едни версии, в продукция – други, и когато ги поставихме – всичко се срина". А тъй като днес имаме тенденция към микросервисна архитектура, когато вместо едно огромно приложение имаме стотици малки, за администрирането им ръчно се изисква огромен екип. Затова и използваме Kubernetes.

Плюсове, плюсове, плюсове

Ако говорим за предимствата на Kubernetes като платформа, то тя има съществени плюсове от гледна точка на управлението на микросервисна архитектура.

Управление на множество реплики. Най-важното е управлението на контейнерите на множество хостове. И още по-важно — управлението на множество реплики на приложенията в контейнерите като единна сущност. Благодарение на това инженерите не трябва да се притесняват за всеки отделен контейнер. Ако един от контейнерите се срине, Kubernetes ще го види и ще го рестартира.
Клъстерна мрежа. Също така, Kubernetes разполага с т. нар. клъстерна мрежа с собствено адресно пространство. Благодарение на това всеки под има свой адрес. Подът се разбира като минималната структурна единица на клъстера, в която се стартират контейнерите. Освен това Kubernetes предоставя функционалност, която обединява балансировчик на натоварването и Service Discovery. Това позволява да се избегне ръчното управление на IP адресите и да се прехвърли тази задача на Kubernetes. А автоматичните health check-ове помагат за откриването на проблеми и пренасочване на трафика към работещите подове.
Управление на конфигурации. Управлението на голям брой приложения затруднява конфигурирането им. За тази цел в Kubernetes има специални ресурси, известни като ConfigMap. Те позволяват централизирано съхраняване на конфигурации и тяхното подаване в подовете при стартиране на приложенията. Тази механика гарантира последователност на конфигурацията, независимо дали става дума за десет или сто реплики на приложения.
Постоянни томове. Контейнерите по своята същност са имутируеми и при спиране на контейнера всички данни, записани на файлова система, ще бъдат унищожени. Но някои приложения съхраняват данни директно на диска. За решаването на този проблем в Kubernetes има функционалност за управление на дисково хранилище — Постоянни томове. Тази механика използва външно хранилище за данни и може да предоставя постоянно хранилище, блочно или файлово, в контейнерите. Такова решение позволява съхраняване на данни отделно от работниците, което ги спасява при повреда на самите работници.
Балансировач на натоварването. Въпреки че в Kubernetes управляваме абстрактни сущности като Deployment, StatefulSet и др., в крайна сметка контейнерите стартират на обикновени виртуални машини или физически сървъри. Те не са безупречни и могат да се сринат по всяко време. Kubernetes ще забележи това и ще пренасочи вътрешния трафик към други реплики. Но какво да правим с трафика, който идва отвън? Ако просто насочим трафика към един от работниците, какво ще стане, ако той се срине и услугата стане недостъпна? За решаването на този проблем в Kubernetes има услуги като Баланизатор на натоварването. Те са предназначени за автоматична настройка на външния облачен балансировач към всички работници в клъстер. Този външен балансировач насочва външния трафик към работниците и следи тяхното състояние. Ако един или повече работници станат недостъпни, трафикът се пренасочва към други. Това позволява създаването на услуги с висока наличност с помощта на Kubernetes.

Kubernetes показва най-добри резултати при стартиране на микросервисни архитектури. Внедряването му в класическа архитектура е възможно, но нямя смисъл. Ако приложението не може да работи в няколко реплики, какво значение има - в Kubernetes ли е или не?

Open source Kubernetes

Open source Kubernetes – чудесна работа: инсталираш и работи. Може да се разгръща на собствените ти сървъри, на собствената ти инфраструктура, да се инсталира master и workers, на които ще се стартират всички приложения. И най-важното – всичко това е безплатно. Въпреки това, има нюанси.

Първият – изискванията към знанията и опита на администраторите и инженерите, които ще развиват и поддържат всичко това. Тъй като клиентът получава пълна свобода на действия в кластера, отговорността за работоспособността на кластера той носи сам. А да счупиш всичко тук е много просто.
Вторият – липсата на интеграции. Ако стартирате Kubernetes, без да имате някаква популярна платформа за виртуализация, няма да получите всички предимства на програмата. Като например използването на Persistent Volumes и услуги Load balancer.

Рисунок 2. Архитектура на k8s

Kubernetes от вендор

Интеграцията с облачен доставчик предоставя две възможности:

На първо място, човек може просто да натисне бутона „създай клъстер“ и да получи вече настроен и готов за работа клъстер.
На второ място, вендорът сам инсталира клъстера и настройва интеграцията с облака.

Как става при нас. Инженерът, който стартира клъстера, посочва колко работници му трябват и с какви параметри (например, 5 работници, всеки с 10 CPU, 16 GB оперативна памет и, да кажем, 100 GB диск). След което получава достъп до вече създадения клъстер. При това работниците, на които се пуска натоварването, напълно се предават на клиента, но целият management plane остава в зоната на отговорност на вендора (ако услугата е предоставена по модела managed service).

Въпреки това, тази схема има свои недостатъци. Заради това, че management plane остава при вендора, той не предоставя пълен достъп на клиента, което намалява гъвкавостта в работата с Kubernetes. Понякога се случва клиентът да желае да добави към Kubernetes някаква специфична функционалност, например, удостоверяване чрез LDAP, а конфигурацията на management plane не го позволява.

Рисунок 3. Пример за клъстер Kubernetes от облачен доставчик

Какво да изберете: open source или вендорски

И така, open source Kubernetes или лицензиран? Ако изберем open source Kubernetes, потребителят прави каквото иска. Но рискът да си навлече неприятности е голям. С лицензираната версия е по-сложно, защото всичко е предварително обмислено и настроено от компанията. Най-голямото предимство на open source Kubernetes е необходимостта от специалисти. С лицензираната версия компанията е освободена от това главоболие, но трябва да реши: да плаща на своите специалисти или на вендора.

Ну какво, предимствата са очевидни, недостатъците също са известни. Едно остава непроменено: Kubernetes решава много проблеми, автоматизирайки управлението на множество контейнери. Кой да изберем, open source или лицензиран, всеки сам взема решение.