2016-жылы биз Буфердебиз , жана азыр 60ка жакын түйүн (AWSде) жана 1500 контейнер биздин k8s кластеринде иштеп жатат . Бирок, биз микросервистерге сыноо жана ката аркылуу өттүк, жана k8s менен бир нече жыл иштегенден кийин дагы жаңы көйгөйлөргө туш болуп жатабыз. Бул постто биз сүйлөшөбүз процессордун чектөөлөрү: эмне үчүн биз аларды жакшы практика деп ойлодук жана эмне үчүн алар мынчалык жакшы болбой калды.
Процессордун чектөөлөрү жана чектөө
Башка көптөгөн Kubernetes колдонуучулары сыяктуу эле, . Мындай жөндөө болбосо, түйүндөгү контейнерлер процессордун бардык күчүн ээлей алат, бул өз кезегинде маанилүү Кубернет процесстерин (мисалы,) пайда кылат. kubelet) суроо-талаптарга жооп берүүнү токтотот. Ошентип, CPU чектерин коюу түйүндөрүңүздү коргоонун жакшы жолу.
Процессордун чектөөлөрү контейнерди белгилүү бир мезгил үчүн колдоно ала турган максималдуу CPU убактысына коет (демейки 100 мс) жана контейнер бул чектен эч качан ашпайт. Kubernetes үчүн дроссель контейнер жана анын чегинен ашып кетүүсүнө жол бербөө үчүн атайын курал колдонулат , бирок бул жасалма CPU чектөөлөрү сиздин контейнерлериңиздин иштешине зыян келтирип, жооп берүү убактысын көбөйтөт.
Процессордун чектөөлөрүн койбосок, эмне болушу мүмкүн?
Тилекке каршы, биз өзүбүз да ушундай көйгөйгө туш болдук. Ар бир түйүндө контейнерлерди башкаруу үчүн жооптуу процесс бар kubelet, жана ал суроо-талаптарга жооп берүүнү токтотту. Түйүн, бул болгондо, абалга кирет NotReady, жана андан контейнерлер башка жакка багытталып, жаңы түйүндөрдө ошол эле көйгөйлөрдү жаратат. Жок дегенде идеалдуу сценарий эмес.
Тыюу жана жооп берүү көйгөйүнүн көрүнүшү
Контейнерди көзөмөлдөө үчүн негизги көрсөткүч болуп саналат trottling, ал сиздин контейнериңиздин канча жолу дросселденгенин көрсөтөт. Процессордун жүктөмү өтө чоңбу же жокпу, биз кээ бир контейнерлерде дроссель бар экендигин кызыгуу менен байкадык. Мисал катары, негизги API'лерибиздин бирин карап көрөлү:
Төмөндө көрүп тургандай, биз чек койгонбуз 800m (0.8 же 80% негизги) жана эң жакшы жеткен эң жогорку баалуулуктар 200m (20% негизги). Кызматты кыскартуудан мурун бизде дагы эле процессордун күчү көп окшойт, бирок...
Сиз процессордун жүктөмү белгиленген чектен төмөн болсо дагы - бир кыйла төмөн болсо да - дроссель дагы деле болоорун байкаган чыгарсыз.
Буга туш болуп, биз көп өтпөй бир нече ресурстарды таптык (, , ) кыскартуудан улам кызматтардын иштешинин жана жооп берүү убактысынын төмөндөшү жөнүндө.
Эмне үчүн биз CPU аз жүктөөдө дроссельди көрөбүз? Кыска версиясы: "Linux ядросунда ката бар, ал процессордун белгиленген чектери бар контейнерлерди керексиз басууга алып келет." Эгер сизди маселенин табияты кызыктырса, презентацияны окуй аласыз ( и варианттар) Дэйв Чилук тарабынан.
CPU чектөөлөрүн алып салуу (өтө этияттык менен)
Узакка созулган талкуулардан кийин биз колдонуучуларыбыздын маанилүү функцияларына түз же кыйыр түрдө таасирин тийгизген бардык кызматтардан процессордук чектөөлөрдү алып салууну чечтик.
Чечим кабыл алуу оңой болгон жок, анткени биз кластерибиздин туруктуулугун жогору баалайбыз. Мурда биз кластерибиздин туруксуздугу менен эксперимент жүргүзүп көрдүк, андан кийин кызматтар өтө көп ресурстарды жеп, алардын бүт түйүнүнүн ишин жайлады. Эми баары бир аз башкача болду: биз өзүбүздүн кластерлерден эмнени күткөнүбүздү так түшүндүк, ошондой эле пландаштырылган өзгөртүүлөрдү ишке ашыруу боюнча жакшы стратегия алдык.
актуалдуу маселе боюнча ишкер кат алышуу.
Чектөөлөр алынып салынганда түйүндөрүңүздү кантип коргоо керек?
"Чексиз" кызматтарды изоляциялоо:
Мурда биз кээ бир түйүндөр абалга келгенин көрдүк notReady, биринчи кезекте өтө көп ресурстарды керектеген кызматтарга байланыштуу.
Биз мындай кызматтарды «байланыштуу» кызматтарга тоскоол болбошу үчүн өзүнчө («белгиленген») түйүндөргө жайгаштырууну чечтик. Натыйжада, кээ бир түйүндөрдү белгилөө жана толеранттуулук параметрин “байланыштуу” кызматтарга кошуу менен, биз кластерди көбүрөөк көзөмөлдөөгө жетиштик жана түйүндөрдөгү көйгөйлөрдү аныктоо оңой болуп калды. Окшош процесстерди өзүңүз жүргүзүү үчүн, сиз менен тааныша аласыз .
Туура процессорду жана эстутум суроосун дайындоо:
Биздин эң чоң коркконубуз бул процесс өтө көп ресурстарды талап кылат жана түйүн суроо-талаптарга жооп бербей калат. Азыртан бери (Datadog аркасында) биз кластерибиздеги бардык кызматтарды так көзөмөлдөй алдык, мен "байланыштуу" деп белгилөөнү пландаштыргандардын бир нече ай иштешин талдап чыктым. Мен жөн гана 20% маржа менен максималдуу CPU колдонууну койдум, ошентип, 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 Булут): Фиксацияланган оңдоо , бирок дроссель менен көйгөйлөр бар .
Эгерде оңдоо дроссель көйгөйүн чечсе, эмне кылуу керек?
Маселе толугу менен чечилгенине ишенбейм. Түзөтүү менен ядро версиясына жеткенде, мен кластерди сынайм жана постту жаңылайм. Эгер кимдир-бирөө жаңыртылган болсо, мен сиздин натыйжаларыңызды окугум келет.
жыйынтыктоо
- Эгер сиз Docker контейнерлери менен Linux астында иштесеңиз (Кубернетес, Mesos, Swarm же башкаларга карабастан), сиздин контейнерлериңиз дросселден улам өндүрүмдүүлүгүн жоготуп коюшу мүмкүн;
- Мүчүлүштүк мурунтан эле оңдолгон деген үмүт менен бөлүштүрүүнүн акыркы версиясына жаңыртып көрүңүз;
- Процессордун чектөөлөрүн алып салуу көйгөйдү чечет, бирок бул өтө этияттык менен колдонулушу керек болгон коркунучтуу техника (адегенде ядрону жаңыртып, натыйжаларды салыштыруу жакшы);
- Эгерде сиз CPU чектөөлөрүн алып салган болсоңуз, CPU жана эстутумуңуздун колдонулушун кылдаттык менен көзөмөлдөңүз жана CPU ресурстары сиздин керектөөңүздөн ашып жатканын текшериңиз;
- Коопсуз вариант - бул чоң аппараттык жүктөмдө жаңы подкектерди түзүү үчүн, кубернеттер аларды бош түйүндөргө дайындайт.
Бул пост сизге контейнер системаларыңыздын иштешин жакшыртууга жардам берет деп үмүттөнөм.
PS автор окурмандар жана комментаторлор менен кат алышууда (англис тилинде).
Source: www.habr.com