Проектиране на Kubernetes клъстери: колко трябва да бъдат?

Прим. прев.: този материал от образователния проект learnk8s — отговор на популярния въпрос при проектирането на инфраструктура на базата на Kubernetes. Надяваме се, че достатъчно подробните описания на предимствата и недостатъците на всеки от вариантите ще помогнат да направите оптимален избор и за вашия проект.

TL;DR: един и същ набор от работни натоварвания може да бъде стартиран на няколко големи клъстера (на всеки клъстер ще се падне голям брой workload’ове) или на множество малки (с малък брой натоварвания във всеки клъстер).

По-долу е представена таблица, в която се оценяват предимствата и недостатъците на всеки подход:

При използване на Kubernetes като платформа за експлоатация на приложения често възникват няколко основни въпроса относно нюансите на настройката на клъстерите:

• Колко клъстера да се използват?
• Колко големи да бъдат?
• Какво трябва да включва всеки клъстер?

В тази статия ще се опитам да отговоря на всички тези въпроси, анализирайки предимствата и недостатъците на всеки подход.

Постановка на въпроса

Като разработчик на софтуер, вероятно паралелно разработвате и експлоатирате множество приложения.

Освен това, множество екземпляри на тези приложения вероятно се стартират в различни среди — например, това могат да бъдат dev, test и prod.

В резултат се получава цяла матрица от приложения и среди:

Приложения и среди

В приведения по-горе пример са представени 3 приложения и 3 среди, което в крайна сметка дава 9 възможни варианта.

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

Обърнете внимание, че екземпляр на приложението може да се състои от множество компонента, като фронтенд, бекенд, база данни и т.н. В случая на микросервизно приложение, екземплярът ще включва всички микросервизи.

В резултат на това възникват няколко въпроса сред потребителите на Kubernetes:

• Трябва ли да разположите всички екземпляри на приложението в един и същ клъстер?
• Трябва ли да създадете отделен клъстер за всеки екземпляр на приложението?
• Или, може би, трябва да се възползвате от комбинация от посочените по-горе подходи?

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

Ето някои от възможните пътища:

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

Както е показано по-долу, първите два подхода са на противоположните краища на спектъра:

От няколко големи клъстера (вляво) до много малки (вдясно)

Като общо правило, се счита, че един клъстер е "по-голям" от друг, ако има повече възли и pod'ове. Например, клъстер с 10 възли и 100 pod'ове е по-голям от клъстер с 1 възел и 10 pod'ове.

Добре, нека да започнем!

1. Един голям общ клъстер

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

Един голям клъстер

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

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

Нека да разгледаме предимствата и недостатъците на този подход.

+ Ефективно използване на ресурсите

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

Например, това важи за мастер-възлите. Обикновено на всеки клъстер Kubernetes се падат по 3 мастер-възла, така че за един единствен клъстер числото ще остане такова (за сравнение, 10 клъстера ще изискват 30 мастер-възла).

По-гореизложената тънкост важи и за другите услуги, функциониращи в мащабите на целия клъстер, като балансировчици на натоварване, Ingress контролери, системи за аутентификация, логване и мониторинг.

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

+ Ниски разходи

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

Това е особено валидно за мастер-възлите, които могат да струват значителни суми независимо от начина на разгръщане (on-premises или в облака).

Някои управлявани услуги Kubernetes, като Google Kubernetes Engine (GKE) или Azure Kubernetes Service (AKS), предоставят управляващ слой безплатно. В такъв случай въпросът за разходите не е толкова остър.

Съществуват и управлявани услуги, които таксуват фиксирана цена за работата на всеки клъстер Kubernetes (например, Amazon Elastic Kubernetes Service, EKS).

+ Ефективно администриране

Управлението на един клъстер е по-лесно, отколкото на множество.

Администрирането може да включва следните задачи:

• обновяване на версията на Kubernetes;
• конфигуриране на CI/CD конвейер;
• инсталиране на CNI плъгин;
• настройка на системата за удостоверяване на потребители;
• инсталиране на контролер за достъп;

и много други…

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

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

А сега няколко думи за недостатъците.

− Единична точка на отказ

В случай на отказ на единствения клъстер, веднага ще спрат да работят всичко натоварванията!

Съществуват маса варианти, в които нещо може да се обърка:

• обновяването на Kubernetes води до неочаквани странични ефекти;
• общоклъстерен компонент (например, CNI плъгин) започва да работи не както се очакваше;
• един от компонентите на клъстера е конфигуриран неправилно;
• сбой в подлежащата инфраструктура.

Един такъв инцидент може да нанесе сериозни щети на всички натоварвания, разположени в общия клъстер.

− Липса на стегната изолация

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

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

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

Това може да стане проблем от гледна точка на сигурността: подобна организация теоретично позволява несвързани приложения да взаимодействат помежду си (преднамерено или случайно).

Освен това, всички работни натоварвания в кластера Kubernetes споделят някои общокластерни услуги, като DNS — това позволява на приложенията да намират услуги на други приложения в кластера.

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

Kubernetes предоставя различни инструменти за предотвратяване на проблеми в системата за безопасност, като PodSecurityPolicies и NetworkPolicies. Въпреки това, за правилното им настройване е необходимо определено ниво на опит; освен това, те не могат да закрият напълно всички уязвимости в безопасността.

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

− Липса на стриктна multi-tenancy

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

Например, приложение може да монополизира някакъв общ ресурс (като процесор или памет) и да лиши други приложения, работещи на същия възел, от достъп до него.

Kubernetes осигурява различни механизми за контрол на такова поведение, като заявки за ресурси и лимити (вж. също статията " CPU лимити и агресивен тротлинг в Kubernetes » — забележка на преводача.), ResourceQuotas и LimitRanges. Въпреки това, както в случая с безопасността, настройването им е доста сложно и те не са в състояние да предотвратят напълно всички неочаквани странични ефекти.

− Много потребители

В случай на единствен кластер, достъпът до него трябва да се предостави на множество хора. И колкото по-голям е броят им, толкова по-висок е рискът те да "счупят" нещо.

В рамките на клъстера може да се контролира кой и какво може да прави, с помощта на управление на достъпа на базата на роли (RBAC) (вж. статията " Потребители и авторизация RBAC в Kubernetes » — забележка на преводача.). Впрочем, това не пречи на потребителите "да счупят" нещо в границите на своята отговорност.

− Кластери не могат да растат безкрайно

Клъстер, който се използва за всички работни натоварвания, вероятно ще бъде доста голям (по отношение на брой възли и pod’ове).

Но тук възниква друг проблем: кластерите в Kubernetes не могат да растат безкрайно.

Съществува теоретичен лимит на размера на клъстера. В Kubernetes той е около 5000 възли, 150 хиляди pod’ове и 300 хиляди контейнери.

Въпреки това, в реалния живот проблемите могат да започнат много по-рано — например, само при 500 възела.

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

Тази проблема се разглежда в съответната статия в оригиналния блог под заглавие „Architecting Kubernetes clusters — choosing a worker node size».

Но нека разгледаме противоположния подход: множество малки клъстери.

2. Множество малки, специализирани клъстери

При този подход използвате отделен клъстер за всеки разгръщан елемент:

Множество малки клъстери

За целите на тази статия, под разгръщан елемент се разбира инстанция на приложение — например, dev-версия на отделно приложение.

В тази стратегия Kubernetes се използва като специализирана изпълнителна среда за отделни инстанции на приложение.

Нека да разгледаме предимствата и недостатъците на този подход.

+ Ограничен „обхват на взрива“

При „повреда“ на клъстера негативните последствия се ограничават само до тези работни натоварвания, които са били разгръщани в този клъстер. Всички други натоварвания остават непокътнати.

+ Изолация

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

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

+ Малко на брой потребители

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

Колкото по-малко хора имат достъп до клъстера, толкова по-нисък е рискът нещо да се „повреди“.

Нека разгледаме минусите.

- Неекономично използване на ресурсите

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

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

- Скъпост

Неекономичното използване на ресурсите автоматично води до високи разходи.

Например, наличието на 30 майсторски възли вместо три с еднаква изчислителна мощност задължително ще се отрази на разходите.

− Сложности при администрирането

Администрирането на множество Kubernetes клъстери е много по-сложно, отколкото работата с един.

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

Скорее всего, ще се наложи да приложите автоматизация, за да повишите ефективността на всички тези задачи.

Сега нека разгледаме по-малко екстремни сценарии.

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

В рамките на този подход създавате отделен клъстер за всички инстанции на конкретно приложение:

Клъстер за приложение

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

Нека да разгледаме предимствата и недостатъците на този подход.

+ Клъстерът може да бъде адаптиран към приложението

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

Тези нужди могат да включват работници с GPU, определени CNI плъгини, service mesh или някаква друга услуга.

Всеки клъстер може да бъде оптимизиран за работещото в него приложение, за да съдържа само това, което е необходимо.

− Различни среди в един клъстер

Недостатък на този подход е, че инстанциите на приложения от различни среди съжителстват в един клъстер.

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

Ако заради действия на разработчиците или бъгове в dev версията в клъстера настъпи срив, потенциално може да пострада и прод версията — огромен недостатък на този подход.

И, накрая, последният сценарий в нашия списък.

4. Един клъстер за всяка среда

Този сценарий предвижда отделен клъстер за всяка среда:

Един клъстер за среда

Например, можете да имате клъстери, dev, test и prod, в които ще стартирате всички инстанции на приложението, предназначени за определена среда.

Ето плюсовете и минусите на този подход.

+ Изолация на прод средата

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

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

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

+ Клъстерът може да бъде адаптиран към средата

Всеки клъстер може да бъде адаптиран към неговата среда. Например, може да:

• инсталирате инструменти за разработка и отстраняване на грешки в dev клъстера;
• инсталирате тестови фреймворкове и инструменти в клъстера; test;
• използвате по-мощно оборудване и мрежови канали в клъстера; prod.

Това позволява да се увеличи ефективността както на разработката, така и на експлоатацията на приложенията.

+ Ограничаване на достъпа до продукционния клъстер

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

Може да се отиде дори по-далеч и изобщо да се лишат хората от достъп до този клъстер, а всички разгръщания да се извършват с помощта на автоматизирания инструмент CI/CD. Такъв подход ще позволи да се минимизира рискът от човешки грешки именно там, където е най-актуално.

А сега няколко думи за недостатъците.

− Липса на изолация между приложенията

Основен недостатък на подхода е липсата на хардуерна и ресурсна изолация между приложенията.

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

Както вече беше споменато, това може да бъде потенциално опасно.

− Невъзможност за локализиране на зависимостите на приложенията

Ако приложението има специални изисквания, то трябва да се задоволят във всички клъстери.

Например, ако приложението изисква GPU, то всеки клъстер трябва да съдържа поне един работник с GPU (дори ако той се използва само от това приложение).

В резултат на това рискуваме да получим по-високи разходи и неефективно използване на ресурсите.

Заключение

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

В статията са разгледани предимствата и недостатъците на различни подходи, започвайки от един глобален клъстер и стигайки до няколко малки и специализирани:

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

И така, какъв подход да изберем?

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

Обаче изборът не се ограничава само до изброените по-горе примери — може да се използва всяко тяхно съчетание!

Например, може да се организират по два клъстера за всеки екип: клъстер за разработка (в който ще бъдат средите dev и test) и клъстер за production (където ще се намира производствената среда).

Опирате на информацията от тази статия, вие ще можете да оптимизирате плюсовете и минусите в съответствие с конкретния сценарий. Успех!

P.S.

Прочетете също в нашия блог:

• «Визуално ръководство за диагностика на проблеми в Kubernetes»;
• «Логовете в Kubernetes (и не само) днес: очаквания и реалност»;
• «Service Mesh: какво трябва да знае всеки софтуерен инженер за най-популярната технология»;
• «Азбука на сигурността в Kubernetes: удостоверяване, авторизация, одит».

Източник: habr.com