Kubernetes konteynerlari uchun eng yaxshi amaliyotlar: salomatlik tekshiruvlari

TP; DR

• Konteynerlar va mikroservislarning yuqori kuzatuvchanligiga erishish uchun jurnallar va asosiy ko'rsatkichlar etarli emas.
• Tezroq tiklanish va chidamlilikni oshirish uchun ilovalar yuqori kuzatuvchanlik printsipini (HOP) qo'llashi kerak.
• Ilova darajasida NOP quyidagilarni talab qiladi: to'g'ri ro'yxatga olish, yaqin monitoring, aqlni tekshirish va ishlash/o'tishni kuzatish.
• NOR elementi sifatida cheklardan foydalaning tayyorlik tekshiruvi и jonli prob Kubernetes.

Salomatlik tekshiruvi shabloni nima?

Muhim ahamiyatga ega bo'lgan va yuqori darajada mavjud bo'lgan dasturni loyihalashda xatoga chidamlilik kabi jihat haqida o'ylash juda muhimdir. Ilova nosozlikdan tezda tiklansa, xatoga chidamli hisoblanadi. Oddiy bulutli ilova mikroservislar arxitekturasidan foydalanadi - bu erda har bir komponent alohida konteynerga joylashtiriladi. Va klasterni loyihalashda k8s ilovasi yuqori darajada mavjudligiga ishonch hosil qilish uchun siz ma'lum naqshlarga amal qilishingiz kerak. Ular orasida Health Check shablon ham bor. Bu ilova k8s ga uning sog'lom ekanligini qanday bildirishini belgilaydi. Bu nafaqat podning ishlayotgani, balki uning so'rovlarni qanday qabul qilishi va ularga javob berishi haqida ham ma'lumot. Kubernetes podning sog'lig'i haqida qanchalik ko'p bilsa, u trafikni yo'naltirish va yukni muvozanatlash bo'yicha shunchalik oqilona qarorlar qabul qiladi. Shunday qilib, yuqori kuzatuvchanlik printsipi ilovaga so'rovlarga o'z vaqtida javob berishga imkon beradi.

Yuqori kuzatuvchanlik printsipi (HOP)

Yuqori kuzatuvchanlik printsipi quyidagilardan biridir konteynerli ilovalarni loyihalash tamoyillari. Mikroservislar arxitekturasida xizmatlar ularning so'rovlari qanday ko'rib chiqilishiga (va to'g'ri) ahamiyat bermaydi, lekin muhimi, ular qabul qiluvchi xizmatlardan qanday javob olishlaridir. Masalan, foydalanuvchini autentifikatsiya qilish uchun bitta konteyner boshqasiga HTTP so‘rovini yuboradi va ma’lum formatdagi javobni kutadi – hammasi shu. PythonJS ham so'rovni qayta ishlashi mumkin va Python Flask javob berishi mumkin. Konteynerlar bir-biriga yashirin tarkibga ega qora qutilarga o'xshaydi. Biroq, NOP printsipi har bir xizmatdan qanchalik sog'lom ekanligini, shuningdek, uning tayyorligi va nosozliklarga chidamlilik holatini ko'rsatadigan bir nechta API so'nggi nuqtalarini ochishni talab qiladi. Kubernetes marshrutlash va yukni muvozanatlash bo'yicha keyingi qadamlarni o'ylab ko'rish uchun ushbu ko'rsatkichlarni so'raydi.

Yaxshi ishlab chiqilgan bulutli ilova asosiy voqealarni standart STDERR va STDOUT kiritish-chiqarish oqimlari yordamida qayd qiladi. Keyinchalik yordamchi xizmat, masalan, filebeat, logstash yoki fluentd, jurnallarni markazlashtirilgan monitoring tizimiga (masalan, Prometey) va jurnallarni yig'ish tizimiga (ELK dasturiy ta'minot to'plami) etkazib beradi. Quyidagi diagrammada bulut ilovasi salomatlik testi namunasi va yuqori kuzatuvchanlik printsipiga muvofiq qanday ishlashi ko'rsatilgan.

Kubernetesda salomatlik tekshiruvi namunasini qanday qo'llash mumkin?

Qutidan tashqari, k8s kontrollerlardan biri yordamida podkastlarning holatini nazorat qiladi (Joylashtirishlar, Replicasets, DaemonSets, Stateful Sets va boshqalar va boshqalar). Ba'zi sabablarga ko'ra podkast tushib qolganini bilib, boshqaruvchi uni qayta ishga tushirishga yoki boshqa tugunga o'tkazishga harakat qiladi. Biroq, pod ishlayotganligi haqida xabar berishi mumkin, lekin uning o'zi ishlamayapti. Misol keltiraylik: ilovangiz Apache-dan veb-server sifatida foydalanadi, siz komponentni klasterning bir nechta podslariga o'rnatdingiz. Kutubxona noto'g'ri sozlanganligi sababli, ilovaga barcha so'rovlar 500 kodi bilan javob beradi (ichki server xatosi). Yetkazib berishni tekshirishda, podkastlarning holatini tekshirish muvaffaqiyatli natija beradi, ammo mijozlar boshqacha fikrda. Biz ushbu istalmagan holatni quyidagicha tasvirlaymiz:

Bizning misolimizda k8s shunday qiladi funksionallikni tekshirish. Ushbu turdagi tekshirishda kubelet konteynerdagi jarayonning holatini doimiy ravishda tekshiradi. Jarayon to'xtaganini tushungandan so'ng, u uni qayta ishga tushiradi. Agar xatoni oddiygina dasturni qayta ishga tushirish orqali hal qilish mumkin bo'lsa va dastur har qanday xatolik uchun o'chirishga mo'ljallangan bo'lsa, NOP va Salomatlik testi namunasiga amal qilish uchun jarayonning sog'lig'ini tekshirish kifoya qiladi. Faqatgina achinarlisi shundaki, barcha xatolar qayta ishga tushirish bilan bartaraf etilmaydi. Bunday holda, k8s podkastdagi muammolarni aniqlashning ikkita chuqurroq usulini taklif qiladi: jonli prob и tayyorlik tekshiruvi.

LivenessProbe

Vaqtida jonli prob kubelet 3 turdagi tekshiruvlarni amalga oshiradi: nafaqat pod ishlayotganligini, balki so'rovlarni qabul qilishga va ularga mos ravishda javob berishga tayyorligini ham aniqlaydi:

• Podga HTTP so'rovini o'rnating. Javob 200 dan 399 gacha bo'lgan oraliqda HTTP javob kodini o'z ichiga olishi kerak. Shunday qilib, 5xx va 4xx kodlari jarayon ishlayotgan bo'lsa ham podada muammolar borligini bildiradi.
• HTTP bo'lmagan xizmatlar (masalan, Postfix pochta serveri) bilan podlarni sinab ko'rish uchun siz TCP ulanishini o'rnatishingiz kerak.
• Pod uchun ixtiyoriy buyruqni bajaring (ichki). Agar buyruqni bajarish kodi 0 bo'lsa, tekshirish muvaffaqiyatli deb hisoblanadi.

Bu qanday ishlashiga misol. Keyingi pod taʼrifida HTTP soʻrovlarida 500 xatolik chiqaradigan NodeJS ilovasi mavjud. Bunday xatolik yuzaga kelganda konteyner qayta ishga tushirilganligiga ishonch hosil qilish uchun biz livenessProbe parametridan foydalanamiz:

apiVersion: v1
kind: Pod
metadata:
 name: node500
spec:
 containers:
   - image: magalix/node500
     name: node500
     ports:
       - containerPort: 3000
         protocol: TCP
     livenessProbe:
       httpGet:
         path: /
         port: 3000
       initialDelaySeconds: 5

Bu boshqa pod ta'riflaridan farq qilmaydi, lekin biz ob'ektni qo'shmoqdamiz .spec.containers.livenessProbe. Parametr httpGet HTTP GET so'rovi yuboriladigan yo'lni qabul qiladi (bizning misolimizda bu /, ammo jangovar stsenariylarda shunga o'xshash narsa bo'lishi mumkin /api/v1/status). Boshqa livenessProbe parametrni qabul qiladi initialDelaySeconds, bu tekshirish operatsiyasiga belgilangan soniyalarni kutishni buyuradi. Kechikish kerak, chunki konteyner ishga tushishi uchun vaqt kerak va qayta ishga tushirilganda u bir muncha vaqt ishlamaydi.

Ushbu sozlamani klasterga qo'llash uchun quyidagilardan foydalaning:

kubectl apply -f pod.yaml

Bir necha soniyadan so'ng siz quyidagi buyruq yordamida pod tarkibini tekshirishingiz mumkin:

kubectl describe pods node500

Chiqish oxirida toping bu nima.

Ko'rib turganingizdek, livenessProbe HTTP GET so'rovini ishga tushirdi, konteyner 500 xatosini yaratdi (bu shunday qilish uchun dasturlashtirilgan) va kubelet uni qayta ishga tushirdi.

Agar NideJS ilovasi qanday dasturlashtirilganiga qiziqsangiz, mana app.js va Dockerfile ishlatilgan:

app.js

var http = require('http');

var server = http.createServer(function(req, res) {
    res.writeHead(500, { "Content-type": "text/plain" });
    res.end("We have run into an errorn");
});

server.listen(3000, function() {
    console.log('Server is running at 3000')
})

Docker fayli

FROM node
COPY app.js /
EXPOSE 3000
ENTRYPOINT [ "node","/app.js" ]

Shuni ta'kidlash kerakki, livenessProbe konteynerni faqat muvaffaqiyatsiz bo'lsa qayta ishga tushiradi. Agar qayta ishga tushirish konteynerning ishlashiga xalaqit beradigan xatoni tuzatmasa, kubelet muammoni hal qilish uchun chora ko'ra olmaydi.

tayyorlik tekshiruvi

ReadinessProbe xuddi livenessProbes (GET so'rovlari, TCP aloqalari va buyruqlar bajarilishi) bilan ishlaydi, nosozliklarni bartaraf etish harakatlaridan tashqari. Nosozlik aniqlangan konteyner qayta ishga tushirilmaydi, lekin kiruvchi trafikdan ajratilgan. Tasavvur qiling-a, konteynerlardan biri juda ko'p hisob-kitoblarni amalga oshiradi yoki og'ir yuk ostida bo'lib, javob vaqtini oshiradi. LivenessProbe holatida javob mavjudligini tekshirish ishga tushiriladi (timeoutSeconds tekshirish parametri orqali), shundan so'ng kubelet konteynerni qayta ishga tushiradi. Ishga tushganda, konteyner resurslarni ko'p talab qiladigan vazifalarni bajarishni boshlaydi va qayta ishga tushiriladi. Bu javob tezligiga muhtoj bo'lgan ilovalar uchun juda muhim bo'lishi mumkin. Misol uchun, yo'lda mashina serverdan javob kutmoqda, javob kechiktiriladi - va mashina avariyaga uchraydi.

Keling, GET so'roviga javob berish vaqtini ikki soniyadan ko'p bo'lmagan qilib o'rnatadigan redinessProbe ta'rifini yozamiz va dastur 5 soniyadan so'ng GET so'roviga javob beradi. Pod.yaml fayli quyidagicha ko'rinishi kerak:

apiVersion: v1
kind: Pod
metadata:
 name: nodedelayed
spec:
 containers:
   - image: afakharany/node_delayed
     name: nodedelayed
     ports:
       - containerPort: 3000
         protocol: TCP
     readinessProbe:
       httpGet:
         path: /
         port: 3000
       timeoutSeconds: 2

Keling, kubectl bilan podni o'rnatamiz:

kubectl apply -f pod.yaml

Keling, bir necha soniya kutamiz va keyin ReadinessProbe qanday ishlaganini ko'ramiz:

kubectl describe pods nodedelayed

Chiqish oxirida siz ba'zi voqealar o'xshashligini ko'rishingiz mumkin Bunisi.

Ko'rib turganingizdek, tekshirish vaqti 2 soniyadan oshganida kubectl podni qayta ishga tushirmadi. Buning o'rniga u so'rovni bekor qildi. Kiruvchi aloqa boshqa, ishlaydigan podslarga yo'naltiriladi.

E'tibor bering, endi pod yuklab olingandan so'ng, kubectl unga so'rovlarni yana yo'naltiradi: GET so'rovlariga javoblar endi kechiktirilmaydi.

Taqqoslash uchun quyida o'zgartirilgan app.js fayli keltirilgan:

var http = require('http');

var server = http.createServer(function(req, res) {
   const sleep = (milliseconds) => {
       return new Promise(resolve => setTimeout(resolve, milliseconds))
   }
   sleep(5000).then(() => {
       res.writeHead(200, { "Content-type": "text/plain" });
       res.end("Hellon");
   })
});

server.listen(3000, function() {
   console.log('Server is running at 3000')
})

TP; DR
Bulutli ilovalar paydo bo'lishidan oldin, jurnallar ilovalar sog'lig'ini kuzatish va tekshirishning asosiy vositasi edi. Biroq, tuzatish choralarini ko'rish uchun hech qanday vosita yo'q edi. Jurnallar bugungi kunda ham foydalidir; ularni to'plash va favqulodda vaziyatlarni tahlil qilish va qarorlar qabul qilish uchun jurnallarni yig'ish tizimiga yuborish kerak. [Bularning barchasi, masalan, monit-dan foydalangan holda bulutli ilovalarsiz amalga oshirilishi mumkin, ammo k8s bilan bu juda osonlashdi :) - muharrir eslatmasi. ]

Bugungi kunda tuzatishlar deyarli real vaqtda amalga oshirilishi kerak, shuning uchun ilovalar endi qora quti bo'lishi shart emas. Yo'q, ular monitoring tizimlariga jarayonlar holati haqida qimmatli ma'lumotlarni so'rash va to'plash imkonini beruvchi so'nggi nuqtalarni ko'rsatishi kerak, shunda ular kerak bo'lganda darhol javob bera oladilar. Bu yuqori kuzatuvchanlik printsipiga (HOP) amal qiladigan ishlash testi dizayn namunasi deb ataladi.

Kubernetes sukut bo'yicha 2 turdagi sog'liqni tekshirishni taklif qiladi: readinessProbe va livenessProbe. Ikkalasi ham bir xil turdagi tekshiruvlardan foydalanadi (HTTP GET so'rovlari, TCP aloqalari va buyruqlar bajarilishi). Ular podalardagi muammolarga javoban qanday qarorlar qabul qilishlari bilan farqlanadi. livenessProbe xato yana takrorlanmasligiga umid qilib konteynerni qayta ishga tushiradi va readinessProbe muammo sababi hal qilinmaguncha podni kiruvchi trafikdan ajratadi.

To'g'ri dastur dizayni tekshirishning ikkala turini o'z ichiga olishi va ular etarli ma'lumotlarni to'plashini ta'minlashi kerak, ayniqsa istisno qilinganda. Shuningdek, u monitoring tizimini (Prometey) muhim sog'liq ko'rsatkichlari bilan ta'minlaydigan zarur API so'nggi nuqtalarini ko'rsatishi kerak.

Manba: www.habr.com