Здравейте, аз съм Дмитрий Краснов. Над пет години администрирам Kubernetes клъстери и създавам сложни микросервисни архитектури. В началото на тази година стартирахме услуга за управление на Kubernetes клъстери на базата на Containerum. Използвайки повода, ще споделя какво представлява самият Kubernetes и какво го различава от интеграцията с доставчици в сравнение с open source.
Първо, какво е . Това е система за управление на контейнери на голям брой хостове. От гръцки, между другото, се превежда като „пилот“ или „рулевой“. Първоначално разработена е от Google, след което е предадена на Cloud Native Computing Foundation, международна неправителствена организация, която обединява водещи световни разработчици, крайни потребители и доставчици на контейнерни технологии.
Да се управлява голям брой контейнери
Сега да разгледаме какво представляват тези контейнери. Това е приложение с всичките му зависимости – основно библиотеките, от които зависи работата на програмата. Всичко това е опаковано в архиви и представено под формата на образ, който може да се изкарва независимо от операционната система, да се тества и не само. Но има проблем – управлението на контейнери на голям брой хостове е много сложно. Затова е създаден Kubernetes.
Образът на контейнера представлява приложение плюс неговите зависимости. Приложението, зависимостите и образът на файловата система на ОС са разположени в различни части на образа, така наречените слоеве. Слоевете могат да се използват повторно за различни контейнери. Например, за всички приложения в компанията може да се използва основният слой Ubuntu. При стартиране на контейнерите не е нужно да се съхраняват на хоста множество копия на един основен слой. Това позволява оптимизиране на съхранението и доставката на образи.
Когато искаме да стартираме приложение от контейнер, нужните слоеве се наслагват един върху друг и се образува оверлейна файлова система. Отгоре се наслага слой за запис, който при спиране на контейнера се изтрива. Това гарантира, че при стартиране на контейнера приложението винаги ще има еднаква среда, която не може да бъде променена. Това осигурява възпроизводимост на средата на различни хостинг ОС. Било то Ubuntu или CentOS, – средата винаги ще бъде еднаква. Освен това контейнерът е изолиран от хоста с вградени в ядрото механизми на Linux. Приложенията в контейнера не виждат файловете, процесите на хоста и съседните контейнери. Тази изолация на приложенията от хостовата ОС предоставя допълнителен слой на сигурност.
За управление на контейнери на хоста има множество инструменти. Най-популярният от тях е Docker. Той позволява да се осигури пълен жизнен цикъл на работа с контейнери. Въпреки това, той работи само на един хост. При необходимост от управление на контейнери на множество хостове, Docker може да превърне живота на инженерите в ад. Затова и беше създаден Kubernetes.
Търсенето на Kubernetes именно се дължи на възможността да управлява групи от контейнери на множество хостове, като някакви единни същности. Популярността на системата осигурява възможност за изграждане на 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 съществуват услуги от тип Load Balancer. Те са предназначени за автоматична настройка на външен облачен балансировчик за всички работници в клъстера. Този външен балансировчик насочва външния трафик към работниците и сам следи за тяхното състояние. Ако един или повече работници станат недостъпни, трафикът се пренасочва към други. Това позволява създаването на високодостъпни услуги с помощта на Kubernetes.
Kubernetes се представя най-добре именно при стартиране на микросервизни архитектури. Внедряването на системата в класическа архитектура е възможно, но безсмислено. Ако приложението не може да работи в няколко реплики, каква е ползата – дали в Kubernetes или не?
Open source Kubernetes
Open source Kubernetes – страхотно нещо: инсталирано и работи. Може да се разположи на собствените железа, на собствената инфраструктура, да се постави майстор и работници, на които ще се стартират всички приложения. А най-важното – всичко това е безплатно. Въпреки това има нюанси.
- Първият – изискванията към знанията и опита на администраторите и инженерите, които ще разгръщат и поддържат всичко това. Тъй като клиентът получава пълна свобода на действие в клъстера, той носи отговорност за работоспособността на клъстера. А да счупите всичко тук е много лесно.
- Вторият – липсата на интеграции. Ако стартирате Kubernetes, без да имате някаква популярна платформа за виртуализация, няма да получите всички предимства на програмата. Като например използването на Persistent Volumes и Load Balancer услуги.
Рисунок 2. Архитектура на k8s
Kubernetes от доставчик
Интеграцията с облачен доставчик предлага две възможности:
- Първо, човек може просто да натисне бутона „създаване на клъстер“ и да получи вече конфигуриран и готов за работа клъстер.
- На второ място, доставчикът самостоятелно разполага клъстера и настройва интеграцията с облака.
Как това се случва при нас. Инженерът, който стартира клъстера, посочва колко работници му трябват и с какви параметри (например, 5 работници, всеки с 10 CPU, 16 GB RAM и, да кажем, 100 GB диск). След което получава достъп до вече формирания клъстер. При това работниците, на които се стартира натоварването, напълно се предоставят на клиента, но целият management plane остава в отговорността на доставчика (в случай, че услугата се предоставя по модел на управлявана услуга).
Но такава схема има своите недостаъци. Поради факта, че management plane остава при доставчика, той не предоставя пълен достъп на клиента, което намалява гъвкавостта при работа с Kubernetes. Понякога се случва клиентът да иска да прикрепи към Kubernetes някаква специфична функционалност, например, аутентификация чрез LDAP, а конфигурацията на management plane това не позволява.
Рисунок 3. Пример на клъстер Kubernetes от облачен доставчик
Какво да изберем: open source или доставчик
И така, open source Kubernetes или вендорски? Ако изберете open source Kubernetes, потребителят прави с него каквото поиска. Но рискува да си стреля в крака. С вендорския вариант това е по-трудно, защото всичко е обмислено и настроено от компанията. Най-големият недостатък на опен сорс Kubernetes е нуждата от специалисти. С вендорското решение компанията се избавя от тази болка в главата, но трябва да реши: да плаща на своите специалисти или на вендора.
Както и да е, плюсовете са очевидни, а минусите също са известни. Едно остава неизменно: Kubernetes решава много проблеми, автоматизирайки управлението на множество контейнери. А кой да изберете, open source или вендорски — всеки сам решава.
Статията е подготвена от Дмитрий Краснов, водещ архитект на услугата Containerum на доставчика #CloudMTS.
Източник: habr.com
