Работни възли на Kubernetes: много малки или няколко големи?

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

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

Капацитет на клъстера

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

Има няколко начина за постигане на желания капацитет на клъстера. Например, имаме нужда от клъстер с общ капацитет от 8 процесорни ядра и 32 GB RAM, защото набор от приложения изисква толкова много ресурси. След това можете да инсталирате два възела с 16 GB памет или четири възела с 8 GB памет, два четириядрени процесора или четири двуядрени.

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

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

Кой вариант е по-добър?

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

Няколко големи възела

Много малки възли

По-лесно управление на клъстер (ако е локално)

Гладко автоматично мащабиране

По-евтино (ако е на място)

Цената е малко по-различна (в облака)

Може да изпълнява ресурсоемки приложения

Пълна репликация

Ресурсите се използват по-ефективно (по-малко разходи за системни демони
По-висока устойчивост на грешки на клъстера

Моля, обърнете внимание, че говорим само за работни възли. Изборът на броя и размера на основните възли е съвсем различна тема.

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

Първи вариант: няколко големи възела

Най-екстремният вариант е един работен възел за целия капацитет на клъстера. В примера по-горе това би бил един работен възел с 16 CPU ядра и 16 GB RAM.

Професионалисти

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

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

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

Маршрутизиране на трафика и разпределение на натоварването между подовете в облака извършва автоматично: трафикът, идващ от интернет, се изпраща към основния балансьор на натоварването, който препраща трафика към порта на един от възлите (услугата NodePort задава порта в диапазона 30000-32767 във всеки клъстерен възел). Правилата, зададени от kube-proxy, пренасочват трафика от възела към под. Ето как изглежда за десет капсули на два възела:

Професионалист #2: По-малко разходи за възел
Мощната кола е по-скъпа, но увеличението на цената не е непременно линейно. С други думи, един десетядрен сървър с 10 GB памет обикновено е по-евтин от десет едноядрени сървъра със същото количество памет.

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

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

Професионалист #3: Можете да стартирате ресурсоемки приложения
Някои приложения изискват мощни сървъри в клъстер. Например, ако система за машинно обучение изисква 8 GB памет, няма да можете да я стартирате на възли от 1 GB, а само с поне един голям работен възел.

Против

Недостатък № 1. Много шушулки на възел
Ако същата задача се изпълнява на по-малко възли, тогава всеки от тях естествено ще има повече подове.

Това може да е проблем.

Причината е, че всеки модул въвежда някои допълнителни разходи за времето за изпълнение на контейнера (напр. Docker), както и kubelet и cAdvisor.

Например kubelet редовно проверява всички контейнери на възел за оцеляване – колкото повече контейнери, толкова повече работа трябва да свърши kubelet.

CAdvisor събира статистически данни за използването на ресурсите за всички контейнери на възел, а kubelet редовно отправя запитвания към тази информация и я предоставя чрез API. Отново, повече контейнери означава повече работа както за cAdvisor, така и за kubelet.

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

В хранилището на Kubernetes някои оплакалче възлите прескачат между статуси Готов/НеГотов, защото редовните kubelet проверки на всички контейнери на възел отнемат твърде дълго време.
Поради тази причина Kubernetes препоръчва поставянето на не повече от 110 шушулки на възел. В зависимост от производителността на възела можете да стартирате повече подове на възел, но е трудно да се предвиди дали ще има проблеми или всичко ще работи добре. Струва си да тествате работата предварително.

Недостатък № 2. Ограничение на репликацията
Твърде малко възли ограничават ефективната степен на репликация на приложението. Например, ако имате приложение с висока достъпност с пет реплики, но само два възела, тогава ефективната степен на репликация на приложението се намалява до две.

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

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

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

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

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

Следователно, колкото повече възли, толкова по-малко е влиянието на хардуерните повреди.

Недостатък #4: Повече стъпки за автоматично мащабиране
Kubernetes има клъстерна система за автоматично мащабиране за облачна инфраструктура, която ви позволява автоматично да добавяте или премахвате възли в зависимост от вашите текущи нужди. С по-големи възли автоматичното мащабиране става по-рязко и тромаво. Например, на два възела, добавянето на допълнителен възел веднага ще увеличи капацитета на клъстера с 50%. И ще трябва да платите за тези ресурси, дори и да не ви трябват.

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

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

Втори вариант: много малки възли

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

Професионалисти

Професионалист #1: По-малко въздействие от провала
Колкото повече възли, толкова по-малко подове на всеки възел. Например, ако имате сто модула на десет възела, тогава всеки възел ще има средно десет модула.

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

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

Професионалист #2: Добра репликация
Ако има достатъчно възли, планировчикът на Kubernetes може да присвои различни възли на всички реплики. По този начин, ако даден възел се повреди, само една реплика ще бъде засегната и приложението ще остане достъпно.

Против

Недостатък No 1. Труден за контрол
Голям брой възли са по-трудни за управление. Например, всеки Kubernetes възел трябва да комуникира с всички останали, тоест броят на връзките нараства квадратично и всички тези връзки трябва да бъдат проследени.

Контролерът на възли в Kubernetes Controller Manager редовно преминава през всички възли в клъстера, за да проверява изправността - колкото повече възли, толкова по-голямо е натоварването на контролера.

Натоварването на базата данни etcd също расте - всеки kubelet и kube-proxy извиква наблюдател за etcd (чрез API), към който etcd трябва да излъчва актуализации на обекти.

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

Kubernetes официално поддържа клъстери с брой възли до 5000. На практика обаче вече има 500 възела може да причини нетривиални проблеми.

За да управлявате голям брой работни възли, трябва да изберете по-мощни главни възли. Например kube-up автоматично се инсталира правилния размер на VM за главния възел в зависимост от броя на работните възли. Тоест, колкото повече работни възли, толкова по-продуктивни трябва да бъдат главните възли.

За решаването на тези специфични проблеми има специални разработки, като напр Виртуален Kubelet. Тази система ви позволява да заобиколите ограниченията и да изградите клъстери с огромен брой работни възли.

Недостатък №2: Повече режийни разходи.
На всеки работен възел Kubernetes изпълнява набор от системни демони - те включват времето за изпълнение на контейнера (като Docker), kube-proxy и kubelet, включително cAdvisor. Заедно те консумират определено фиксирано количество ресурси.

Ако имате много малки възли, съотношението на тези разходи за всеки възел е по-голямо. Например, представете си, че всички системни демони на един възел заедно използват 0,1 CPU ядра и 0,1 GB памет. Ако имате един десетядрен възел с 10 GB памет, тогава демоните консумират 1% от капацитета на клъстера. От друга страна, на десет едноядрени възела с 1 GB памет, демоните ще заемат 10% от капацитета на клъстера.

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

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

Например, всяка капсула изисква 0,75 GB памет. Ако имате десет възела, всеки с 1 GB памет, можете да стартирате десет pods, оставяйки всеки възел с 0,25 GB неизползвана памет.

Това означава, че 25% от цялата памет на клъстера се губи.

На голям възел с 10 GB памет можете да стартирате 13 от тези модули - и ще има само един неизползван фрагмент от 0,25 GB.

В този случай само 2,5% от паметта се губи.

По този начин ресурсите се използват по-оптимално на по-големи възли.

Няколко големи възли или много малки?

И така, кое е по-добре: няколко големи възела в клъстер или много малки? Както винаги, няма ясен отговор. Много зависи от вида на приложението.

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

В междинни ситуации направете избор въз основа на предимствата и недостатъците на всяка опция. Може би някои аргументи са по-подходящи за вашата ситуация от други.

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

Няма единна рецепта и всяка ситуация има свои собствени нюанси и само производството ще покаже истината.

Преводът е изготвен от екипа на облачната платформа Облачни решения на Mail.ru.

Повече за Kubernetes: 25 полезни инструмента за управление и внедряване на клъстери.

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