ڪبرنيٽس ڪنٽينرز لاءِ بهترين طريقا: صحت جي چڪاس

TL، ڊاڪٽر

• ڪنٽينرز ۽ مائڪرو سروسز جي اعلي مشاهدي حاصل ڪرڻ لاء، لاگ ۽ پرائمري ميٽرڪ ڪافي نه آهن.
• تيز بحالي ۽ وڌندڙ لچڪ لاءِ، ايپليڪيشنن کي هاءِ آبزرويبلٽي پرنسپل (HOP) لاڳو ڪرڻ گهرجي.
• ايپليڪيشن جي سطح تي، NOP جي ضرورت آهي: مناسب لاگنگ، ويجهي مانيٽرنگ، صفائي چيڪ، ۽ ڪارڪردگي/منتقلي ٽريڪنگ.
• NOR جي عنصر طور چيڪ استعمال ڪريو تياري جاچ и زندگي جي جاچ ڪبرنيٽس.

صحت جي چڪاس ٽيمپليٽ ڇا آهي؟

جڏهن هڪ مشن-نازڪ ۽ انتهائي دستياب ايپليڪيشن کي ڊزائين ڪرڻ، اهو تمام ضروري آهي ته اهڙي قسم جي باري ۾ سوچڻ لاء غلطي رواداري. هڪ ايپليڪيشن سمجهي ويندي آهي غلطي رواداري جيڪڏهن اها ناڪامي کان جلدي بحال ٿئي. هڪ عام ڪلائوڊ ايپليڪيشن مائڪرو سروسز آرڪيٽيڪچر استعمال ڪري ٿي - جتي هر جزو هڪ الڳ ڪنٽينر ۾ رکيل آهي. ۽ انهي ڳالهه کي يقيني بڻائڻ لاءِ ته k8s تي ايپليڪيشن تمام گهڻي دستياب آهي جڏهن توهان هڪ ڪلستر ٺاهيو ٿا، توهان کي ڪجهه نمونن جي پيروي ڪرڻ جي ضرورت آهي. انهن مان صحت جي چڪاس ٽيمپليٽ آهي. اهو بيان ڪري ٿو ته ايپليڪيشن k8s کي ڪيئن ٻڌائي ٿي ته اهو صحتمند آهي. هي نه رڳو معلومات آهي ته ڇا پوڊ هلي رهيو آهي، پر اهو پڻ آهي ته اهو ڪيئن حاصل ڪري ٿو ۽ درخواستن جو جواب ڏئي ٿو. وڌيڪ ڪبرنيٽس پوڊ جي صحت جي باري ۾ ڄاڻي ٿو، هوشيار فيصلا اهو ٽريفڪ روٽنگ ۽ لوڊ بيلنسنگ بابت ڪري ٿو. اهڙيء طرح، اعلي مشاهدو اصول درخواست کي بروقت انداز ۾ درخواستن جو جواب ڏيڻ جي اجازت ڏئي ٿو.

اعلي مشاهدو اصول (HOP)

اعلي مشاهدي جو اصول هڪ آهي ڪنٽينر ٿيل ايپليڪيشنن کي ڊزائين ڪرڻ لاء اصول. هڪ microservices فن تعمير ۾، خدمتن کي پرواه ناهي ته ڪيئن انهن جي درخواست تي عمل ڪيو وڃي ٿو (۽ صحيح طور تي ائين)، پر ڇا معاملو آهي ته اهي وصول ڪندڙ خدمتن کان ڪيئن جواب حاصل ڪن ٿا. مثال طور، هڪ صارف جي تصديق ڪرڻ لاء، هڪ ڪنٽينر هڪ ٻئي ڏانهن HTTP درخواست موڪلي ٿو، هڪ خاص فارميٽ ۾ جواب جي توقع آهي - اهو سڀ ڪجهه آهي. PythonJS پڻ درخواست تي عمل ڪري سگھي ٿو، ۽ پٿون فلاسڪ جواب ڏئي سگھي ٿو. ڪنٽينر هڪ ٻئي ڏانهن لڪيل مواد سان بليڪ باڪس وانگر آهن. جڏهن ته، NOP اصول هر خدمت جي ضرورت آهي ڪيترن ئي API جي آخري پوائنٽن کي بي نقاب ڪرڻ لاء جيڪي ظاهر ڪن ٿا ته اهو ڪيترو صحتمند آهي، انهي سان گڏ ان جي تيارگي ۽ غلطي رواداري جي حيثيت. ڪبرنيٽس انهن اشارن جي درخواست ڪري ٿو ته جيئن روئٽنگ ۽ لوڊ بيلنسنگ لاءِ ايندڙ مرحلن ذريعي سوچڻ لاءِ.

هڪ سٺي ڊزائين ڪيل ڪلائوڊ ايپليڪيشن معياري I/O اسٽريمز STDERR ۽ STDOUT استعمال ڪندي پنهنجي مکيه واقعن کي لاگ ان ڪري ٿي. اڳتي هلي هڪ معاون سروس اچي ٿي، مثال طور فائل بيٽ، لاگ اسٽاش يا فلوئنٽ، لاگ پهچائڻ هڪ مرڪزي مانيٽرنگ سسٽم (مثال طور Prometheus) ۽ هڪ لاگ ڪليڪشن سسٽم (ELK سافٽ ويئر سوٽ). هيٺ ڏنل ڊراگرام ڏيکاري ٿو ته ڪئين ڪلائوڊ ايپليڪيشن صحت ٽيسٽ جي نموني ۽ اعلي مشاهدي جي اصول جي مطابق ڪم ڪري ٿي.

ڪبرنيٽس ۾ صحت جي چڪاس جو نمونو ڪيئن لاڳو ڪجي؟

دٻي کان ٻاهر، k8s مانيٽر ڪري ٿو پوڊ جي حالت کي ڪنٽرولرز مان هڪ استعمال ڪندي (نوڪريون, ReplicaSets, ڊيمون سيٽ, رياستي سيٽ وغيره وغيره). دريافت ڪيو ويو آهي ته پوڊ ڪجهه سببن لاء گر ٿي ويو آهي، ڪنٽرولر ان کي ٻيهر شروع ڪرڻ يا ان کي ٻئي نوڊ ڏانهن منتقل ڪرڻ جي ڪوشش ڪري ٿو. بهرحال، هڪ پوڊ رپورٽ ڪري سگهي ٿو ته اهو مٿي ۽ هلندڙ آهي، پر اهو پاڻ ڪم نه ڪري رهيو آهي. اچو ته هڪ مثال ڏيو: توهان جي ايپليڪيشن Apache کي ويب سرور طور استعمال ڪري ٿي، توهان ڪلستر جي ڪيترن ئي پوڊس تي جزو انسٽال ڪيو. جيئن ته لائبريري غلط ترتيب ڏني وئي هئي، ايپليڪيشن جون سڀئي درخواستون ڪوڊ 500 (اندروني سرور جي غلطي) سان جواب ڏين ٿيون. جڏهن ترسيل جي جانچ ڪندي، پوڊ جي صورتحال کي جانچڻ هڪ ڪامياب نتيجو ڏئي ٿو، پر گراهڪ مختلف سوچن ٿا. اسان هن ناپسنديده صورتحال کي هن ريت بيان ڪنداسين:

اسان جي مثال ۾، k8s ڪندو آھي ڪارڪردگي جي چڪاس. هن قسم جي تصديق ۾، ڪوبلٽ مسلسل ڪنٽرول ۾ عمل جي حالت کي جانچيندو آهي. هڪ دفعو هو سمجهي ٿو ته اهو عمل بند ٿي ويو آهي، هو ان کي ٻيهر شروع ڪندو. جيڪڏهن غلطي صرف ايپليڪيشن کي ٻيهر شروع ڪرڻ سان حل ٿي سگهي ٿي، ۽ پروگرام ڪنهن به غلطي تي بند ڪرڻ لاءِ ٺهيل آهي، ته پوءِ هڪ عمل صحت جي چڪاس تمام ضروري آهي توهان کي NOP ۽ هيلٿ ٽيسٽ جي نموني جي پيروي ڪرڻ جي ضرورت آهي. رڳو افسوس اهو آهي ته ٻيهر شروع ڪرڻ سان سڀئي غلطيون ختم نه ٿيون ٿين. انهي حالت ۾، k8s پيش ڪري ٿو 2 گہرا طريقا پوڊ سان مسئلن جي نشاندهي ڪرڻ لاءِ: زندگي جي جاچ и تياري جاچ.

زندگي جي جاچ

دوران زندگي جي جاچ kubelet 3 قسم جي چيڪن کي انجام ڏئي ٿو: نه رڳو اهو طئي ڪري ٿو ته ڇا پوڊ هلي رهيو آهي، پر اهو پڻ آهي ته ڇا اهو حاصل ڪرڻ لاء تيار آهي ۽ مناسب طور تي درخواستن جو جواب ڏئي ٿو:

• پوڊ ڏانهن هڪ HTTP درخواست سيٽ ڪريو. جواب ۾ 200 کان 399 تائين رينج ۾ هڪ HTTP جوابي ڪوڊ هجڻ لازمي آهي. اهڙيءَ طرح، ڪوڊ 5xx ۽ 4xx سگنل ڏئي ٿو ته پوڊ کي مسئلو آهي، جيتوڻيڪ اهو عمل هلندڙ آهي.
• نان-HTTP خدمتن سان پوڊس کي جانچڻ لاءِ (مثال طور، پوسٽ فڪس ميل سرور)، توھان کي ھڪ TCP ڪنيڪشن قائم ڪرڻو پوندو.
• پوڊ (اندروني طور) لاءِ صوابديدي حڪم جاري ڪريو. چيڪ کي ڪامياب سمجهيو ويندو آهي جيڪڏهن ڪمانڊ مڪمل ڪرڻ جو ڪوڊ 0 آهي.

اهو ڪيئن ڪم ڪرڻ جو هڪ مثال. ايندڙ پوڊ جي وصف هڪ NodeJS ايپليڪيشن تي مشتمل آهي جيڪا HTTP درخواستن تي 500 غلطي اڇلائي ٿي. انهي ڳالهه کي يقيني بڻائڻ لاءِ ته ڪنٽينر ٻيهر شروع ٿئي ٿو جڏهن اهڙي غلطي ملي ٿي، اسان استعمال ڪريون ٿا livenessProbe پيٽرول:

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

هي ڪنهن ٻئي پوڊ جي تعريف کان مختلف ناهي، پر اسان هڪ اعتراض شامل ڪري رهيا آهيون .spec.containers.livenessProbe. پيرا ميٽر httpGet اهو رستو قبول ڪري ٿو جنهن ڏانهن HTTP GET درخواست موڪلي وئي آهي (اسان جي مثال ۾ هي آهي /، پر جنگي منظرنامي ۾ ٿي سگھي ٿو ڪجھھ جھڙو /api/v1/status). ٻيو livenessProbe هڪ پيرا ميٽر قبول ڪري ٿو initialDelaySeconds، جيڪو تصديق جي عمل کي هدايت ڪري ٿو ته سيڪنڊن جي مخصوص تعداد جو انتظار ڪريو. دير جي ضرورت آهي ڇو ته ڪنٽينر کي شروع ٿيڻ ۾ وقت جي ضرورت آهي، ۽ جڏهن ٻيهر شروع ڪيو ويندو ته اهو ڪجهه وقت لاءِ دستياب نه هوندو.

ھن سيٽنگ کي ڪلستر تي لاڳو ڪرڻ لاء، استعمال ڪريو:

kubectl apply -f pod.yaml

ڪجھ سيڪنڊن کان پوء، توھان ھيٺ ڏنل حڪم استعمال ڪندي پوڊ جي مواد کي چيڪ ڪري سگھو ٿا:

kubectl describe pods node500

پيداوار جي آخر ۾، ڳولهيو اهو ئي آهي.

جئين توهان ڏسي سگهو ٿا، livenessProbe هڪ HTTP GET درخواست شروع ڪئي، ڪنٽينر هڪ غلطي 500 پيدا ڪئي (جيڪو اهو ڪرڻ لاء پروگرام ڪيو ويو هو)، ۽ ڪوبلٽ ان کي ٻيهر شروع ڪيو.

جيڪڏهن توهان حيران ٿي رهيا آهيو ته NideJS ايپليڪيشن ڪيئن پروگرام ڪئي وئي، هتي آهي app.js ۽ Dockerfile جيڪي استعمال ڪيا ويا آهن:

ايپ.جس

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')
})

Dockerfile

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

اهو نوٽ ڪرڻ ضروري آهي: livenessProbe صرف ڪنٽينر کي ٻيهر شروع ڪندو جيڪڏهن اهو ناڪام ٿئي. جيڪڏهن ٻيهر شروع ٿيڻ واري غلطي کي درست نه ڪندو آهي جيڪو ڪنٽينر کي هلائڻ کان روڪي رهيو آهي، ڪوبيليٽ مسئلي کي درست ڪرڻ لاء قدم کڻڻ جي قابل نه هوندو.

تياري جاچ

ReadinessProbe ساڳيءَ طرح ڪم ڪري ٿو LivenessProbes (GET درخواستون، TCP ڪميونيڪيشن ۽ ڪمانڊ ايگزيڪيوشن)، سواءِ مسئلن جي حل ڪرڻ واري عمل جي. ڪنٽينر جنهن ۾ ناڪامي معلوم ڪئي وئي آهي ٻيهر شروع نه ڪئي وئي آهي، پر ايندڙ ٽرئفڪ کان الڳ ٿيل آهي. تصور ڪريو ته ھڪڙو ڪنٽينر تمام گھڻي حساب سان انجام ڏئي رھيو آھي يا ڳري بار ھيٺ آھي، جنھن ڪري جوابي وقت وڌي رھيا آھن. LivenessProbe جي صورت ۾، جواب جي دستيابي جي چڪاس شروع ڪئي وئي آهي (ٽائم آئوٽ سيڪنڊ جي چڪاس جي پيٽرولر ذريعي)، جنهن کان پوء ڪوبيليٽ ڪنٽينر کي ٻيهر شروع ڪري ٿو. جڏهن شروع ڪيو ويو، ڪنٽينر شروع ٿئي ٿو وسيلا-گھڻي ڪمن کي انجام ڏيڻ ۽ ٻيهر شروع ٿئي ٿو. اهو ايپليڪيشنن لاءِ نازڪ ٿي سگهي ٿو جن کي جواب جي رفتار جي ضرورت آهي. مثال طور، هڪ ڪار جڏهن روڊ تي سرور کان جواب جي انتظار ۾ آهي، جواب ۾ دير ٿي وئي آهي - ۽ ڪار هڪ حادثي ۾ ٿئي ٿي.

اچو ته هڪ redinessProbe وصف لکون جيڪو GET درخواست جي جواب جو وقت مقرر ڪندو ٻن سيڪنڊن کان وڌيڪ نه، ۽ ايپليڪيشن 5 سيڪنڊن کان پوءِ GET درخواست جو جواب ڏيندو. pod.yaml فائل هن طرح ڏسڻ گهرجي:

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

اچو ته kubectl سان هڪ پوڊ ترتيب ڏيو:

kubectl apply -f pod.yaml

اچو ته ڪجهه سيڪنڊن جو انتظار ڪريون ۽ پوءِ ڏسو ته ڪيئن تياري پروب ڪم ڪيو:

kubectl describe pods nodedelayed

پيداوار جي آخر ۾ توهان ڏسي سگهو ٿا ته ڪجهه واقعا ساڳيا آهن هي هڪ.

جئين توهان ڏسي سگهو ٿا، ڪبيڪل پوڊ کي ٻيهر شروع نه ڪيو جڏهن چيڪ جو وقت 2 سيڪنڊن کان وڌي ويو. ان جي بدران، هن درخواست کي رد ڪري ڇڏيو. ايندڙ ڪميونيڪيشن ٻين ڏانهن موڪليا ويا آهن, ڪم pods.

نوٽ ڪريو ته ھاڻي اھو پوڊ آف لوڊ ڪيو ويو آھي، kubectl ان کي ٻيهر درخواستون ڏئي ٿو: GET جي درخواستن جا جواب وڌيڪ دير نه آھن.

مقابلي لاءِ، ھيٺ ڏنل آھي تبديل ٿيل app.js فائل:

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، ڊاڪٽر
بادل ايپليڪيشنن جي اچڻ کان اڳ، لاگز ايپليڪيشن جي صحت جي نگراني ۽ جانچ ڪرڻ جو بنيادي ذريعو هئا. تنهن هوندي به، ڪو به وسيلو نه هو ته ڪو به اصلاحي قدم کڻڻ لاء. لاگس اڄ به ڪارآمد آهن؛ انهن کي گڏ ڪرڻ جي ضرورت آهي ۽ ايمرجنسي حالتن جو تجزيو ڪرڻ ۽ فيصلا ڪرڻ لاءِ لاگ گڏ ڪرڻ واري نظام ڏانهن موڪليو وڃي. [اهو سڀ ڪجهه ڪلائوڊ ايپليڪيشنن کان سواءِ ٿي سگهي ٿو مانيٽ استعمال ڪندي، مثال طور، پر k8s سان اهو تمام آسان ٿي ويو آهي :) - ايڊيٽر جو نوٽ. ]

اڄ، سڌارن کي تقريبا حقيقي وقت ۾ ٺاهيو وڃي ٿو، تنهنڪري ايپليڪيشنن کي هاڻي ڪارو بڪس نه هجڻ گهرجي. نه، انهن کي آخري پوائنٽ ڏيکارڻ گهرجي جيڪي نگراني سسٽم کي سوال ڪرڻ ۽ عمل جي حالت بابت قيمتي ڊيٽا گڏ ڪرڻ جي اجازت ڏين ٿيون ته جيئن اهي فوري طور تي جواب ڏئي سگھن. ان کي پرفارمنس ٽيسٽ ڊيزائن پيٽرن سڏيو ويندو آهي، جيڪو اعليٰ مشاهدي جي اصول (HOP) جي پيروي ڪري ٿو.

Kubernetes پيش ڪري ٿو 2 قسم جا صحت جا چيڪ ڊفالٽ طور: ReadinessProbe ۽ livenessProbe. ٻئي هڪ ئي قسم جا چيڪ استعمال ڪندا آهن (HTTP GET درخواستون، TCP ڪميونيڪيشن ۽ ڪمانڊ ايگزيڪيوشن). انهن ۾ اختلاف آهي ته اهي پوڊ ۾ مسئلن جي جواب ۾ ڪهڙا فيصلا ڪن ٿا. livenessProbe ڪنٽينر کي ٻيهر شروع ڪري ٿو اميد ته غلطي ٻيهر نه ٿيندي، ۽ ReadinessProbe پوڊ کي ايندڙ ٽرئفڪ کان الڳ ڪري ٿو جيستائين مسئلي جو سبب حل نه ٿئي.

مناسب ايپليڪيشن ڊيزائن کي شامل ڪرڻ گهرجي ٻنهي قسمن جي چڪاس ۽ يقيني بڻائين ته اهي ڪافي ڊيٽا گڏ ڪن، خاص طور تي جڏهن هڪ استثنا اڇلايو وڃي. اهو پڻ ضروري API جي آخري پوائنٽن کي ڏيکارڻ گهرجي جيڪي نگراني سسٽم (Prometheus) کي اهم صحت جي ماپن سان گڏ مهيا ڪن ٿا.

جو ذريعو: www.habr.com