Защо е необходим Kubernetes и защо е повече от PaaS
Не само Docker, но и Kubernetes стигнаха до голямо производство. И ако дори с контейнери далеч не винаги всичко е съвсем просто, тогава „пилотът“ още повече остава извън границите на правилното разбиране сред много системни администратори, инженери на DevOps и разработчици. Тази кратка статия се опитва да отговори на един от вечните въпроси (в контекста на Kubernetes) с визуално обяснение на идеята и характеристиките на този проект. Може би това ви липсваше, за да започнете близко запознаване с Kubernetes или дори с неговата работа?
Съосновател и архитект на голяма онлайн услуга Box(около 1400 служители)Сам Годс, в своя разговор на KubeCon миналата година, посочи типично погрешно възприемане на Kubernetes. Мнозина смятат този продукт за друга рамка за оркестриране на контейнери. Но ако всичко наистина беше така, тогава защо разработчиците му неуморно ще напомнят за „корените на Kubernetes API, които се връщат към архитектурата*, която е създадена повече от 10 години като част от проекта Google Borg.“ Google Borg е мениджър на клъстери, предназначен да изпълнява хиляди задачи паралелно в хиляди приложения, работещи на множество клъстери. Именно тази архитектура Kubernetes наследява, пренасяйки идеите за клъстери в съвременната почва на контейнери. Как това е различно от многото облачни платформи, които съществуват днес? Нека започнем със самата концепция заплатформи.
* Архитектурата Kubernetes е проектирана да бъде разширяема, но от разработчиците се иска да следват основните принципи.
Kubernetes като платформа
Архитектът Бокс дава следното определение: „Платформаосигурява слой абстракция, който премахва проблема от вас, така че можете да създавате върху него [без да мислите за това].“ Примери: платформата Linux дава възможност за изпълнение на системни повиквания независимо от хардуера на компютъра, а платформата Java позволява изпълнението на приложения независимо от операционната система. Каква трябва да бъде платформата за стартиране на приложения, създадени според принципите на микросервизната архитектура?
Ключовите характеристики на такава платформа сапреносимост и разширяемост. Всяка облачна платформа предлага различни опции за постигане на тези цели. Например за автоматично мащабиране AWS има Auto Scaling Groups, Google Cloud Platform има Autoscaler, Microsoft Azure има Scale Set, OpenStack има API за автоматично мащабиране в Heat. Всичко това само по себе си не е лошо, т.к. нуждите са задоволени, но крайният потребител е в беда. За да хоства приложение, всеки доставчик на услуги трябва да поддържа своите механизми: да добави API поддръжка, да вземе предвид спецификата на използваната реализация и т.н. В допълнение, всички тези решения нямат система за откриване на услуги за наистина удобно и автоматизирано внедряване на микроуслуги. Но какво ще стане, ако трябва да сте гъвкави и да можете да хоствате приложения в различни среди (в публичния облак, във вашия собствен център за данни, на клиентски сървъри ...)?
Това е първият плюс и същност на Kubernetes като платформа, тоест една наистина универсална система за внедряване на приложения, чието физическо разполагане може да се извърши навсякъде и по всякакъв начин: на голо метално устройство, в публични или частни облаци, независимо от техните разработчици и специфични API. Но страхотното в Kubernetes е не самокъдеда стартирате, акакво:в крайна сметка това могат да бъдат приложения на различни езици и за различни операционни системи, те могат да бъдат без състояние и със състояние. Поддържа се принципът „ако едно приложение може да работи в контейнер, то трябва да работи добре в Kubernetes“.
Целта на Kubernetes като платформа е даосигури основна, абстрактна платформа като услуга (Platform as a Service, PaaS), като същевременно поддържа гъвкавостпри избора на специфичните компоненти на този PaaS.
Kubernetes и PaaS
- Kubernetes не предлага никакви вградени услуги за съобщения, обработка на данни, СУБД и др.
- Kubernetes няма собствен магазин с готови услуги за внедряване с едно кликване.
- Kubernetes не внедрява изходен код или създава приложения. Процесите на непрекъсната интеграция (CI) се поддържат, но внедряването им е оставено на други инструменти.
- По същия начин за системите за регистриране и наблюдение.
Заключение
По отношение на Kubernetes можем да кажем, че тази система еосновата, самата „стандартна библиотека“ за изграждане на PaaS и други подобни решения.