Пры стварэнні кластара Kubernetes могуць узнікаць пытанні: колькі наладзіць працоўных вузлоў і якога тыпу? Што лепш для кластара on-premise: купіць некалькі магутных сервераў ці задзейнічаць дзясятак старых машын у вашым дата-цэнтры? А ў воблаку лепш узяць восем аднаядзерных ці два чатырох'ядравыя інстансы?
Адказы на гэтыя пытанні - у артыкуле у перакладзе каманды .
Ёмістасць кластара
У цэлым, кластар Kubernetes можна разглядаць як вялікі "супервузел". Яго агульная вылічальная магутнасць з'яўляецца сумай магутнасцяў усіх складнікаў вузлоў.
Існуе некалькі спосабаў дасягнуць жаданай мэтавай ёмістасці кластара. Напрыклад, нам патрэбен кластар з агульнай ёмістасцю 8 працэсарных ядраў і 32 ГБ аператыўнай памяці, таму што набор прыкладанняў патрабуе такой колькасці рэсурсаў. Тады можна ўсталяваць два вузла па 16 ГБ памяці або чатыры вузла па 8 ГБ памяці, два чатырох'ядравых працэсара або чатыры двух'ядравых.
Вось толькі два магчымыя спосабы стварэння кластара:
Абедзве опцыі даюць кластар з аднолькавай ёмістасцю, але ў канфігурацыі знізу ўсталявана чатыры малодшых вузла, а ў канфігурацыі зверху - два вялікіх.
Які варыянт лепш?
Каб адказаць на гэтае пытанне, разгледзім перавагі абодвух варыянтаў. Мы звялі іх у табліцу.
Некалькі вялікіх вузлоў
Шмат маленькіх вузлоў
Прасцей кіраванне кластарам (калі ён on-premise)
Плыўнае аўтамаштабаванне
Танней (калі on-premise)
Кошт мала адрозніваецца (у воблаку)
Можна запускаць рэсурсаёмістыя прыкладанні
Паўнавартасная рэплікацыя
Рэсурсы выкарыстоўваюцца больш эфектыўна (менш аверхед на сістэмныя дэманы)
Вышэй адмоваўстойлівасць кластара
Звярніце ўвагу, што мы гаворым толькі пра працоўныя вузлы. Выбар колькасці і памеру галоўных вузлоў - зусім іншая тэма.
Такім чынам, абмяркуем падрабязней кожны пункт з табліцы.
Першы варыянт: некалькі вялікіх вузлоў
Самы экстрэмальны варыянт - адзін працоўны вузел на ўсю ёмістасць кластара. У прыкладзе вышэй гэта быў бы адзін працоўны вузел з 16 ядрамі ЦП і 16 ГБ аператыўнай памяці.
Плюсы
Плюс № 1. Прасцей кіраванне
Прасцей кіраваць некалькімі машынамі, чым цэлым паркам. Хутчэй накатваць абнаўленні і выпраўленні, прасцей сінхранізаваць. Колькасць збояў у абсалютных лічбах таксама меншая.
Звярніце ўвагу, што ўсё вышэйсказанае ставіцца да свайго жалеза, сваіх сервераў, а не да хмарных інстанс.
У воблаку іншая сітуацыя. Там упраўленнем займаецца пастаўшчык хмарных паслуг. Такім чынам, кіраванне дзесяццю вузламі ў воблаку асоба не адрозніваецца ад кіравання адным вузлом.
Маршрутызацыя трафіку і размеркаванне нагрузкі паміж падамі ў воблаку : трафік, які прыходзіць з інтэрнэту, накіроўваецца на асноўны балансавальнік нагрузкі, той накіроўвае трафік на порт аднаго з вузлоў (сэрвіс NodePort выстаўляе порт у дыяпазоне 30000-32767 у кожным вузле кластара). Правілы, усталяваныя kube-proxy, перанакіроўваюць трафік з вузла на пад. Вось як гэта выглядае для дзесяці падоў на двух вузлах:
Плюс № 2. Менш затрат на вузел
Магутная машына даражэйшая, але рост цаны не абавязкова лінейны. Іншымі словамі, адзін дзесяціядзерны сервер з 10 ГБ памяці звычайна танней, чым дзесяць аднаядзерных з той жа колькасцю памяці.
Але звернеце ўвагу, што гэтае правіла звычайна не працуе ў хмарных сэрвісах. У бягучых схемах коштаўтварэння ва ўсіх асноўных пастаўшчыкоў хмарных паслуг кошту растуць лінейна з павелічэннем ёмістасці.
Такім чынам, у воблаку звычайна нельга зэканоміць на больш магутных сэрверах.
Плюс № 3. Можна запускаць рэсурсаёмістыя прыкладанні
Некаторым прыкладанням неабходны магутныя серверы ў кластары. Напрыклад, калі сістэма машыннага навучання патрабуе 8 ГБ памяці, вы не зможаце запусціць яе на вузлах па 1 ГБ, а толькі пры наяўнасці хаця б аднаго вялікага працоўнага вузла.
Мінусы
Мінус № 1. Шмат pod'аў на вузел
Калі адна і тая ж задача выконваецца на меншай колькасці вузлоў, то на кожным з іх, натуральна, будзе больш пад'аў.
Гэта можа стаць праблемай.
Чыннік у тым, што кожны модуль уносіць некаторыя накладныя выдаткі на асяроддзе выканання кантэйнера (напрыклад, Docker), а таксама kubelet і cAdvisor.
Напрыклад, kubelet рэгулярна зандуе на жывучасць усе кантэйнеры на вузле - чым больш кантэйнераў, тым больш працы ў kubelet.
CAdvisor збірае статыстыку выкарыстання рэсурсаў усіх кантэйнераў на вузле, а kubelet рэгулярна запытвае гэтую інфармацыю і дае яе праз API. Ізноў жа, чым больш кантэйнераў, тым больш працы і для cAdvisor, і для kubelet.
Калі колькасць модуляў вырасце, гэта можа запаволіць сістэму і нават падарваць яе надзейнасць.
У рэпазітары Kubernetes некаторыя , Што вузлы скачуць паміж статутамі Ready/NotReady, паколькі рэгулярныя праверкі kubelet ўсіх кантэйнераў на вузле займаюць занадта шмат часу.
Па гэтай прычыне Kubernetes . У залежнасці ад прадукцыйнасці вузла вы можаце запускаць больш падоў на вузел, але цяжка прадказаць, узнікнуць праблемы ці ўсё будзе працаваць добра. Варта загадзя пратэставаць працу.
Мінус № 2. Абмежаванне на рэплікацыю
Занадта малы лік вузлоў абмяжоўвае эфектыўную ступень рэплікацыі прыкладанняў. Напрыклад, калі ў вас дадатак высокай даступнасці з пяці рэплік, але толькі два вузла, то эфектыўная ступень рэплікацыі прыкладання памяншаецца да двух.
Пяць рэплік можна размеркаваць толькі на два вузлы, і калі адзін з іх не працуе, ён адразу выводзіць са строю некалькі рэплік.
Калі ў вас пяць вузлоў ці больш, кожная рэпліка будзе выконвацца на асобным вузле, а збой аднаго вузла выдаліць не больш за адну рэпліку.
Такім чынам, патрабаванні высокай даступнасці могуць запатрабаваць наяўнасці вызначанай мінімальнай колькасці вузлоў у кластары.
Мінус № 3. Горшыя наступствы збою
Пры невялікай колькасці вузлоў кожны збой нясе больш сур'ёзныя наступствы. Напрыклад, калі ў вас усяго два вузлы, і адзін з іх выходзіць са строю, знікае адразу палова вашых модуляў.
Вядома, Kubernetes перанясе працоўную нагрузку з які адмовіў вузла на іншыя. Але калі іх мала, то вольнай ёмістасці можа не хапіць. У выніку частка вашых прыкладанняў будуць недаступныя, пакуль вы не падымеце які адмовіў вузел.
Такім чынам, чым больш вузлоў - тым менш уплыў апаратных збояў.
Мінус № 4. Больш за крокі аўтамаштабавання
У Kubernetes працуе сістэма аўтамаштабавання кластара для хмарнай інфраструктуры, што дазваляе аўтаматычна дадаваць або выдаляць вузлы ў залежнасці ад бягучых запатрабаванняў. З вялікімі вузламі аўтамаштабаванне становіцца больш рэзкім і нязграбным. Напрыклад, на двух вузлах даданне дадатковага вузла павялічыць ёмістасць кластара адразу на 50%. І вам давядзецца заплаціць за гэтыя рэсурсы, нават калі яны вам не патрэбныя.
Такім чынам, калі вы плануеце выкарыстоўваць аўтаматычнае маштабаванне кластара, то чым менш вузлы - тым больш гнуткае і эканамічнае маштабаванне вы атрымаеце.
Цяпер разгледзім перавагі і недахопы вялікай колькасці маленькіх вузлоў.
Другі варыянт: мноства маленькіх вузлоў
Перавагі гэтага падыходу, у сутнасці, выцякаюць з недахопаў процілеглага варыянту з некалькімі буйнымі вузламі.
Плюсы
Плюс № 1. Менш наступствы збою
Чым больш вузлоў, тым менш пад'аў на кожным вузле. Напрыклад, калі ў вас сто модуляў на дзесяць вузлоў, то на кожным вузле будзе ў сярэднім па дзесяць модуляў.
Такім чынам, калі адзін з вузлоў выходзіць са строю, вы губляеце ўсяго 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 ядра ЦП і 0,1 ГБ памяці. Калі ў вас адзін дзесяціядзерны вузел з 10 ГБ памяці, то дэманы спажываюць 1% ёмістасці кластара. З іншага боку, на дзесяці аднаядзерных вузлах па 1 ГБ памяці дэманы забяруць 10% ёмістасці кластара.
Такім чынам, чым менш вузлоў, тым больш эфектыўна выкарыстоўваецца інфраструктура.
Мінус № 3. Неэфектыўнае выкарыстанне рэсурсаў
На маленькіх вузлах можа скласціся сітуацыя, што астатнія фрагменты рэсурсаў занадта малыя, каб прызначыць ім нейкую працоўную нагрузку, таму яны застаюцца невыкарыстоўванымі.
Напрыклад, кожны pod патрабуе 0,75 ГБ памяці. Калі ў вас дзесяць вузлоў, і на кожным па 1 ГБ памяці, можна запусціць дзесяць pod'ов - у выніку на кожным вузле застанецца 0,25 ГБ невыкарыстоўваемай памяці.
Гэта азначае, што 25% памяці ўсяго кластара марнуецца марна.
На вялікім вузле з 10 ГБ памяці вы можаце запусціць 13 такіх модуляў – і застанецца ўсяго адзін невыкарыстоўваны фрагмент 0,25 ГБ.
У гэтым выпадку марна расходуецца толькі 2,5, XNUMX% памяці.
Такім чынам, на вялікіх вузлах больш аптымальна выдаткоўваюцца рэсурсы.
Некалькі вялікіх вузлоў ці шмат маленькіх?
Такім чынам, што ж лепш: некалькі вялікіх вузлоў у кластары ці шмат маленькіх? Як заўсёды, адназначнага адказу няма. Многае залежыць ад тыпу прыкладання.
Напрыклад, калі з дадаткам патрабуецца 10 ГБ памяці, відавочны выбар на карысць вялікіх вузлоў. А калі прыкладанне патрабуе дзесяціразовай рэплікацыі для высокай даступнасці, наўрад ці варта рызыкаваць, размяшчаючы рэплікі за ўсё на двух вузлах - у кластары павінна быць мінімум дзесяць вузлоў.
У прамежкавых сітуацыях рабіце выбар, зыходзячы з пераваг і недахопаў кожнага варыянта. Магчыма, нейкія аргументы больш актуальныя для вашай сітуацыі за іншыя.
І зусім не абавязкова рабіць усё вузлы аднолькавага памеру. Нішто не замінае эксперыментаваць спачатку з вузламі аднаго памеру, потым дадаць да іх вузлы іншага памеру, спалучаючы іх у кластары. Рабочыя вузлы кластара Kubernetes могуць быць цалкам гетэрагеннымі. Так што можна паспрабаваць сумясціць перавагі абодвух падыходаў.
Адзінага рэцэпту не існуе, а ў кожнай сітуацыі свае нюансы, і толькі прадакшн пакажа праўду.
Пераклад падрыхтаваны камандай хмарнай платформы .
Яшчэ пра Kubernetes: .
Крыніца: habr.com