Qanday qilib Kubernetesdagi pod ustuvorliklari Grafana Laboratoriyalarida ishlamay qolishga olib keldi

Eslatma. tarjima.: Biz sizning e'tiboringizga Grafana yaratuvchilari tomonidan qo'llab-quvvatlanadigan bulut xizmatida so'nggi vaqtlarda to'xtab qolish sabablari haqida texnik ma'lumotlarni taqdim etamiz. Bu infratuzilma sifatini yaxshilash uchun mo'ljallangan yangi va juda foydali ko'rinadigan funksiya... ishlab chiqarish voqeliklarida uni qo'llashning ko'plab nuanslarini ta'minlamasangiz, qanday zarar etkazishi mumkinligiga klassik misoldir. Bu kabi materiallar paydo bo'lganda juda yaxshi, bu sizga nafaqat xatolaringizdan o'rganish imkonini beradi. Tafsilotlar ushbu matnning Grafana Labs mahsulot bo'yicha vitse-prezidentining tarjimasida keltirilgan.

Qanday qilib Kubernetesdagi pod ustuvorliklari Grafana Laboratoriyalarida ishlamay qolishga olib keldi

19-iyul, juma kuni Grafana Cloud-dagi Hosted Prometey xizmati taxminan 30 daqiqa davomida ishlamay qoldi. Men uzilishdan zarar ko'rgan barcha mijozlardan uzr so'rayman. Bizning vazifamiz sizga kerak bo'lgan monitoring vositalarini taqdim etishdir va biz ularning mavjud bo'lmasligi hayotingizni qiyinlashtirishi mumkinligini tushunamiz. Biz bu voqeani juda jiddiy qabul qilamiz. Bu eslatmada nima sodir bo‘lganligi, qanday javob berganimiz va bu takrorlanmasligi uchun nima qilayotganimiz tushuntiriladi.

Sana oldin

Grafana Cloud Hosted Prometey xizmatiga asoslangan Cortex — CNCF loyihasi gorizontal ravishda kengaytiriladigan, yuqori darajada mavjud, ko'p ijarachili Prometey xizmatini yaratish. Korteks arxitekturasi individual mikroservislar to'plamidan iborat bo'lib, ularning har biri o'z funktsiyasini bajaradi: replikatsiya, saqlash, so'rovlar va boshqalar. Korteks faol rivojlanmoqda va doimiy ravishda yangi xususiyatlarni qo'shib, ish faoliyatini yaxshilaydi. Biz muntazam ravishda yangi Cortex relizlarini klasterlarga joylashtiramiz, shunda mijozlar ushbu xususiyatlardan foydalanishlari mumkin - xayriyatki, Cortex uzilishlarsiz yangilanishi mumkin.

Uzluksiz yangilanishlar uchun Ingester Cortex xizmati yangilash jarayonida qo'shimcha Ingester replikasini talab qiladi. (Eslatma. tarjima.: Ingester - korteksning asosiy komponenti. Uning vazifasi doimiy namunalar oqimini to'plash, ularni Prometey bo'laklariga guruhlash va DynamoDB, BigTable yoki Cassandra kabi ma'lumotlar bazasida saqlashdir.) Bu eski Ingesterlarga joriy ma'lumotlarni yangi Ingesterlarga yuborish imkonini beradi. Shuni ta'kidlash kerakki, Ingesterlar resurslarga talabchan. Ularning ishlashi uchun sizda 4 yadro va har bir podda 15 GB xotira bo'lishi kerak, ya'ni. Kubernetes klasterlarimizda asosiy mashinaning qayta ishlash quvvati va xotirasining 25%. Umuman olganda, biz odatda klasterda 4 yadro va 15 Gb xotiradan ko'ra ko'proq foydalanilmayotgan resurslarga egamiz, shuning uchun biz yangilanishlar paytida ushbu qo'shimcha qabul qiluvchilarni osongina aylantira olamiz.

Biroq, tez-tez shunday bo'ladiki, normal ish paytida hech bir mashinada foydalanilmagan resurslarning 25 foizi yo'q. Ha, biz hatto harakat qilmaymiz: protsessor va xotira har doim boshqa jarayonlar uchun foydali bo'ladi. Ushbu muammoni hal qilish uchun biz foydalanishga qaror qildik Kubernetes Pod ustuvorliklari. Bu g‘oya Ingesterlarga boshqa (fuqaroligi bo‘lmagan) mikroservislarga qaraganda yuqoriroq ustuvorlik berishdir. Qo'shimcha (N+1) Ingesterni ishga tushirishimiz kerak bo'lganda, biz boshqa kichikroq podlarni vaqtincha almashtiramiz. Bu podlar boshqa mashinalardagi bepul resurslarga o'tkaziladi va qo'shimcha Ingesterni ishga tushirish uchun etarlicha katta "teshik" qoldiradi.

18-iyul, payshanba kuni biz klasterlarimizga to‘rtta yangi ustuvor darajani taqdim etdik: tanqidiy, balandligi, o'rta и past. Ular bir hafta davomida mijoz trafigiga ega bo'lmagan ichki klasterda sinovdan o'tkazildi. Odatiy bo'lib, belgilangan ustuvorligi bo'lmagan podalar qabul qilinadi o'rta ustuvor, sinf bilan Ingesters uchun belgilangan yuqori ustuvorlik. Tanqidiy monitoring uchun ajratilgan edi (Prometey, Alertmanager, tugun-eksportchi, kube-state-metrikalar va boshqalar). Bizning konfiguratsiyamiz ochiq va siz PRni ko'rishingiz mumkin shu yerda.

Baxtsiz hodisa

19-iyul, juma kuni muhandislardan biri yirik mijoz uchun yangi maxsus Cortex klasterini ishga tushirdi. Ushbu klaster konfiguratsiyasi yangi pod ustuvorliklarini o'z ichiga olmagan, shuning uchun barcha yangi podkastlarga birlamchi ustuvorlik berilgan - o'rta.

Kubernetes klasterida yangi Cortex klasteri uchun yetarli resurslar yo'q edi va mavjud ishlab chiqarish Cortex klasteri yangilanmadi (Ingesterlarsiz qoldi. baland ustuvorlik). Chunki yangi klasterning Ingesterlari sukut bo'yicha mavjud edi o'rta ustuvor va ishlab chiqarishdagi mavjud podalar umuman ustunliksiz ishladi, yangi klasterning Ingesterlari mavjud Cortex ishlab chiqarish klasteridagi Ingesterlarni almashtirdi.

Ishlab chiqarish klasteridagi quvilgan Ingester uchun ReplicaSet chiqarib tashlangan podani aniqladi va belgilangan nusxalar sonini saqlab qolish uchun yangisini yaratdi. Yangi pod sukut bo'yicha tayinlangan o'rta ustuvorlik va ishlab chiqarishdagi yana bir "eski" Ingester o'z resurslarini yo'qotdi. Natija bo'ldi ko'chki jarayoni, bu esa Cortex ishlab chiqarish klasterlari uchun Ingester'dan barcha podslarning siljishiga olib keldi.

Ingesterlar statistik ma'lumotlarga ega va ma'lumotlarni oldingi 12 soat davomida saqlaydi. Bu bizga ularni uzoq muddatli saqlashga yozishdan oldin ularni yanada samaraliroq siqish imkonini beradi. Bunga erishish uchun Cortex tarqatilgan xesh jadvali (DHT) yordamida ma'lumotlarni seriyalar bo'ylab parchalaydi va har bir seriyani Dynamo uslubidagi kvorum mustahkamligidan foydalangan holda uchta Ingesterda takrorlaydi. Cortex o'chirilgan Ingesterlarga ma'lumotlarni yozmaydi. Shunday qilib, ko'p sonli Ingesterlar DHTni tark etganda, Cortex yozuvlarning etarli darajada takrorlanishini ta'minlay olmaydi va ular qulab tushadi.

Aniqlash va tuzatish

"Xato byudjeti" asosidagi yangi Prometey bildirishnomalari (xatolarga asoslangan byudjet — tafsilotlar keyingi maqolada paydo bo'ladi) o'chirish boshlanganidan 4 daqiqa o'tgach, signal chala boshladi. Keyingi besh daqiqa ichida biz diagnostika ishlarini olib bordik va yangi va mavjud ishlab chiqarish klasterlarini joylashtirish uchun asosiy Kubernetes klasterini kengaytirdik.

Yana besh daqiqadan so'ng, eski Ingesterlar o'z ma'lumotlarini muvaffaqiyatli yozdilar, yangilari ishga tushdi va Cortex klasterlari yana mavjud bo'ldi.

Yana 10 daqiqa Cortex oldida joylashgan autentifikatsiya teskari proksi-serverlarining xotiradan qolgan (OOM) xatolarini tashxislash va tuzatishga sarflandi. OOM xatolariga QPS ning oʻn baravar oshishi sabab boʻlgan (biz oʻylaymizki, mijozning Prometey serverlarining haddan tashqari tajovuzkor soʻrovlari tufayli).

Natijalar

Umumiy uzilish vaqti 26 daqiqani tashkil etdi. Hech qanday maʼlumot yoʻqolmadi. Ingesterlar barcha xotiradagi ma'lumotlarni uzoq muddatli saqlashga muvaffaqiyatli yukladilar. O'chirish vaqtida buferlangan mijoz Prometey serverlari o'chirildi (masofadan) yozuvlar yordamida yangi API remote_write WAL asosida (muallifi Kallum Styan Grafana Labs dan) va halokatdan keyin muvaffaqiyatsiz yozuvlarni takrorladi.

Qanday qilib Kubernetesdagi pod ustuvorliklari Grafana Laboratoriyalarida ishlamay qolishga olib keldi
Ishlab chiqarish klasterini yozish operatsiyalari

topilmalar

Ushbu hodisadan saboq olish va uning takrorlanmasligi uchun zarur choralarni ko'rish muhimdir.

Orqaga nazar tashlasak, biz sukut bo'yicha o'rnatmasligimiz kerak edi o'rta ishlab chiqarishdagi barcha Ingesterlar qabul qilinmaguncha ustuvorlik balandligi ustuvorlik. Bundan tashqari, ularga oldindan g'amxo'rlik qilish kerak edi yuqori ustuvorlik. Hozir hammasi tuzatildi. Umid qilamizki, bizning tajribamiz boshqa tashkilotlarga Kubernetesdagi pod ustuvorliklaridan foydalanishda yordam beradi.

Biz konfiguratsiyasi klaster uchun global bo'lgan har qanday qo'shimcha ob'ektlarni joylashtirish ustidan nazoratning qo'shimcha darajasini qo'shamiz. Bundan buyon bunday o'zgarishlar baholanadi bоko'proq odamlar. Bundan tashqari, halokatga sabab bo'lgan modifikatsiya alohida loyiha hujjati uchun juda ahamiyatsiz deb hisoblangan - bu faqat GitHub sonida muhokama qilingan. Bundan buyon konfiguratsiyalardagi barcha bunday o'zgarishlar tegishli loyiha hujjatlari bilan birga bo'ladi.

Va nihoyat, biz guvohi bo'lgan OOM haddan tashqari yuklanishining oldini olish uchun autentifikatsiya teskari proksi-serverining hajmini o'zgartirishni avtomatlashtiramiz va kelajakda shunga o'xshash muammolarni oldini olish uchun qayta tiklash va masshtablash bilan bog'liq Prometheus standart sozlamalarini ko'rib chiqamiz.

Muvaffaqiyatsizlik ba'zi ijobiy oqibatlarga olib keldi: zarur resurslarni olgandan so'ng, Cortex qo'shimcha aralashuvsiz avtomatik ravishda tiklandi. U bilan ishlashda ham qimmatli tajriba orttirdik Grafana Loki - bizning yangi jurnallarni yig'ish tizimi - bu barcha Ingesterlarning nosozlik paytida va undan keyin o'zini to'g'ri tutishini ta'minlashga yordam berdi.

Tarjimondan PS

Shuningdek, bizning blogimizda o'qing:

Manba: www.habr.com

a Izoh qo'shish