27 aprel konferentsiyada , "DevOps" bo'limining bir qismi sifatida "Kubernetesda avtomatik o'lchov va resurslarni boshqarish" hisoboti berildi. Bu sizning ilovalaringizning yuqori mavjudligini ta'minlash va eng yuqori samaradorlikni ta'minlash uchun K8-dan qanday foydalanishingiz haqida gapiradi.
An'anaga ko'ra, biz taqdim etishdan mamnunmiz (44 daqiqa, maqoladan ko'ra ko'proq ma'lumotli) va matn shaklida asosiy xulosa. Bor!
Keling, hisobot mavzusini so'zma-so'z tahlil qilib, oxiridan boshlaylik.
Kubernetes
Aytaylik, bizning xostimizda Docker konteynerlari mavjud. Nima uchun? Takroriylik va izolyatsiyani ta'minlash, bu esa o'z navbatida oddiy va yaxshi joylashtirish imkonini beradi, CI/CD. Bizda konteynerli bunday transport vositalari ko'p.
Bu holatda Kubernetes nima beradi?
- Biz bu mashinalar haqida o'ylashni to'xtatamiz va "bulut" bilan ishlashni boshlaymiz. konteynerlar klasteri yoki podalar (idishlar guruhlari).
- Bundan tashqari, biz alohida podalar haqida o'ylamaymiz, lekin ko'proq narsani boshqaramizоkattaroq guruhlar. Bunday yuqori darajadagi primitivlar ma'lum bir ish yukini ishga tushirish uchun shablon borligini aytishga imkon bering va bu erda uni ishga tushirish uchun kerakli miqdordagi misollar mavjud. Agar shablonni keyinchalik o'zgartirsak, barcha misollar o'zgaradi.
- Yordamida deklarativ API Muayyan buyruqlar ketma-ketligini bajarish o'rniga, biz Kubernetes tomonidan yaratilgan "dunyo tuzilishi" ni (YAMLda) tasvirlaymiz. Va yana: tavsif o'zgarganda, uning haqiqiy ko'rinishi ham o'zgaradi.
Resurslarni boshqarish
Markaziy protsessor
Keling, serverda nginx, php-fpm va mysql-ni ishga tushiramiz. Ushbu xizmatlarda haqiqatan ham ko'proq jarayonlar ishlaydi, ularning har biri hisoblash resurslarini talab qiladi:
(slayddagi raqamlar "to'tiqushlar", har bir jarayonning hisoblash quvvatiga bo'lgan mavhum ehtiyoji)
Bu bilan ishlashni osonlashtirish uchun jarayonlarni guruhlarga birlashtirish mantiqan to'g'ri keladi (masalan, barcha nginx jarayonlari bitta guruhga "nginx"). Buning oddiy va aniq yo'li har bir guruhni konteynerga solib qo'yishdir:
Davom etish uchun konteyner nima ekanligini eslab qolishingiz kerak (Linuxda). Ularning paydo bo'lishi yadroda ancha vaqt oldin amalga oshirilgan uchta asosiy xususiyat tufayli mumkin bo'ldi: , и . Keyingi rivojlanishga boshqa texnologiyalar yordam berdi (shu jumladan Docker kabi qulay "qobiqlar"):
Hisobot kontekstida bizni faqat qiziqtiradi guruhlar, chunki nazorat guruhlari resurslarni boshqarishni amalga oshiradigan konteynerlar (Docker va boshqalar) funksionalligining bir qismidir. Guruhlarga birlashtirilgan jarayonlar, biz xohlaganimizdek, nazorat guruhlari.
Keling, ushbu jarayonlar uchun protsessor talablariga qaytaylik, endi esa jarayonlar guruhlari uchun:
(Takror aytamanki, barcha raqamlar resurslarga bo'lgan ehtiyojning mavhum ifodasidir)
Shu bilan birga, protsessorning o'zi ma'lum cheklangan resursga ega (misolda bu 1000), bu hamma uchun etishmasligi mumkin (barcha guruhlarning ehtiyojlari yig'indisi 150+850+460=1460). Bu holatda nima bo'ladi?
Yadro resurslarni taqsimlashni boshlaydi va uni har bir guruhga bir xil miqdordagi resurslarni berib, "adolatli" qiladi. Lekin birinchi holatda ularning soni kerak bo'lgandan ko'p (333>150), shuning uchun ortiqcha (333-150=183) zaxirada qoladi, bu ham boshqa ikkita konteyner o'rtasida teng taqsimlanadi:
Natijada: birinchi konteyner etarli resurslarga ega edi, ikkinchisi - etarli resurslarga ega emas edi, uchinchisi - etarli resurslarga ega emas edi. Bu harakatlar natijasidir Linuxda "halol" rejalashtiruvchi - . Uning ishlashi topshiriq yordamida sozlanishi mumkin og'irliklar konteynerlarning har biri. Masalan, bu kabi:
Keling, ikkinchi konteynerda (php-fpm) resurslarning etishmasligi holatini ko'rib chiqaylik. Barcha konteyner resurslari jarayonlar o'rtasida teng taqsimlanadi. Natijada, asosiy jarayon yaxshi ishlaydi, lekin barcha ishchilar sekinlashadi va kerakli narsaning yarmidan kamini oladi:
CFS rejalashtiruvchisi shunday ishlaydi. Biz konteynerlarga tayinlaydigan og'irliklarni qo'shimcha ravishda chaqiramiz so'rovlar. Nima uchun bu shunday - batafsilroq ko'ring.
Keling, butun vaziyatni boshqa tomondan ko'rib chiqaylik. Ma'lumki, barcha yo'llar Rimga, kompyuterda esa protsessorga olib boradi. Bitta protsessor, ko'p vazifalar - sizga svetofor kerak. Resurslarni boshqarishning eng oddiy usuli - bu "svetofor": ular bir jarayonga protsessorga belgilangan kirish vaqtini berdi, keyin keyingisiga va hokazo.
Ushbu yondashuv qattiq kvotalar deb ataladi (qattiq cheklash). Keling, buni oddiy tarzda eslaylik chegaralar. Biroq, agar siz barcha konteynerlarga cheklovlarni taqsimlasangiz, muammo paydo bo'ladi: MySQL yo'l bo'ylab harakatlanardi va bir nuqtada uning protsessorga bo'lgan ehtiyoji tugadi, ammo boshqa barcha jarayonlar protsessor tugaguncha kutishga majbur bo'ladi. bo'sh.
Keling, Linux yadrosi va uning protsessor bilan o'zaro ta'siriga qaytaylik - umumiy rasm quyidagicha:
cgroup ikkita sozlamaga ega - asosan bu ikkita oddiy "burilish" bo'lib, ular sizga quyidagilarni aniqlashga imkon beradi:
- konteyner uchun og'irlik (so'rovlar) hisoblanadi ulushlar;
- konteyner vazifalari (cheklovlari) ustida ishlash uchun umumiy CPU vaqtining foizi kvota.
CPU qanday o'lchanadi?
Turli xil usullar mavjud:
- nima parrots, hech kim bilmaydi - har safar muzokara qilish kerak.
- Foiz aniqroq, ammo nisbiy: 50 yadroli va 4 yadroli serverning 20% butunlay boshqa narsalar.
- Siz allaqachon aytib o'tilganlardan foydalanishingiz mumkin og'irliklar, buni Linux biladi, lekin ular ham nisbiydir.
- Eng to'g'ri variant hisoblash resurslarini o'lchashdir soniya. Bular. real vaqt soniyalariga nisbatan protsessor vaqtining soniyalarida: 1 real soniya uchun protsessor vaqtining 1 soniyasi berilgan - bu butun CPU yadrosi.
Gapirishni yanada osonlashtirish uchun ular to'g'ridan-to'g'ri o'lchashni boshladilar yadrolari, ya'ni ular tomonidan haqiqiyga nisbatan bir xil CPU vaqti. Linux og'irliklarni tushunganligi sababli, lekin protsessor vaqti/yadrolari unchalik ko'p emas, biridan ikkinchisiga tarjima qilish uchun mexanizm kerak edi.
Keling, 3 ta protsessor yadroli server bilan oddiy misolni ko'rib chiqaylik, bu erda uchta podkaga og'irliklar (500, 1000 va 1500) beriladi, ular ularga ajratilgan yadrolarning mos keladigan qismlariga (0,5, 1 va 1,5) osongina aylantiriladi.
Agar siz yadrolar ikki barobar ko'p bo'lgan ikkinchi serverni olsangiz (6) va u erda bir xil podlarni joylashtirsangiz, yadrolarning taqsimlanishini oddiygina 2 ga (mos ravishda 1, 2 va 3) ko'paytirish orqali osongina hisoblash mumkin. Ammo muhim lahza ushbu serverda to'rtinchi pod paydo bo'lganda sodir bo'ladi, uning og'irligi qulaylik uchun 3000 ni tashkil qiladi. U CPU resurslarining bir qismini (yadrolarning yarmini) oladi va qolgan podalar uchun ular qayta hisoblab chiqiladi (yarimga qisqartiriladi):
Kubernetes va CPU resurslari
Kubernetes-da CPU resurslari odatda o'lchanadi milliadraks, ya'ni. Asosiy og'irlik sifatida 0,001 yadro olinadi. (Linux/cgroups terminologiyasida xuddi shu narsa CPU ulushi deb ataladi, ammo aniqrog'i, 1000 millikor = 1024 protsessor ulushi.) K8s serverda barcha podslarning og'irliklari yig'indisi uchun CPU resurslaridan ko'ra ko'proq podlarni joylashtirmasligini ta'minlaydi.
Bu qanday sodir bo'ladi? Kubernetes klasteriga server qo'shsangiz, unda qancha protsessor yadrolari mavjudligi haqida xabar beriladi. Yangi podkad yaratishda esa Kubernetes rejalashtiruvchisi bu podkadka qancha yadro kerakligini biladi. Shunday qilib, podkad yetarlicha yadrolar mavjud bo'lgan serverga tayinlanadi.
Agar nima bo'ladi yo'q so'rov ko'rsatilganmi (ya'ni, podda kerakli miqdordagi yadrolar mavjud emas)? Keling, Kubernetes resurslarni qanday hisoblashini aniqlaylik.
Pod uchun siz ikkala so'rovni (CFS rejalashtiruvchisi) va chegaralarni belgilashingiz mumkin (svetoforni eslaysizmi?):
- Agar ular teng ko'rsatilgan bo'lsa, u holda podka QoS klassi tayinlanadi kafolatlangan. Har doim mavjud bo'lgan yadrolarning bu soni kafolatlangan.
- Agar so'rov chegaradan kam bo'lsa - QoS klassi portlash mumkin. Bular. Biz, masalan, pod har doim 1 yadrodan foydalanishini kutamiz, ammo bu qiymat uning uchun cheklov emas: ba'zan pod ko'proq foydalanishi mumkin (serverda buning uchun bepul resurslar mavjud bo'lganda).
- QoS klassi ham mavjud eng yaxshi harakat — so'rov ko'rsatilmagan o'sha podlarni o'z ichiga oladi. Resurslar ularga oxirgi marta beriladi.
xotira
Xotira bilan vaziyat o'xshash, ammo biroz boshqacha - axir, bu resurslarning tabiati boshqacha. Umuman olganda, o'xshashlik quyidagicha:
Keling, so'rovlar xotirada qanday amalga oshirilishini ko'rib chiqaylik. Podlar serverda yashashiga ruxsat bering, xotira sarfini o'zgartiring, toki ulardan biri shunchalik katta bo'lib, xotirasi tugaguncha. Bunday holda, OOM qotili paydo bo'ladi va eng katta jarayonni o'ldiradi:
Bu har doim ham bizga mos kelmaydi, shuning uchun biz uchun qaysi jarayonlar muhimligini va o'ldirmaslik kerakligini tartibga solish mumkin. Buning uchun parametrdan foydalaning oom_score_adj.
Keling, protsessorning QoS sinflariga qaytaylik va podlar uchun xotira iste'moli ustuvorliklarini aniqlaydigan oom_score_adj qiymatlari bilan o'xshashlik keltiramiz:
- Qopqoq uchun eng past oom_score_adj qiymati - -998 - bunday podani oxirgi marta o'ldirish kerakligini anglatadi, bu kafolatlangan.
- Eng yuqori - 1000 eng yaxshi harakat, bunday podalar birinchi navbatda o'ldiriladi.
- Qolgan qiymatlarni hisoblash uchun (portlash mumkin) formula mavjud bo'lib, uning mohiyati shundan iboratki, pod qancha ko'p resurslar so'rasa, uni o'ldirish ehtimoli shunchalik kam bo'ladi.
Ikkinchi "burilish" - limit_in_bayt - chegaralar uchun. U bilan hamma narsa oddiyroq: biz chiqarilgan xotiraning maksimal miqdorini tayinlaymiz va bu erda (protsessordan farqli o'laroq) uni qanday o'lchash (xotira) haqida hech qanday savol yo'q.
jami
Kubernetesdagi har bir pod beriladi requests и limits - CPU va xotira uchun ikkala parametr:
- so'rovlar asosida serverlar o'rtasida podkastlarni taqsimlovchi Kubernetes rejalashtiruvchisi ishlaydi;
- barcha parametrlar asosida podning QoS klassi aniqlanadi;
- Nisbiy og'irliklar CPU so'rovlari asosida hisoblanadi;
- CFS rejalashtiruvchisi CPU so'rovlari asosida tuzilgan;
- OOM killer xotira so'rovlari asosida tuzilgan;
- protsessor chegaralari asosida "svetofor" sozlangan;
- Xotira cheklovlariga asoslanib, guruh uchun chegara sozlangan.
Umuman olganda, ushbu rasm resurslarni boshqarishning asosiy qismi Kubernetesda qanday sodir bo'lishi haqidagi barcha savollarga javob beradi.
Avtomatik masshtablash
K8s klaster-avtoshkari
Tasavvur qilaylik, butun klaster allaqachon ishg'ol qilingan va yangi pod yaratish kerak. Pod ko'rinmasa-da, u holatda osilib turadi kutish. Uning paydo bo'lishi uchun biz klasterga yangi serverni ulashimiz yoki... klaster-avtoshkalani o'rnatishimiz mumkin, bu biz uchun buni amalga oshiradi: bulut provayderidan virtual mashinaga buyurtma bering (API so'rovidan foydalanib) va uni klasterga ulang. , shundan so'ng pod qo'shiladi.
Bu Kubernetes klasterining avtomatik o'lchovidir, u juda yaxshi ishlaydi (bizning tajribamizda). Biroq, boshqa joylarda bo'lgani kabi, bu erda ham ba'zi nuances bor ...
Biz klaster hajmini oshirganimizdek, hamma narsa yaxshi edi, lekin klaster paydo bo'lganda nima bo'ladi o'zini ozod qila boshladi? Muammo shundaki, podlarni ko'chirish (xostlarni bo'shatish uchun) texnik jihatdan juda qiyin va resurslar nuqtai nazaridan qimmat. Kubernetes butunlay boshqacha yondashuvdan foydalanadi.
Joylashtirish xususiyatiga ega 3 ta serverdan iborat klasterni ko'rib chiqing. Unda 6 ta pods bor: endi har bir server uchun 2 tadan. Negadir biz serverlardan birini o'chirib qo'ymoqchi edik. Buning uchun biz buyruqdan foydalanamiz kubectl drain, qaysi:
- ushbu serverga yangi podlarni yuborishni taqiqlaydi;
- serverdagi mavjud bo'laklarni o'chiradi.
Kubernetes podalar sonini (6) saqlash uchun javobgar bo'lganligi sababli, bu oddiy qayta yaratadi ularni boshqa tugunlarda emas, balki o'chirilganda emas, chunki u allaqachon yangi podlarni joylashtirish uchun mavjud emas deb belgilangan. Bu Kubernetes uchun asosiy mexanik.
Biroq, bu erda ham bir nuance bor. Xuddi shunday vaziyatda StatefulSet uchun (Doployment o'rniga) harakatlar boshqacha bo'ladi. Endi bizda allaqachon davlat ilovasi mavjud - masalan, MongoDB bilan uchta pods, ulardan birida qandaydir muammo bor (ma'lumotlar buzilgan yoki podning to'g'ri ishga tushishiga xalaqit beradigan boshqa xato). Va biz yana bitta serverni o'chirishga qaror qildik. Nima bo'ladi?
MongoDB mumkin o'ladi, chunki u kvorumga muhtoj: uchta o'rnatish klasteri uchun kamida ikkitasi ishlashi kerak. Biroq, bu sodir bo'lmayapti - Rahmat PodDisruptionBudget. Ushbu parametr ishlaydigan podkastlarning minimal talab qilinadigan sonini aniqlaydi. MongoDB podkastlaridan biri endi ishlamay qolganligini bilish va PodDisruptionBudget MongoDB uchun o'rnatilganligini ko'rish minAvailable: 2, Kubernetes podani oʻchirishga ruxsat bermaydi.
Xulosa: klaster chiqarilganda podslarning harakati (va aslida qayta yaratilishi) to'g'ri ishlashi uchun PodDisruptionBudget-ni sozlash kerak.
Gorizontal masshtablash
Keling, boshqa vaziyatni ko'rib chiqaylik. Kubernetesda Deployment sifatida ishlaydigan dastur mavjud. Foydalanuvchi trafigi uning podkastlariga keladi (masalan, ulardan uchtasi bor) va biz ulardagi ma'lum bir ko'rsatkichni o'lchaymiz (masalan, CPU yuki). Yuk ko'tarilganda, biz uni jadvalga yozamiz va so'rovlarni tarqatish uchun podalar sonini ko'paytiramiz.
Bugungi kunda Kubernetesda buni qo'lda qilish shart emas: o'lchangan yuk ko'rsatkichlarining qiymatlariga qarab podalar sonining avtomatik ko'payishi/kamayishi sozlangan.
Bu erda asosiy savollar: aniq nimani o'lchash kerak и qanday talqin qilish kerak olingan qiymatlar (podalar sonini o'zgartirish to'g'risida qaror qabul qilish uchun). Siz juda ko'p o'lchashingiz mumkin:
Buni texnik jihatdan qanday qilish kerak - ko'rsatkichlarni to'plash va h.k. — Men hisobotda batafsil gapirdim . Va optimal parametrlarni tanlash bo'yicha asosiy maslahat tajriba!
bor (Foydalanishning to'yinganligi va xatolar), ma'nosi quyidagicha. Masalan, php-fpm ni qanday asosda o'lchash mantiqiy? Ishchilar tugab borayotganiga asoslanib, bu foydalanish. Va agar ishchilar tugagan bo'lsa va yangi ulanishlar qabul qilinmasa, bu allaqachon to'yinganlik. Ushbu parametrlarning ikkalasi ham o'lchanishi kerak va qiymatlarga qarab, masshtablash amalga oshirilishi kerak.
Xulosa o'rniga
Hisobotning davomi bor: vertikal masshtablash va to'g'ri resurslarni qanday tanlash haqida. Bu haqda keyingi videolarda gaplashaman - o'tkazib yubormaslik uchun obuna bo'ling!
Video va slaydlar
Spektakldan video (44 daqiqa):
Hisobot taqdimoti:
PS
Bizning blogimizdagi Kubernetes haqidagi boshqa xabarlar:
- «» (Andrey Polovov; 8-yil 2019-aprel, Saint HighLoad++ da);
- «» (Dmitriy Stolyarov; 8 yil 2018 noyabr HighLoad++ da);
- «» (Dmitriy Stolyarov; 28 yil 2018-may, RootConf da);
- «» (Dmitriy Stolyarov; 7 yil 2017 noyabr HighLoad++ da);
- «» (Dmitriy Stolyarov; 6 yil 2017 iyunda RootConf da).
Manba: www.habr.com