2016 жылы біз Буферде болдық , және қазір 60-қа жуық түйін (AWS жүйесінде) және 1500 контейнер басқаратын k8s кластерімізде жұмыс істейді. . Дегенмен, біз сынақ және қате арқылы микросервистерге көштік, тіпті k8s-пен бірнеше жыл жұмыс істегеннен кейін де біз әлі де жаңа мәселелерге тап боламыз. Бұл постта біз сөйлесетін боламыз процессор шектеулері: неге біз оларды жақсы тәжірибе деп ойладық және неге олар соншалықты жақсы болмады.
Процессор шектеулері және реттеу
Көптеген басқа Kubernetes пайдаланушылары сияқты, . Мұндай параметр болмаса, түйіндегі контейнерлер процессордың барлық қуатын ала алады, бұл өз кезегінде маңызды Кубернет процестерін тудырады (мысалы, kubelet) сұрауларға жауап беруді тоқтатады. Осылайша, CPU шектеулерін орнату түйіндерді қорғаудың жақсы тәсілі болып табылады.
Процессор шектеулері контейнерді белгілі бір уақыт ішінде (әдепкі 100 мс) пайдалана алатын ең жоғары CPU уақытына орнатады және контейнер бұл шектен ешқашан аспайды. Kubernetes үшін дроссельдеу контейнерге және оның шектен асып кетуіне жол бермеу үшін арнайы құрал қолданылады , бірақ бұл жасанды CPU шектеулері өнімділікке нұқсан келтіреді және контейнерлеріңіздің жауап беру уақытын арттырады.
Процессорға шектеу қоймасақ не болуы мүмкін?
Өкінішке орай, бұл мәселеге өзіміз де тап болдық. Әрбір түйінде контейнерлерді басқаруға жауапты процесс бар kubelet, және ол сұрауларға жауап беруді тоқтатты. Бұл орын алған кезде түйін күйге өтеді NotReady, және одан контейнерлер басқа жерге қайта бағытталады және жаңа түйіндерде бірдей мәселелерді жасайды. Кем дегенде идеалды сценарий емес.
Тығыздау және жауап беру мәселесінің көрінісі
Контейнерді бақылаудың негізгі көрсеткіші болып табылады trottling, ол сіздің контейнеріңіздің қанша рет дроссельденгенін көрсетеді. Біз процессордың шамадан тыс жүктелуіне қарамастан, кейбір контейнерлерде дроссельдің болуын қызығушылықпен байқадық. Мысал ретінде негізгі API интерфейстеріміздің бірін қарастырайық:
Төменде көріп отырғаныңыздай, біз шектеу қойдық 800m (0.8 немесе 80% негізгі) және ең жоғары мәндер ең жақсы жетеді 200m (20% негізгі). Қызметті төмендетпес бұрын бізде әлі де процессордың көп қуаты бар сияқты, бірақ...
Сіз процессордың жүктелуі көрсетілген шектен төмен болса да - айтарлықтай төмен болса да, дроссель әлі де болатынын байқаған боларсыз.
Осыған тап болып, біз көп ұзамай бірнеше ресурстарды таптық (, , ) дроссельге байланысты қызметтердің өнімділігі мен жауап беру уақытының төмендеуі туралы.
Неліктен біз процессордың төмен жүктемесінде дроссельді көреміз? Қысқа нұсқасы: «Linux ядросында процессордың белгіленген шектеулері бар контейнерлерді қажетсіз азайтуды тудыратын қате бар». Егер сізді мәселенің мәні қызықтырса, презентацияны оқи аласыз ( и опциялары) Дэйв Чилук.
CPU шектеулерін жою (өте сақтықпен)
Ұзақ талқылаулардан кейін біз пайдаланушыларымыздың маңызды функцияларына тікелей немесе жанама әсер еткен барлық қызметтерден процессорлық шектеулерді алып тастауды шештік.
Шешім қабылдау оңай болған жоқ, өйткені біз кластеріміздің тұрақтылығын жоғары бағалаймыз. Бұрын біз кластеріміздің тұрақсыздығымен тәжірибе жасап көрдік, содан кейін қызметтер тым көп ресурстарды тұтынып, олардың бүкіл түйінінің жұмысын баяулатты. Енді бәрі басқаша болды: біз өз кластерлерімізден не күткенімізді нақты түсіндік, сондай-ақ жоспарланған өзгерістерді жүзеге асырудың жақсы стратегиясы болды.
Өзекті мәселе бойынша іскерлік хат алмасу.
Шектеулер жойылған кезде түйіндерді қалай қорғауға болады?
«Шектеусіз» қызметтерді оқшаулау:
Бұрын біз кейбір түйіндердің күйге түскенін көрдік notReady, ең алдымен тым көп ресурстарды тұтынатын қызметтерге байланысты.
Біз мұндай қызметтерді «байланысты» қызметтерге кедергі жасамас үшін бөлек («белгіленген») түйіндерге орналастыруды шештік. Нәтижесінде, кейбір түйіндерді белгілеу және төзімділік параметрін «байланысты емес» қызметтерге қосу арқылы біз кластерді бақылауға қол жеткіздік және түйіндерге қатысты мәселелерді анықтау оңайырақ болды. Ұқсас процестерді өз бетіңізше орындау үшін сіз өзіңізбен танысуға болады .
Дұрыс процессор мен жад сұрауын тағайындау:
Біздің ең үлкен қорқынышымыз процесс тым көп ресурстарды тұтынады және түйін сұрауларға жауап беруді тоқтатады. Енді (Datadog арқасында) біз кластеріміздегі барлық қызметтерді нақты бақылай алатындықтан, мен «байланысты» деп белгілеуді жоспарлағандардың бірнеше айлық жұмысын талдадым. Мен жай ғана 20% маржамен максималды процессорды пайдалануды орнаттым, осылайша k8s түйінге басқа қызметтерді тағайындауға тырысқан жағдайда түйінде бос орын бөлдім.
Графиктен көріп отырғаныңыздай, процессорға максималды жүктеме жетті 242m CPU ядролары (0.242 процессор ядролары). Процессор сұрауы үшін осы мәннен сәл үлкенірек санды алу жеткілікті. Қызметтер пайдаланушыға бағытталғандықтан, ең жоғары жүктеме мәндері трафикпен сәйкес келетінін ескеріңіз.
Жадты пайдалану және сұраулар үшін де солай істеңіз, және voila - бәріңіз реттелдіңіз! Қауіпсіздікті арттыру үшін көлденең подкасттың автомасштабтауын қосуға болады. Осылайша, ресурс жүктемесі жоғары болған сайын, автомасштабтау жаңа подкасттарды жасайды, ал кубернеттер оларды бос орны бар түйіндерге таратады. Кластердің өзінде бос орын қалмаған жағдайда, өзіңізге ескерту орнатуға немесе олардың автомасштабтауы арқылы жаңа түйіндерді қосуды теңшеуге болады.
Минустардың ішінен біз жеңілгенімізді атап өткен жөн.«, яғни. бір түйінде жұмыс істейтін контейнерлер саны. Трафиктің төмен тығыздығында бізде көптеген «босаңсулар» болуы мүмкін және сізде процессордың жоғары жүктемесіне жету мүмкіндігіңіз бар, бірақ автомасштабтау түйіндері соңғысына көмектесуі керек.
нәтижелері
Мен соңғы бірнеше аптадағы эксперименттердің осы тамаша нәтижелерін жариялағаныма қуаныштымын; біз барлық өзгертілген қызметтерде жауаптың айтарлықтай жақсарғанын байқадық:
Біз басты бетте ең жақсы нәтижелерге қол жеткіздік (), сонда қызмет жеделдеді жиырма екі рет!
Linux ядросының қатесі түзетілді ме?
Иә, тарату 4.19 және одан жоғары нұсқасы.
Дегенмен, оқығанда 2020 жылдың екінші қыркүйегі үшін біз әлі де ұқсас қатесі бар кейбір Linux жобалары туралы еске түсіреміз. Менің ойымша, кейбір Linux дистрибутивтерінде бұл қате әлі де бар және оны түзету үстінде.
Егер тарату нұсқаңыз 4.19-дан төмен болса, мен соңғы нұсқасына жаңартуды ұсынар едім, бірақ кез келген жағдайда процессор шектеулерін алып тастауға тырысып, дроссельдің сақталатынын көру керек. Төменде Kubernetes басқару қызметтері мен Linux дистрибутивтерінің ішінара тізімін көре аласыз:
- Debian: таратудың соңғы нұсқасына біріктірілген түзету, , және өте жаңа көрінеді (). Кейбір алдыңғы нұсқалар да түзетілуі мүмкін.
- Ubuntu: соңғы нұсқаға біріктірілген түзету
- EKS әлі түзетуге қол жеткізді . Егер нұсқаңыз осыдан төмен болса, AMI жаңартуыңыз керек.
- копс: у
kops 1.18+Негізгі хост кескіні Ubuntu 20.04 болады. Егер копс нұсқасы ескірек болса, сізге түзетуді күту қажет болуы мүмкін. Қазір өзіміз күтіп отырмыз. - GKE (Google Cloud): Біріктірілген түзету , дегенмен дроссельде проблемалар бар .
Түзету дроссель мәселесін шешсе не істеу керек?
Мәселе толығымен шешілгеніне сенімді емеспін. Түзетілген ядро нұсқасына жеткенде, мен кластерді тексеремін және постты жаңартамын. Егер біреу әлдеқашан жаңартқан болса, мен сіздің нәтижелеріңізді оқуға қызығамын.
қорытынды
- Linux жүйесінде Docker контейнерлерімен жұмыс істесеңіз (Kubernetes, Mesos, Swarm немесе басқалары маңызды емес), сіздің контейнерлеріңіз дроссельге байланысты өнімділігін жоғалтуы мүмкін;
- Қате түзетілді деген үмітпен таратудың соңғы нұсқасына жаңартып көріңіз;
- Процессор шектеулерін жою мәселені шешеді, бірақ бұл өте сақтықпен қолданылуы керек қауіпті әдіс (алдымен ядроны жаңартып, нәтижелерді салыстыру жақсы);
- Егер сіз CPU шектеулерін алып тастасаңыз, процессорды және жадты пайдалануды мұқият қадағалаңыз және CPU ресурстары тұтыну мөлшерінен асып түсетініне көз жеткізіңіз;
- Қауіпсіз опция - кубернеттердің оларды бос түйіндерге тағайындауы үшін аппараттық жүктеме жоғары болған жағдайда жаңа подкасттарды жасау үшін автоматты масштабтау.
Бұл пост контейнерлік жүйелеріңіздің жұмысын жақсартуға көмектеседі деп үміттенемін.
PS автор оқырмандармен және комментаторлармен хат алысады (ағылшын тілінде).
Ақпарат көзі: www.habr.com