При създаването на кластер Kubernetes могат да възникнат въпроси: колко работни възли да се настроят и какъв тип? Какво е по-добре за локален кластер: да купите няколко мощни сървъра или да използвате десетина стари машини във вашия дата център? А в облака по-добре ли е да вземете осем едноядрени инстанции или две четириядрени?
Отговорите на тези въпроси са в статията в превода на екипа .
Капацитет на клъстера
Като цяло, кластерът Kubernetes може да се разглежда като голям "супер възел". Общата му изчислителна мощ е сумата от мощностите на всички съставляващи възли.
Съществуват няколко начина за постигане на желаната целева вместимост на клъстера. Например, нуждаем се от кластер с общ капацитет от 8 процесорни ядра и 32 GB оперативна памет, тъй като наборът от приложения изисква такова количество ресурси. Тогава можем да инсталираме два възела с 16 GB памет или четири възела с 8 GB памет, два четириядрени процесора или четири двуядрени.
Ето само два възможни начина за създаване на кластер:
И двете опции дават кластер с еднакъв капацитет, но в конфигурацията отдолу са инсталирани четири по-малки възла, а в конфигурацията отгоре — два по-големи.
Кой вариант е по-добър?
За да отговорим на този въпрос, ще разгледаме предимствата на двата варианта. Събрахме ги в таблица.
Няколко големи възли
Много малки възли
По-лесно управление на клъстера (ако е локален)
Плавно автоматично мащабиране
По-евтино (ако е локално)
Цената е почти еднаква (в облака)
Могат да се изпълняват ресурсоемки приложения
Пълноценно репликиране
Ресурсите се използват по-ефективно (по-малко оверхед за системни демони)
По-висока отказоустойчивост на клъстера
Обърнете внимание, че говорим само за работните възли. Изборът на количество и размер на главните възли е съвсем различна тема.
И така, нека разгледаме по-подробно всяка точка от таблицата.
Първи вариант: няколко големи възли
Най-екстремният вариант е един работен възел за целия капацитет на клъстера. В примера по-горе това би бил един работен възел с 16 ядра ЦП и 16 GB оперативна памет.
Плюсове
Плюс № 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 някои , че възлите прескачат между статусите Ready/NotReady, тъй като редовните проверки на kubelet за всички контейнери на възела отнемат твърде много време.
Поради тази причина Kubernetes . В зависимост от производителността на възела можете да пуснете повече pod’ове на възел, но е трудно да се предвиди дали ще възникнат проблеми или всичко ще работи добре. Струва си предварително да тествате работата.
Недостатък № 2. Ограничение за репликация
Твърде малкият брой възли ограничава ефективната степен на репликация на приложенията. Например, ако имате приложение с висока наличност от пет реплики, но само два възла, ефективната степен на репликация на приложението намалява на две.
Пет реплики могат да се разпределят само на два възла, и ако един от тях не работи, веднага изключва няколко реплики.
Ако имате пет или повече възли, всяка реплика ще се изпълнява на отделен възел, а повредата на един възел ще премахне не повече от една реплика.
Следователно, изискванията за висока наличност могат да изискват наличие на определен минимален брой възли в кластера.
Недостатък № 3. По-лоши последствия от повреда
При малък брой възли всяка повреда има по-сериозни последствия. Например, ако имате само два възла и единият от тях се повреди, половината от вашите модули изчезват веднага.
Разбира се, Kubernetes ще премести натоварването от повредения възел на други. Но ако те са малко, свободният капацитет може да не е достатъчен. В резултат на това част от вашите приложения ще бъдат недостъпни, докато не стартирате отново повредения възел.
Така че, колкото повече възли — толкова по-малко влияние на хардуерните повреди.
Недостатък № 4. По-големи стъпки за автоматично мащабиране
В Kubernetes работи система за автоматично мащабиране на клъстера за облачна инфраструктура, което позволява автоматично добавяне или премахване на възли в зависимост от текущите нужди. С големи възли автоматичното мащабиране става по-рязко и неудобно. Например, добавянето на допълнителен възел при два възела увеличава капацитета на клъстера веднага с 50%. И вие ще трябва да платите за тези ресурси, дори ако не са ви нужни.
Следователно, ако планирате да използвате автоматично мащабиране на клъстера, то колкото по-малки са възлите - толкова по-гъвкаво и икономично мащабиране ще получите.
Сега нека разгледаме предимствата и недостатъците на голям брой малки възли.
Втора опция: много малки възли
Предимствата на този подход по същество произтичат от недостатъците на противоположния вариант с няколко големи възли.
Плюсове
Плюс № 1. По-малко последствия от сбой
Чем повече възли, толкова по-малко pod’ове на всеки възел. Например, ако имате сто модула на десет възла, то на всеки възел ще има средно по десет модула.
По този начин, ако един от възлите се повреди, вие губите само 10% от работната натовареност. Има вероятност да бъде засегнато само малко количество реплики, а приложенията по принцип да останат в работно състояние.
Освен това, на останалите възли вероятно ще има достатъчно свободни ресурси за работната натовареност на повредения възел, така че Kubernetes може свободно да преразпредели pod’ите и вашите приложения относително бързо да се върнат в работно състояние.
Плюс № 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 ядра CPU и 0,1 GB RAM. Ако имате един десетоядрен възел с 10 GB RAM, демоните консумират 1% от капацитета на клъстера. От друга страна, на десет едноядрени възли с по 1 GB RAM демоните ще вземат 10% от капацитета на клъстера.
Следователно, колкото по-малко възли, толкова по-ефективно се използва инфраструктурата.
Недостатък № 3. Неефективно използване на ресурсите
На малки възли може да възникне ситуация, при която останалите фрагменти от ресурси са твърде малки, за да бъдат назначени за някаква работна натовареност, поради което остават неизползвани.
Например, всеки pod изисква 0,75 GB RAM. Ако имате десет възли, и на всеки по 1 GB RAM, можете да стартирате десет pod’а — в крайна сметка на всеки възел ще остане 0,25 GB неизползвана памет.
Това означава, че 25% от паметта на целия клъстер се губи.
На голям възел с 10 GB RAM можете да стартирате 13 такива модула — и ще остане само един неизползван фрагмент от 0,25 GB.
В този случай в пустошта се харчат само 2,5% от паметта.
По този начин ресурсите се разпределят оптимално на големите възли.
Няколко големи възли или много малки?
И така, което е по-добре: няколко големи възли в кластера или много малки? Както винаги, няма еднозначен отговор. Много зависи от типа на приложението.
Например, ако приложението изисква 10 ГБ памет, очевидният избор е за големите възли. А ако приложението изисква десеткратна репликация за висока наличност, едва ли трябва да рискувате, разполагавайки репликите само на два възла — в кластера трябва да има минимум десет възла.
В междинни ситуации направете избора си, основавайки се на предимствата и недостатъците на всеки вариант. Може би някои аргументи са по-актуални за вашата ситуация, отколкото други.
Не е задължително всички възли да са еднакви по размер. Нищо не пречи да експериментирате първо с възли на еднакъв размер, след което да добавите възли с различен размер, комбинирайки ги в кластера. Работните възли на Kubernetes могат да бъдат напълно хетерогенни. Така че можете да опитате да комбинирате предимствата на двата подхода.
Не съществува универсална рецепта, а всяка ситуация има своите нюанси, и само продукцията ще покаже истината.
Преводът е подготвен от екипа на облачната платформа. .
Още за Kubernetes: .
Източник: habr.com
