Съвременните приложения рядко се състоят от един процес, работещ на една машина. Обикновено те включват няколко компонента, като API, потребителски интерфейс, база данни и фонови процеси, които трябва да работят надеждно в различни среди. Контейнерите улесняват пакетирането и стартирането на тези компоненти, но с разрастването на инфраструктурата тяхното управление става по-сложно.

При повече натоварвания вече трябва да се мисли за скалиране, възстановяване при откази, разпределение на ресурсите и внедряване на нови версии без ненужни прекъсвания. Именно тук се открояват разликите между Docker и Kubernetes. Двете технологии решават различни задачи и изборът между тях зависи най-вече от мащаба и изискванията на конкретното приложение.

Какво представлява контейнеризацията и защо се използва?

Приложенията зависят от библиотеки, среди за изпълнение (runtime), системни пакети и конфигурации. Разликите между средите за разработка, тестване и продукция могат да доведат до ситуации, в които едно и също приложение работи по различен начин. Контейнеризацията решава голяма част от този проблем, като пакетира приложението и необходимите му зависимости в преносима и стандартизирана среда.

Еднаква среда за приложението

Контейнерният образ (container image) съдържа кода на приложението и необходимите му зависимости. Той може да бъде изграден веднъж и след това използван при разработка, тестване и внедряване, без средата да се пресъздава ръчно на всяка машина.

Изолиране на зависимостите

Различните приложения могат да използват различни версии на едни и същи библиотеки и компоненти. Контейнерите ги изолират едно от друго, което намалява риска от конфликти и позволява всяко приложение да използва необходимите му зависимости.

По-предвидимо внедряване

Използването на един и същ контейнерен образ в различните етапи прави внедряването по-предвидимо. Конфигурациите, чувствителните данни (secrets), мрежовите настройки и постоянните данни все още се управляват отделно, но средата за изпълнение на самото приложение остава последователна.

Кога контейнерите вече не са достатъчни?

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

При по-малки среди тези процеси могат да се управляват сравнително лесно. Когато обаче приложенията работят на множество машини и броят на контейнерите нараства, координацията между тях става значително по-сложна. Именно тук възниква необходимостта от инструменти за оркестрация като Kubernetes.

Каква е разликата между Docker и Kubernetes?

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

Docker създава и стартира контейнери

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

Kubernetes управлява контейнерите в клъстер

Kubernetes добавя следващото ниво на управление, когато контейнеризираните приложения трябва да работят на множество машини. Вместо всяка инстанция да се управлява ръчно, се задава желаното състояние (desired state), което Kubernetes автоматично се стреми да поддържа. Платформата може да разпределя натоварванията между различни машини, да поддържа необходимия брой реплики, да възстановява отказали компоненти и да управлява актуализациите.

Пример от практиката: ресторант с една или няколко кухни

Представете си ресторант, в който всяко ястие се приготвя на предварително организирана работна станция с необходимите продукти, инструменти и инструкции. Docker изпълнява подобна роля при приложенията: осигурява стандартизирана среда, в която всеки компонент разполага с необходимото, за да работи.

Ако ресторантът има само една кухня и сравнително малко поръчки, управлението е лесно. Но представете си верига с няколко кухни и стотици поръчки. Някой трябва да решава коя кухня да поеме всяка поръчка, да пренасочва работата при проблем, да добавя капацитет при натоварване и да следи необходимият брой работни станции да бъде винаги наличен.

Това е ролята на Kubernetes. Docker осигурява средата, в която отделните приложения могат да работят, а Kubernetes координира множество такива натоварвания и определя къде и как да бъдат изпълнявани.

Как работи Docker на практика?

Docker позволява приложението да бъде пакетирано в контейнерен образ и след това стартирано по един и същ начин в различни среди. Процесът обхваща няколко основни стъпки.

Създаване на контейнерен образ

Dockerfile описва как да бъде изграден контейнерният образ, включително необходимата среда, зависимости и файлове на приложението. След това образът може да бъде съхранен в container registry и използван за разработка, тестване или продукция.

Стартиране и управление на контейнери

Docker Engine използва контейнерните образи, за да създава и управлява контейнери. Те могат лесно да бъдат стартирани, спрени или заменени с нова версия, без приложението да се променя директно върху хост-а.

Свързване на услуги и съхранение на данни

Docker предоставя мрежи за комуникация между отделните услуги и volumes за постоянно съхранение на данни. Така например приложението може да комуникира с база данни, без съхраняваната информация да зависи от жизнения цикъл на конкретен контейнер.

Управление на няколко услуги с Docker Compose

Когато приложението включва няколко свързани услуги, Docker Compose позволява те да бъдат описани и управлявани заедно. Един Compose файл може да дефинира контейнерите, мрежите, volumes и основните им настройки, така че цялата среда да се стартира като едно цяло.

Примера с ресторанта

Ако се върнем към примера с ресторанта, Dockerfile може да се сравни с инструкцията как да бъде подготвена една работна станция: какво оборудване, продукти и инструменти са необходими. Контейнерният образ е готовият модел на тази станция, а Docker позволява тя да бъде създадена и използвана винаги по един и същ начин.

Когато ресторантът се нуждае от няколко свързани станции, например за основни ястия, напитки и десерти, Docker Compose определя как те да бъдат организирани и да работят заедно. Това е удобно, докато всичко се управлява в рамките на една кухня.

Как Kubernetes управлява контейнерите в клъстер?

Когато контейнерите работят на множество машини, те трябва да бъдат разпределяни, свързвани, скалирани и възстановявани при проблем. Kubernetes автоматизира голяма част от тези задачи, като поддържа предварително зададеното състояние на приложенията.

Поддържане на желаното състояние

В Kubernetes се задава желаното състояние (desired state) на приложението, например използваният контейнерен образ, необходимият брой реплики и ресурсите. Ако реалното състояние се промени, платформата предприема действия, за да го възстанови.

Разпределяне на натоварванията

Kubernetes разпределя натоварванията между наличните машини (nodes) в клъстера според необходимите ресурси и зададените правила. Така не е необходимо всяка инстанция да бъде разпределяна ръчно.

Скалиране и възстановяване

Kubernetes може да поддържа необходимия брой реплики, да заменя отказали Pods и да премества натоварвания между различни nodes. Реалната устойчивост обаче зависи и от архитектурата на приложението, конфигурацията и инфраструктурата.

Свързване на услугите

Kubernetes Services осигуряват стабилен начин за комуникация между приложенията, дори когато отделните Pods се заменят или преместват и техните IP адреси се променят.

Контролирани актуализации

Kubernetes може постепенно да заменя работещите инстанции с нови версии чрез rolling updates. При проблем внедряването може да бъде върнато към предишна версия (rollback), без всички контейнери да се управляват ръчно.

Основното предимство на Kubernetes е именно тази автоматизирана координация. Вместо екипът да управлява всеки контейнер поотделно, платформата се грижи приложенията в клъстера да работят според предварително зададените изисквания.

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

Как Docker и Kubernetes работят заедно?

Docker и Kubernetes могат да бъдат част от един и същ процес. Docker се използва за създаване и тестване на контейнерния образ, който след това може да бъде съхранен в container registry и внедрен в Kubernetes клъстер.

Dockerfile → Image → Registry → Kubernetes → Pod

С други думи, Docker подготвя приложението за работа в контейнер, а Kubernetes управлява къде и как то ще работи в клъстера.

Пример с ресторанта

Ако продължим аналогията с ресторанта, Docker определя как да бъде подготвена всяка работна станция, а Kubernetes организира работата на тези станции между различните кухни. Едното стандартизира отделната среда, а другото координира работата в по-голям мащаб.

Kubernetes все още ли използва Docker?

Не като вграден container runtime. Поддръжката на dockershim беше премахната в Kubernetes 1.24, а платформата използва Container Runtime Interface (CRI) за работа с runtime среди като containerd и CRI-O.

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

Кога да изберете Docker, Docker Compose или Kubernetes?

Изборът зависи основно от сложността на приложението и начина, по който трябва да бъде управлявано.

Изберете Docker, когато:

• работите с отделни контейнери;
• приложението може да работи надеждно на един хост;
• не се нуждаете от автоматизирано управление на ниво клъстер.

Изберете Docker Compose, когато:

• приложението включва няколко свързани услуги;
• искате да управлявате контейнерите, мрежите и volumes като една среда;
• всички услуги могат да работят на един хост.

Изберете Kubernetes, когато:

• натоварванията трябва да бъдат разпределени между множество машини;
• имате нужда от автоматизирано скалиране и възстановяване при откази;
• приложението изисква управление и актуализации на ниво клъстер.

Kubernetes не е задължително следващата стъпка след Docker или Compose. Ако по-простото решение покрива изискванията за производителност, наличност и скалиране, добавянето на клъстер може само да увеличи сложността.

Заключение

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

Когато тези нужди изискват Kubernetes, но не искате да поемате цялата оперативна тежест по управлението на клъстера, ние от Delta.BG предлагаме Managed Kubernetes. Услугата обхваща проектирането и внедряването на клъстера, както и неговия мониторинг, сигурност, актуализации и текуща поддръжка. Решението може да бъде реализирано в нашия публичен облак, върху dedicated servers, в колокационна среда или върху собствена on-premises инфраструктура.

Ако обмисляте използването на Kubernetes за вашите приложения, свържете се с нас на support@delta.bg или +359 2 4 288 288, за да обсъдим вашите изисквания.