Istio o'chirgich: noto'g'ri konteynerlarni o'chirish

Bayramlar tugadi va biz Istio Service Mesh turkumidagi ikkinchi postimiz bilan qaytdik.

Bugungi mavzu - "O'chirish to'xtatuvchisi" bo'lib, u rus elektrotexnika tiliga tarjima qilinganda "o'chirish to'xtatuvchisi" degan ma'noni anglatadi, umumiy tilda - "o'chirgich". Faqat Istioda bu mashina qisqa tutilgan yoki haddan tashqari yuklangan kontaktlarning zanglashiga olib emas, balki noto'g'ri konteynerlarni o'chiradi.

Bu qanday qilib ideal ishlashi kerak

Mikroservislar Kubernetes tomonidan boshqarilsa, masalan, OpenShift platformasida ular yukga qarab avtomatik ravishda kattalashadi va kamayadi. Mikroservislar podlarda ishlayotganligi sababli, bitta so'nggi nuqtada konteynerlashtirilgan mikroservisning bir nechta nusxalari bo'lishi mumkin va Kubernetes so'rovlarni yo'naltiradi va ular o'rtasida yuk balansini o'rnatadi. Va - ideal holda - bularning barchasi mukammal ishlashi kerak.

Mikroservislar kichik va vaqtinchalik ekanligini eslaymiz. Efemerlik, ya'ni bu erda paydo bo'lish va yo'q bo'lish qulayligi ko'pincha kam baholanadi. Podda mikroservisning boshqa nusxasining tug'ilishi va o'limi juda kutilgan narsadir, OpenShift va Kubernetes buni yaxshi hal qiladi va hamma narsa ajoyib ishlaydi - lekin yana nazariy jihatdan.

Bu aslida qanday ishlaydi

Endi tasavvur qiling-a, mikroservisning ma'lum bir nusxasi, ya'ni konteyner yaroqsiz bo'lib qoldi: yoki u javob bermaydi (xato 503), yoki eng yoqimsiz, u javob beradi, lekin juda sekin. Boshqacha qilib aytadigan bo'lsak, u glitchy bo'ladi yoki so'rovlarga javob bermaydi, lekin u avtomatik ravishda hovuzdan olib tashlanmaydi. Bu holatda nima qilish kerak? Qayta urinish uchunmi? Uni marshrutlash sxemasidan olib tashlashim kerakmi? Va "juda sekin" nimani anglatadi - raqamlarda qancha va ularni kim aniqlaydi? Balki biroz tanaffus qilib, keyinroq qayta urinib ko'ring? Agar shunday bo'lsa, qanchadan keyin?

Istiodagi hovuzni chiqarish nima

Va bu erda Istio o'zining O'chirish to'xtatuvchisi himoya mashinalari bilan yordamga keladi, ular noto'g'ri konteynerlarni marshrutlash va yukni muvozanatlash resurs hovuzidan vaqtincha olib tashlaydi, Hovuzni chiqarish protsedurasini amalga oshiradi.

Chiqib ketishni aniqlash strategiyasidan foydalangan holda, Istio chiziqdan tashqarida bo'lgan egri chiziqni aniqlaydi va ularni uyqu oynasi deb ataladigan ma'lum vaqt davomida manbalar hovuzidan olib tashlaydi.

Bu OpenShift platformasida Kubernetes-da qanday ishlashini ko'rsatish uchun, keling, ombordagi misoldan oddiy ishlaydigan mikroservislarning skrinshotidan boshlaylik. Red Hat dasturchi demolari. Bu yerda bizda ikkita pods bor, v1 va v2, ularning har biri bitta konteynerda ishlaydi. Istio marshrutlash qoidalari ishlatilmaganda, Kubernetes sukut bo'yicha teng muvozanatli aylanma marshrutlashni o'rnatadi:

Halokatga tayyorlanmoqda

Pool Ejection ni amalga oshirishdan oldin siz Istio marshrutlash qoidasini yaratishingiz kerak. Aytaylik, biz so'rovlarni podalar o'rtasida 50/50 nisbatda taqsimlamoqchimiz. Bundan tashqari, biz v2 konteynerlar sonini bittadan ikkitaga ko'paytiramiz, masalan:

oc scale deployment recommendation-v2 --replicas=2 -n tutorial

Endi biz marshrutlash qoidasini o'rnatdik, shunda trafik podalar o'rtasida 50/50 nisbatda taqsimlanadi.

Ushbu qoidaning natijasi quyidagicha ko'rinadi:

Bu ekranning 50/50 emas, balki 14:9 bo'lishi bilan ayb topishingiz mumkin, ammo vaqt o'tishi bilan vaziyat yaxshilanadi.

Xato qilish

Keling, ikkita v2 konteynerdan birini o'chirib qo'yamiz, shunda bizda bitta sog'lom v1 konteyner, bitta sog'lom v2 konteyner va bitta nosoz v2 konteyner bo'ladi:

Xatoni tuzatish

Shunday qilib, bizda noto'g'ri idish bor va Hovuzni chiqarish vaqti keldi. Juda oddiy konfiguratsiyadan foydalanib, biz ushbu muvaffaqiyatsiz konteynerni har qanday marshrutlash sxemasidan 15 soniya davomida chiqarib tashlaymiz, u sog'lom holatga qaytadi (qayta ishga tushiring yoki ish faoliyatini tiklang). Bu konfiguratsiya qanday ko'rinishga ega va uning ish natijalari:

Ko'rib turganingizdek, muvaffaqiyatsiz v2 konteyneri endi marshrutlash so'rovlari uchun ishlatilmaydi, chunki u hovuzdan olib tashlangan. Ammo 15 soniyadan keyin u avtomatik ravishda hovuzga qaytadi. Aslida, biz hozirgina Pool Ejection qanday ishlashini ko'rsatdik.

Arxitektura qurishni boshlaylik

Pool Ejection Istio’ning monitoring imkoniyatlari bilan birgalikda ishlamay qolish vaqtlari va nosozliklarni bartaraf qilmasa, kamaytirish uchun noto‘g‘ri konteynerlarni avtomatik ravishda almashtirish uchun asos yaratishni boshlash imkonini beradi.
 
NASAning bitta baland shiori bor - Muvaffaqiyatsizlik - bu variant emas, uning muallifi parvoz direktori hisoblanadi. Gen Kranz. Buni rus tiliga "Muvaffaqiyatsizlik - bu variant emas" deb tarjima qilish mumkin va bu erda ma'no shundaki, agar sizda etarli iroda bo'lsa, hamma narsani amalga oshirish mumkin. Biroq, haqiqiy hayotda muvaffaqiyatsizliklar o'z-o'zidan sodir bo'lmaydi, ular muqarrar, hamma joyda va hamma narsada. Mikroservislar holatida ular bilan qanday kurashish mumkin? Bizning fikrimizcha, iroda kuchiga emas, balki konteynerlarning imkoniyatlariga tayangan ma'qul. Kubernetes, RedHat OpenShiftva Istio.

Istio, yuqorida yozganimizdek, jismoniy dunyoda o'zini yaxshi isbotlagan elektron to'xtatuvchilari kontseptsiyasini amalga oshiradi. Elektr to'xtatuvchisi kontaktlarning zanglashiga olib keladigan qismini o'chirib qo'ygani kabi, Istio dasturiy ta'minoti O'chirish to'xtatuvchisi so'rovlar oqimi va muammoli konteyner o'rtasidagi aloqani oxirgi nuqtada biror narsa noto'g'ri bo'lganda, masalan, server ishdan chiqqanida yoki ishlay boshlaganda ochadi. sekinlashish.

Bundan tashqari, ikkinchi holatda faqat ko'proq muammolar mavjud, chunki bitta konteynerning tormozlari nafaqat unga kirish xizmatlarida kechikishlar kaskadiga olib keladi va buning natijasida butun tizimning ish faoliyatini pasaytiradi, balki takroriy yuklarni ham keltirib chiqaradi. allaqachon sekin ishlaydigan xizmatga so'rovlar, bu vaziyatni yanada og'irlashtiradi.

Nazariy jihatdan o'chirgich

Circuit Breaker so'nggi nuqtaga so'rovlar oqimini boshqaradigan proksi-serverdir. Ushbu nuqta ishlashni to'xtatganda yoki belgilangan sozlamalarga qarab, sekinlasha boshlasa, proksi-server konteyner bilan aloqani uzadi. Keyinchalik yukni muvozanatlash tufayli trafik boshqa konteynerlarga yo'naltiriladi. Ulanish ma'lum bir uyqu oynasi uchun ochiq qoladi, aytaylik, ikki daqiqa, keyin esa yarim ochiq hisoblanadi. Keyingi so'rovni yuborishga urinish ulanishning keyingi holatini aniqlaydi. Agar xizmatda hamma narsa yaxshi bo'lsa, ulanish ish holatiga qaytadi va yana yopiladi. Agar xizmatda hali ham biror narsa noto'g'ri bo'lsa, ulanish uziladi va uyqu oynasi qayta yoqiladi. O'chirgichning soddalashtirilgan holati diagrammasi quyidagicha ko'rinadi:

Bu erda shuni ta'kidlash kerakki, bularning barchasi tizim arxitekturasi darajasida sodir bo'ladi. Shuning uchun, bir nuqtada siz ilovalaringizga Circuit Breaker bilan ishlashni o'rgatishingiz kerak bo'ladi, masalan, javob sifatida standart qiymatni taqdim etish yoki iloji bo'lsa, xizmat mavjudligiga e'tibor bermaslik. Buning uchun katta hajmli naqsh ishlatiladi, ammo bu maqola doirasidan tashqarida.

Amalda o'chirgich

Masalan, biz OpenShift-da tavsiya etilgan mikroxizmatimizning ikkita versiyasini ishga tushiramiz. 1-versiya yaxshi ishlaydi, lekin v2 da biz serverdagi sekinlashuvlarni taqlid qilish uchun kechikish bilan quramiz. Natijalarni ko'rish uchun asbobdan foydalaning qamal qilish:

siege -r 2 -c 20 -v customer-tutorial.$(minishift ip).nip.io

Hammasi ishlayotganga o'xshaydi, lekin nima evaziga? Bir qarashda bizda 100% mavjudlik bor, lekin diqqat bilan ko'rib chiqing - tranzaksiyaning maksimal davomiyligi 12 soniyagacha. Bu aniq darboğaz va uni kengaytirish kerak.

Buning uchun biz sekin konteynerlarga qo'ng'iroqlarni yo'q qilish uchun Istio-dan foydalanamiz. O'chirish to'xtatuvchisi yordamida mos keladigan konfiguratsiya shunday ko'rinadi:

HttpMaxRequestsPerConnection parametri bilan oxirgi qator mavjud bo'lganidan tashqari boshqa - ikkinchi - ulanishni yaratishga urinayotganda ulanishni uzish kerakligini bildiradi. Bizning konteynerimiz sekin xizmatni taqlid qilganligi sababli, bunday holatlar vaqti-vaqti bilan yuzaga keladi va keyin Istio 503 xatosini qaytaradi, ammo qamal shuni ko'rsatadi:

OK, bizda o'chirgich bor, keyin nima bo'ladi?

Shunday qilib, biz xizmatlarning manba kodiga umuman tegmasdan avtomatik o'chirishni amalga oshirdik. Yuqorida tavsiflangan O'chirish to'xtatuvchisi va Hovuzni chiqarish protsedurasidan foydalanib, biz tormoz konteynerlarini ular normal holatga qaytgunga qadar manba hovuzidan olib tashlashimiz va ularning holatini belgilangan chastotada tekshirishimiz mumkin - bizning misolimizda bu ikki daqiqa (sleepWindow parametri).

Ilovaning 503 xatosiga javob berish qobiliyati hali ham manba kodi darajasida o'rnatilganligini unutmang. Vaziyatga qarab Circuit Breaker-dan foydalanishning ko'plab strategiyalari mavjud.

Keyingi postda: Biz Istio-ga allaqachon o'rnatilgan yoki osongina qo'shilgan kuzatish va monitoring, shuningdek, tizimga xatolarni qasddan qanday kiritish haqida gaplashamiz.

Manba: www.habr.com