🥇Kubernetesdagi jonli zondlar xavfli bo'lishi mumkin

Eslatma. tarjima.: Zalandolik yetakchi muhandis Xenning Jeykobs Kubernetes foydalanuvchilari orasida zondlarning tirikligi (va tayyorligi) maqsadini va ulardan to‘g‘ri foydalanishni tushunishda bir necha bor muammolarni payqagan. Shuning uchun u o'z fikrlarini K8s hujjatlarining bir qismiga aylanadigan ushbu keng qamrovli eslatmada to'pladi.

Sog'liqni saqlash tekshiruvlari, Kubernetesda ma'lum tiriklik problari (ya'ni, so'zma-so'z "hayotiylik testlari" - taxminan tarjimasi), juda xavfli bo'lishi mumkin. Iloji bo'lsa, ulardan qochishni tavsiya qilaman: istisnolar, ular haqiqatan ham zarur bo'lganda va ulardan foydalanishning o'ziga xos xususiyatlari va oqibatlaridan to'liq xabardor bo'lsangiz. Ushbu nashr jonlilik va tayyorlikni tekshirish haqida gapiradi, shuningdek, qanday hollarda sizga aytib beradi qiymatga ega va siz ulardan foydalanmasligingiz kerak.

Mening hamkasbim Sandor yaqinda Twitter-da o'zi duch keladigan eng ko'p uchraydigan xatolar, jumladan, tayyorlik/jonlilik tekshiruvlaridan foydalanish bilan bog'liq xatolar bilan o'rtoqlashdi:

Noto'g'ri sozlangan livenessProbe yuqori yuklanish holatlarini og'irlashtirishi mumkin (qor to'pi yopilishi + potentsial uzoq konteyner/ilovani ishga tushirish vaqti) va qaramlikning pasayishi kabi boshqa salbiy oqibatlarga olib kelishi mumkin. (Shuningdek qarang mening so'nggi maqolam K3s + ACME kombinatsiyasida so'rovlar sonini cheklash haqida). Jonlilik tekshiruvi tashqi ma'lumotlar bazasi bo'lgan sog'liqni tekshirish bilan birlashtirilganda bundan ham yomoni: bitta JB xatosi barcha konteynerlaringizni qayta ishga tushiradi!

Umumiy xabar "Jonli zondlardan foydalanmang" bu holatda u ko'p yordam bermaydi, shuning uchun tayyorlik va jonlilik tekshiruvlari nima uchun ekanligini ko'rib chiqaylik.

Eslatma: Quyidagi testlarning aksariyati dastlab Zalandoning ichki ishlab chiquvchi hujjatlariga kiritilgan.

Tayyorlik va jonlilikni tekshirish

Kubernetes deb nomlangan ikkita muhim mexanizmni taqdim etadi tiriklik zondlari va tayyorlik zondlari. Ular vaqti-vaqti bilan dastur kutilganidek ishlayotganligini tasdiqlash uchun HTTP so'rovini yuborish, TCP ulanishini ochish yoki konteynerda buyruqni bajarish kabi ba'zi amallarni bajaradilar.

Kubernetes foydalanadi tayyorlik problarikonteyner trafikni qabul qilishga tayyorligini tushunish uchun. Agar pod barcha idishlari tayyor bo'lsa, foydalanishga tayyor hisoblanadi. Ushbu mexanizmdan foydalanishdan biri Kubernetes xizmatlari (va ayniqsa Ingress) uchun qaysi podlar orqa tomon sifatida ishlatilishini nazorat qilishdir.

Jonli zondlar Kubernetesga konteynerni qayta ishga tushirish vaqti kelganini tushunishga yordam bering. Masalan, bunday tekshirish ilova bir joyda tiqilib qolganda blokirovkani bartaraf etishga imkon beradi. Konteynerni bu holatda qayta ishga tushirish xatolarga qaramay, dasturni ishga tushirishga yordam beradi, lekin u ham kaskadli nosozliklarga olib kelishi mumkin (pastga qarang).

Agar dasturning faolligi/tayyorligi tekshirilmaganda yangilanishni o‘rnatmoqchi bo‘lsangiz, Kubernetes holatni kutayotganda uning chiqarilishi to‘xtatiladi. Ready barcha podlardan.

misol

Bu erda yo'lni tekshirishga tayyorlik tekshiruvining misoli keltirilgan /health standart sozlamalar bilan HTTP orqali (interval: 10 soniya, vaqt tugadi: 1 soniya, muvaffaqiyat chegarasi: 1, muvaffaqiyatsizlik chegarasi: 3):

# часть общего описания deployment'а/стека
podTemplate:
  spec:
    containers:
    - name: my-container
      # ...
      readinessProbe:
        httpGet:
          path: /health
          port: 8080

tavsiyalar

HTTP so'nggi nuqtasiga ega mikroservislar uchun (REST va boshqalar) har doim tayyorlik tekshiruvini aniqlang, bu ilova (pod) trafikni qabul qilishga tayyorligini tekshiradi.
Tayyorlik tekshiruviga ishonch hosil qiling haqiqiy veb-server portining mavjudligini qamrab oladi:
- "admin" yoki "boshqaruv" deb nomlangan portlardan ma'muriy maqsadlarda foydalanish (masalan, 9090) uchun readinessProbe, agar asosiy HTTP porti (masalan, 8080) trafikni qabul qilishga tayyor bo'lsa, oxirgi nuqta OK ni qaytarishiga ishonch hosil qiling*;
  * Men Zalandoda bu sodir bo'lmagan kamida bitta holatdan xabardorman, ya'ni. readinessProbe Men "boshqaruv" portini tekshirdim, lekin keshni yuklashda muammolar tufayli serverning o'zi ishlamadi.
- tayyorlik zondini alohida portga ulash, asosiy portdagi ortiqcha yuk sog'liq tekshiruvida aks ettirilmasligiga olib kelishi mumkin (ya'ni, serverdagi iplar hovuzi to'lgan, ammo sog'liqni tekshirish hali hammasi joyida ekanligini ko'rsatadi. ).
Bunga ishonch hosil qiling tayyorlik tekshiruvi ma'lumotlar bazasini ishga tushirish/ko'chirish imkonini beradi;
- Bunga erishishning eng oson yo'li HTTP serveriga ishga tushirish tugallangandan keyingina bog'lanish (masalan, ma'lumotlar bazasini ko'chirish). Flyway va h.k.); ya'ni sog'liqni tekshirish holatini o'zgartirish o'rniga, ma'lumotlar bazasini ko'chirish tugamaguncha veb-serverni ishga tushirmang*.
  * Shuningdek, siz poddan tashqaridagi init konteynerlaridan maʼlumotlar bazasi migratsiyasini ham ishga tushirishingiz mumkin. Men hali ham mustaqil dasturlarning muxlisiman, ya'ni ilovalar konteyneri ma'lumotlar bazasini tashqi muvofiqlashtirishsiz kerakli holatga qanday keltirishni biladi.
Foydalanish httpGet odatdagi sog'liqni tekshirish punktlari orqali tayyorlikni tekshirish uchun (masalan, /health).
Standart tekshirish parametrlarini tushuning (interval: 10s, timeout: 1s, successThreshold: 1, failureThreshold: 3):
- standart variantlar podkastga aylanishini bildiradi tayyormas taxminan 30 soniyadan so'ng (3 ta muvaffaqiyatsiz aql tekshiruvi).
Texnologik stek (masalan, Java/Spring) ruxsat bersa, salomatlik va ko‘rsatkichlarni boshqarishni oddiy trafikdan ajratish uchun “admin” yoki “boshqaruv” uchun alohida portdan foydalaning:
- lekin 2-band haqida unutmang.
Agar kerak bo'lsa, tayyorlik zondi keshni isitish/yuklash va konteyner qizib ketguncha 503 holat kodini qaytarish uchun ishlatilishi mumkin:
- Shuningdek, men sizga yangi chekni o'qishni tavsiya qilaman startupProbe, 1.16 versiyasida paydo bo'ldi (Biz bu haqda rus tilida yozgan edik shu yerda - taxminan. tarjima.).

Ogohlantirishlar

Tashqi qaramlikka tayanmang (masalan, ma'lumotlar omborlari) tayyorlik/jonlilik testlarini o'tkazishda - bu kaskadli nosozliklarga olib kelishi mumkin:
- Misol tariqasida, bitta Postgres ma'lumotlar bazasiga qarab 10 ta podkastli REST xizmatini olaylik: tekshirish JB bilan ishlaydigan ulanishga bog'liq bo'lsa, tarmoq/JB tomonida kechikish bo'lsa, barcha 10 pods muvaffaqiyatsiz bo'lishi mumkin - odatda bu hammasi mumkin bo'lgandan ham yomonroq tugaydi;
- E'tibor bering, Spring Data sukut bo'yicha ma'lumotlar bazasi ulanishini tekshiradi*;
  * Bu Spring Data Redisning standart xatti-harakatidir (hech bo'lmaganda men oxirgi marta tekshirganman), bu "halokatli" muvaffaqiyatsizlikka olib keldi: Redis qisqa vaqt davomida mavjud bo'lmaganda, barcha podlar "halokatga uchradi".
- Bu ma'noda "tashqi" bir xil dasturning boshqa podlarini ham anglatishi mumkin, ya'ni kaskadli ishdan chiqishning oldini olish uchun tekshirish bir xil klasterning boshqa podslarining holatiga bog'liq bo'lmasligi kerak:
  - natijalar taqsimlangan holatga ega boʻlgan ilovalar uchun farq qilishi mumkin (masalan, podlarda xotirada keshlash).
Jonli zonddan foydalanmang podalar uchun (istisnolar - ular haqiqatan ham zarur bo'lgan holatlar va siz ulardan foydalanishning o'ziga xos xususiyatlari va oqibatlaridan to'liq xabardor bo'lishingiz mumkin):
- Jonlilik tekshiruvi osilgan konteynerlarni tiklashga yordam beradi, biroq siz ilovangiz ustidan toʻliq nazoratga ega boʻlganingiz uchun osilgan jarayonlar va blokirovkalar kabi holatlar roʻy bermasligi kerak: eng yaxshi muqobil dasturni ataylab buzib tashlash va uni avvalgi barqaror holatga qaytarishdir;
- Muvaffaqiyatsiz jonli tekshiruv konteynerni qayta ishga tushirishga olib keladi va shu bilan yuklash bilan bog'liq xatolar oqibatlarini kuchaytirishi mumkin: konteynerni qayta ishga tushirish ishlamay qolishga olib keladi (hech bo'lmaganda dasturni ishga tushirish muddati uchun, aytaylik 30-toq soniya), yangi xatolarga olib keladi , boshqa konteynerlardagi yukni oshirish va ularning ishdan chiqish ehtimolini oshirish va h.k.;
- tashqi qaramlik bilan birlashtirilgan jonlilikni tekshirish - bu eng yomon kombinatsiya bo'lib, kaskadli nosozliklar bilan tahdid qiladi: ma'lumotlar bazasi tomonidagi biroz kechikish barcha konteynerlaringizni qayta ishga tushirishga olib keladi!
Jonlilik va tayyorlikni tekshirish parametrlari boshqacha bo'lishi kerak:
- siz bir xil sog'liqni tekshirishga ega, ammo javob chegarasi yuqori (failureThreshold), masalan, holatni tayinlang tayyormas 3 ta urinishdan so'ng va 10 ta urinishdan keyin jonli zond muvaffaqiyatsiz bo'lgan deb hisoblang;
Exec tekshiruvlaridan foydalanmang, chunki ular zombi jarayonlarining paydo bo'lishiga olib keladigan ma'lum muammolar bilan bog'liq:
- tafsilotlar: qarang Datadog mutaxassislari tomonidan taqdimot.

Xulosa

Podka qachon trafikni qabul qilishga tayyorligini aniqlash uchun tayyorlik problaridan foydalaning.
Jonli zondlardan faqat kerak bo'lganda foydalaning.
Tayyorlik/jonlilik problaridan noto'g'ri foydalanish mavjudlikning pasayishiga va kaskadli nosozliklarga olib kelishi mumkin.

Mavzu bo'yicha qo'shimcha materiallar

Kubernetes hujjatlari: Jonlilik va tayyorlik tekshiruvlarini sozlang;
Kubernetesning jonliligi va tayyorgarligi tekshiruvlari qayta ko'rib chiqildi: o'zingizni boshqa oyog'ingizga otishdan qanday qochish kerak;
O'limdan so'ng NRE laboratoriyalarining uzilishi (u livenessProbe haqida ham gapiradi).

Yangilangan № 1, 2019-09-29

Ma'lumotlar bazasini ko'chirish uchun init konteynerlari haqida: Izoh qo'shildi.

EJ menga eslatdi PDB haqida: jonlilikni tekshirish bilan bog'liq muammolardan biri podalar o'rtasidagi muvofiqlashtirishning yo'qligi. Kubernetes bor Podni buzish byudjetlari (PDB) ilova duch kelishi mumkin bo'lgan bir vaqtda nosozliklar sonini cheklash uchun, biroq tekshiruvlar PDBni hisobga olmaydi. Ideal holda, biz K8-ga: "Agar sinov muvaffaqiyatsiz tugasa, bitta podkastni qayta ishga tushiring, lekin vaziyatni yomonlashtirmaslik uchun hammasini qayta ishga tushirmang" deb aytishimiz mumkin.

Brayan buni juda yaxshi ta'kidladi: “Nima ekanligini aniq bilsangiz, jonli zonddan foydalaning eng yaxshi narsa dasturni o'ldirishdir"(yana, o'zingizni bezovta qilmang).

Yangilangan № 2, 2019-09-29

Foydalanishdan oldin hujjatlarni o'qib chiqish haqida: Men tegishli so'rovni yaratdim (xususiyat so'rovi) hayot zondlari haqidagi hujjatlarni qo'shish uchun.

Tarjimondan PS

Shuningdek, bizning blogimizda o'qing:

Manba: www.habr.com

Kubernetesdagi jonli zondlar xavfli bo'lishi mumkin