TL; DR
- Konteynerlərin və mikroservislərin yüksək müşahidə qabiliyyətinə nail olmaq üçün qeydlər və ilkin ölçülər kifayət deyil.
- Daha sürətli bərpa və artan davamlılıq üçün tətbiqlər Yüksək Müşahidə Prinsipini (HOP) tətbiq etməlidir.
- Tətbiq səviyyəsində NOP tələb edir: düzgün giriş, yaxın monitorinq, ağlı başında olma yoxlanışı və performans/keçid izləmə.
- NOR elementi kimi çeklərdən istifadə edin Hazırlıq Probu и canlılıqSondu Kubernetes.
Sağlamlıq yoxlaması şablonu nədir?
Missiya baxımından kritik və yüksək əlçatan proqram tərtib edərkən, nasazlığa dözümlülük kimi bir aspekt haqqında düşünmək çox vacibdir. Tətbiq uğursuzluqdan tez bərpa olunarsa, nasazlığa dözümlü hesab olunur. Tipik bir bulud tətbiqi mikroservis arxitekturasından istifadə edir - burada hər bir komponent ayrıca konteynerə yerləşdirilir. Bir klaster dizayn edərkən k8s-dəki tətbiqin yüksək səviyyədə mövcud olduğundan əmin olmaq üçün müəyyən nümunələrə əməl etməlisiniz. Onların arasında Sağlamlıq Yoxlama Şablonu da var. Tətbiqin k8s-ə sağlam olduğunu necə bildirdiyini müəyyən edir. Bu, təkcə podun işlək olub-olmaması haqqında məlumat deyil, həm də onun sorğuları necə qəbul etməsi və onlara cavab verməsi haqqındadır. Kubernetes podun sağlamlığı haqqında nə qədər çox bilsə, trafikin marşrutlaşdırılması və yük balansı ilə bağlı daha ağıllı qərarlar qəbul edir. Beləliklə, Yüksək Müşahidə Prinsipi tətbiqə müraciətlərə vaxtında cavab verməyə imkan verir.
Yüksək müşahidə prinsipi (HOP)
Yüksək müşahidəçilik prinsipi bunlardan biridir . Mikroxidmətlər arxitekturasında xidmətlər onların sorğusunun necə işləndiyinə (və haqlı olaraq) əhəmiyyət vermir, amma önəmli olan onların qəbul edən xidmətlərdən necə cavab almasıdır. Məsələn, istifadəçinin autentifikasiyası üçün bir konteyner digərinə HTTP sorğusu göndərir, müəyyən formatda cavab gözləyir - hamısı budur. PythonJS də sorğunu emal edə bilər və Python Flask cavab verə bilər. Konteynerlər bir-birinə gizli məzmunu olan qara qutulara bənzəyir. Bununla belə, NOP prinsipi hər bir xidmətdən onun nə qədər sağlam olduğunu, həmçinin hazırlığını və nasazlığa dözümlülüyünü göstərən çoxsaylı API son nöqtələrini ifşa etməyi tələb edir. Kubernetes marşrutlaşdırma və yük balansı üçün növbəti addımları düşünmək üçün bu göstəriciləri tələb edir.
Yaxşı dizayn edilmiş bulud proqramı standart I/O axınları STDERR və STDOUT istifadə edərək əsas hadisələrini qeyd edir. Sonra köməkçi xidmət gəlir, məsələn, filebeat, logstash və ya fluentd, logları mərkəzləşdirilmiş monitorinq sisteminə (məsələn, Prometheus) və log toplama sisteminə (ELK proqram dəsti). Aşağıdakı diaqram bulud tətbiqinin Sağlamlıq Testi Nümunəsinə və Yüksək Müşahidə Prinsipinə uyğun olaraq necə işlədiyini göstərir.
Kubernetes-də Sağlamlıq Yoxlama Nümunəsini necə tətbiq etmək olar?
Qutudan kənarda, k8s nəzarətçilərdən birini istifadə edərək podların vəziyyətinə nəzarət edir (, , , və s. və s.). Podun nədənsə düşdüyünü aşkar edərək, nəzarətçi onu yenidən işə salmağa və ya başqa qovşağa köçürməyə çalışır. Bununla belə, pod işlək vəziyyətdə olduğunu bildirə bilər, lakin özü işləmir. Bir misal verək: tətbiqiniz Apache-dən veb-server kimi istifadə edir, siz komponenti klasterin bir neçə podunda quraşdırmısınız. Kitabxana səhv konfiqurasiya olunduğundan, proqrama edilən bütün sorğular 500 kodu ilə cavab verir (daxili server xətası). Çatdırılmanı yoxlayarkən, podların vəziyyətini yoxlamaq uğurlu nəticə verir, lakin müştərilər fərqli düşünür. Bu arzuolunmaz vəziyyəti aşağıdakı kimi təsvir edəcəyik:
Bizim nümunəmizdə k8s edir funksionallıq yoxlanışı. Bu tip yoxlamada kubelet konteynerdəki prosesin vəziyyətini davamlı olaraq yoxlayır. Prosesin dayandığını anladıqdan sonra onu yenidən işə salacaq. Səhv sadəcə tətbiqi yenidən başlatmaqla həll edilə bilərsə və proqram hər hansı bir səhvə görə bağlanmaq üçün nəzərdə tutulubsa, NOP və Sağlamlıq Test Nümunəsinə əməl etmək üçün prosesin sağlamlığı yoxlanışı sizə lazım olan tək şeydir. Yeganə təəssüf ki, bütün səhvlər yenidən başlamaqla aradan qaldırılmır. Bu halda, k8s pod ilə problemləri müəyyən etmək üçün 2 daha dərin üsul təklif edir: и .
LivenessProbe
Hələlik canlılıqSondu kubelet 3 növ yoxlama həyata keçirir: təkcə podun işlək olub-olmadığını müəyyən etmir, həm də sorğuları qəbul etməyə və adekvat cavab verməyə hazır olub-olmadığını müəyyən edir:
- Pod üçün HTTP sorğusu qurun. Cavabda 200-dən 399-a qədər olan intervalda HTTP cavab kodu olmalıdır. Beləliklə, 5xx və 4xx kodları proses davam etsə də, podun problemlərinin olduğunu bildirir.
- Qeyri-HTTP xidmətləri (məsələn, Postfix poçt serveri) ilə podları sınamaq üçün siz TCP bağlantısı qurmalısınız.
- Pod üçün ixtiyari əmri yerinə yetirin (daxili olaraq). Komanda tamamlama kodu 0 olarsa, yoxlama uğurlu sayılır.
Bunun necə işlədiyinə dair bir nümunə. Növbəti pod tərifində HTTP sorğularında 500 xətası atan NodeJS tətbiqi var. Belə bir xəta alarkən konteynerin yenidən işə salındığından əmin olmaq üçün biz livenessProbe parametrindən istifadə edirik:
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: 5Bu, hər hansı digər pod tərifindən fərqlənmir, lakin biz obyekt əlavə edirik .spec.containers.livenessProbe. Parametr httpGet HTTP GET sorğusunun göndərildiyi yolu qəbul edir (bizim nümunəmizdə bu /, lakin döyüş ssenarilərində belə bir şey ola bilər /api/v1/status). Digər livenessProbe bir parametr qəbul edir initialDelaySeconds, yoxlama əməliyyatına müəyyən sayda saniyə gözləməyi əmr edir. Gecikmə lazımdır, çünki konteynerin işə salınması üçün vaxt lazımdır və yenidən işə salındıqda bir müddət əlçatan olmayacaq.
Bu parametri klasterə tətbiq etmək üçün istifadə edin:
kubectl apply -f pod.yamlBir neçə saniyədən sonra aşağıdakı əmrdən istifadə edərək podun məzmununu yoxlaya bilərsiniz:
kubectl describe pods node500Çıxışın sonunda tapın .
Gördüyünüz kimi, livenessProbe HTTP GET sorğusunu başlatdı, konteyner 500 xətası yaratdı (bunu etmək üçün proqramlaşdırılmışdı) və kubelet onu yenidən işə saldı.
NideJS tətbiqinin necə proqramlaşdırıldığı ilə maraqlanırsınızsa, istifadə olunan app.js və Dockerfile budur:
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 faylı
FROM node
COPY app.js /
EXPOSE 3000
ENTRYPOINT [ "node","/app.js" ]Bunu qeyd etmək vacibdir: livenessProbe yalnız uğursuz olduqda konteyneri yenidən işə salacaq. Yenidən başlatma konteynerin işləməsinə mane olan xətanı düzəltməzsə, kubelet problemi düzəltmək üçün tədbir görə bilməyəcək.
Hazırlıq Probu
ReadinessProbe, problemlərin aradan qaldırılması tədbirləri istisna olmaqla, livenessProbes (GET sorğuları, TCP kommunikasiyaları və əmrlərin icrası) kimi işləyir. Arızanın aşkar edildiyi konteyner yenidən işə salınmır, lakin gələn trafikdən təcrid olunur. Təsəvvür edin ki, konteynerlərdən biri çoxlu hesablamalar aparır və ya ağır yük altındadır və cavab müddətinin artmasına səbəb olur. LivenessProbe vəziyyətində cavabın əlçatanlığının yoxlanılması işə salınır (timeoutSeconds yoxlama parametri vasitəsilə), bundan sonra kubelet konteyneri yenidən işə salır. Başladıqda, konteyner resurs tələb edən vəzifələri yerinə yetirməyə başlayır və yenidən işə salınır. Bu, cavab sürətinə ehtiyacı olan tətbiqlər üçün kritik ola bilər. Məsələn, avtomobil yolda olarkən serverdən cavab gözləyir, cavab gecikir - və avtomobil qəzaya uğrayır.
GET sorğusunun cavab müddətini iki saniyədən çox olmayan müddətə təyin edəcək redinessProbe tərifini yazaq və proqram 5 saniyədən sonra GET sorğusuna cavab verəcək. pod.yaml faylı belə görünməlidir:
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: 2Gəlin kubectl ilə pod yerləşdirək:
kubectl apply -f pod.yamlGəlin bir neçə saniyə gözləyək və sonra ReadinessProbe-un necə işlədiyini görək:
kubectl describe pods nodedelayedÇıxışın sonunda bəzi hadisələrin oxşar olduğunu görə bilərsiniz .
Gördüyünüz kimi, kubectl yoxlama müddəti 2 saniyədən çox olduqda podu yenidən başlatmadı. Əvəzində o, sorğunu ləğv etdi. Gələn kommunikasiyalar digər işləyən podlara yönləndirilir.
Nəzərə alın ki, indi pod yükləndikdən sonra kubectl sorğuları yenidən ona yönləndirir: GET sorğularına cavablar artıq gecikdirilmir.
Müqayisə üçün aşağıda dəyişdirilmiş app.js faylı verilmişdir:
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')
})TL; DR
Bulud proqramlarının meydana çıxmasından əvvəl, loglar tətbiqin sağlamlığını izləmək və yoxlamaq üçün əsas vasitə idi. Bununla belə, hər hansı bir düzəliş tədbiri görmək üçün heç bir vasitə yox idi. Qeydlər bu gün də faydalıdır; fövqəladə halları təhlil etmək və qərar qəbul etmək üçün onları toplamaq və jurnal toplama sisteminə göndərmək lazımdır. [Bütün bunları, məsələn, monit istifadə edərək bulud proqramları olmadan etmək olardı, lakin k8s ilə bu, daha asan oldu :) – redaktorun qeydi. ]
Bu gün, demək olar ki, real vaxt rejimində düzəlişlər edilməlidir, buna görə tətbiqlər artıq qara qutular olmamalıdır. Xeyr, onlar monitorinq sistemlərinə proseslərin vəziyyəti haqqında qiymətli məlumatları sorğulamağa və toplamaq imkanı verən son nöqtələri göstərməlidirlər ki, lazım olduqda dərhal cavab verə bilsinlər. Bu, Yüksək Müşahidə Prinsipinə (HOP) əməl edən Performans Testinin Dizayn Nümunəsi adlanır.
Kubernetes standart olaraq 2 növ sağlamlıq yoxlaması təklif edir: readinessProbe və livenessProbe. Hər ikisi eyni növ yoxlamalardan istifadə edir (HTTP GET sorğuları, TCP kommunikasiyaları və əmrlərin icrası). Podlardakı problemlərə cavab olaraq hansı qərarlar verdikləri ilə fərqlənirlər. livenessProbe xətanın yenidən baş verməyəcəyi ümidi ilə konteyneri yenidən işə salır və readinessProbe problemin səbəbi həll olunana qədər podu daxil olan trafikdən təcrid edir.
Düzgün tətbiq dizaynı hər iki yoxlama növünü əhatə etməli və onların kifayət qədər məlumat toplamasını təmin etməlidir, xüsusən də istisnalar atıldıqda. O, həmçinin monitorinq sistemini (Prometey) mühüm sağlamlıq göstəriciləri ilə təmin edən zəruri API son nöqtələrini göstərməlidir.
Mənbə: www.habr.com