Кубернетестеги CPU чектөөлөрү жана агрессивдүү басуу

Эскертүү. котормо.: Европалык саякат агрегатору болгон Омионун көз жоосун алган бул тарыхы окурмандарды негизги теориядан Кубернетес конфигурациясынын кызыктуу практикалык татаалдыктарына алып барат. Мындай учурлар менен таанышуу сиздин көз карашыңызды кеңейтүүгө гана жардам бербестен, майда-чүйдө эмес көйгөйлөрдүн алдын алууга да жардам берет.

Сизде тиркеме тыгылып калып, ден соолук текшерүүлөрүнө жооп бербей, эмне үчүн экенин түшүнө албай калган учурларыңыз болду беле? Мүмкүн болгон бир түшүндүрмө CPU ресурстук квотанын чектерине байланыштуу. Бул тууралуу биз бул макалада сүйлөшөбүз.

TL; DR:
Эгер сиз CFS квотасы катасы бар Linux ядросунун версиясын колдонуп жатсаңыз, Kubernetes'те CPU чектөөлөрүн өчүрүүнү (же Kubeletте CFS квотасын өчүрүүнү) катуу сунуштайбыз. Өзөгүндө жок олуттуу жана жакшы белгилүү ашыкча дроссель жана кечигүүлөргө алып келген ката.

Омиодо бүт инфраструктураны Kubernetes башкарат. Биздин бардык мамлекеттик жана жарандыгы жок жумуш жүктөрүбүз бир гана Kubernetes'те иштейт (биз Google Kubernetes Engine колдонобуз). Акыркы алты айда биз туш келди басаңдоолорду байкай баштадык. Тиркемелер тоңуп калат же ден соолук текшерүүлөрүнө жооп бербей калат, тармакка байланышы үзүлөт ж.б. Бул жүрүм-турум бизди көпкө таң калтырды, акыры биз бул көйгөйгө олуттуу мамиле кылууну чечтик.

Макаланын кыскача мазмуну:

• контейнерлер жана Kubernetes жөнүндө бир нече сөз;
• CPU суроо-талаптары жана чектөөлөрү кантип ишке ашат;
• CPU чеги көп ядролуу чөйрөдө кантип иштейт;
• CPU тескөөнү кантип көзөмөлдөө керек;
• Маселени чечүү жана нюанстар.

Контейнерлер жана Kubernetes жөнүндө бир нече сөз

Kubernetes инфраструктура дүйнөсүндөгү заманбап стандарт болуп саналат. Анын негизги милдети - контейнер оркестри.

Контейнерлер

Мурда серверлерде иштөө үчүн Java JARs/WARs, Python Eggs же аткарылуучу файлдар сыяктуу артефакттарды түзүшүбүз керек болчу. Бирок, алардын иштеши үчүн кошумча иштерди аткаруу керек болчу: иштөө чөйрөсүн (Java/Python) орнотуу, керектүү файлдарды керектүү жерлерге жайгаштыруу, операциялык системанын белгилүү бир версиясы менен шайкештикти камсыздоо ж.б. Башкача айтканда, конфигурацияны башкарууга кылдат көңүл буруу керек болчу (бул көбүнчө иштеп чыгуучулар менен системалык администраторлордун ортосунда талаш-тартыштын булагы болгон).

Контейнерлер баарын өзгөрттү. Эми артефакт контейнердин сүрөтү. Ал программаны гана эмес, толук кандуу аткаруу чөйрөсүн (Java/Python/...), ошондой эле алдын ала орнотулган жана даяр болгон керектүү файлдарды/пакеттерди камтыган кеңейтилген аткарылуучу файлдын бир түрү катары көрсөтүлүшү мүмкүн. чуркоо. Контейнерлерди эч кандай кошумча кадамдарсыз жайгаштырууга жана башка серверлерде иштетүүгө болот.

Мындан тышкары, контейнерлер өздөрүнүн кумдук чөйрөсүндө иштешет. Алардын өздөрүнүн виртуалдык тармак адаптери, мүмкүнчүлүгү чектелген өз файлдык системасы, процесстердин өз иерархиясы, CPU жана эстутум боюнча өз чектөөлөрү ж.б. Мунун баары Linux ядросунун атайын подсистемасынын – аттар мейкиндигинин аркасында ишке ашат.

Kubernetes

Жогоруда айтылгандай, Kubernetes контейнер оркестри болуп саналат. Ал мындай иштейт: сиз ага машиналардын бассейнин берип, анан: "Эй, Кубернетес, келгиле, менин контейнеримдин он нускасын 2 процессор жана ар бири 3 ГБ эстутум менен ишке киргизип, аларды иштетели!" Калганын Кубернетес чечет. Ал бош сыйымдуулукту табат, контейнерлерди ишке киргизет жана керек болсо аларды өчүрүп күйгүзөт, версияларды өзгөртүүдө жаңыртууну чыгарат ж.б. Негизи, Kubernetes сизге аппараттык компонентти абстракциялоого мүмкүндүк берет жана тиркемелерди жайылтуу жана иштетүү үчүн ылайыктуу системалардын кеңири түрүн түзөт.

Кубернетес жөнөкөй адамдын көз карашынан

Kubernetes'те кандай суроо-талаптар жана чектөөлөр бар

Макул, биз контейнерлерди жана Кубернеттерди жаап койдук. Бир эле машинада бир нече контейнер жайгаша аларын да билебиз.

Аналогияны коммуналдык батир менен көрсөтсө болот. Кең жай (машиналар/агрегаттар) алынып, бир нече ижарачыларга (контейнерлер) ижарага берилет. Кубернетес риэлтор катары иштейт. Суроо туулат, ижарачыларды бири-бири менен чыр-чатактардан кантип сактоо керек? Алардын бири, айталы, жарым күнгө ваннаны карызга алууну чечсечи?

Бул жерде суроо-талаптар жана чектөөлөр пайда болот. CPU өтүнүч пландаштыруу максатында гана керек. Бул контейнердин "каалоо тизмеси" сыяктуу нерсе жана ал эң ылайыктуу түйүндү тандоо үчүн колдонулат. Ошол эле учурда CPU чек ижара келишими менен салыштырууга болот - биз контейнер үчүн бирдикти тандап алгандан кийин дароо албайт белгиленген чектерден чыгуу. Мына ушул жерден маселе келип чыгат...

Kubernetes'те суроо-талаптар жана чектөөлөр кантип ишке ашырылат

Кубернетес CPU чектерин ишке ашыруу үчүн ядрого орнотулган тескөө механизмин (саат циклдерин өткөрүп жиберүү) колдонот. Эгер колдонмо чектен ашып кетсе, дроссель иштетилет (б.а. ал CPU циклин азыраак алат). Эстутум боюнча суроо-талаптар жана чектөөлөр башкача уюштурулган, ошондуктан аларды аныктоо оңой. Бул үчүн, жөн гана подкасттын акыркы кайра күйгүзүү абалын текшериңиз: ал "OOMKilled" же жокпу. CPU тескөө оңой эмес, анткени K8s метрикаларды топтор боюнча эмес, колдонуу боюнча гана жеткиликтүү кылат.

CPU өтүнүчү

CPU сурамы кантип ишке ашат

Жөнөкөйлүк үчүн, мисал катары 4 ядролуу CPU менен машинаны колдонуу процессин карап көрөлү.

K8s ресурстарды (эстутум жана процессор) бөлүштүрүүнү көзөмөлдөө үчүн башкаруу тобунун механизмин (круппаларды) колдонот. Ал үчүн иерархиялык модель бар: бала ата-энелик топтун чегин мурастайт. Бөлүштүрүү деталдары виртуалдык файл тутумунда сакталат (/sys/fs/cgroup). Процессордо бул /sys/fs/cgroup/cpu,cpuacct/*.

K8s файлды колдонот cpu.share процессор ресурстарын бөлүштүрүү. Биздин учурда, тамыр cgroup CPU ресурстарынын 4096 үлүшүн алат - колдо болгон процессордун 100% (1 ядро ​​= 1024; бул белгиленген маани). Тамыр тобу катталган урпактардын үлүшүнө жараша ресурстарды пропорционалдуу бөлүштүрөт cpu.share, жана алар, өз кезегинде, алардын урпактары менен, ж.б.у.с. Кадимки Kubernetes түйүнүндө, тамырлар тобунун үч баласы бар: system.slice, user.slice и kubepods. Биринчи эки подгруппа ресурстарды системалык жүктөмдөрдүн жана K8ден тышкары колдонуучу программаларынын ортосунда бөлүштүрүү үчүн колдонулат. Акыркы - kubepods — Кубернетес тарабынан поддондор арасында ресурстарды бөлүштүрүү үчүн түзүлгөн.

Жогорудагы диаграмма биринчи жана экинчи подгруппалардын ар бирин алганын көрсөтүп турат 1024 үлүштөр, kuberpod подгруппа бөлүнгөн 4096 үлүштөр Бул кантип мүмкүн: түпкү топтун гана мүмкүнчүлүгү бар 4096 үлүштөрү, жана анын тукумдарынын үлүштөрүнүн суммасы бул сандан бир топ ашып кетет (6144)? Мааниси логикалык мааниге ээ, ошондуктан Linux пландоочусу (CFS) аны CPU ресурстарын пропорционалдуу бөлүштүрүү үчүн колдонот. Биздин учурда биринчи эки топ алышат 680 реалдуу үлүштөрү (16,6 4096%), ал эми kubepod калган алат 2736 үлүштөр Токтоп калган учурда биринчи эки топ белунген ресурстарды пайдаланышпайт.

Бактыга жараша, пландоочу колдонулбаган CPU ресурстарын текке кетирбөө үчүн механизмге ээ. Ал "бос" кубаттуулукту глобалдык бассейнге өткөрүп берет, андан ал кошумча процессордун күчүн талап кылган топторго бөлүштүрүлөт (тегеректөө жоготууларын болтурбоо үчүн өткөрүп берүү партиялар менен жүргүзүлөт). Ушундай эле ыкма урпактардын бардык урпактарына карата колдонулат.

Бул механизм процессордун күчүн адилет бөлүштүрүүнү камсыздайт жана эч ким башкалардын ресурстарын "уурдап кетпесин" камсыздайт.

CPU чеги

K8sдеги чектөөлөрдүн жана суроо-талаптардын конфигурациялары окшош болгонуна карабастан, аларды ишке ашыруу түп-тамырынан бери айырмаланат: бул эң адаштыруучу жана эң аз документтештирилген бөлүгү.

K8s ишке кирет CFS квота механизми лимиттерди ишке ашыруу. Алардын орнотуулары файлдарда көрсөтүлгөн cfs_period_us и cfs_quota_us cgroup каталогунда (файл да ошол жерде жайгашкан cpu.share).

айырмаланып, cpu.share, квота негизделген убакыт мезгили, жана жеткиликтүү процессордун кубаттуулугунда эмес. cfs_period_us мезгилдин (доордун) узактыгын белгилейт - ал ар дайым 100000 мкс (100 мс). K8sде бул маанини өзгөртүү мүмкүнчүлүгү бар, бирок ал азырынча альфада гана жеткиликтүү. Пландоочу колдонулган квоталарды кайра баштоо үчүн доорду колдонот. Экинчи файл cfs_quota_us, ар бир доордо жеткиликтүү убакытты (квотаны) көрсөтөт. Ал микросекунддарда да көрсөтүлгөнүнө көңүл буруңуз. Квота доордун узундугунан ашып кетиши мүмкүн; башкача айтканда, 100 мсден жогору болушу мүмкүн.

Келгиле, 16 ядролуу машиналардагы эки сценарийди карап көрөлү (Омиодо бизде эң кеңири таралган компьютер түрү):

1-сценарий: 2 жип жана 200 мс чеги. Тыюу жок

2-сценарий: 10 жип жана 200 мс чеги. Тыюу 20 мсден кийин башталат, процессордун ресурстарына кирүү дагы 80 мсден кийин улантылат

Сиз CPU чегин койдуңуз дейли 2 ядролор; Kubernetes бул маанини 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 чектөөлөрүнөн баш тарттык жана OS ядросун кластерлерде ката оңдолгон эң акыркы версияга жаңырта баштадык. Биздин кызматтарда каталардын саны (HTTP 5xx) дароо бир топ төмөндөдү:

HTTP 5xx каталары

Бир маанилүү кызмат үчүн HTTP 5xx каталары

Жооп берүү убактысы p95

Критикалык кызмат сурамынын күтүү убактысы, 95-проценттил

Операциялык чыгымдар

Сарпталган сааттардын саны

балык деген эмне?

Макаланын башында айтылгандай:

Аналогияны коммуналдык квартира менен салыштырууга болот... Кубернетес риэлтордук милдетин аткарат. Бирок ижарачыларды бири-бири менен чыр-чатактардан кантип сактоо керек? Алардын бири, айталы, жарым күнгө ваннаны карызга алууну чечсечи?

Мына кармаш. Бир бейкапар контейнер машинадагы бардык CPU ресурстарын жеп коюшу мүмкүн. Эгер сизде акылдуу тиркеме стек болсо (мисалы, JVM, Go, Node VM туура конфигурацияланган), анда бул көйгөй эмес: сиз мындай шарттарда көпкө иштей аласыз. Бирок тиркемелер начар оптималдаштырылса же такыр оптималдаштырылбаса (FROM java:latest), кырдаал көзөмөлдөн чыгып кетиши мүмкүн. Omio'до бизде негизги тил стек үчүн адекваттуу демейки жөндөөлөрү бар автоматташтырылган базалык Докер файлдары бар, андыктан бул маселе болгон эмес.

Биз көрсөткүчтөрдү көзөмөлдөөнү сунуштайбыз USE (колдонуу, каныккандык жана каталар), API кечигүүлөрү жана ката ылдамдыгы. Натыйжалар күтүүлөргө жооп беришин камсыз кылуу.

шилтемелер

Бул биздин окуя. Төмөнкү материалдар эмне болуп жатканын түшүнүүгө чоң жардам берди:

• kernel.org → CFS Scheduler;
• kernel.org → CFS өткөрүү жөндөмдүүлүгүн башкаруу;
• Linux контейнердик пландоону түшүнүү;
• Linux контейнерлери жөнүндө билишиңиз керек болгон нерселердин баары, I бөлүк: Linux башкаруу топтору жана процесстерди изоляциялоо;
• Kubernetes Failure Stories - "процессорду чектөөнү" издеңиз.

Kubernetes мүчүлүштүктөрү тууралуу кабарлар:

• #51135: Кепилденген поддондор үчүн CPU чектерин коюудан качыңыз;
• #67577: CFS квоталары керексиз дроссельге алып келиши мүмкүн;
• Өтө агрессивдүү CFS.

Сиздин практикаңызда ушундай көйгөйлөргө туш болдуңузбу же контейнерлүү өндүрүш чөйрөлөрүндө дроссель менен байланышкан тажрыйбаңыз барбы? Комментарийлерде окуяңыз менен бөлүшүңүз!

Котормочудан PS

Биздин блогдон дагы окуңуз:

• «Kubernetes'те автоматтык масштабдоо жана ресурстарды башкаруу (карап чыгуу жана видео отчет)";
• «CPU менеджери Kubernetesте кантип иштейт";
• «kubectl иштеткенде, Kubernetesте эмне болот? 2 бөлүк«.

Source: www.habr.com