Какво е Kubernetes?

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

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

Използвайки концепцията на Labels и Pods Kubernetes логически групира едно приложение, изградено от няколко контейнера и спомага за разкриването и мениджмънта на приложението.

След вече създадено Docker изображение на приложението, то се „предава“ на Kubernetes, който от своя страна намира къде, стартира и наблюдава работата на контейнера.

За да дадем по-добър пример за абстракцията, която Kubernetes предлага, нека разгледаме стандартна IaaS услуга – клиентите, използващи виртуалните машини, не се интересуват от производителя на хардуера, изграждащ инфраструктурата – стига да получават желаната производителност – няма значение дали сървърите са Dell, HP или SuperMicro, докато работят коректно. Клиентът избира ресурси, операционна система и локацията на датацентъра, в който да бъде вдигната машината, след което клауд контролният панел/оркестраторът има грижата да я провизира на хипервизор с достатъчно ресурси и стартира в желаното състояние. По този начин физическата инфраструктура се абстрахира от IaaS модела.

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

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

Какво е Pod?

Kubernetes е разработен от Google за управление на множество контейнери, но вместо да се държи всеки контейнер поотделно, разпределяйки го по възли от клъстера, Kubernetes логически групира контейнерите в Pod-ове. Ако вземем за пример едно приложение, състоящо се от контейнер с логиката на приложението и контейнер, съдържащ базата данни ще видим, че контейнерите на това приложение могат да бъдат логически групирани (в Pod) и съответно при преместване на приложението от един възел на клъстера на друг е нужно да се премести само един Pod, който включва всичко нужно за приложението. Реално погледнато Pod-овете се намират на едно ниво по-високо от контейнерите, добавящи декларативна обвивка около тях.

Когато създаваме Pod-ове трябва да се има в предвид, че те се смятат за „краткотрайна единица“ в Kubernetes – няма да оцелеят след рестарт на машината, повреда или спиране за maintenance. За да се избегне това, Pod-овете се стартират чрез друга единица на Kubernetes – Replication Controllers, които създават и премахват Pod-ове според нуждата.

Какво е Replication Controller?

Replication Controller-ите са една от основните единици на Kubernetes, която използваме при разполагане на една или повече инстанции на нашето приложение на Kubernetes клъстера. Всеки Replication Controller има зададено желано състояние. При засичане на отклонение от желаното състояние клъстерът се грижи разликата да бъде изгладена и състоянието на Replication Controller-a да бъде докарано до декларираното. За пример може да разгледаме следната ситуация – имаме 3 реплики на Replication Controller, правим промяна и обновяваме декларацията на контролера и вече желаното му състояние е с 4 реплики. Съответно контролерът ще сравни сегашното състояние (3 инстанции) и новото желано състояние (4 инстанции) и ще създаде още една реплика някъде на клъстера. Използвайки Labels контролерът следи и управлява единствено Pod-овете, които са маркирани към него.

Какво представляват Labels и Selectors?

Labels са key/value двойка, която се добавя към Kubernetes обекти (например Pod-ове, но не само). Те се използват за разделяне, идентифициране и групиране на раличните обекти. Labels могат да се задават при създаването на един обект или да се добавят допълнително, след като той вече е създаден. Основната функция на Labels е на организационно ниво – например групиране на различни версии на front-end частта на едно приложение: environment=production, environment=dev и тн. Съответно може да имаме няколко Label-а и чрез тях да указваме какво да бъде маркирано. Пример: искаме да маркираме всички front-end Replication Controller-и, които са в production, и имат version=v2.0. По този начин може гъвкаво да добавим нова версия на приложението ни към вече работещата стара и те да работят паралелно.

Selectors
С помощта на Selector-ите ние декларираме кои Label-и желаем да изберем. Чрез Selector-ите ние казваме на нашия Service, че искаме да пренасочва трафик към всички Pod-ове с отговарящия Label. Пример: ако декларираме Selectorname=frontend“ в нашия Service, то той ще пренасочва трафика към всички Pod-ове с деклариран Labelname=frontend„.

Какво e Service?

Services представляват примитивни Load Balancer-и, осигуряващи достъпност до Pod-овете, стартирани от Replication Controller-ите, без да е нужно да използваме IP адреса на определен Pod (тъй като те се сменят при пресъздаването на Pod). Това става възможно благодарение на споменатите по-рано Label-и и Selector-и: при деклариране на Service, чрез задаване на Selector се посочва към кои Label-и да бъде пренасочван трафика. Пример: ако декларираме Selectorname=frontend“ в нашия Service, то той ще пренасочва трафика към всички Pod-ове с деклариран Labelname=frontend„. 

Обновена: 01.11.2022

Беше ли Ви полезна тази статия?

Вижте още