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