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

Забележка. превод: този материал е от образователен проект научите8s - отговорът на популярен въпрос при проектирането на инфраструктура, базирана на Kubernetes. Надяваме се, че достатъчно подробните описания на плюсовете и минусите на всяка от опциите ще ви помогнат да направите най-добрия избор за вашия проект.

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

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

Когато използвате Kubernetes като платформа за стартиране на приложения, често има няколко основни въпроса относно тънкостите на конфигурирането на клъстери:

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

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

Изложение на въпрос

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

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

Резултатът е цяла матрица от приложения и среди:

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

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

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

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

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

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

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

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

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

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

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

Като цяло се счита, че един клъстер е „по-голям“ от друг, ако има повече от сумата от възли и подове. Например, клъстер с 10 възела и 100 пода е по-голям от клъстер с 1 възел и 10 пода.

Е, да започваме!

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

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

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

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

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

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

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

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

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

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

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

+ евтино

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

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

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

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

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

По-лесно е да управлявате един клъстер, отколкото няколко.

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

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

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

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

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

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

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

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

Има много опции за това, когато нещо може да се обърка:

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

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

− Липса на твърда изолация

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

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

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

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

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

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

Kubernetes предоставя различни инструменти за предотвратяване на проблеми със сигурността, като напр PodSecurityPolicies и NetworkPolicies. Те обаче изискват известен опит за правилно конфигуриране и не могат да затворят абсолютно всички дупки в сигурността.

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

− Липса на твърдо многонаемане

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

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

Kubernetes предоставя различни механизми за контрол на това поведение, като напр заявки за ресурси и ограничения (вижте също статията " Ограничения на процесора и агресивно дроселиране в Kubernetes “- прибл. превод), Квоти за ресурси и LimitRanges. Въпреки това, както в случая със сигурността, тяхната конфигурация е доста нетривиална и те не са в състояние да предотвратят абсолютно всички непредвидени странични ефекти.

− Голям брой потребители

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

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

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

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

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

Има теоретично ограничение за размера на клъстера. В Kubernetes е приблизително 5000 възли, 150k подове и 300k контейнери.

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

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

Този проблем е разгледан в свързана статия в оригиналния блог, озаглавена "Архитектиране на клъстери на Kubernetes - избор на размер на работния възел".

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

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

С този подход използвате отделен клъстер за всеки елемент, който внедрявате:

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

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

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

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

+ Ограничен "радиус на експлозия"

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

+ Изолация

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

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

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

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

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

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

− Неефективно използване на ресурсите

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

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

− Скъпо

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

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

− Административни трудности

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

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

И така, кой подход да изберете?

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

Изборът обаче не се ограничава до горните примери – можете да използвате произволна комбинация от тях!

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

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

PS

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

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

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