Kubernetes кластерин түзүүдө суроолор пайда болушу мүмкүн: канча жумушчу түйүн конфигурациялоо керек жана кандай түрү? Жергиликтүү кластер үчүн эмнеси жакшы: бир нече күчтүү серверлерди сатып алыңыз же маалымат борборуңузда ондогон эски машиналарды колдонуңуз? Булуттагы сегиз бир ядролуу же эки төрт ядролуу инстанцияларды алуу жакшыбы?
Бул суроолорго жооп макалада. буйруктун котормосунда .
Кластердин сыйымдуулугу
Жалпысынан алганда, Kubernetes кластерин чоң "супер түйүн" катары кароого болот. Анын жалпы эсептөө күчү анын бардык түзүүчү түйүндөрүнүн ыйгарым укуктарынын суммасы болуп саналат.
Каалаган кластердин кубаттуулугуна жетүү үчүн бир нече жолдор бар. Мисалы, бизге жалпы кубаттуулугу 8 процессордун өзөгү жана 32 ГБ оперативдүү эси бар кластер керек, анткени тиркемелердин топтому ушунчалык көп ресурстарды талап кылат. Андан кийин 16 ГБ эс тутуму бар эки түйүн же 8 ГБ эс тутуму бар төрт түйүн, эки төрт ядролуу процессор же төрт эки ядролуу процессорлорду орното аласыз.
Бул жерде кластер түзүүнүн эки гана жолу бар:
Эки вариант тең бирдей кубаттуулуктагы кластерди чыгарат, бирок төмөнкү конфигурацияда төрт кичирээк түйүн жана жогорку конфигурацияда эки чоңураак түйүн бар.
Кайсы вариант жакшыраак?
Бул суроого жооп берүү үчүн эки варианттын тең артыкчылыктарын карап көрөлү. Биз аларды таблицада жыйынтыктап чыктык.
Бир нече чоң түйүндөр
Көптөгөн майда түйүндөр
Кластерди башкаруу жеңилирээк (эгерде ал жерде болсо)
Жылмакай автомасштабтоо
Арзаныраак (эгер жерде болсо)
Баасы бир аз башкача (булутта)
Ресурсту көп талап кылган колдонмолорду иштете алат
Толук репликация
Ресурстар натыйжалуураак колдонулат (системанын демондорунда азыраак чыгым
Кластердин катачылыкка чыдамкайлыгы жогору
Сураныч, биз жумушчу түйүндөр жөнүндө гана сөз болуп жатканын эске алыңыз. Негизги түйүндөрдүн санын жана өлчөмүн тандоо - такыр башка тема.
Ошентип, келгиле, үстөлдүн ар бир пунктун кененирээк талкуулайлы.
Биринчи параметр: бир нече чоң түйүндөр
Эң экстремалдуу вариант - бүт кластердин кубаттуулугу үчүн бир жумушчу түйүн. Жогорудагы мисалда бул 16 CPU өзөгү жана 16 ГБ оперативдүү эси бар бир жумушчу түйүн болмок.
Плюсы
Плюс № 1. Башкаруу жеңилирээк
Бүтүндөй бир паркты башкарууга караганда бир нече машинаны башкаруу оңой. Жаңыртууларды жана оңдоолорду чыгаруу тезирээк жана синхрондоштуруу оңой. Абсолюттук сандардагы каталардын саны да азыраак.
Жогоруда айтылгандардын баары булут инстанцияларына эмес, сиздин жабдыктарыңызга, серверлериңизге тиешелүү экенин эске алыңыз.
Булуттагы абал башкача. Ал жерде башкаруу булут кызматын камсыздоочу тарабынан ишке ашырылат. Ошентип, булуттагы он түйүндү башкаруу бир түйүндү башкаруудан анча деле айырмаланбайт.
Трафиктин маршруту жана жүктү булуттагы поддондор арасында бөлүштүрүү : Интернеттен келген трафик трафикти түйүндөрдүн биринин портуна багыттаган негизги жүк балансына жөнөтүлөт (NodePort кызматы ар бир кластер түйүнүндө портту 30000-32767 диапазонуна орнотот). Kube-proxy тарабынан коюлган эрежелер трафикти түйүндөн подкокко багыттайт. Бул эки түйүндөрдөгү он кабык үчүн кандай көрүнөт:
Pro №2: Бир түйүн үчүн азыраак чыгым
Күчтүү машина кымбатыраак, бирок баанын өсүшү сөзсүз түрдө сызыктуу эмес. Башкача айтканда, 10 ГБ эс тутуму бар бир он ядролуу сервер, адатта, эс тутуму бирдей көлөмдөгү он бир ядролуу серверге караганда арзаныраак.
Бирок бул эреже булут кызматтарында иштебей турганын эске алыңыз. Бардык негизги булут провайдерлеринин учурдагы баа схемаларында баалар кубаттуулукка жараша сызыктуу түрдө жогорулайт.
Ошентип, булутта сиз көбүнчө күчтүү серверлерде сактай албайсыз.
Pro #3: Сиз ресурстарды көп талап кылган колдонмолорду иштете аласыз
Кээ бир колдонмолор кластерде күчтүү серверлерди талап кылат. Мисалы, машинаны үйрөнүү системасы 8 ГБ эстутумду талап кылса, сиз аны 1 ГБ түйүндөрдө иштете албайсыз, бирок жок дегенде бир чоң жумушчу түйүн менен гана иштейсиз.
Минусы
Кемчилик № 1. Ар бир түйүнгө көп кабык
Эгерде ошол эле тапшырма азыраак түйүндөрдө аткарылса, анда алардын ар биринде табигый түрдө көбүрөөк уячалар болот.
Бул көйгөй болушу мүмкүн.
Себеби, ар бир модуль контейнердин иштөө убактысына (мисалы, Docker), ошондой эле kubelet жана cAdvisor үчүн кошумча чыгымдарды киргизет.
Мисалы, кубелет түйүндөгү бардык контейнерлерди үзгүлтүксүз текшерип турат — канчалык көп контейнер болсо, кубелет ошончолук көп жумуш аткарышы керек.
CAdvisor түйүндөгү бардык контейнерлер үчүн ресурстарды колдонуу статистикасын чогултат жана kubelet бул маалыматты үзгүлтүксүз сурап, API аркылуу камсыз кылат. Дагы бир жолу, көбүрөөк контейнерлер cAdvisor жана kubelet үчүн дагы көбүрөөк жумушту билдирет.
Эгерде модулдардын саны көбөйсө, ал системаны жайлатып, ал тургай анын ишенимдүүлүгүн төмөндөтүшү мүмкүн.
Kubernetes репозиторийинде кээ бир бул түйүндөр Даяр/Даяр эмес статустарынын ортосунда өтүшөт, анткени түйүндөгү бардык контейнерлерди кубелет аркылуу үзгүлтүксүз текшерүү өтө көп убакытты талап кылат.
Ушул себептен Kubernetes . Түйүндүн иштешине жараша, ар бир түйүнгө көбүрөөк подкектерди иштете аласыз, бирок көйгөйлөр болобу же баары жакшы иштейби деп айтуу кыйын. Бул ишти алдын ала сынап көрүүгө арзырлык.
Кемчилик №2. Репликацияга чектөө
Өтө аз түйүндөр колдонмону репликациялоонун эффективдүү көлөмүн чектейт. Мисалы, эгер сизде беш репликасы бар, бирок эки гана түйүнү бар жогорку жеткиликтүү тиркеме болсо, анда тиркеменин репликациясынын эффективдүү даражасы экиге чейин кыскарат.
Беш репликаларды эки түйүн боюнча гана бөлүштүрсө болот, эгер алардын бири иштебей калса, ал бир эле учурда бир нече репликаны жок кылат.
Эгер сизде беш же андан көп түйүн болсо, ар бир реплика өзүнчө түйүндө иштейт жана бир түйүн иштебей калса, эң көп дегенде бир репликаны жок кылат.
Ошентип, жеткиликтүүлүктүн жогорку талаптары кластердеги түйүндөрдүн белгилүү бир минималдуу санын талап кылышы мүмкүн.
№3 кемчилик
Аз сандагы түйүндөр менен, ар бир бузулуу олуттуураак кесепеттерге алып келет. Мисалы, сизде эки гана түйүн бар болсо жана алардын бири иштебей калса, модулдарыңыздын жарымы дароо жок болот.
Албетте, Кубернетес жумуш жүгүн ийгиликсиз түйүндөн башкаларга көчүрөт. Бирок алардын саны аз болсо, анда бош кубаттуулук жетишсиз болушу мүмкүн. Натыйжада, сиз ишке ашпай калган түйүндү келтирмейинче колдонмолоруңуздун айрымдары жеткиликсиз болот.
Ошентип, түйүндөр канчалык көп болсо, аппараттык бузулуулардын таасири ошончолук аз болот.
Кемчилик №4: Көбүрөөк автоматтык масштабдоо кадамдары
Kubernetes булут инфраструктурасы үчүн кластердик автоматтык масштабдоо тутумуна ээ, ал учурдагы муктаждыктарыңызга жараша түйүндөрдү автоматтык түрдө кошууга же алып салууга мүмкүндүк берет. Чоң түйүндөр менен автомасштабтоо кескин жана татаал болуп калат. Мисалы, эки түйүндө, кошумча түйүн кошуу кластердин кубаттуулугун дароо 50% га жогорулатат. Жана сизге керек болбосо да, ал ресурстар үчүн төлөөгө туура келет.
Ошентип, сиз автоматтык кластердин масштабын колдонууну пландаштырсаңыз, түйүндөр канчалык кичирээк болсо, ошончолук ийкемдүү жана үнөмдүү масштабга ээ болосуз.
Эми көп сандагы майда түйүндөрдүн артыкчылыктары менен кемчиликтерин карап көрөлү.
Экинчи вариант: көптөгөн майда түйүндөр
Бул ыкманын артыкчылыктары негизинен бир нече чоң түйүндөр менен карама-каршы варианттын кемчиликтеринен келип чыгат.
Плюсы
Pro №1: Ийгиликтин азыраак таасири
Канчалык көп түйүндөр болсо, ар бир түйүндө ошончолук аз. Мисалы, он түйүнгө жүз модулуңуз болсо, анда ар бир түйүндө орто эсеп менен он модул болот.
Ошентип, түйүндөрдүн бири иштебей калса, сиз жумуштун 10% гана жоготосуз. Мүмкүнчүлүктөр аз сандагы репликаларга гана таасирин тийгизип, жалпы колдонмо иштеп кала берет.
Кошумчалай кетсек, калган түйүндөр иштебей калган түйүндүн иш жүгүн көтөрүү үчүн жетиштүү бош ресурстарга ээ болушу мүмкүн, ошондуктан Kubernetes поддондорду эркин башкара алат жана колдонмолоруңуз функционалдык абалына салыштырмалуу тез кайтып келет.
Pro # 2: Жакшы репликация
Эгерде түйүндөр жетиштүү болсо, Kubernetes пландоочусу бардык репликаларга башка түйүндөрдү дайындай алат. Ошентип, түйүн иштебей калса, бир гана репликага таасир этет жана колдонмо жеткиликтүү бойдон калат.
Минусы
Кемчилик №1. Башкаруу кыйын
Көп сандагы түйүндөрдү башкаруу кыйыныраак. Мисалы, ар бир Kubernetes түйүнү башкалар менен баарлашуусу керек, башкача айтканда, байланыштардын саны квадраттык түрдө өсөт жана бул байланыштардын бардыгын көзөмөлдөө керек.
Kubernetes Controller Managerдеги түйүн контроллери ден соолукту текшерүү үчүн кластердеги бардык түйүндөр аркылуу үзгүлтүксүз басып өтөт - түйүндөрдүн саны канчалык көп болсо, контроллерге ошончолук көп жүк келет.
etcd базасына жүктөө да өсүп жатат - ар бир kubelet жана kube-прокси чалуулар etcd үчүн (API аркылуу), ага etcd объект жаңыртууларын таркатышы керек.
Жалпысынан алганда, ар бир жумушчу түйүн башкы түйүндөрдүн системалык компоненттерине кошумча жүктү жүктөйт.
Kubernetes расмий түрдө кластерлерди колдойт . Бирок, иш жүзүндө буга чейин 500 түйүн бар .
Жумушчу түйүндөрүнүн көп санын башкаруу үчүн, сиз күчтүүрөөк мастер түйүндөрдү тандап алышыңыз керек. Мисалы, кубе жумушчу түйүндөрдүн санына жараша мастер түйүн үчүн туура VM өлчөмү. Башкача айтканда, жумушчу түйүндөр канчалык көп болсо, мастер түйүндөр ошончолук өндүрүмдүү болушу керек.
Бул конкреттүү көйгөйлөрдү чечүү үчүн, мисалы, атайын иштеп чыгуулар бар . Бул система чектөөлөрдү айланып өтүүгө жана жумушчу түйүндөрүнүн чоң саны менен кластерлерди курууга мүмкүндүк берет.
Кемчилик №2: Көбүрөөк кошумча чыгымдар.
Ар бир жумушчу түйүндө Kubernetes тутум демондорунун топтомун иштетет - алар контейнердин иштөө убактысын (мисалы, Docker), kube-proxy жана kubelet, анын ичинде cAdvisor камтыйт. Алар биргелешип белгилүү бир белгиленген өлчөмдөгү ресурстарды керектешет.
Эгер сизде майда түйүндөр көп болсо, ар бир түйүндө бул үстөктүн үлүшү чоңураак болот. Мисалы, бир түйүндөгү бардык система демондору чогуу 0,1 CPU өзөктөрүн жана 0,1 ГБ эстутумду колдоноорун элестетиңиз. Эгер сизде 10 ГБ эс тутуму бар бир он ядролуу түйүн болсо, анда демондор кластердин сыйымдуулугунун 1% ын керектейт. Башка жагынан алганда, 1 ГБ эс тутуму бар он бир ядролуу түйүндөрдө демондор кластердин сыйымдуулугунун 10% ээлейт.
Ошентип, түйүндөр канчалык аз болсо, инфраструктура ошончолук эффективдүү колдонулат.
Кемчилик №3. Ресурстарды эффективдүү пайдалануу
Кичинекей түйүндөрдө, калган ресурстук бөлүктөр кандайдыр бир жумуш жүгүн дайындоо үчүн өтө кичинекей болгондуктан, алар пайдаланылбай калышы мүмкүн.
Мисалы, ар бир поддон 0,75 ГБ эстутум талап кылат. Эгер сизде ар биринде 1 ГБ эстутум бар он түйүн болсо, ар бир түйүнгө 0,25 ГБ колдонулбаган эстутум калтырып, он поддонду иштете аласыз.
Бул бүткүл кластердин эс тутумунун 25% текке кетет дегенди билдирет.
10 ГБ эс тутуму бар чоң түйүндө сиз бул модулдардын 13үн иштете аласыз - жана 0,25 ГБ колдонулбаган бир гана фрагмент болот.
Бул учурда эстутумдун 2,5% гана бошко кетет.
Ошентип, ресурстар чоң түйүндөрдө оптималдуураак колдонулат.
Бир нече чоң түйүндөрбү же көп майдаларыбы?
Демек, кайсынысы жакшы: кластерде бир нече чоң түйүндөрбү же көп майда түйүндөрбү? Адаттагыдай эле, так жооп жок. Көп нерсе өтүнмөнүн түрүнө жараша болот.
Мисалы, эгер тиркеме 10 ГБ эстутумду талап кылса, чоңураак түйүндөр анык тандоо болуп саналат. Жана эгер тиркеме жогорку жеткиликтүүлүк үчүн он эселенген репликацияны талап кылса, репликаларды эки эле түйүнгө жайгаштыруу тобокелдигине арзыбайт - кластерде эң аз он түйүн болушу керек.
Ортодогу кырдаалда ар бир варианттын артыкчылыктары жана кемчиликтери боюнча тандоо жасаңыз. Балким, кээ бир аргументтер башкаларга караганда сиздин абалыңызга көбүрөөк тиешелүү.
Жана бардык түйүндөрдү бирдей өлчөмдө жасоонун кереги жок. Адегенде бирдей өлчөмдөгү түйүндөр менен эксперимент жүргүзүүгө, андан кийин аларга башка өлчөмдөгү түйүндөрдү кошууга, аларды кластерге бириктирүүгө эч нерсе тоскоол болбойт. Kubernetes кластериндеги жумушчу түйүндөр толугу менен гетерогендүү болушу мүмкүн. Ошентип, сиз эки ыкманын артыкчылыктарын айкалыштырууга аракет кылсаңыз болот.
Эч бир рецепт жок, ар бир кырдаалдын өзүнүн нюанстары бар, бир гана өндүрүш чындыкты көрсөтөт.
Котормо булут платформа командасы тарабынан даярдалган .
Kubernetes жөнүндө көбүрөөк маалымат: .
Source: www.habr.com
