Прим. прев.: този материал от образователен проект — отговор на популярния въпрос при проектирането на инфраструктура на база Kubernetes. Надяваме се, че достатъчно подробните описания на предимствата и недостатъците на всеки от вариантите ще помогнат за оптималния избор и за вашия проект.
TL;DR: един и същ набор от работни натоварвания може да бъде стартиран на няколко големи клъстера (на всеки клъстер ще се падне голямо количество workloads) или на множество по-малки (с малко натоварвания във всеки клъстер).
По-долу е представена таблица, в която се оценяват предимствата и недостатъците на всеки подход:
При използване на Kubernetes като платформа за експлоатация на приложения често възникват няколко фундаментални въпроса относно нюансите на настройката на клъстерите:
- Колко клъстера да се използват?
- Колко големи да бъдат?
- Какво трябва да включва всеки клъстер?
В тази статия ще се опитам да отговоря на всички тези въпроси, анализирайки предимствата и недостатъците на всеки подход.
Поставяне на въпроса
Като създател на софтуер, вероятно разработвате и експлоатирате множество приложения паралелно.
Освен това, множество копия на тези приложения вероятно се изпълняват в различни среди — например, те могат да бъдат dev, test и prod.
В резултат се получава цяла матрица от приложения и среди:
Приложения и среди
В горния пример са представени 3 приложения и 3 среди, което в крайна сметка дава 9 възможни варианта.
Всяко копие на приложението представлява самостоятелна единица за разгръщане, с която може да се работи независимо от другите.
Обърнете внимание, че копие на приложението може да се състои от множество компоненти, като фронтенд, бекенд, база данни и т.н. В случай на микросервизно приложение копието ще включва всички микросервизи.
В резултат на това на потребителите на Kubernetes им възникват няколко въпроса:
- Дали да се разположат всички копия на приложението в един клъстер?
- Дали да се създаде отделен клъстер за всяко копие на приложението?
- Или, възможно ли е да се възползвате от комбинация от гореспоменатите подходи?
Всички тези варианти са напълно жизнеспособни, тъй като Kubernetes е гъвкава система, която не ограничава потребителя в възможностите.
Ето някои от възможните пътища:
- един голям общ клъстер;
- множество малки специализирани клъстери;
- един клъстер за всяко приложение;
- един клъстер за всяка среда.
Както е показано по-долу, първите два подхода са в противоположни краища на скалата от варианти:
От няколко големи клъстера (вляво) до множество малки (вдясно)
Обикновено се счита, че един клъстер е "по-голям" от друг, ако разполага с повече възли и pod’ове. Например, клъстер с 10 възли и 100 pod’ове е по-голям от клъстер с 1 възел и 10 pod’ове.
Нека започнем!
1. Един голям общ клъстер
Първият вариант е да разположите всички работни натоварвания в един клъстер:
Един голям клъстер
В рамките на този подход клъстерът се използва като универсална инфраструктурна платформа — всичко необходимо просто разгръщате в съществуващия клъстер Kubernetes.
Kubernetes позволява логично разделение на частите на клъстера помежду им, така че за всеки екземпляр на приложение може да се използва собствено пространство имен.
Нека разгледаме плюсовете и минусите на този подход.
+ Ефективно използване на ресурсите
В случай на единствен клъстер ще е необходима само една копие на всички ресурси, необходими за стартиране и управление на клъстера Kubernetes.
Например, това важи за мастер-възлите. Обикновено за всеки клъстер Kubernetes се предполага наличие на 3 мастер-възла, така че за един единствен клъстер тяхното число ще остане такова (за сравнение, 10 клъстера ще изискват 30 мастер-възла).
Посочената точка важи и за други услуги, работещи в мащабите на целия клъстер, като балансировачи на натоварването, контролери Ingress, системи за автентикация, логване и мониторинг.
В единен клъстер всички тези услуги могат да се използват веднага за всички работни натоварвания (не е нужно да създавате техни копия, както в случай на множество клъстери).
+ Ниска цена
В резултат на гореизложеното, по-малкото количество клъстери обикновено е по-евтино, тъй като липсват разходи за излишни ресурси.
Това е особено важно за мастер-възлите, които могат да струват значителни суми независимо от начина на разполагане (на място или в облака).
Някои управляеми (managed) услуги Kubernetes, като или , предоставят управляващ слой безплатно. В този случай въпросът за разходите е по-малко належащ.
Съществуват и управлявани услуги, които начисляват фиксирана такса за работата на всеки Kubernetes клъстер (например, ).
+ Ефективно администриране
Управлението на един клъстер е по-лесно, отколкото на многократни.
Администрирането може да включва следните задачи:
- обновление на версията на Kubernetes;
- настройка на CI/CD конвейера;
- инсталиране на CNI плъгин;
- настройка на системата за удостоверяване на потребителите;
- инсталиране на контролер за достъп;
и много други…
В случай на един клъстер ще се наложи да се справяте с всичко това само веднъж.
За множество клъстери операциите ще трябва да се повтарят многократно, което вероятно ще изисква определена автоматизация на процесите и инструменти, за да се осигури системност и единство в процеса.
Сега няколко думи за недостатъците.
− Една точка на отказ
В случай на отказ на единствен клъстер, работните натоварвания ще спрат веднага всичко да работят!
Съществуват множество варианти, в които нещо може да не върви по план:
- обновление на Kubernetes води до неочаквани странични ефекти;
- компонент на клъстера (например, CNI плъгин) работи не както се очаква;
- един от компонентите на клъстера е неправилно настроен;
- неуспех в подлежащата инфраструктура.
Един такъв инцидент може да причини сериозни щети на всички работни натоварвания, разположени в общия клъстер.
− Липса на строга изолация
Работата в общ клъстер означава, че приложенията споделят хардуер, мрежови възможности и операционна система на възлите на клъстера.
В известен смисъл, два контейнера с две различни приложения, работещи на един и същ възел, са подобни на два процеса, работещи на една и съща машина под управлението на една и съща ОС.
Linux контейнерите осигуряват известна форма на изолация, но тя е далеч от силна, колкото например, тази, която осигуряват виртуалните машини. По същество, процес в контейнер е същият процес, стартиран в операционната система на хоста.
Това може да стане проблем от гледна точка на сигурността: такава организация теоретично позволява несвързани приложения да взаимодействат помежду си (преднамерено или случайно).
Освен това, всички работни натоварвания в Kubernetes кластера споделят някои общи кластерни услуги, като — това позволява на приложенията да намират услугите на други приложения в кластера.
Всички горепосочени точки могат да имат различно значение в зависимост от изискванията за сигурност на приложенията.
Kubernetes предоставя различни инструменти за предотвратяване на проблеми в системата за сигурност, като и . Въпреки това, за правилната им настройка е необходимо определено опит, освен това те не могат да затворят всички дупки в сигурността.
Важно е винаги да помним, че Kubernetes е проектиран първоначално за споделяне, а не за изолация и сигурност.
− Липса на строг multi-tenancy
Като се има предвид множеството общи ресурси в Kubernetes кластера, има много начини, по които различни приложения могат да "настъпват едно друго на петите".
Например, едно приложение може да монополизира определен общ ресурс (като процесор или памет) и да лиши другите приложения, работещи на същия възел, от достъп до него.
Kubernetes осигурява различни механизми за контрол на такова поведение, като (вж. също статията "“ — бел. на прев.), и . Въпреки това, както при сигурността, тяхната настройка е доста сложна и не могат да предотвратят абсолютно всички неочаквани странични ефекти.
− Голям брой потребители
В случай на единствен кластер, трябва да се осигури достъп до него за множество хора. И колкото повече са те, толкова по-висок е рискът те да "счупят" нещо.
Вътре в кластера може да се контролира кой и какво може да прави с помощта на (вж. статията "“ — бел. на прев.). Въпреки това, то не пречи на потребителите да "счупят" нещо в пределите на своята зона на отговорност.
− Кластерите не могат да растат безкрайно
Кластер, който се използва за всички работни натоварвания, вероятно ще бъде доста голям (по брой на възли и pod-ове).
Но тук възниква друг проблем: кластерите в Kubernetes не могат да растат безкрайно.
Съществува теоретичен лимит на размера на кластера. В Kubernetes той е около .
Въпреки това, в реалния живот проблемите могат да започнат много по-рано — например, само при .
Става въпрос, че големите клъстери оказват високо натоварване на управляващия слой на Kubernetes. С други думи, за да поддържате клъстера в работно състояние и да използвате ресурсите ефективно, е необходимо внимателно конфигуриране.
Тази проблема е разгледана в съответната статия в оригиналния блог с заглавие „».
Но нека разгледаме противоположния подход: множество малки клъстери.
2. Множество малки, специализирани клъстери
При този подход използвате отделен клъстер за всеки разгръщан елемент:
Множество малки клъстери
За целите на тази статия под разгръщан елемент разбирате инстанция на приложение — например, dev-версия на отделно приложение.
В тази стратегия Kubernetes се използва като специализирана среда за изпълнение за отделни инстанции на приложения.
Нека разгледаме плюсовете и минусите на този подход.
+ Ограничен „радиус на разрушаване“
При „повреда“ на клъстера негативните последици са ограничени само до тези работни натоварвания, които са били разгръщани в този клъстер. Всички останали работни натоварвания остават непокътнати.
+ Изолация
Работните натоварвания, разположени в индивидуални клъстери, нямат общи ресурси, като процесор, памет, операционна система, мрежа или други услуги.
В резултат получаваме строга изолация между несвързаните приложения, което може да окаже благоприятно влияние върху тяхната сигурност.
+ Нисък брой потребители
Като се има предвид, че всеки клъстер съдържа само ограничен набор от работни натоварвания, се намалява броят на потребителите с достъп до него.
Колкото по-малко хора имат достъп до клъстера, толкова по-нисък е рискът от "повреда".
Нека да разгледаме недостатъците.
− Неефективно използване на ресурсите
Както споменах по-рано, всеки клъстер на Kubernetes изисква определен набор от управляващи ресурси: управлявани възли, компоненти на контролния слой, решения за мониторинг и логиране.
В случай на голям брой малки клъстери, е необходимо да се отдели по-голям дял от ресурсите за управление.
− Висока цена
Неефективното използване на ресурсите автоматично води до високи разходи.
Например, наличието на 30 майсторски възли вместо три при същата изчислителна мощност непременно ще се отрази на разходите.
− Сложности в администрирането
Администрирането на множество Kubernetes клъстери е много по-сложно, отколкото работата с един.
Например, ще се наложи да настроите удостоверяване и разрешаване за всеки клъстер. Обновлението на версията на Kubernetes също ще трябва да се проведе няколко пъти.
Скоро ще се наложи да приложите автоматизация, за да увеличите ефективността на всички тези задачи.
Сега нека разгледаме по-малко крайни сценарии.
3. Един клъстер за всяко приложение
В рамките на този подход създавате отделен клъстер за всички инстанции на конкретно приложение:
Клъстер за приложение
Този път може да се разглежда като обобщение на принципа „отделен клъстер за екипа“, тъй като обикновено един екип инженери разработва едно или няколко приложения.
Нека разгледаме плюсовете и минусите на този подход.
+ Клъстерът може да бъде настроен според приложението
Ако приложението има специални нужди, те могат да бъдат реализирани в клъстера, без да засягат другите клъстери.
Тези нужди могат да включват работници с GPU, определени CNI плъгини, service mesh или някаква друга услуга.
Всеки клъстер може да бъде настроен според работещото в него приложение, за да съдържа само необходимото.
− Различни среди в един клъстер
Недостатък на този подход е, че инстанциите на приложения от различни среди съществуват в един и същ клъстер.
Например, prod версията на приложението работи в същия клъстер, както и dev версията. Това също означава, че разработчиците извършват действия в същия клъстер, в който функционира production версията на приложението.
Ако заради действия на разработчиците или бъгове в dev версията в клъстера настъпи срив, потенциално може да пострада и prod версията — огромен недостатък на този подход.
И накрая, последният сценарий в нашия списък.
4. Един клъстер за всяка среда
Този сценарий предвижда отделен клъстер за всяка среда:
Един клъстер за среда
Например, може да имате клъстери dev, test и prod, в които ще стартирате всички инстанции на приложението, предназначени за определена среда.
Ето плюсовете и минусите на този подход.
+ Изолация на prod средата
В рамките на този подход всички среди се изолират една от друга. Въпреки това, на практика това е особено важно за прод-средата.
Production версиите на приложението вече не зависят от събитията в другите клъстери и среди.
По този начин, ако в dev клъстера внезапно възникне проблем, прод версиите на приложенията ще продължат да работят, сякаш нищо не се е случило.
+ Клъстерът може да бъде адаптиран към средата
Всеки клъстер може да бъде адаптиран за неговата среда. Например, може да:
- инсталирате инструменти за разработка и отстраняване на грешки в dev клъстера;
- инсталирате тестови фреймуъркове и инструменти в клъстера; test;
- използвате по-мощно оборудване и мрежови канали в клъстера; prod.
Това позволява да се повиши ефективността както на разработката, така и на експлоатацията на приложения.
+ Ограничаване на достъпа до production клъстера
Необходимостта от работа с prod клъстера директно възниква рядко, така че може значително да се ограничи кръгът на лицата, които имат достъп до него.
Може да отидете дори по-далеч и изцяло да лишите хората от достъп до този клъстер, а всички разгръщания да се извършват чрез автоматизиран инструмент CI/CD. Такъв подход ще позволи максимално да се намали рискът от човешки грешки точно там, където е най-актуално.
Сега няколко думи за недостатъците.
− Липса на изолация между приложенията
Основният недостатък на подхода е липсата на апаратна и ресурсна изолация между приложенията.
Несвързаните приложения споделят ресурсите на клъстера: системното ядро, процесор, памет и някои други услуги.
Както вече беше споменато, това може да бъде потенциално опасно.
− Невъзможност за локализиране на зависимостите на приложенията
Ако приложението има специални изисквания, те трябва да бъдат удовлетворени във всички клъстери.
Например, ако приложението изисква GPU, всеки клъстер трябва да съдържа поне един worker с GPU (дори и да се използва само от това приложение).
В резултат на това рискуваме да получим по-високи разходи и неефективно използване на ресурсите.
Заключение
При наличие на определен набор от приложения тях може да се разположи в няколко големи клъстера или в множество малки.
В статията са обсъдени предимствата и недостатъците на различните подходи, започвайки от един глобален клъстер и завършвайки с няколко малки и специализирани:
- един голям общ клъстер;
- множество малки специализирани клъстери;
- един клъстер за всяко приложение;
- един клъстер за всяка среда.
Така че, какъв подход да изберете?
Както обикновено, отговорът зависи от случая на употреба: необходимо е да се преценят предимствата и недостатъците на различните подходи и да се избере най-оптималният вариант.
Въпреки това изборът не се ограничава само до посочените примери — можете да използвате всяка от техните комбинации!
Например, можете да организирате по два клъстера за всеки екип: клъстер за разработка (в който ще има среди dev и test) и клъстер за производството (където ще се намира продукционната среда).
Основавайки се на информацията от тази статия, вие ще можете да оптимизирате предимствата и недостатъците за конкретния сценарий. Успех!
P.S.
Прочетете също в нашия блог:
- «»;
- «»;
- «»;
- «».
Източник: habr.com
