При създаването на Kubernetes кластер могат да възникнат въпроси: колко работни възела да настроим и какъв тип? Какво е по-добре за on-premise кластер: да купим няколко мощни сървъра или да активираме десет стари машини в дата центъра? А в облака дали е по-добре да вземем осем единични ядра или два с четири ядра?
Отговорите на тези въпроси са в статията в превод на екипа .
Капацитет на клъстера
Като цяло, Kubernetes кластерът може да бъде разглеждан като голям "супервъзел". Общата му изчислителна мощност е сумата на мощностите на всички включени възли.
Има няколко начина да постигнете желаната целева мощност на клъстера. Например, ако ни е необходим клъстер с общ капацитет от 8 процесорни ядра и 32 GB оперативна памет, защото наборът от приложения изисква такова количество ресурси. Тогава можем да инсталираме два възела с 16 GB памет или четири възела с 8 GB памет, две четириядрени процесора или четири двуядрени.
Ето само два възможни начина за изграждане на клъстер:
И двете опции дават клъстер с еднаква мощност, но в конфигурацията отдолу са инсталирани четири по-малки възела, а в конфигурацията отгоре — два по-големи.
Кой вариант е по-добър?
За да отговорим на този въпрос, нека разгледаме предимствата на двете опции. Събрахме ги в таблица.
Няколко големи възела
Много малки възела
По-просто управление на клъстера (ако е on-premise)
Плавно автоматично мащабиране
По-евтино (ако е on-premise)
Цената не се различава много (в облака)
Може да се стартират ресурсоемки приложения
Пълна репликация
Ресурсите се използват по-ефективно (по-малко оувърхед за системни демони)
По-висока отказоустойчивост на клъстера
Обърнете внимание, че говорим само за работните възли. Изборът на брой и размер на главните възли е съвсем различна тема.
И така, нека обсъдим по-подробно всяка точка от таблицата.
Първият вариант: няколко големи възела
Най-крайният вариант — един работен възел за целия капацитет на клъстера. В примера по-горе това би бил един работен възел с 16 ядра на процесора и 16 GB оперативна памет.
Плюсове
Плюс № 1. По-просто управление
По-лесно е да управляваш с няколко машини, отколкото с целия парк. По-бързо се прилагат актуализации и корекции, по-лесно е да се синхронизират. Броят на сривовете в абсолютни числа също е по-малък.
Обърнете внимание, че всичко казано по-горе се отнася до собственото ви оборудване, собствените ви сървъри, а не до облачни инстанции.
В облака ситуацията е различна. Услугата облачен доставчик управлява управлението. Така че управлението на десет възли в облака не се различава особено от управлението на един възел.
Маршрутизацията на трафика и разпределението на натоварването между подовете в облака : идващият интернет трафик се насочва към основния балансировчик на натоварването, който насочва трафика към порта на един от възлите (услугата NodePort задава порт в диапазона 30000-32767 на всеки възел в кластера). Правилата, установени от kube-proxy, пренасочват трафика от възела към пода. Ето как изглежда за десет пода на два възела:
Плюс № 2. По-малко разходи на възел
Мощната машина е по-скъпа, но повишението на цената не е задължително линейно. С други думи, един десетядрен сървър с 10 ГБ памет обикновено е по-евтин от десет едноядрени с същото количество памет.
Но обърнете внимание, че това правило обикновено не работи в облачните услуги. В настоящите схеми за ценообразуване на всички основни облачни доставчици цените нарастват линейно с увеличаването на капацитета.
Така че, в облака обикновено не може да се спести на по-мощни сървъри.
Плюс № 3. Могат да се стартират ресурсоемки приложения
Някои приложения изискват мощни сървъри в кластера. Например, ако системата за машинно обучение изисква 8 ГБ памет, не можете да я стартирате на възли с 1 ГБ, а само ако имате поне един голям работен възел.
Минуси
Минус № 1. Много пода на възел
Ако една и съща задача се изпълнява на по-малко възли, то на всеки от тях естествено ще има повече пода.
Това може да стане проблем.
Причината е, че всеки модул внася определени разходи за средата на изпълнение на контейнера (например Docker), а също и kubelet и cAdvisor.
Например, kubelet редовно проверява жизнеспособността на всички контейнери на възела — колкото повече контейнери, толкова повече работа има за kubelet.
CAdvisor събира статистика за използването на ресурсите на всички контейнери на възлите, а kubelet редовно изисква тази информация и я предоставя чрез API. Отново, колкото повече контейнери, толкова повече работа и за cAdvisor, и за kubelet.
Ако броят на модулите се увеличи, това може да забави системата и дори да подкопае нейната надеждност.
В репозиторият на Kubernetes някои , че възлите скачат между статусите Ready/NotReady, тъй като редовните проверки на kubelet за всички контейнери на възела отнемат твърде много време.
Поради тази причина Kubernetes . В зависимост от производителността на възела, можете да стартирате повече pod-ове на възел, но трудно може да се предскаже дали ще възникнат проблеми или всичко ще работи добре. Трябва да се тества предварително.
Недостатък № 2. Ограничение на репликацията
Твърде малкият брой възли ограничава ефективността на репликацията на приложенията. Например, ако имате приложение с висока наличност, което използва пет реплики, но имате само два възла, ефективността на репликацията на приложението намалява до два.
Пет реплики могат да бъдат разпределени само на два възла, и ако един от тях не работи, веднага изключва няколко реплики.
Ако имате пет възла или повече, всяка реплика ще работи на отделен възел, а неуспехът на един възел ще премахне не повече от една реплика.
По този начин, изискванията за висока наличност могат да изискват определен минимален брой възли в кластера.
Недостатък № 3. По-лоши последствия от отказ
При малък брой възли всеки отказ носи по-сериозни последствия. Например, ако имате само два възла, и един от тях се провали, това веднага елиминира половината от вашите модули.
Разбира се, Kubernetes ще пренасочи натоварването от отказалия се възел на другите. Но ако са малко, свободният капацитет може да не е достатъчен. В резултат част от вашите приложения ще бъдат недостъпни, докато не възстановите отказалия се възел.
По този начин, колкото повече възли - толкова по-малко влияние на хардуерните откази.
Недостатък № 4. Повече стъпки за автоматично мащабиране
В Kubernetes работи система за автоматично мащабиране на клъстера за облачна инфраструктура, което позволява автоматично добавяне или премахване на възел в зависимост от текущите нужди. С големите възли, автоматичното мащабиране става по-остро и тромаво. Например, при два възла, добавянето на допълнителен възел ще увеличи капацитета на клъстера веднага с 50%. И ще трябва да платите за тези ресурси, дори и да не ви трябват.
Следователно, ако планирате да използвате автоматично мащабиране на клъстера, то колкото по-малки са възлите — толкова по-гъвкаво и икономично мащабиране ще получите.
Сега нека разгледаме предимствата и недостатъците на множество малки възли.
Вторият вариант: множество малки възли
Предимствата на този подход всъщност произтичат от недостатъците на противоположния вариант с няколко големи възли.
Плюсове
Плюс № 1. По-малко последици от повреди
Колкото повече възли, толкова по-малко подове на всеки възел. Например, ако имате сто модула на десет възла, то на всеки възел ще има средно по десет модула.
Следователно, ако един от възлите се провали, вие ще загубите само 10% от работното натоварване. Има вероятност, че ще бъдат засегнати само малко реплики, а приложенията като цяло ще останат трудоспособни.
Освен това, на останалите възли, вероятно ще има достатъчно свободни ресурси за работното натоварване на провалилия се възел, така че Kubernetes може свободно да преопрограмира подовете, и вашите приложения сравнително бързо ще се върнат в функционално състояние.
Плюс № 2. Добра репликация
Ако възлите са достатъчно, планиращият Kubernetes може да назначи на всички реплики различни възли. По този начин, в случай на провал на възел, ще бъде засегната само една реплика, а приложението ще остане достъпно.
Минуси
Минус № 1. Осложнено управление
С много възли е по-трудно за управление. Например, всеки възел на Kubernetes трябва да взаимодейства с всички останали, т.е. броят на връзките расте квадратно и всички тези връзки трябва да се проследяват.
Контролерът на възлите в контролера на Kubernetes редовно обхожда всички възли в клъстера, за да провери работоспособността — колкото повече възли, толкова по-голямо е натоварването на контролера.
Нараства и натоварването на базата данни etcd — всеки kubelet и kube-proxy заявява за etcd (чрез API), на който etcd трябва да предава актуализации на обекта.
Общо, всеки работен възел натоварва допълнително системните компоненти на главните възли.
Официално Kubernetes поддържа клъстери с Все пак, на практика 500 възли .
За управление на голям брой работни възли трябва да се избират по-мощни главни възли. Например, kube-up правилния размер на VM за главния възел в зависимост от броя на работните възли. Тоест, колкото повече работни възли, толкова по-мощни трябва да бъдат главните възли.
За решаване на тези специфични проблеми съществуват специални разработки, като Тази система позволява да се заобиколят ограниченията и да се изграждат клъстери с огромно количество работни възли.
Недостатък № 2. Повече разходи
На всеки работен възел Kubernetes стартира набор от системни демони — те включват среда за изпълнение на контейнери (например, Docker), kube-proxy и kubelet, включително cAdvisor. Всички заедно те консумират определено фиксирано количество ресурси.
Ако имате много малки възли, дялът на тези разходи на всеки възел е по-голям. Например, представете си, че всички системни демони на един възел заедно използват 0,1 ядра ЦП и 0,1 ГБ памет. Ако имате един десетядрен възел с 10 ГБ памет, тогава демоните консумират 1% от капацитета на клъстера. От друга страна, на десет едноядрени възли с по 1 ГБ памет демоните ще отнемат 10% от капацитета на клъстера.
Така че, колкото по-малко възли, толкова по-ефективно се използва инфраструктурата.
Недостатък № 3. Неефективно използване на ресурсите
На малки възли може да се получи ситуация, в която останалите фрагменти от ресурсите са твърде малки, за да им бъде назначена някаква работна натоварване, затова остават неизползвани.
Например, всеки pod изисква 0,75 ГБ памет. Ако имате десет възли и на всеки по 1 ГБ памет, можете да стартирате десет pod’а — в крайна сметка на всеки възел ще остане 0,25 ГБ неизползвана памет.
Това означава, че 25% от паметта на целия клъстер се харчи напразно.
На голям възел с 10 ГБ памет можете да стартирате 13 такива модула — и ще остане само един неизползван фрагмент от 0,25 ГБ.
В този случай напразно се харчи само 2,5% от паметта.
По този начин ресурсите се използват оптимално на големите възли.
Няколко големи възли или много малки?
И така, кое е по-добре: няколко големи възли в клъстер или много малки? Както винаги, отговорът не е еднозначен. Много зависи от типа приложение.
Например, ако приложението изисква 10 ГБ памет, изборът в полза на големите възли е очевиден. А ако приложението изисква десеткратна репликация за висока наличност, едва ли е разумно да рискуваме, като поставяме реплики само на два възела — в клъстера трябва да има минимум десет възли.
В междинни ситуации направете избор, базирайки се на предимствата и недостатъците на всеки вариант. Може би някои аргументи са по-актуални за вашата ситуация от други.
И не е необходимо да направите всичките възли да са еднакви по размер. Нищо не пречи да експериментирате първо със възли с еднакъв размер, след това да добавите към тях възли с различен размер, комбинирайки ги в клъстер. Работните възли на клъстера Kubernetes могат да бъдат напълно хетерогенни. Така че можете да опитате да съчетаете предимствата на двата подхода.
Не съществува универсална рецепта, а всяка ситуация има своите нюанси, и само продукцията ще покаже истината.
Преводът е подготвен от екипа на облачната платформа .
Още за Kubernetes: .
Източник: habr.com
