Ескерту. аударма: Еуропалық саяхат агрегаторы Омионың бұл көз ашатын тарихы оқырмандарды негізгі теориядан Кубернетес конфигурациясының қызықты практикалық қыр-сырына дейін жеткізеді. Мұндай жағдайлармен танысу сіздің көкжиегіңізді кеңейтіп қана қоймайды, сонымен қатар маңызды емес мәселелердің алдын алуға көмектеседі.
Орнында тұрып қалған, денсаулық тексерулеріне жауап беруді тоқтататын және неге екенін түсінбейтін қолданбаны кездестірдіңіз бе? Ықтимал түсініктеме CPU ресурстарының квота шектеулеріне қатысты. Бұл туралы біз осы мақалада айтатын боламыз.
TL; DR:
CFS квотасы қатесі бар Linux ядросының нұсқасын пайдаланып жатсаңыз, Kubernetes жүйесінде CPU шектеулерін өшіруді (немесе Kubelet бағдарламасында CFS квотасын өшіруді) қатаң түрде ұсынамыз. Өзекте ауыр және шамадан тыс дроссельдер мен кідірістерге әкелетін қате.
Омио қаласында бүкіл инфрақұрылымды Кубернетес басқарады. Біздің барлық күй және азаматтығы жоқ жұмыс жүктемелері тек Kubernetes жүйесінде жұмыс істейді (біз Google Kubernetes Engine қолданамыз). Соңғы алты айда біз кездейсоқ баяулауларды байқай бастадық. Қолданбалар қатып қалады немесе денсаулық тексерулеріне жауап беруді тоқтатады, желіге қосылымды жоғалтады және т.б. Бұл мінез-құлық бізді ұзақ уақыт бойы таң қалдырды, ақыры біз бұл мәселеге байыпты қарауды шештік.
Мақаланың қысқаша мазмұны:
- Контейнерлер мен Кубернеттер туралы бірнеше сөз;
- CPU сұраулары мен шектеулері қалай жүзеге асырылады;
- CPU шегі көп ядролы орталарда қалай жұмыс істейді;
- CPU тежеуін қалай бақылауға болады;
- Мәселені шешу және нюанстар.
Контейнерлер мен Кубернеттер туралы бірнеше сөз
Kubernetes негізінен инфрақұрылым әлеміндегі заманауи стандарт болып табылады. Оның негізгі міндеті - контейнерлік оркестрлеу.
Контейнерлер
Бұрын серверлерде іске қосу үшін Java JAR/WAR, Python Eggs немесе орындалатын файлдар сияқты артефактілерді жасауға тура келді. Дегенмен, олардың жұмыс істеуі үшін қосымша жұмыстарды орындау қажет болды: орындау ортасын (Java/Python) орнату, қажетті файлдарды дұрыс орындарға орналастыру, операциялық жүйенің белгілі бір нұсқасымен үйлесімділікті қамтамасыз ету және т.б. Басқаша айтқанда, конфигурацияны басқаруға мұқият назар аудару керек болды (бұл көбінесе әзірлеушілер мен жүйелік әкімшілер арасындағы қайшылықтардың көзі болды).
Контейнерлер бәрін өзгертті. Енді артефакт контейнерлік кескін болып табылады. Ол бағдарламаны ғана емес, сонымен қатар толыққанды орындау ортасын (Java/Python/...), сондай-ақ алдын ала орнатылған және пайдалануға дайын қажетті файлдарды/бумаларды қамтитын кеңейтілген орындалатын файл түрі ретінде ұсынылуы мүмкін. жүгіру. Контейнерлер кез келген қосымша қадамдарсыз әртүрлі серверлерде орналастырылуы және іске қосылуы мүмкін.
Сонымен қатар, контейнерлер өздерінің құмсалғыш ортасында жұмыс істейді. Олардың өздерінің виртуалды желі адаптері, қол жетімділігі шектеулі жеке файлдық жүйесі, процестердің өзіндік иерархиясы, орталық процессор мен жадтағы өз шектеулері және т.б. Осының бәрі Linux ядросының арнайы ішкі жүйесі – аттар кеңістігінің арқасында жүзеге асырылады.
Kubernetes
Жоғарыда айтылғандай, Кубернетес - контейнер оркестрі. Ол келесідей жұмыс істейді: сіз оған машиналар пулын бересіз, содан кейін: «Ей, Кубернетес, әрқайсысында 2 процессор және 3 ГБ жады бар контейнерімнің он данасын іске қосып, олардың жұмысын жалғастырайық!» Дейсіз. Қалғанын Кубернетес шешеді. Ол бос сыйымдылықты табады, контейнерлерді іске қосады және қажет болған жағдайда оларды қайта іске қосады, нұсқаларды өзгерткен кезде жаңартуды шығарады және т.б. Негізінде, Kubernetes сізге аппараттық құрамдас бөлікті алып тастауға мүмкіндік береді және қолданбаларды орналастыру және іске қосу үшін қолайлы жүйелердің кең ауқымын жасайды.
Кубернетес қарапайым адам тұрғысынан
Kubernetes-тегі сұраулар мен шектеулер дегеніміз не
Жарайды, біз контейнерлер мен Кубернеттерді жаптық. Сондай-ақ, бір құрылғыда бірнеше контейнер болуы мүмкін екенін білеміз.
Аналогияны коммуналдық пәтермен жасауға болады. Кең үй-жайлар (машиналар/блоктар) алынып, бірнеше жалға алушыларға (контейнерлерге) жалға беріледі. Кубернетес риэлтор ретінде әрекет етеді. Сұрақ туындайды, жалға алушыларды бір-бірімен жанжалдан қалай сақтауға болады? Егер олардың біреуі, айталық, ваннаны жарты күнге қарызға алуды шешсе ше?
Бұл жерде сұраулар мен шектеулер пайда болады. Орталық Есептеуіш Бөлім өтініш жоспарлау мақсатында ғана қажет. Бұл контейнердің «тілектер тізімі» сияқты нәрсе және ол ең қолайлы түйінді таңдау үшін қолданылады. Сонымен қатар процессор шектеу жалдау шартымен салыстыруға болады - біз контейнерге бірлікті таңдаған бойда алмайды белгіленген шектен шығу. Міне, мәселе осыдан туындайды...
Кубернетесте сұраулар мен шектеулер қалай жүзеге асырылады
Кубернетес орталық процессордың шектеулерін жүзеге асыру үшін ядроға енгізілген тежеу механизмін (сағат циклдерін өткізіп жіберу) пайдаланады. Қолданба шектен асып кетсе, тежеу қосылады (яғни ол процессордың аз циклдерін қабылдайды). Жадқа арналған сұраулар мен шектеулер басқаша ұйымдастырылған, сондықтан оларды анықтау оңайырақ. Бұл әрекетті орындау үшін подкасттың соңғы қайта іске қосу күйін тексеріңіз: ол «OOMKilled» ма. CPU тежеу оңай емес, өйткені K8s көрсеткіштерді топтар бойынша емес, тек пайдалану арқылы қол жетімді етеді.
CPU сұрауы
CPU сұрауы қалай орындалады
Қарапайымдылық үшін мысал ретінде 4 ядролы процессоры бар машинаны пайдалану процесін қарастырайық.
K8s ресурстарды (жад пен процессор) бөлуді басқару үшін басқару тобының механизмін (топтар) пайдаланады. Ол үшін иерархиялық үлгі қол жетімді: бала ата-аналық топтың шегін иеленеді. Тарату мәліметтері виртуалды файлдық жүйеде сақталады (/sys/fs/cgroup). Процессор жағдайында бұл /sys/fs/cgroup/cpu,cpuacct/*.
K8s файлды пайдаланады cpu.share процессор ресурстарын бөлу. Біздің жағдайда түбірлік топ CPU ресурстарының 4096 үлесін алады - процессордың қол жетімді қуатының 100% (1 ядро = 1024; бұл бекітілген мән). Түбірлік топ ресурстарды тіркелген ұрпақтардың үлесіне қарай пропорционалды түрде бөледі cpu.share, ал олар өз кезегінде ұрпақтарымен де солай істейді, т.б. Әдеттегі Кубернетес түйінінде түбірлік топта үш бала болады: system.slice, user.slice и kubepods. Алғашқы екі топша маңызды жүйе жүктемелері мен K8-ден тыс пайдаланушы бағдарламалары арасында ресурстарды бөлу үшін пайдаланылады. Соңғы - kubepods — ресурстарды қоршаулар арасында тарату үшін Kubernetes жасаған.
Жоғарыдағы диаграмма бірінші және екінші топшалардың әрқайсысын алғанын көрсетеді 1024 акциялар, kuberpod қосалқы тобымен бөлінген 4096 акциялар Бұл қалай мүмкін: түпкі топ тек қана қол жеткізе алады 4096 акциялар, ал оның ұрпақтарының үлестерінің сомасы бұл саннан айтарлықтай асып түседі (6144)? Мәселе мынада, мән логикалық мағынаға ие, сондықтан Linux жоспарлаушысы (CFS) оны процессор ресурстарын пропорционалды бөлу үшін пайдаланады. Біздің жағдайда алғашқы екі топ алады 680 нақты акциялар (16,6-дан 4096%), қалған бөлігін kubepod алады 2736 акциялар Жұмыс тоқтап қалған жағдайда алғашқы екі топ бөлінген ресурстарды пайдаланбайды.
Бақытымызға орай, жоспарлаушыда пайдаланылмаған CPU ресурстарын ысырап етпеу механизмі бар. Ол «бос» сыйымдылықты жаһандық пулға тасымалдайды, одан ол қосымша процессор қуатын қажет ететін топтарға таратылады (дөңгелектеу шығындарын болдырмау үшін тасымалдау партиялармен жүзеге асырылады). Ұқсас әдіс ұрпақтардың барлық ұрпақтарына қолданылады.
Бұл механизм процессор қуатының әділ бөлінуін қамтамасыз етеді және ешкім басқалардан ресурстарды «ұрламауын» қамтамасыз етеді.
CPU шегі
K8-дегі шектеулер мен сұраныстардың конфигурациялары ұқсас болғанына қарамастан, олардың орындалуы түбегейлі ерекшеленеді: бұл ең жаңылыстырушы және ең аз құжатталған бөлігі.
K8s қосылады шектеулерді жүзеге асыру. Олардың параметрлері файлдарда көрсетілген cfs_period_us и cfs_quota_us cgroup каталогында (файл да сол жерде орналасқан cpu.share).
айырмашылығы cpu.share, квота негізделген уақыт периоды, және қол жетімді процессор қуатында емес. cfs_period_us кезеңнің (дәуірдің) ұзақтығын көрсетеді - ол әрқашан 100000 мкс (100 мс). K8s жүйесінде бұл мәнді өзгерту мүмкіндігі бар, бірақ ол әлі альфа нұсқасында ғана қолжетімді. Жоспарлаушы қолданылған квоталарды қайта бастау үшін дәуірді пайдаланады. Екінші файл cfs_quota_us, әрбір дәуірдегі қолжетімді уақытты (квота) көрсетеді. Оның микросекундтарда да көрсетілгенін ескеріңіз. Квота дәуір ұзақтығынан асуы мүмкін; басқаша айтқанда, ол 100 мс артық болуы мүмкін.
16 ядролы машиналардағы екі сценарийді қарастырайық (бізде Omio-да бар компьютердің ең көп таралған түрі):
1-сценарий: 2 ағын және 200 мс шегі. Тығыздау жоқ
2-сценарий: 10 ағын және 200 мс шегі. Тығыздау 20 мс кейін басталады, процессор ресурстарына қол жеткізу тағы 80 мс кейін қайта жалғасады.
Сіз CPU шегін орнаттыңыз делік 2 ядролар; Кубернетес бұл мәнді 200 мс-ге аударады. Бұл контейнер дроссельсіз ең көбі 200 мс CPU уақытын пайдалана алатынын білдіреді.
Міне, қызық осы жерден басталады. Жоғарыда айтылғандай, қолжетімді квота 200 мс құрайды. Егер сіз параллель жұмыс жасасаңыз он ағындар 12 ядролы құрылғыдағы (2-сценарий үшін суретті қараңыз), барлық басқа подкасттар жұмыс істемей тұрғанда, квота небәрі 20 мс (10 * 20 мс = 200 мс болғандықтан) таусылады және осы подкасттың барлық ағындары ілініп қалады. » (дроссель) келесі 80 мс. Жоғарыда айтылған , соның салдарынан шамадан тыс дроссель орын алады және контейнер тіпті бар квотаны орындай алмайды.
Қапшықтардағы дроссельді қалай бағалауға болады?
Жай ғана подкастқа кіріп, орындаңыз cat /sys/fs/cgroup/cpu/cpu.stat.
-
nr_periods— жоспарлаушы кезеңдердің жалпы саны; -
nr_throttled— композициядағы дроссельдік кезеңдердің саныnr_periods; -
throttled_time— наносекундтардағы жинақталған дроссельдік уақыт.
Шынымен не болып жатыр?
Нәтижесінде біз барлық қолданбаларда жоғары дроссельді аламыз. Кейде ол кіреді бір жарым есе есептелгеннен күшті!
Бұл әртүрлі қателерге әкеледі - дайындықты тексеру сәтсіздіктері, контейнердің қатып қалуы, желі қосылымының үзілуі, қызметтік қоңыраулардағы күту уақыты. Бұл, сайып келгенде, кідірістің артуына және қателіктердің жоғарылауына әкеледі.
Шешім және оның салдары
Мұнда бәрі қарапайым. Біз CPU шектеулерінен бас тарттық және кластерлердегі ОЖ ядросын қате түзетілген соңғы нұсқаға жаңартуды бастадық. Біздің қызметтердегі қателер саны (HTTP 5xx) бірден айтарлықтай төмендеді:
HTTP 5xx қателері
Бір маңызды қызмет үшін HTTP 5xx қателері
Жауап беру уақыты p95
Маңызды қызмет сұрауының кешігуі, 95-процентиль
Операциялық шығындар
Өткізілген даналық сағаттардың саны
Ұстау деген не?
Мақаланың басында айтылғандай:
Аналогияны коммуналдық пәтермен жасауға болады... Кубернетес риэлтор қызметін атқарады. Бірақ жалға алушыларды бір-бірімен қақтығыстардан қалай сақтауға болады? Егер олардың біреуі, айталық, ваннаны жарты күнге қарызға алуды шешсе ше?
Міне, аулау. Бір абайсыз контейнер құрылғыдағы барлық қол жетімді CPU ресурстарын жеуі мүмкін. Егер сізде смарт қолданбалар стегі болса (мысалы, JVM, Go, Node VM дұрыс конфигурацияланған), онда бұл проблема емес: мұндай жағдайларда ұзақ уақыт жұмыс істей аласыз. Бірақ қолданбалар нашар оңтайландырылған немесе мүлде оңтайландырылмаған болса (FROM java:latest), жағдай бақылаудан шығып кетуі мүмкін. Omio-да бізде негізгі тіл стекіне сәйкес әдепкі параметрлері бар автоматтандырылған базалық Docker файлдары бар, сондықтан бұл мәселе болған жоқ.
Көрсеткіштерді бақылауды ұсынамыз (пайдалану, қанықтылық және қателер), API кідірістері және қателік жылдамдығы. Нәтижелердің үміттерге сәйкес келетініне көз жеткізіңіз.
сілтемелер
Бұл біздің тарихымыз. Төмендегі материалдар не болып жатқанын түсінуге көмектесті:
- ;
- ;
- ;
- ;
- - «процессорды шектеуді» іздеңіз.
Kubernetes қате туралы есептері:
- ;
- ;
- .
Сіз өзіңіздің тәжірибеңізде ұқсас мәселелерге тап болдыңыз ба немесе контейнерленген өндіріс орталарында дроссельмен байланысты тәжірибеңіз бар ма? Пікірлерде тарихыңызбен бөлісіңіз!
Аудармашыдан PS
Біздің блогта да оқыңыз:
- ««;
- ««;
- ««.
Ақпарат көзі: www.habr.com