کبرنیٹس کنٹینرز کے لیے بہترین پریکٹسز: ہیلتھ چیکس

TL؛ ڈاکٹر

• کنٹینرز اور مائیکرو سروسز کے اعلیٰ مشاہدے کو حاصل کرنے کے لیے لاگ اور پرائمری میٹرکس کافی نہیں ہیں۔
• تیزی سے بحالی اور لچک میں اضافہ کے لیے، ایپلی کیشنز کو ہائی آبزرویبلٹی پرنسپل (HOP) کا اطلاق کرنا چاہیے۔
• درخواست کی سطح پر، NOP کی ضرورت ہوتی ہے: مناسب لاگنگ، قریبی نگرانی، سنجیدگی کی جانچ، اور کارکردگی/ٹرانزیشن ٹریسنگ۔
• چیک کو NOR کے عنصر کے طور پر استعمال کریں۔ تیاری کی جانچ и livenessProbe کوبرنیٹس۔

ہیلتھ چیک ٹیمپلیٹ کیا ہے؟

مشن کے لیے اہم اور انتہائی دستیاب ایپلی کیشن کو ڈیزائن کرتے وقت، غلطی کی رواداری جیسے پہلو کے بارے میں سوچنا بہت ضروری ہے۔ اگر کوئی درخواست ناکامی سے جلد ٹھیک ہو جائے تو اسے غلطی برداشت کرنے والا سمجھا جاتا ہے۔ ایک عام کلاؤڈ ایپلی کیشن مائیکرو سروسز فن تعمیر کا استعمال کرتی ہے - جہاں ہر جزو کو الگ کنٹینر میں رکھا جاتا ہے۔ اور یہ یقینی بنانے کے لیے کہ k8s پر ایپلیکیشن بہت زیادہ دستیاب ہے جب آپ ایک کلسٹر ڈیزائن کرتے ہیں، آپ کو کچھ نمونوں کی پیروی کرنے کی ضرورت ہے۔ ان میں ہیلتھ چیک ٹیمپلیٹ بھی شامل ہے۔ یہ اس بات کی وضاحت کرتا ہے کہ ایپلیکیشن کس طرح k8s کو بتاتی ہے کہ یہ صحت مند ہے۔ یہ نہ صرف اس بارے میں معلومات ہے کہ آیا پوڈ چل رہا ہے، بلکہ یہ بھی ہے کہ یہ درخواستوں کو کیسے وصول کرتا ہے اور ان کا جواب دیتا ہے۔ کوبرنیٹس پوڈ کی صحت کے بارے میں جتنا زیادہ جانتا ہے، یہ ٹریفک روٹنگ اور لوڈ بیلنسنگ کے بارے میں اتنے ہی بہتر فیصلے کرتا ہے۔ اس طرح، اعلی مشاہداتی اصول درخواست کو بروقت درخواستوں کا جواب دینے کی اجازت دیتا ہے۔

اعلی مشاہداتی اصول (HOP)

اعلی مشاہدے کا اصول ان میں سے ایک ہے۔ کنٹینرائزڈ ایپلی کیشنز کو ڈیزائن کرنے کے اصول. مائیکرو سروسز آرکیٹیکچر میں، سروسز کو اس بات کی پرواہ نہیں ہوتی کہ ان کی درخواست پر کیسے عمل ہوتا ہے (اور بجا طور پر)، لیکن اہم بات یہ ہے کہ وہ وصول کرنے والی خدمات سے کیسے ردعمل حاصل کرتے ہیں۔ مثال کے طور پر، کسی صارف کی توثیق کرنے کے لیے، ایک کنٹینر دوسرے کو HTTP درخواست بھیجتا ہے، ایک مخصوص فارمیٹ میں جواب کی توقع کرتے ہوئے - بس۔ PythonJS درخواست پر کارروائی بھی کر سکتا ہے، اور Python Flask جواب دے سکتا ہے۔ کنٹینرز بلیک باکسز کی طرح ہوتے ہیں جن میں ایک دوسرے سے پوشیدہ مواد ہوتا ہے۔ تاہم، NOP اصول کے مطابق ہر سروس کو متعدد API اینڈ پوائنٹس کو ظاہر کرنے کی ضرورت ہوتی ہے جو اس بات کی نشاندہی کرتی ہے کہ یہ کتنی صحت مند ہے، نیز اس کی تیاری اور غلطی کو برداشت کرنے کی حیثیت۔ روٹنگ اور لوڈ بیلنسنگ کے اگلے مراحل کے بارے میں سوچنے کے لیے Kubernetes ان اشاریوں کی درخواست کرتا ہے۔

ایک اچھی طرح سے ڈیزائن کردہ کلاؤڈ ایپلیکیشن معیاری I/O اسٹریمز STDERR اور STDOUT کا استعمال کرتے ہوئے اپنے اہم واقعات کو لاگ کرتی ہے۔ اس کے بعد ایک معاون سروس آتی ہے، مثال کے طور پر فائل بیٹ، لاگ اسٹیش یا روانی، ایک مرکزی نگرانی کے نظام (مثال کے طور پر پرومیتھیس) اور لاگ کلیکشن سسٹم (ELK سافٹ ویئر سوٹ) کو لاگز فراہم کرتی ہے۔ نیچے دیا گیا خاکہ دکھاتا ہے کہ کس طرح کلاؤڈ ایپلیکیشن ہیلتھ ٹیسٹ پیٹرن اور اعلی مشاہداتی اصول کے مطابق کام کرتی ہے۔

Kubernetes میں ہیلتھ چیک پیٹرن کا اطلاق کیسے کریں؟

باکس سے باہر، k8s کنٹرولرز میں سے ایک کا استعمال کرتے ہوئے پوڈز کی حالت کی نگرانی کرتا ہے (تعینات۔, ریپلی سیٹس, ڈیمن سیٹس, اسٹیٹفول سیٹس وغیرہ وغیرہ)۔ یہ دریافت کرنے کے بعد کہ پوڈ کسی وجہ سے گر گیا ہے، کنٹرولر اسے دوبارہ شروع کرنے یا کسی دوسرے نوڈ میں منتقل کرنے کی کوشش کرتا ہے۔ تاہم، ایک پوڈ یہ اطلاع دے سکتا ہے کہ یہ چل رہا ہے، لیکن یہ خود کام نہیں کر رہا ہے۔ آئیے ایک مثال دیتے ہیں: آپ کی ایپلی کیشن اپاچی کو ویب سرور کے طور پر استعمال کرتی ہے، آپ نے کلسٹر کے کئی پوڈز پر جزو انسٹال کیا ہے۔ چونکہ لائبریری کو غلط طریقے سے ترتیب دیا گیا تھا، اس لیے ایپلیکیشن کی تمام درخواستوں کا جواب کوڈ 500 (اندرونی سرور کی خرابی) کے ساتھ ملتا ہے۔ ڈیلیوری کی جانچ کرتے وقت، پوڈز کی حالت چیک کرنے سے ایک کامیاب نتیجہ ملتا ہے، لیکن گاہک مختلف سوچتے ہیں۔ ہم اس ناپسندیدہ صورتحال کو اس طرح بیان کریں گے:

ہماری مثال میں، k8s کرتا ہے۔ فعالیت کی جانچ. اس قسم کی تصدیق میں، کیوبلیٹ کنٹینر میں عمل کی حالت کو مسلسل چیک کرتا ہے۔ ایک بار جب وہ سمجھتا ہے کہ عمل رک گیا ہے، تو وہ اسے دوبارہ شروع کر دے گا۔ اگر صرف ایپلی کیشن کو دوبارہ شروع کرنے سے غلطی کو حل کیا جا سکتا ہے، اور پروگرام کو کسی بھی خرابی پر بند کرنے کے لیے ڈیزائن کیا گیا ہے، تو آپ کو NOP اور ہیلتھ ٹیسٹ پیٹرن پر عمل کرنے کے لیے صرف ایک عمل کی صحت کی جانچ کی ضرورت ہے۔ صرف افسوس کی بات یہ ہے کہ دوبارہ شروع کرنے سے تمام خرابیاں ختم نہیں ہوتی ہیں۔ اس صورت میں، k8s پوڈ کے ساتھ مسائل کی نشاندہی کرنے کے 2 گہرے طریقے پیش کرتا ہے: livenessProbe и تیاری کی جانچ.

LivenessProbe

کے دوران livenessProbe کیوبلیٹ 3 قسم کے چیک کرتا ہے: نہ صرف یہ طے کرتا ہے کہ پوڈ چل رہا ہے، بلکہ یہ بھی کہ آیا یہ درخواستوں کو وصول کرنے اور مناسب طریقے سے جواب دینے کے لیے تیار ہے:

• پوڈ پر ایک HTTP درخواست ترتیب دیں۔ جواب میں 200 سے 399 کی رینج میں ایک HTTP رسپانس کوڈ ہونا ضروری ہے۔ اس طرح، کوڈ 5xx اور 4xx اشارہ کرتے ہیں کہ پوڈ کو مسائل درپیش ہیں، حالانکہ عمل چل رہا ہے۔
• نان ایچ ٹی ٹی پی سروسز (مثال کے طور پر، پوسٹ فکس میل سرور) کے ساتھ پوڈز کی جانچ کرنے کے لیے، آپ کو ایک TCP کنکشن قائم کرنے کی ضرورت ہے۔
• پوڈ (اندرونی طور پر) کے لیے صوابدیدی کمانڈ پر عمل کریں۔ اگر کمانڈ مکمل کرنے کا کوڈ 0 ہے تو چیک کو کامیاب سمجھا جاتا ہے۔

یہ کیسے کام کرتا ہے اس کی ایک مثال۔ اگلی پوڈ ڈیفینیشن میں ایک نوڈ جے ایس ایپلی کیشن ہے جو 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 جو استعمال کیے گئے تھے:

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

ڈاکر فائل

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

یہ نوٹ کرنا ضروری ہے: livenessProbe صرف کنٹینر کو دوبارہ شروع کرے گا اگر یہ ناکام ہو جائے۔ اگر دوبارہ شروع کرنے سے اس خرابی کو درست نہیں ہوتا ہے جو کنٹینر کو چلنے سے روک رہی ہے، تو کیوبلیٹ مسئلہ کو درست کرنے کے لیے کارروائی نہیں کر سکے گا۔

تیاری کی جانچ

ReadinessProbe اسی طرح کام کرتا ہے LivenessProbes (GET درخواستیں، TCP کمیونیکیشنز اور کمانڈ پر عمل درآمد)، سوائے خرابیوں کا سراغ لگانے کے اقدامات کے۔ وہ کنٹینر جس میں ناکامی کا پتہ چلا ہے اسے دوبارہ شروع نہیں کیا جاتا ہے، بلکہ آنے والی ٹریفک سے الگ تھلگ کیا جاتا ہے۔ تصور کریں کہ کنٹینرز میں سے ایک بہت زیادہ حساب کتاب کر رہا ہے یا بھاری بوجھ کے نیچے ہے، جس کی وجہ سے ردعمل کا وقت بڑھ رہا ہے۔ LivenessProbe کے معاملے میں، جواب کی دستیابی کی جانچ شروع کی جاتی ہے (ٹائم آؤٹ سیکنڈز چیک پیرامیٹر کے ذریعے)، جس کے بعد کیوبلیٹ کنٹینر کو دوبارہ شروع کرتا ہے۔ شروع ہونے پر، کنٹینر وسائل سے متعلق کام انجام دینا شروع کر دیتا ہے اور دوبارہ شروع ہو جاتا ہے۔ یہ ان ایپلی کیشنز کے لیے اہم ہو سکتا ہے جن کو رسپانس کی رفتار کی ضرورت ہوتی ہے۔ مثال کے طور پر، سڑک پر ایک کار سرور سے جواب کا انتظار کر رہی ہے، جواب میں تاخیر ہوتی ہے - اور کار حادثے کا شکار ہو جاتی ہے۔

آئیے ایک ریڈینس پروب تعریف لکھیں جو 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 سیکنڈ سے تجاوز کر گیا تو kubectl نے پوڈ کو دوبارہ شروع نہیں کیا۔ اس کے بجائے اس نے درخواست منسوخ کر دی۔ آنے والی کمیونیکیشنز کو دوسرے، ورکنگ پوڈز پر بھیج دیا جاتا ہے۔

نوٹ کریں کہ اب پوڈ آف لوڈ ہو چکا ہے، 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؛ ڈاکٹر
کلاؤڈ ایپلی کیشنز کی آمد سے پہلے، لاگز ایپلی کیشن کی صحت کی نگرانی اور جانچ کا بنیادی ذریعہ تھے۔ تاہم، کوئی اصلاحی اقدام کرنے کا کوئی ذریعہ نہیں تھا۔ لاگز آج بھی کارآمد ہیں؛ ہنگامی حالات کا تجزیہ کرنے اور فیصلے کرنے کے لیے انہیں جمع کرنے اور لاگ جمع کرنے کے نظام کو بھیجنے کی ضرورت ہے۔ [یہ سب کچھ کلاؤڈ ایپلی کیشنز کے بغیر monit کا استعمال کرتے ہوئے کیا جا سکتا ہے، مثال کے طور پر، لیکن k8s کے ساتھ یہ بہت آسان ہو گیا :) - ایڈیٹر کا نوٹ۔ ]

آج، تقریباً حقیقی وقت میں تصحیحیں کی جانی ہیں، اس لیے درخواستوں کو اب بلیک باکس نہیں ہونا چاہیے۔ نہیں، انہیں اختتامی نکات دکھانا چاہیے جو نگرانی کے نظام کو عمل کی حالت کے بارے میں قیمتی ڈیٹا کو استفسار کرنے اور جمع کرنے کی اجازت دیتے ہیں تاکہ اگر ضروری ہو تو وہ فوری طور پر جواب دے سکیں۔ اسے پرفارمنس ٹیسٹ ڈیزائن پیٹرن کہا جاتا ہے، جو ہائی آبزرویبلٹی پرنسپل (HOP) کی پیروی کرتا ہے۔

Kubernetes 2 قسم کے ہیلتھ چیکس بطور ڈیفالٹ پیش کرتا ہے: ReadinessProbe اور livenessProbe۔ دونوں ایک ہی قسم کے چیک استعمال کرتے ہیں (HTTP GET درخواستیں، TCP کمیونیکیشنز اور کمانڈ ایگزیکیوشن)۔ وہ اس بات میں اختلاف رکھتے ہیں کہ وہ پھلی کے مسائل کے جواب میں کیا فیصلے کرتے ہیں۔ livenessProbe کنٹینر کو اس امید پر دوبارہ شروع کرتا ہے کہ غلطی دوبارہ نہیں ہوگی، اور ریڈینس پروب پوڈ کو آنے والی ٹریفک سے اس وقت تک الگ کر دیتا ہے جب تک کہ مسئلہ کی وجہ حل نہ ہو جائے۔

مناسب ایپلیکیشن ڈیزائن میں دونوں قسم کی جانچ شامل ہونی چاہیے اور اس بات کو یقینی بنانا چاہیے کہ وہ کافی ڈیٹا اکٹھا کریں، خاص طور پر جب کوئی استثناء دیا جائے۔ اسے ضروری API اینڈ پوائنٹس بھی دکھانا چاہیے جو مانیٹرنگ سسٹم (Prometheus) کو صحت کے اہم میٹرکس فراہم کرتے ہیں۔

ماخذ: www.habr.com