Kubernetes кластерін жасау кезінде сұрақтар туындауы мүмкін: конфигурациялау үшін қанша жұмыс түйіні және қандай түрі бар? Жергілікті кластер үшін не жақсы: бірнеше қуатты серверлерді сатып алу немесе деректер орталығында ондаған ескі машиналарды пайдалану? Бұлтта сегіз бір ядролы немесе екі төрт ядролы дананы алған дұрыс па?
Бұл сұрақтарға жауаптар мақалада. команданың аудармасында .
Кластердің сыйымдылығы
Жалпы алғанда, Кубернетес кластерін үлкен «супертүйін» ретінде қарастыруға болады. Оның жалпы есептеу қуаты оны құрайтын барлық түйіндердің қуаттарының қосындысы болып табылады.
Қалаған кластер сыйымдылығы мақсатына жетудің бірнеше жолы бар. Мысалы, бізге жалпы сыйымдылығы 8 процессор өзегі және 32 ГБ оперативті жады бар кластер қажет, себебі қолданбалар жиынтығы өте көп ресурстарды қажет етеді. Содан кейін 16 ГБ жады бар екі түйінді немесе 8 ГБ жады бар төрт түйінді, екі төрт ядролы процессорды немесе төрт екі ядролы төрт түйінді орнатуға болады.
Мұнда кластерді құрудың екі мүмкін жолы бар:
Екі опция бірдей сыйымдылығы бар кластерді шығарады, бірақ төменгі конфигурацияда төрт кішірек түйін және жоғарғы конфигурацияда екі үлкенірек түйін бар.
Қай нұсқа жақсырақ?
Бұл сұраққа жауап беру үшін екі нұсқаның да артықшылықтарын қарастырайық. Біз оларды кестеде жинақтадық.
Бірнеше үлкен түйіндер
Көптеген шағын түйіндер
Кластерді басқару оңайырақ (егер ол жергілікті болса)
Тегіс автомасштабтау
Арзанырақ (егер жергілікті болса)
Бағасы сәл өзгеше (бұлтта)
Ресурсты көп қажет ететін қолданбаларды іске қоса алады
Толық репликация
Ресурстар тиімдірек пайдаланылады (жүйе демондарына аз шығын
Кластердің ақауларға төзімділігі жоғары
Назар аударыңыз, біз тек жұмысшы түйіндері туралы айтып отырмыз. Негізгі түйіндердің саны мен өлшемін таңдау - мүлдем басқа тақырып.
Сонымен, кестедегі әрбір тармақты толығырақ талқылайық.
Бірінші нұсқа: бірнеше үлкен түйіндер
Ең экстремалды опция - бүкіл кластердің сыйымдылығы үшін бір жұмысшы түйіні. Жоғарыдағы мысалда бұл 16 процессорлық ядросы және 16 ГБ жедел жады бар жалғыз жұмысшы түйіні болады.
Плюсы
Плюс № 1. Басқаруды жеңілдету
Бүкіл флотты басқарудан гөрі бірнеше машинаны басқару оңайырақ. Жаңартулар мен түзетулерді шығару жылдамырақ және синхрондау оңайырақ. Абсолюттік сандардағы сәтсіздіктер саны да аз.
Жоғарыда айтылғандардың барлығы бұлтты даналарға емес, сіздің аппараттық құралыңызға, серверлеріңізге қатысты екенін ескеріңіз.
Бұлтта жағдай басқаша. Онда басқаруды бұлттық қызмет провайдері басқарады. Осылайша, бұлттағы он түйінді басқару бір түйінді басқарудан айтарлықтай ерекшеленбейді.
Трафикті маршруттау және бұлттағы бөлімдер арасындағы жүктемені бөлу : Интернеттен келетін трафик трафикті түйіндердің бірінің портына бағыттайтын негізгі жүктеме теңестірушіге жіберіледі (NodePort қызметі әрбір кластер түйінінде портты 30000-32767 диапазонында орнатады). kube-proxy орнатқан ережелер трафикті түйіннен подкастқа бағыттайды. Екі түйіндегі он түйінге ұқсайды:
Pro №2: бір түйіннің құны аз
Қуатты автокөлік қымбатырақ, бірақ бағаның өсуі міндетті түрде сызықты емес. Басқаша айтқанда, 10 ГБ жады бар бір он ядролы сервер, әдетте, жады көлемі бірдей он бір ядролы серверге қарағанда арзанырақ.
Бірақ бұл ереже әдетте бұлттық қызметтерде жұмыс істемейтінін ескеріңіз. Барлық негізгі бұлттық провайдерлердің ағымдағы баға схемаларында бағалар сыйымдылыққа байланысты сызықты түрде өседі.
Осылайша, бұлтта сіз әдетте қуаттырақ серверлерде үнемдей алмайсыз.
Pro #3: Ресурсты көп қажет ететін қолданбаларды іске қосуға болады
Кейбір қолданбалар кластерде қуатты серверлерді қажет етеді. Мысалы, машиналық оқыту жүйесі 8 ГБ жадты қажет етсе, сіз оны 1 ГБ түйіндерде іске қоса алмайсыз, тек кем дегенде бір үлкен жұмысшы түйінімен ғана іске қосасыз.
Минусы
Кемшілігі № 1. Әр түйінге көп түйіршіктер
Егер бірдей тапсырма азырақ түйіндерде орындалса, онда олардың әрқайсысында табиғи түрде көбірек түйіршіктер болады.
Бұл мәселе болуы мүмкін.
Себебі, әрбір модуль контейнердің орындалу уақытына (мысалы, Docker), сондай-ақ kubelet пен cAdvisor-ға қосымша шығындарды енгізеді.
Мысалы, кубелет өмір сүру мүмкіндігі үшін түйіндегі барлық контейнерлерді жүйелі түрде зерттейді — контейнерлер неғұрлым көп болса, кубелет соғұрлым көп жұмыс істеуі керек.
CAdvisor түйіндегі барлық контейнерлер үшін ресурстарды пайдалану статистикасын жинайды және kubelet бұл ақпаратты жүйелі түрде сұрайды және оны API арқылы қамтамасыз етеді. Тағы да, көп контейнерлер cAdvisor және kubelet үшін көп жұмысты білдіреді.
Егер модульдер саны көбейсе, ол жүйенің жұмысын баяулатады және тіпті оның сенімділігін төмендетеді.
Кубернетес репозиторийінде кейбір бұл түйіндер Дайын/Дайын емес күйлері арасында ауысады, себебі түйіндегі барлық контейнерлерді тұрақты кубелет тексерулері тым ұзақ уақыт алады.
Осы себепті Кубернетес . Түйіннің өнімділігіне байланысты әр түйінге көбірек қосқыштарды іске қосуға болады, бірақ ақаулар туындайтынын немесе бәрі жақсы жұмыс істейтінін болжау қиын. Жұмысты алдын ала сынаған жөн.
Кемшілік No 2. Репликацияның шектелуі
Тым аз түйіндер қолданбаның репликациясының тиімді көлемін шектейді. Мысалы, егер сізде бес репликасы бар, бірақ тек екі түйіні бар жоғары қолжетімді бағдарлама болса, қолданбаның репликацияның тиімді дәрежесі екіге дейін азаяды.
Бес репликаны тек екі түйінге таратуға болады және олардың біреуі сәтсіз болса, ол бірден бірнеше көшірмелерді өшіреді.
Егер сізде бес немесе одан да көп түйін болса, әрбір реплика бөлек түйінде жұмыс істейді және бір түйіннің сәтсіздігі ең көбі бір репликаны жояды.
Осылайша, жоғары қолжетімділік талаптары кластердегі түйіндердің белгілі бір ең аз санын талап етуі мүмкін.
Кемшілік No 3. Сәтсіздіктің нашар салдары
Түйіндердің аз санымен әрбір сәтсіздіктің одан да ауыр зардаптары бар. Мысалы, сізде тек екі түйін болса және олардың біреуі сәтсіз болса, модульдердің жартысы бірден жоғалады.
Әрине, Кубернетес жұмыс жүктемесін сәтсіз түйіннен басқаларға тасымалдайды. Бірақ егер олардың саны аз болса, онда бос сыйымдылық жеткіліксіз болуы мүмкін. Нәтижесінде кейбір қолданбалар сәтсіз түйінді шығарғанша қолжетімсіз болады.
Осылайша, түйіндер неғұрлым көп болса, аппараттық ақаулардың әсері соғұрлым аз болады.
№4 кемшілігі: Көбірек автоматты масштабтау қадамдары
Kubernetes-те бұлтты инфрақұрылымға арналған кластерді автоматты масштабтау жүйесі бар, ол ағымдағы қажеттіліктерге байланысты түйіндерді автоматты түрде қосуға немесе жоюға мүмкіндік береді. Үлкенірек түйіндермен автомасштабтау күрт және қиын болады. Мысалы, екі түйінде қосымша түйінді қосу кластердің сыйымдылығын бірден 50%-ға арттырады. Және бұл ресурстарды қажет етпесе де төлеуге тура келеді.
Осылайша, автоматты кластерді масштабтауды пайдалануды жоспарласаңыз, түйіндер неғұрлым кішірек болса, соғұрлым икемді және үнемді масштабтау аласыз.
Енді шағын түйіндердің үлкен санының артықшылықтары мен кемшіліктерін қарастырайық.
Екінші нұсқа: көптеген шағын түйіндер
Бұл тәсілдің артықшылықтары негізінен бірнеше үлкен түйіндері бар қарама-қарсы опцияның кемшіліктерінен туындайды.
Плюсы
Pro №1: Сәтсіздіктің әсері аз
Неғұрлым көп түйіндер болса, соғұрлым әрбір түйінде аз тармақтар. Мысалы, он түйінге жүз модуль болса, онда әрбір түйінде орта есеппен он модуль болады.
Осылайша, егер түйіндердің біреуі сәтсіз болса, сіз жұмыс жүктемесінің тек 10% жоғалтасыз. Көшірмелердің аз ғана санына әсер етіп, жалпы қолданба жұмыс істеп тұруы ықтимал.
Бұған қоса, қалған түйіндерде сәтсіз түйіннің жұмыс жүктемесін өңдеу үшін жеткілікті бос ресурстар болуы мүмкін, сондықтан Kubernetes подкасттарды еркін қайта жоспарлауы мүмкін және қолданбаларыңыз салыстырмалы түрде тез функционалдық күйге оралады.
Pro №2: Жақсы репликация
Түйіндер жеткілікті болса, Kubernetes жоспарлаушысы барлық көшірмелерге әртүрлі түйіндерді тағайындай алады. Осылайша, егер түйін сәтсіз болса, тек бір көшірмеге әсер етеді және қолданба қолжетімді болып қалады.
Минусы
Кемшілік No 1. Бақылау қиын
Түйіндердің үлкен санын басқару қиынырақ. Мысалы, әрбір Kubernetes түйіні барлық басқалармен байланысуы керек, яғни қосылымдар саны квадраттық түрде өседі және осы қосылымдардың барлығын қадағалау қажет.
Kubernetes Controller Manager жүйесіндегі түйін контроллері денсаулықты тексеру үшін кластердегі барлық түйіндерді жүйелі түрде аралайды - түйіндер неғұрлым көп болса, контроллерге соғұрлым көп жүктеме түседі.
etcd дерекқорындағы жүктеме де өсуде - әрбір kubelet және kube-прокси қоңыраулары etcd үшін (API арқылы), оған etcd нысан жаңартуларын таратуы керек.
Жалпы алғанда, әрбір жұмысшы түйін негізгі түйіндердің жүйелік құрамдастарына қосымша жүктеме береді.
Kubernetes ресми түрде кластерлерді қолдайды . Дегенмен, іс жүзінде қазірдің өзінде 500 түйін бар .
Жұмысшы түйіндерінің көп санын басқару үшін қуаттырақ негізгі түйіндерді таңдау керек. Мысалы, kube-up жұмысшы түйіндерінің санына байланысты негізгі түйін үшін дұрыс VM өлшемі. Яғни, жұмысшы түйіндері неғұрлым көп болса, негізгі түйіндер соғұрлым өнімді болуы керек.
Осы нақты мәселелерді шешу үшін арнайы әзірлемелер бар, мысалы . Бұл жүйе шектеулерді айналып өтуге және жұмысшы түйіндерінің үлкен саны бар кластерлерді құруға мүмкіндік береді.
№2 кемшілігі: Қосымша шығындар.
Әрбір жұмысшы түйінінде Kubernetes жүйелік демондар жинағын іске қосады - олар контейнердің жұмыс уақыты (мысалы, Docker), kube-proxy және kubelet, соның ішінде cAdvisor кіреді. Олар бірге ресурстардың белгілі бір белгіленген мөлшерін тұтынады.
Егер сізде көптеген шағын түйіндер болса, әрбір түйіндегі осы үстеме шығындардың үлесі үлкенірек болады. Мысалы, бір түйіндегі барлық жүйелік демондар бірге 0,1 процессорлық ядро мен 0,1 ГБ жадты пайдаланады деп елестетіңіз. Егер сізде 10 ГБ жады бар бір он ядролы түйін болса, онда демондар кластер сыйымдылығының 1% тұтынады. Екінші жағынан, 1 ГБ жады бар бір ядролы он түйінде демондар кластер сыйымдылығының 10% алады.
Осылайша, түйіндер неғұрлым аз болса, инфрақұрылым соғұрлым тиімдірек пайдаланылады.
Кемшілік No3. Ресурстарды тиімсіз пайдалану
Кішкентай түйіндерде қалған ресурс бөліктері кез келген жұмыс жүктемесін тағайындау үшін тым кішкентай болуы мүмкін, сондықтан олар пайдаланылмайды.
Мысалы, әрбір подвод 0,75 ГБ жадты қажет етеді. Егер сізде әрқайсысында 1 ГБ жады бар он түйін болса, әрбір түйінде 0,25 ГБ пайдаланылмаған жады қалдырып, он түйінді іске қосуға болады.
Бұл бүкіл кластердің жадының 25% босқа кететінін білдіреді.
10 ГБ жады бар үлкен түйінде сіз осы модульдердің 13-ін іске қоса аласыз - және 0,25 ГБ пайдаланылмаған бір ғана фрагмент болады.
Бұл жағдайда жадтың тек 2,5% босқа кетеді.
Осылайша, ресурстар үлкенірек түйіндерде тиімдірек пайдаланылады.
Бірнеше үлкен түйіндер немесе көптеген кішкентай түйіндер?
Сонымен, қайсысы жақсы: кластердегі бірнеше үлкен түйіндер немесе көптеген кішкентай түйіндер? Әдеттегідей, нақты жауап жоқ. Көп нәрсе қолдану түріне байланысты.
Мысалы, егер қолданба 10 ГБ жадты қажет етсе, үлкенірек түйіндер айқын таңдау болып табылады. Ал егер қолданба жоғары қолжетімділік үшін он еселік репликацияны қажет етсе, репликаларды тек екі түйінге орналастыру тәуекелі екіталай - кластерде кемінде он түйін болуы керек.
Аралық жағдайларда әрбір опцияның артықшылықтары мен кемшіліктеріне негізделген таңдау жасаңыз. Мүмкін кейбір дәлелдер басқаларға қарағанда сіздің жағдайыңызға көбірек сәйкес келеді.
Және барлық түйіндерді бірдей өлшемде ету мүлдем қажет емес. Алдымен бірдей өлшемдегі түйіндермен тәжірибе жасауға, содан кейін оларға басқа өлшемдегі түйіндерді қосып, оларды кластерге біріктіруге ештеңе кедергі болмайды. Kubernetes кластеріндегі жұмысшы түйіндері толығымен гетерогенді болуы мүмкін. Сондықтан сіз екі тәсілдің артықшылықтарын біріктіруге тырысуға болады.
Бірыңғай рецепт жоқ, және әрбір жағдайдың өз нюанстары бар, тек өндіріс шындықты көрсетеді.
Бұлттық платформа тобы дайындаған аударма .
Kubernetes туралы толығырақ: .
Ақпарат көзі: www.habr.com