Kubernetes работнички јазли: многу мали или неколку големи?

Кога креирате кластер Kubernetes, може да се појават прашања: колку работни јазли да се конфигурираат и каков тип? Што е подобро за кластер во просторија: купете неколку моќни сервери или користете десетина стари машини во вашиот центар за податоци? Дали е подобро да земете осум еднојадрени или две четири-јадрени примероци во облакот?

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

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

Општо земено, кластерот Кубернетс може да се смета како голем „суперјазол“. Неговата вкупна пресметковна моќ е збирот на моќите на сите негови составни јазли.

Постојат неколку начини да ја постигнете саканата цел за капацитет на кластерот. На пример, потребен ни е кластер со вкупен капацитет од 8 процесорски јадра и 32 GB RAM, бидејќи збир на апликации бара толку многу ресурси. Потоа можете да инсталирате два јазли со 16 GB меморија или четири јазли со 8 GB меморија, два процесори со четири јадра или четири двојадрени.

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

Двете опции произведуваат кластер со ист капацитет, но долната конфигурација има четири помали јазли, а горната конфигурација има два поголеми јазли.

Која опција е подобра?

За да одговориме на ова прашање, да ги погледнеме предностите на двете опции. Ги сумиравме во табела.

Неколку големи јазли

Многу мали јазли

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

Непречено автоматско скалирање

Поевтино (ако е во просторија)

Цената е малку поинаква (во облакот)

Може да работи апликации со интензивни ресурси

Целосна репликација

Ресурсите се користат поефикасно (помалку трошоци за системските демони
Поголема толеранција на грешки во кластерот

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

Значи, да разговараме за секоја точка од табелата подетално.

Првата опција: неколку големи јазли

Најекстремната опција е еден работник јазол за целиот капацитет на кластерот. Во примерот погоре, ова ќе биде еден работник јазол со 16 јадра на процесорот и 16 GB RAM меморија.

Добрите

Плус бр. 1. Полесно управување
Полесно е да управувате со неколку машини отколку со цела флота. Побрзо се објавуваат ажурирања и поправки и полесно е да се синхронизираат. Помал е и бројот на неуспеси во апсолутни бројки.

Ве молиме имајте предвид дека сето горенаведено се однесува на вашиот хардвер, вашите сервери, а не на примероци во облак.

Ситуацијата е поинаква во облакот. Таму, управувањето го води давателот на облак услуги. Така, управувањето со десет јазли во облакот не се разликува многу од управувањето со еден јазол.

Рутирање на сообраќајот и дистрибуција на оптоварување помеѓу мешунките во облакот се врши автоматски. Правилата поставени од kube-proxy го пренасочуваат сообраќајот од јазолот до подлогата. Еве како изгледаат десет мешунки на два јазли:

Про #2: Помали трошоци по јазол
Моќниот автомобил е поскап, но зголемувањето на цената не е нужно линеарно. Со други зборови, еден сервер со десет јадра со 10 GB меморија обично е поевтин од десет сервери со едно јадрени со иста количина на меморија.

Но, имајте во предвид дека ова правило обично не функционира во облак услугите. Во тековните шеми за цени на сите големи даватели на облак, цените се зголемуваат линеарно со капацитетот.

Така, во облакот обично не можете да заштедите на помоќни сервери.

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

Конс

Недостаток бр. 1. Многу мешунки по јазол
Ако истата задача се изведува на помалку јазли, тогаш секој од нив природно ќе има повеќе мешунки.

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

Причината е тоа што секој модул воведува некои надземни трошоци за траење на контејнерот (на пр. Docker), како и kubelet и cAdvisor.

На пример, кубелет редовно ги испитува сите контејнери на јазолот за опстанок - колку повеќе контејнери, толку повеќе работа треба да заврши кубелетот.

CAdvisor собира статистика за користење ресурси за сите контејнери на јазолот, а kubelet редовно ги бара овие информации и ги обезбедува преку API. Повторно, повеќе контејнери значи повеќе работа и за cAdvisor и за kubelet.

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

Во складиштето на Кубернетес некои се пожалидека јазлите скокаат помеѓу статусите Ready/NotReady бидејќи редовните кубелет проверки на сите контејнери на јазол траат премногу долго.
Поради оваа причина Kubernetes препорачува да се стават не повеќе од 110 мешунки по јазол. Во зависност од перформансите на јазолот, можете да извршите повеќе подлоги по јазол, но тешко е да се предвиди дали ќе има проблеми или сè ќе работи добро. Вреди да се тестира работата однапред.

Недостаток бр. 2. Ограничување на репликацијата
Премалку јазли го ограничуваат ефективниот степен на репликација на апликацијата. На пример, ако имате апликација со висока достапност со пет реплики, но само два јазли, тогаш ефективниот степен на репликација на апликацијата се намалува на два.

Пет реплики може да се дистрибуираат само на два јазли, а ако еден од нив не успее, ќе отстрани повеќе реплики одеднаш.

Ако имате пет или повеќе јазли, секоја реплика ќе работи на посебен јазол, а неуспехот на еден јазол ќе отстрани најмногу една реплика.

Така, високите барања за достапност може да бараат одреден минимален број на јазли во кластерот.

Недостаток бр. 3. Полоши последици од неуспехот
Со мал број јазли, секој неуспех има посериозни последици. На пример, ако имате само два јазли и еден од нив не успее, половина од вашите модули исчезнуваат веднаш.

Се разбира, Kubernetes ќе го префрли обемот на работа од неуспешниот јазол на други. Но, ако има малку од нив, тогаш можеби нема да има доволно слободен капацитет. Како резултат на тоа, некои од вашите апликации ќе бидат недостапни додека не го појавите неуспешниот јазол.

Така, колку повеќе јазли, толку е помало влијанието на хардверските неуспеси.

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

Така, ако планирате да користите автоматско скалирање на кластери, колку се помали јазлите, толку пофлексибилно и поекономично ќе добиете скалирање.

Сега да ги погледнеме предностите и недостатоците на голем број мали јазли.

Втора опција: многу мали јазли

Предностите на овој пристап во суштина произлегуваат од недостатоците на спротивната опција со неколку големи јазли.

Добрите

Про #1: Помало влијание од неуспехот
Колку повеќе јазли, толку помалку мешунки на секој јазол. На пример, ако имате сто модули на десет јазли, тогаш секој јазол ќе има во просек десет модули.

На овој начин, ако еден од јазлите не успее, губите само 10% од обемот на работа. Шансите се дека само мал број реплики ќе бидат засегнати и целокупната апликација ќе остане оперативна.

Дополнително, преостанатите јазли веројатно ќе имаат доволно бесплатни ресурси за да се справат со обемот на работа на неуспешниот јазол, така што Kubernetes може слободно да ги презакажува подлогите и вашите апликации ќе се вратат во функционална состојба релативно брзо.

Про #2: Добра репликација
Ако има доволно јазли, распоредувачот на Kubernetes може да додели различни јазли на сите реплики. На овој начин, ако некој јазол не успее, само една реплика ќе биде засегната и апликацијата ќе остане достапна.

Конс

Недостаток бр. 1. Тешко се контролира
Потешко е да се управуваат со голем број јазли. На пример, секој Kubernetes јазол мора да комуницира со сите други, односно, бројот на врски расте квадратно и сите овие врски треба да се следат.

Контролорот на јазли во Kubernetes Controller Manager редовно поминува низ сите јазли во кластерот за да го провери здравјето - колку повеќе јазли, толку повеќе се оптоварува контролорот.

Расте и оптоварувањето на базата на податоци etcd - секој Kubelet и Kube-proxy повици набљудувач за etcd (преку API), на кој etcd треба да емитува ажурирања на објекти.

Општо земено, секој работник јазол наметнува дополнително оптоварување на системските компоненти на главните јазли.

Kubernetes официјално поддржува кластери со број на јазли до 5000. Сепак, во пракса веќе има 500 јазли може да предизвика нетривијални проблеми.

За да управувате со голем број работнички јазли, треба да изберете помоќни главни јазли. На пример, кубе-ап автоматски се инсталира правилната големина на VM за главниот јазол во зависност од бројот на работнички јазли. Односно, колку повеќе работнички јазли, толку попродуктивни треба да бидат главните јазли.

За да се решат овие конкретни проблеми постојат посебни случувања, како на пр Виртуелна куберет. Овој систем ви овозможува да ги заобиколите ограничувањата и да изградите кластери со огромен број работнички јазли.

Недостаток # 2: Повеќе режиски трошоци.
На секој работник јазол, Kubernetes работи збир на системски демони - тие вклучуваат време на траење на контејнерот (како што е Docker), kube-proxy и kubelet, вклучувајќи го и cAdvisor. Заедно трошат одредена фиксна количина на ресурси.

Ако имате многу мали јазли, процентот на овие надземни трошоци на секој јазол е поголем. На пример, замислете дека сите системски демони на еден јазол заедно користат 0,1 јадра на процесорот и 0,1 GB меморија. Ако имате еден јазол со десет јадра со 10 GB меморија, тогаш демоните трошат 1% од капацитетот на кластерот. Од друга страна, на десет еднојадрени јазли со 1 GB меморија, демоните ќе заземат 10% од капацитетот на кластерот.

Така, колку помалку јазли, толку поефикасно се користи инфраструктурата.

Недостаток бр. 3. Неефикасно користење на ресурсите
На малите јазли, може да биде дека преостанатите делови од ресурси се премногу мали за да им се додели оптоварување на работа, па тие остануваат неискористени.

На пример, секој подлога бара 0,75 GB меморија. Ако имате десет јазли, секој со 1 GB меморија, можете да извршите десет места, оставајќи го секој јазол со 0,25 GB неискористена меморија.

Ова значи дека 25% од меморијата на целиот кластер е залудно потрошена.

На голем јазол со 10 GB меморија, можете да извршите 13 од овие модули - и ќе има само еден неискористен фрагмент од 0,25 GB.

Во овој случај, само 2,5% од меморијата се троши.

Така, ресурсите се користат пооптимално на поголемите јазли.

Неколку големи јазли или многу мали?

Значи, што е подобро: неколку големи јазли во кластер или многу мали? Како и секогаш, нема јасен одговор. Многу зависи од видот на апликацијата.

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

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

И воопшто не е неопходно сите јазли да се направат со иста големина. Ништо не ве спречува да експериментирате прво со јазли со иста големина, а потоа да додавате јазли со различна големина на нив, комбинирајќи ги во кластер. Работничките јазли во кластерот Kubernetes можат да бидат целосно хетерогени. Така, можете да се обидете да ги комбинирате предностите на двата пристапи.

Не постои единствен рецепт, а секоја ситуација има свои нијанси, а само производството ќе ја покаже вистината.

Превод подготвен од тимот на облак платформата Mail.ru Cloud Solutions.

Повеќе за Kubernetes: 25 Корисни алатки за управување и распоредување кластери.

Извор: www.habr.com