2016 yilda biz Buferdamiz , va hozirda 60 ga yaqin tugunlar (AWS da) va 1500 ta konteynerlar bizning k8s klasterimizda ishlamoqda. . Biroq, biz mikroservislarga sinov va xato orqali o'tdik va hatto k8s bilan bir necha yil ishlaganimizdan keyin ham biz yangi muammolarga duch kelamiz. Ushbu postda biz bu haqda gaplashamiz protsessor cheklovlari: nega biz ularni yaxshi amaliyot deb o'yladik va nima uchun ular unchalik yaxshi bo'lmadi.
Protsessor cheklovlari va cheklovi
Boshqa ko'plab Kubernetes foydalanuvchilari singari, . Bunday sozlamasiz, tugundagi konteynerlar protsessorning barcha quvvatini egallashi mumkin, bu esa o'z navbatida muhim Kubernetes jarayonlarini keltirib chiqaradi (masalan, kubelet) so'rovlarga javob berishni to'xtatadi. Shunday qilib, protsessor chegaralarini o'rnatish tugunlaringizni himoya qilishning yaxshi usuli hisoblanadi.
Protsessor cheklovlari konteynerni ma'lum bir davr uchun foydalanishi mumkin bo'lgan maksimal CPU vaqtiga o'rnatadi (standart 100ms) va konteyner hech qachon bu chegaradan oshmaydi. Kubernetes uchun bostirish konteyner va uning chegaradan oshib ketishiga yo'l qo'ymaslik uchun maxsus asbob ishlatiladi , ammo bu sun'iy protsessor cheklovlari ishlashga putur etkazadi va konteynerlaringizning javob vaqtini oshiradi.
Agar protsessor chegaralarini o'rnatmasak nima bo'lishi mumkin?
Afsuski, biz o'zimiz bu muammoga duch keldik. Har bir tugun konteynerlarni boshqarish uchun javobgar bo'lgan jarayonga ega kubelet, va u so'rovlarga javob berishni to'xtatdi. Tugun, bu sodir bo'lganda, holatga o'tadi NotReady, va undan konteynerlar boshqa joyga yo'naltiriladi va yangi tugunlarda bir xil muammolarni yaratadi. Hech bo'lmaganda ideal stsenariy emas.
Bloklash va javob berish muammosining namoyon bo'lishi
Konteynerni kuzatish uchun asosiy ko'rsatkich trottling, bu sizning konteyneringiz necha marta gaz tushirilganligini ko'rsatadi. Biz protsessor yukining haddan tashqari yuklanishidan qat'i nazar, ba'zi konteynerlarda drossel mavjudligini qiziqish bilan payqadik. Misol tariqasida, asosiy API-larimizdan birini ko'rib chiqamiz:
Quyida ko'rib turganingizdek, biz cheklovni o'rnatdik 800m (0.8 yoki 80% yadro) va eng yaxshi maksimal qiymatlarga erishiladi 200m (20% yadro). Aftidan, xizmatni o'chirishdan oldin bizda protsessor kuchi hali ham ko'p, ammo...
Ehtimol, protsessor yuki belgilangan chegaralardan past bo'lsa ham - sezilarli darajada pastroq bo'lsa ham, siqilish hali ham sodir bo'lishini payqadingiz.
Bunga duch kelganimizda, biz tez orada bir nechta manbalarni topdik (, , ) tejamkorlik tufayli xizmatlarning ishlashi va javob berish vaqtining pasayishi haqida.
Nima uchun biz protsessorning past yuklanishida siqilishni ko'ramiz? Qisqa versiya: "Linux yadrosida protsessor chegaralari ko'rsatilgan konteynerlarni keraksiz ravishda qisqartirishga olib keladigan xatolik mavjud." Muammoning mohiyati bilan qiziqsangiz, taqdimotni o'qishingiz mumkin ( и variantlari) Deyv Chiluk tomonidan.
CPU cheklovlarini olib tashlash (o'ta ehtiyotkorlik bilan)
Uzoq davom etgan munozaralardan so'ng biz foydalanuvchilarimiz uchun muhim funksiyalarga bevosita yoki bilvosita ta'sir ko'rsatadigan barcha xizmatlardan protsessor cheklovlarini olib tashlashga qaror qildik.
Qaror qabul qilish oson bo'lmadi, chunki biz klasterimiz barqarorligini juda qadrlaymiz. Ilgari biz klasterimizning beqarorligi bilan tajriba o'tkazdik, keyin xizmatlar juda ko'p resurslarni iste'mol qildi va ularning butun tugunining ishini sekinlashtirdi. Endi hamma narsa biroz boshqacha edi: biz klasterlarimizdan nimani kutayotganimizni aniq tushundik, shuningdek, rejalashtirilgan o'zgarishlarni amalga oshirish uchun yaxshi strategiyamiz.
dolzarb masala bo'yicha ish yozishmalar.
Cheklovlar olib tashlanganda tugunlaringizni qanday himoya qilish kerak?
"Cheklanmagan" xizmatlarni izolyatsiya qilish:
O'tmishda biz ba'zi tugunlarning holatga kelganini ko'rdik notReady, birinchi navbatda juda ko'p resurslarni iste'mol qilgan xizmatlar tufayli.
Biz bunday xizmatlarni alohida ("yorliqlangan") tugunlarga joylashtirishga qaror qildik, shunda ular "tegishli" xizmatlarga aralashmaydi. Natijada, ba'zi tugunlarni belgilash va tolerantlik parametrini "aloqasiz" xizmatlarga qo'shish orqali biz klaster ustidan ko'proq nazoratga erishdik va tugunlar bilan bog'liq muammolarni aniqlash osonroq bo'ldi. Shunga o'xshash jarayonlarni o'zingiz amalga oshirish uchun siz o'zingiz bilan tanishishingiz mumkin .
To'g'ri protsessor va xotira so'rovini belgilash:
Bizning eng katta qo'rquvimiz bu jarayon juda ko'p resurslarni iste'mol qilishi va tugun so'rovlarga javob berishni to'xtatishi edi. Endi (Datadog tufayli) biz klasterimizdagi barcha xizmatlarni aniq kuzatishimiz mumkin edi, men "bog'liqsiz" deb belgilashni rejalashtirganlarning bir necha oylik ishini tahlil qildim. Men oddiygina protsessordan maksimal foydalanishni 20% marj bilan o'rnatdim va agar k8s tugunga boshqa xizmatlarni tayinlashga harakat qilsa, tugunga joy ajratdim.
Grafikda ko'rib turganingizdek, protsessorning maksimal yuklanishiga erishildi 242m CPU yadrolari (0.242 protsessor yadrolari). Protsessor so'rovi uchun bu qiymatdan biroz kattaroq raqamni olish kifoya. Shuni esda tutingki, xizmatlar foydalanuvchiga yo'naltirilganligi sababli, yuklanishning eng yuqori qiymatlari trafik bilan mos keladi.
Xotiradan foydalanish va so'rovlar bilan ham xuddi shunday qiling, va voila - hammangiz sozlangansiz! Kattaroq xavfsizlik uchun siz gorizontal pod avtomatik o'lchovni qo'shishingiz mumkin. Shunday qilib, har safar resurs yuki yuqori bo'lsa, avtomatik o'lchov yangi podslarni yaratadi va kubernetlar ularni bo'sh joy bo'lgan tugunlarga tarqatadi. Agar klasterning o'zida bo'sh joy qolmagan bo'lsa, siz o'zingizga ogohlantirish o'rnatishingiz yoki ularning avtomatik o'lchami orqali yangi tugunlarni qo'shishni sozlashingiz mumkin.
Kamchiliklardan shuni ta'kidlash kerakki, biz "da yutqazdik"", ya'ni. bitta tugunda ishlaydigan konteynerlar soni. Trafik zichligi past bo'lganida bizda juda ko'p "dam olish" bo'lishi mumkin va siz yuqori protsessor yukiga erishishingiz mumkin, ammo avtomatik o'lchash tugunlari ikkinchisiga yordam berishi kerak.
Natijalar
Oxirgi bir necha hafta davomida o‘tkazilgan tajribalar natijasida olingan ajoyib natijalarni e’lon qilishdan mamnunman; biz barcha o‘zgartirilgan xizmatlarda javob berishda sezilarli yaxshilanishlarni ko‘rdik:
Biz bosh sahifamizda eng yaxshi natijalarga erishdik (), u erda xizmat tezlashdi yigirma ikki marta!
Linux yadrosi xatosi tuzatildimi?
Ha, tarqatish versiyalari 4.19 va undan yuqori.
Biroq, o'qish paytida 2020 yil ikkinchi sentyabr uchun Biz hali ham shunga o'xshash xato bilan ba'zi Linux loyihalari haqida eslatib turamiz. O'ylaymanki, ba'zi Linux distributivlarida hali ham bu xato mavjud va ularni tuzatish ustida ishlamoqda.
Agar tarqatish versiyangiz 4.19 dan past bo'lsa, men eng so'nggi versiyasiga yangilashni maslahat beraman, lekin har qanday holatda protsessor cheklovlarini olib tashlashga urinib ko'rishingiz va siqilish davom etayotganini ko'rishingiz kerak. Quyida siz Kubernetes boshqaruv xizmatlari va Linux distributivlarining qisman roʻyxatini koʻrishingiz mumkin:
- Debian: tarqatishning so'nggi versiyasiga o'rnatilgan tuzatish, , va juda yangi ko'rinadi (). Ba'zi oldingi versiyalar ham tuzatilishi mumkin.
- Ubuntu: so'nggi versiyaga o'rnatilgan tuzatish
- EKS hali tuzatgan . Agar sizning versiyangiz bundan past bo'lsa, AMI-ni yangilashingiz kerak.
- kops: у
kops 1.18+Asosiy xost tasviri Ubuntu 20.04 bo'ladi. Agar sizning kops versiyangiz eskiroq bo'lsa, tuzatishni kutishingiz kerak bo'lishi mumkin. Hozir o'zimiz kutyapmiz. - GKE (Google Cloud): Birlashtirilgan tuzatish , ammo drossel bilan bog'liq muammolar mavjud .
Agar tuzatish siqilish muammosini hal qilsa nima qilish kerak?
Muammo butunlay hal qilinganiga ishonchim komil emas. Tuzatish bilan yadro versiyasiga kelganimizda, men klasterni sinab ko'raman va postni yangilayman. Agar kimdir allaqachon yangilangan bo'lsa, men sizning natijalaringizni o'qishni xohlayman.
xulosa
- Agar siz Linux ostida Docker konteynerlari bilan ishlasangiz (Kubernetes, Mesos, Swarm yoki boshqalardan qat'iy nazar), sizning konteynerlaringiz tormozlash tufayli unumdorligini yo'qotishi mumkin;
- Xato tuzatilgan degan umidda tarqatishning so'nggi versiyasiga yangilashga harakat qiling;
- Protsessor cheklovlarini olib tashlash muammoni hal qiladi, ammo bu juda ehtiyotkorlik bilan ishlatilishi kerak bo'lgan xavfli texnikadir (avval yadroni yangilash va natijalarni solishtirish yaxshiroqdir);
- Agar siz protsessor cheklovlarini olib tashlagan bo'lsangiz, protsessor va xotiradan foydalanishni diqqat bilan kuzatib boring va protsessor resurslaringiz iste'molingizdan oshib ketganiga ishonch hosil qiling;
- Kubernetlar ularni bo'sh tugunlarga tayinlashi uchun apparat yuki yuqori bo'lgan taqdirda yangi podlarni yaratish uchun podkastlarni avtomatik o'lchash xavfsiz variant bo'ladi.
Umid qilamanki, bu post konteyner tizimlarining ish faoliyatini yaxshilashga yordam beradi.
PS muallif o'quvchilar va sharhlovchilar bilan yozishmalarni olib boradi (ingliz tilida).
Manba: www.habr.com