Men Kube Eagle - Prometey eksportchisini yaratdim. Bu kichik va o'rta klasterlarning resurslarini yaxshiroq tushunishga yordam beradigan ajoyib narsa bo'lib chiqdi. Oxir-oqibat, men yuzlab dollarlarni tejadim, chunki men to'g'ri mashina turlarini tanladim va ish yuklari uchun dastur resurslari chegaralarini sozladim.
Men sizga foydalari haqida aytib beraman , lekin birinchi navbatda men shov-shuvga nima sabab bo'lganini va nima uchun yuqori sifatli monitoring zarurligini tushuntiraman.
Men 4-50 tugunli bir nechta klasterlarni boshqardim. Har bir klasterda 200 tagacha mikroservis va ilovalar mavjud. Mavjud uskunadan yaxshiroq foydalanish uchun ko'pchilik o'rnatishlar portlash mumkin bo'lgan operativ xotira va protsessor resurslari bilan tuzilgan. Shunday qilib, podlar kerak bo'lganda mavjud resurslarni olishi mumkin va shu bilan birga ushbu tugundagi boshqa ilovalarga xalaqit bermaydi. Xo'sh, bu ajoyib emasmi?
Garchi klaster nisbatan kam protsessor (8%) va RAM (40%) iste'mol qilgan bo'lsa-da, biz tugundagidan ko'proq xotirani ajratishga harakat qilganda, biz doimiy ravishda pod'larning oldini olish bilan bog'liq muammolarga duch keldik. O'sha paytda bizda Kubernetes resurslarini kuzatish uchun faqat bitta boshqaruv paneli bor edi. Shunga o'xshash:
Faqat cAdvisor ko'rsatkichlari bilan Grafana asboblar paneli
Bunday panelda ko'p xotira va protsessorni iste'mol qiladigan tugunlarni ko'rish muammo emas. Muammo nima sababdan ekanligini aniqlashdir. Podkalarni joyida ushlab turish uchun, albatta, barcha podkalarda kafolatlangan resurslarni o'rnatish mumkin (so'ralgan resurslar chegaraga teng). Lekin bu apparatdan eng oqilona foydalanish emas. Klaster bir necha yuz gigabayt xotiraga ega bo'lib, ba'zi tugunlar och qolgan, boshqalari esa zaxirada 4-10 GB qolgan.
Ma'lum bo'lishicha, Kubernetes rejalashtiruvchisi ish yuklarini mavjud resurslar bo'yicha notekis taqsimlagan. Kubernetes rejalashtiruvchisi turli xil konfiguratsiyalarni hisobga oladi: yaqinlik, nosozliklar va bardoshlik qoidalari, mavjud tugunlarni cheklashi mumkin bo'lgan tugun selektorlari. Lekin mening holimda bunday narsa yo'q edi va podalar har bir tugundagi so'ralgan resurslarga qarab rejalashtirilgan edi.
Eng ko'p bepul resurslarga ega bo'lgan va so'rov shartlarini qondiradigan tugun pod uchun tanlangan. Biz tugunlarda so'ralgan resurslar haqiqiy foydalanishga mos kelmasligini aniqladik va bu erda Kube Eagle va uning resurslarni monitoring qilish imkoniyatlari yordamga keldi.
Menda deyarli barcha Kubernetes klasterlari faqat nazorat ostida и . Node Exporter kiritish-chiqarish va disk, protsessor va operativ xotiradan foydalanish statistikasini taqdim etadi, Kube State Metrics esa Kubernetes ob'ekt ko'rsatkichlarini, masalan, so'rovlar, CPU va xotira resurslari chegaralarini ko'rsatadi.
Biz foydalanish ko'rsatkichlarini Grafana'dagi so'rovlar va cheklovlar ko'rsatkichlari bilan birlashtirishimiz kerak, keyin biz muammo haqida barcha ma'lumotlarni olamiz. Bu oddiy tuyuladi, lekin ikkita vosita aslida yorliqlarni boshqacha nomlaydi va ba'zi ko'rsatkichlarda metadata yorliqlari umuman yo'q. Kube Eagle hamma narsani o'zi bajaradi va panel quyidagicha ko'rinadi:
Biz resurslar bilan bog'liq ko'plab muammolarni hal qilishga va uskunalarni tejashga muvaffaq bo'ldik:
- Ba'zi ishlab chiquvchilar mikroservislar uchun qancha resurs kerakligini bilishmagan (yoki shunchaki bezovta qilishmagan). Resurslar uchun noto'g'ri so'rovlarni topishning hech qanday usuli yo'q edi - buning uchun biz iste'mol va so'rovlar va cheklovlarni bilishimiz kerak. Endi ular Prometey ko'rsatkichlarini ko'radilar, haqiqiy foydalanishni kuzatadilar va so'rovlar va cheklovlarni o'zgartiradilar.
- JVM ilovalari imkon qadar ko'proq RAM oladi. Axlat yig'uvchi faqat 75% dan ortiq foydalanilganda xotirani chiqaradi. Aksariyat xizmatlar portlash mumkin bo'lgan xotiraga ega bo'lganligi sababli, u doimo JVM tomonidan ishg'ol qilingan. Shu sababli, ushbu Java xizmatlarining barchasi kutilganidan ko'ra ko'proq RAM iste'mol qildi.
- Ba'zi ilovalar juda ko'p xotira talab qildi va Kubernetes rejalashtiruvchisi bu tugunlarni boshqa ilovalarga bermadi, garchi ular boshqa tugunlarga qaraganda erkinroq bo'lsa ham. Bitta ishlab chiquvchi tasodifan so‘rovga qo‘shimcha raqam qo‘shib qo‘ydi va operativ xotiraning katta qismini oldi: 20 o‘rniga 2 GB. Hech kim buni sezmadi. Ilova 3 ta nusxaga ega edi, shuning uchun 3 ta tugun ta'sir qildi.
- Biz resurs cheklovlarini joriy qildik, to'g'ri so'rovlar bilan podkastlarni qayta rejalashtirdik va barcha tugunlarda apparatdan foydalanishning ideal balansiga ega bo'ldik. Bir nechta tugunlar butunlay yopilishi mumkin edi. Va keyin bizda noto'g'ri mashinalar mavjudligini ko'rdik (xotiraga emas, balki CPUga yo'naltirilgan). Biz turini o'zgartirdik va yana bir nechta tugunlarni o'chirib tashladik.
natijalar
Klasterdagi portlash mumkin bo'lgan resurslar bilan siz mavjud uskunadan samaraliroq foydalanasiz, ammo Kubernetes rejalashtiruvchisi manbalarga bo'lgan so'rovlar asosida podlarni rejalashtiradi va bu juda qiyin. Ikki qushni bitta tosh bilan o'ldirish uchun: muammolarni oldini olish va resurslardan to'liq foydalanish uchun sizga yaxshi monitoring kerak. Shuning uchun u foydali bo'ladi (Prometey eksportchisi va Grafana asboblar paneli).
Manba: www.habr.com