27 сәуірде конференцияда , «DevOps» бөлімінің бөлігі ретінде «Kubernetes-те автоматты масштабтау және ресурстарды басқару» есебі берілді. Бұл қолданбалардың жоғары қолжетімділігін қамтамасыз ету және ең жоғары өнімділікті қамтамасыз ету үшін K8s қалай пайдалануға болатыны туралы айтады.
Дәстүр бойынша біз қуана ұсынамыз (44 минут, мақаладан әлдеқайда ақпараттылығы) және мәтін түрінде негізгі түйіндеме. Бар!
Есептің тақырыбын сөзбе-сөз талдап, соңынан бастайық.
Kubernetes
Біздің хостымызда Docker контейнерлері бар делік. Не үшін? Қайталануды және оқшаулауды қамтамасыз ету үшін, бұл өз кезегінде қарапайым және жақсы орналастыруға мүмкіндік береді, CI/CD. Бізде контейнері бар мұндай көліктер көп.
Бұл жағдайда Кубернетес не береді?
- Біз бұл машиналар туралы ойлауды тоқтатып, «бұлтпен» жұмыс істей бастаймыз. контейнерлер кластері немесе бүршіктер (контейнерлердің топтары).
- Сонымен қатар, біз жеке бөтелкелер туралы ойламаймыз, бірақ көбірек басқарамызоүлкен топтар. Мұндай жоғары деңгейлі примитивтер белгілі бір жұмыс жүктемесін орындауға арналған үлгі бар деп айтуға мүмкіндік береді және мұнда оны іске қосу үшін даналардың қажетті саны берілген. Үлгіні кейіннен өзгертсек, барлық даналар өзгереді.
- Көмегімен декларативті API Арнайы пәрмендер тізбегін орындаудың орнына біз Кубернетес жасаған «әлем құрылымын» (YAML-де) сипаттаймыз. Және тағы да: сипаттама өзгерген кезде оның нақты дисплейі де өзгереді.
Ресурстарды басқару
Орталық Есептеуіш Бөлім
Серверде nginx, php-fpm және MySQL іске қосайық. Бұл қызметтерде іс жүзінде одан да көп процестер іске қосылады, олардың әрқайсысы есептеу ресурстарын қажет етеді:
(слайдтағы сандар – «тотықұстар», әр процестің есептеу қуатына деген абстрактілі қажеттілігі)
Мұнымен жұмыс істеуді жеңілдету үшін процестерді топтарға біріктіру қисынды (мысалы, барлық nginx процестерін бір топқа «nginx»). Мұны істеудің қарапайым және айқын жолы - әр топты контейнерге салу:
Жалғастыру үшін контейнердің не екенін есте сақтау керек (Linux жүйесінде). Олардың пайда болуы бұрыннан іске асырылған ядродағы үш негізгі мүмкіндіктің арқасында мүмкін болды: , и . Әрі қарай дамытуға басқа технологиялар (соның ішінде Docker сияқты ыңғайлы «қабықтар») көмектесті:
Есептің контекстінде бізді тек қызықтырады топтар, өйткені басқару топтары ресурстарды басқаруды жүзеге асыратын контейнерлер (Docker және т.б.) функционалдық бөлігі болып табылады. Біз қалағандай топтарға біріктірілген процестер бақылау топтары болып табылады.
Осы процестерге, ал енді процестер топтарына арналған CPU талаптарына оралайық:
(Қайталаймын, барлық сандар ресурстарға деген қажеттіліктің абстрактілі көрінісі)
Сонымен бірге процессордың өзінде белгілі бір шектеулі ресурс бар (мысалда бұл 1000), бұл барлығына жетіспеуі мүмкін (барлық топтардың қажеттіліктерінің қосындысы 150+850+460=1460). Бұл жағдайда не болады?
Ядро ресурстарды таратуды бастайды және оны әр топқа бірдей ресурстарды бере отырып, «әділ» жасайды. Бірақ бірінші жағдайда олардың саны қажеттіден көп (333>150), сондықтан артық (333-150=183) резервте қалады, ол да екі басқа контейнер арасында бірдей бөлінеді:
Нәтижесінде: бірінші контейнерде ресурстар жеткілікті болды, екіншісінде - ресурстар жеткіліксіз болды, үшіншіде - ресурстар жеткіліксіз болды. Бұл әрекеттердің нәтижесі Linux жүйесіндегі «адал» жоспарлаушы - . Оның жұмысын тапсырма арқылы реттеуге болады салмағы контейнерлердің әрқайсысы. Мысалы, келесідей:
Екінші контейнерде (php-fpm) ресурстардың жетіспеушілігін қарастырайық. Барлық контейнер ресурстары процестер арасында бірдей бөлінеді. Нәтижесінде негізгі процесс жақсы жұмыс істейді, бірақ барлық жұмысшылар қажеттінің жартысынан азын ала отырып, баяулайды:
CFS жоспарлаушысы осылай жұмыс істейді. Әрі қарай біз контейнерлерге тағайындайтын салмақтарды атаймыз сұраулар. Неліктен бұлай болды - әрі қарай қараңыз.
Барлық жағдайды екінші жағынан қарастырайық. Өздеріңіз білетіндей, барлық жолдар Римге, ал компьютер жағдайында орталық процессорға апарады. Бір процессор, көптеген тапсырмалар - сізге бағдаршам қажет. Ресурстарды басқарудың ең қарапайым тәсілі «бағдаршам» болып табылады: олар бір процесске орталық процессорға бекітілген қол жеткізу уақытын берді, содан кейін келесіге және т.б.
Бұл тәсіл қатаң квоталар деп аталады (қатаң шектеу). Оны қарапайым түрде еске түсірейік шектеулер. Дегенмен, егер сіз шектеулерді барлық контейнерлерге таратсаңыз, мәселе туындайды: MySQL жол бойымен жүріп келе жатқан және белгілі бір сәтте оның CPU қажеттілігі аяқталды, бірақ барлық басқа процестер процессорды күтуге мәжбүр болады. жұмыс істемейтін.
Linux ядросына және оның орталық процессормен әрекеттестігіне оралайық - жалпы сурет келесідей:
cgroup-тың екі параметрі бар - негізінен бұл екі қарапайым «бұралу» мыналарды анықтауға мүмкіндік береді:
- контейнер салмағы (сұраныс) болып табылады акциялар;
- контейнерлік тапсырмалармен жұмыс істеуге арналған процессордың жалпы уақытының пайызы (шектері). квота.
Орталық процессорды қалай өлшеуге болады?
Әртүрлі жолдар бар:
- Не болды попугая, ешкім білмейді - сіз әр уақытта келіссөздер жүргізуіңіз керек.
- Пайыздар анық, бірақ салыстырмалы: 50 ядросы және 4 ядросы бар сервердің 20% -ы мүлдем басқа нәрселер.
- Сіз жоғарыда аталғандарды пайдалана аласыз салмағы, оны Linux біледі, бірақ олар да салыстырмалы.
- Ең адекватты нұсқа - есептеу ресурстарын өлшеу секунд. Анау. нақты уақыт секундына қатысты процессор уақытының секундтарымен: 1 нақты секундқа 1 секунд процессор уақыты берілді - бұл бүкіл процессордың бір ядросы.
Сөйлеуді жеңілдету үшін олар тікелей өлшей бастады ядролар, олар бойынша нақтыға қатысты бірдей CPU уақытын білдіреді. Linux салмақты түсінетіндіктен, бірақ CPU уақыты/ядролары соншалықты көп емес, бірінен екіншісіне аудару механизмі қажет болды.
3 процессорлық ядросы бар сервермен қарапайым мысалды қарастырайық, мұнда үш тармаққа салмақтар (500, 1000 және 1500) беріледі, олар оларға бөлінген ядролардың сәйкес бөліктеріне оңай түрленеді (0,5, 1 және 1,5).
Егер сіз екі есе көп ядро (6) болатын екінші серверді алсаңыз және сол жерге бірдей подкасттарды орналастырсаңыз, ядролардың таралуын жай 2-ге көбейту арқылы оңай есептеуге болады (тиісінше 1, 2 және 3). Бірақ маңызды сәт осы серверде салмағы 3000 болатын төртінші подвод пайда болған кезде орын алады. Ол орталық процессор ресурстарының бір бөлігін (ядролардың жартысын) алып тастайды, ал қалған бөліктер үшін олар қайта есептеледі (жартысы қысқарады):
Kubernetes және CPU ресурстары
Kubernetes-те CPU ресурстары әдетте өлшенеді миллиадракс, яғни. Негізгі салмақ ретінде 0,001 өзек алынады. (Linux/cgroups терминологиясындағы бірдей нәрсе CPU үлесі деп аталады, бірақ дәлірек айтқанда, 1000 милликор = 1024 CPU үлесі.) K8s серверде барлық қосқыштардың салмақтарының қосындысы үшін орталық процессор ресурстарына қарағанда көбірек қосқыштарды орналастырмайтынын қамтамасыз етеді.
Бұл қалай болады? Серверді Kubernetes кластеріне қосқанда, оның қанша CPU өзегі бар екені хабарланады. Жаңа подкаст жасаған кезде, Kubernetes жоспарлаушысы осы подкастқа қанша ядро қажет болатынын біледі. Осылайша, подкаст жеткілікті ядросы бар серверге тағайындалады.
Не болады екен емес сұрау көрсетілген (яғни, подводта қажетті ядролардың белгілі саны жоқ)? Кубернетес ресурстарды қалай санайтынын анықтап көрейік.
Қосқыш үшін сұрауларды (CFS жоспарлаушы) және шектеулерді (бағдаршам есіңізде ме?) көрсетуге болады.
- Егер олар тең деп көрсетілсе, онда қосқышқа QoS сыныбы тағайындалады кепілдік. Бұл әрқашан қол жетімді ядролардың санына кепілдік беріледі.
- Егер сұрау шектеуден аз болса - QoS класы жарылғыш. Анау. Біз, мысалы, подкаст әрқашан 1 ядроны пайдаланады деп күтеміз, бірақ бұл мән ол үшін шектеу емес: кейде pod көбірек пайдалана алады (серверде бұл үшін бос ресурстар болған кезде).
- Сондай-ақ QoS класы бар ең жақсы күш — оған сұрауы көрсетілмеген дәл сол бөлімдер кіреді. Ресурстар оларға соңғы рет беріледі.
жад
Жадымен жағдай ұқсас, бірақ сәл өзгеше - бұл ресурстардың табиғаты әртүрлі. Жалпы, ұқсастық келесідей:
Сұраныстардың жадта қалай орындалатынын көрейік. Жадты тұтынуды өзгерте отырып, олардың біреуі жады таусылғанша үлкен болғанша, серверде тұруға мүмкіндік беріңіз. Бұл жағдайда OOM өлтірушісі пайда болады және ең үлкен процесті өлтіреді:
Бұл бізге әрқашан сәйкес келе бермейді, сондықтан қандай процестер біз үшін маңызды және өлтірілмеуі керек екенін реттеуге болады. Мұны істеу үшін параметрді пайдаланыңыз oom_score_adj.
Орталық процессордың QoS сыныптарына оралайық және подкасттар үшін жадты тұтыну басымдықтарын анықтайтын oom_score_adj мәндеріне ұқсастық жасайық:
- Тұтқыр үшін ең төменгі oom_score_adj мәні - -998 - мұндай подкастты соңғы рет өлтіру керек дегенді білдіреді. кепілдік.
- Ең жоғарысы – 1000 ең жақсы күш, мұндай бүршіктер алдымен өлтіріледі.
- Қалған мәндерді есептеу үшін (жарылғыш) формуласы бар, оның мәні подвод неғұрлым көп ресурстар сұраса, оның өлтіру ықтималдығы соғұрлым аз болатындығына байланысты.
Екінші «бұралу» - байтпен_шектеу - шектеулер үшін. Оның көмегімен бәрі оңайырақ: біз шығарылған жадтың максималды көлемін тағайындаймыз және мұнда (процессордан айырмашылығы) оны (жадты) қалай өлшеуге болатыны туралы мәселе жоқ.
Барлығы
Кубернетестегі әрбір подвод беріледі requests и limits - процессор мен жадтың екі параметрі:
- сұрауларға негізделген Kubernetes жоспарлаушысы жұмыс істейді, ол серверлер арасында подкасттарды таратады;
- барлық параметрлер негізінде подводтың QoS класы анықталады;
- Салыстырмалы салмақтар CPU сұраулары негізінде есептеледі;
- CFS жоспарлаушы процессор сұраулары негізінде конфигурацияланады;
- OOM киллері жад сұрауларына негізделген конфигурацияланады;
- «бағдаршам» процессор шектеулеріне негізделген конфигурацияланады;
- Жад шектеулерінің негізінде топ тобы үшін шектеу конфигурацияланады.
Жалпы, бұл сурет ресурстарды басқарудың негізгі бөлігі Kubernetes-те қалай орын алатыны туралы барлық сұрақтарға жауап береді.
Автомасштабтау
K8s кластер-автомасштабтаушысы
Бүкіл кластер жұмыс істеп тұрғанын және жаңа подкаст жасау керек екенін елестетіп көрейік. Қондырғы пайда болмаса да, ол күйде тұрады күту. Оның пайда болуы үшін біз кластерге жаңа серверді қоса аламыз немесе... кластер-автомасштабты орната аламыз, ол біз үшін мұны жасайды: бұлт провайдерінен виртуалды машинаға тапсырыс беріңіз (API сұрауын пайдаланып) және оны кластерге қосыңыз , содан кейін подвод қосылады.
Бұл тамаша жұмыс істейтін (біздің тәжірибемізде) Kubernetes кластерінің автомасштабтауы. Дегенмен, басқа жерде сияқты, мұнда да кейбір нюанстар бар ...
Біз кластердің өлшемін ұлғайтқанша бәрі жақсы болды, бірақ кластер болған кезде не болады өзін боса бастады? Мәселе мынада, қосқыштарды тасымалдау (хосттарды босату үшін) техникалық тұрғыдан өте қиын және ресурстар тұрғысынан қымбат. Кубернетес мүлдем басқа тәсілді қолданады.
Орналастыру мүмкіндігі бар 3 серверден тұратын кластерді қарастырыңыз. Оның 6 түйіні бар: енді әрбір сервер үшін 2 бар. Қандай да бір себептермен біз серверлердің бірін өшіргіміз келді. Ол үшін пәрменді қолданамыз kubectl drain, ол:
- осы серверге жаңа подкасттарды жіберуге тыйым салады;
- сервердегі бар подкасттарды жояды.
Кубернетес түйіршіктер санын (6) сақтауға жауапты болғандықтан, бұл жай ғана қайта жасайды оларды басқа түйіндерде, бірақ өшірілгенінде емес, өйткені ол жаңа подкасттарды орналастыру үшін қолжетімсіз деп белгіленген. Бұл Кубернетес үшін негізгі механик.
Дегенмен, мұнда да бір нюанс бар. Ұқсас жағдайда StatefulSet үшін (орналастыру орнына) әрекеттер басқаша болады. Қазір бізде күйі бар қосымша бар - мысалы, MongoDB бар үш подколь, олардың біреуінде қандай да бір мәселе бар (деректер бүлінген немесе подкасттың дұрыс іске қосылуына кедергі келтіретін басқа қате). Біз тағы бір серверді өшіруді шештік. Не болады?
MongoDB мүмкін өледі, себебі оған кворум қажет: үш қондырғыдан тұратын кластер үшін кемінде екеуі жұмыс істеуі керек. Дегенмен, бұл болып жатқан жоқ - рахмет PodDisruptionBudget. Бұл параметр жұмыс бағандарының ең аз қажетті санын анықтайды. MongoDB қосқыштарының бірі енді жұмыс істемейтінін білу және PodDisruptionBudget MongoDB үшін орнатылғанын көру minAvailable: 2, Kubernetes подкастты жоюға рұқсат бермейді.
Төменгі жол: кластер шығарылған кезде подводтардың қозғалысы (және шын мәнінде, қайта жасалуы) дұрыс жұмыс істеуі үшін PodDisruptionBudget конфигурациялау қажет.
Көлденең масштабтау
Басқа жағдайды қарастырайық. Kubernetes жүйесінде Deployment ретінде іске қосылған қолданба бар. Пайдаланушы трафигі оның блоктарына келеді (мысалы, олардың үшеуі бар) және біз олардағы белгілі бір көрсеткішті өлшейміз (мысалы, CPU жүктемесі). Жүктеме ұлғайған кезде, біз оны кестеге жазамыз және сұрауларды тарату үшін блоктардың санын көбейтеміз.
Бүгінгі күні Кубернетеде мұны қолмен жасаудың қажеті жоқ: өлшенген жүктеме индикаторларының мәндеріне байланысты бағандар санын автоматты түрде арттыру/азайту конфигурацияланады.
Мұндағы негізгі сұрақтар: нақты нені өлшеу керек и қалай түсіндіруге болады алынған мәндер (бұдақтар санын өзгерту туралы шешім қабылдау үшін). Сіз көп нәрсені өлшей аласыз:
Мұны техникалық түрде қалай жасауға болады - көрсеткіштерді жинау және т.б. — туралы баяндамада егжей-тегжейлі айттым . Оңтайлы параметрлерді таңдаудың негізгі кеңесі болып табылады эксперимент!
бар (Қолданудың қанықтығы және қателері), мағынасы төмендегідей. Мысалы, php-fpm масштабтаудың қандай негізде мағынасы бар? Жұмысшылардың таусылып жатқанына сүйене отырып, бұл кәдеге жарату. Ал егер жұмысшылар бітсе және жаңа байланыстар қабылданбаса, бұл қазірдің өзінде қанықтыру. Бұл параметрлердің екеуі де өлшенуі керек және мәндерге байланысты масштабтау жүргізілуі керек.
Орнына жасасу
Есептің жалғасы бар: тік масштабтау және дұрыс ресурстарды таңдау туралы. Бұл туралы алдағы видеоларда айтатын боламын - жіберіп алмау үшін жазылыңыз!
Бейнелер мен слайдтар
Спектакльден бейне (44 минут):
Баяндаманы көрсету:
PS
Біздің блогтағы Кубернетес туралы басқа есептер:
- «» (Андрей Половов; 8 сәуір, 2019 ж. Saint HighLoad++);
- «» (Дмитрий Столяров; 8 жылғы 2018 қарашада HighLoad++);
- «» (Дмитрий Столяров; 28 жылғы 2018 мамырда RootConf сайтында);
- «» (Дмитрий Столяров; 7 жылғы 2017 қарашада HighLoad++);
- «» (Дмитрий Столяров; 6 жылғы 2017 маусымда RootConf сайтында).
Ақпарат көзі: www.habr.com