🥇کوبرنیٹس میں زندہ رہنے کی تحقیقات خطرناک ہو سکتی ہیں

نوٹ. ترجمہ: Zalando کے لیڈ انجینئر، Henning Jacobs، نے کبرنیٹس کے صارفین کے درمیان جاندار (اور تیاری) تحقیقات کے مقصد اور ان کے درست استعمال کو سمجھنے میں بار بار مسائل کا مشاہدہ کیا ہے۔ اس لیے، اس نے اپنے خیالات کو اس وسیع نوٹ میں جمع کیا، جو آخر کار K8s دستاویزات کا حصہ بن جائے گا۔

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

میرے ساتھی سینڈور نے حال ہی میں ٹویٹر پر سب سے زیادہ عام غلطیوں کا اشتراک کیا ہے جن کا سامنا اسے ہوتا ہے، بشمول وہ جو تیاری/جاندار تحقیقات کے استعمال سے متعلق ہیں:

غلط طریقے سے ترتیب دیا گیا ہے۔ livenessProbe زیادہ بوجھ والے حالات (سنو بال شٹ ڈاؤن + ممکنہ طور پر طویل کنٹینر/ایپلی کیشن شروع ہونے کا وقت) اور دیگر منفی نتائج جیسے انحصار میں کمی کا باعث بن سکتے ہیں۔ (بھی دیکھو میرا حالیہ مضمون K3s+ACME مجموعہ میں درخواستوں کی تعداد کو محدود کرنے کے بارے میں). یہ اور بھی برا ہوتا ہے جب لائیونس پروب کو ہیلتھ چیک کے ساتھ ملایا جاتا ہے، جو کہ ایک بیرونی ڈیٹا بیس ہے: ایک واحد DB ناکامی آپ کے تمام کنٹینرز کو دوبارہ شروع کردے گی۔!

عمومی پیغام "زندگی کی تحقیقات کا استعمال نہ کریں" اس معاملے میں یہ زیادہ مدد نہیں کرتا، تو آئیے دیکھتے ہیں کہ تیاری اور زندہ دلی کی جانچ کس کے لیے ہے۔

نوٹ: ذیل میں زیادہ تر ٹیسٹ اصل میں Zalando کے اندرونی ڈویلپر دستاویزات میں شامل تھے۔

تیاری اور زندہ دلی کی جانچ

Kubernetes نامی دو اہم میکانزم فراہم کرتا ہے۔ زندہ دلی کی تحقیقات اور تیاری کی تحقیقات. وہ وقتاً فوقتاً کچھ کارروائیاں انجام دیتے ہیں جیسے کہ HTTP درخواست بھیجنا، TCP کنکشن کھولنا، یا کنٹینر میں کمانڈ کو عمل میں لانا — اس بات کی تصدیق کرنے کے لیے کہ ایپلیکیشن توقع کے مطابق کام کر رہی ہے۔

Kubernetes استعمال کرتا ہے۔ تیاری کی تحقیقاتیہ سمجھنے کے لیے کہ کنٹینر ٹریفک کو قبول کرنے کے لیے کب تیار ہے۔ ایک پھلی کو استعمال کے لیے تیار سمجھا جاتا ہے اگر اس کے تمام کنٹینر تیار ہوں۔ اس طریقہ کار کا ایک استعمال یہ کنٹرول کرنا ہے کہ کون سی پوڈز کوبرنیٹس سروسز (اور خاص طور پر Ingress) کے لیے بیک اینڈ کے طور پر استعمال کی جاتی ہیں۔

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

اگر آپ کسی ایسی ایپلیکیشن اپ ڈیٹ کو تعینات کرنے کی کوشش کرتے ہیں جو لائیونس/تیاری جانچ میں ناکام ہو جاتی ہے، تو اس کا رول آؤٹ رک جائے گا کیونکہ کبرنیٹس سٹیٹس کا انتظار کر رہا ہے۔ Ready تمام پھلیوں سے.

مثال کے طور پر

راستے کی جانچ پڑتال کی تیاری کی تحقیقات کی ایک مثال یہ ہے۔ /health پہلے سے طے شدہ ترتیبات کے ساتھ HTTP کے ذریعے (وقفہ: 10 سیکنڈز، وقت ختم: 1 سیکنڈ، کامیابی کی حد: 1، ناکامی کی حد:3):

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

سفارشات

HTTP اینڈ پوائنٹ والی مائیکرو سروسز کے لیے (REST، وغیرہ) ہمیشہ تیاری کی تحقیقات کی وضاحت کریں۔، جو چیک کرتا ہے کہ آیا ایپلیکیشن (پوڈ) ٹریفک کو قبول کرنے کے لیے تیار ہے۔
تیاری کی تحقیقات کو یقینی بنائیں اصل ویب سرور پورٹ کی دستیابی کا احاطہ کرتا ہے۔:
- انتظامی مقاصد کے لیے بندرگاہوں کا استعمال، جسے "ایڈمن" یا "مینیجمنٹ" کہا جاتا ہے (مثال کے طور پر، 9090)، کے لیے readinessProbeاس بات کو یقینی بنائیں کہ اختتامی نقطہ صرف ٹھیک لوٹتا ہے اگر بنیادی HTTP پورٹ (جیسے 8080) ٹریفک کو قبول کرنے کے لیے تیار ہے*؛
  *میں Zalando میں کم از کم ایک کیس سے واقف ہوں جہاں ایسا نہیں ہوا، یعنی readinessProbe میں نے "منیجمنٹ" پورٹ کو چیک کیا، لیکن کیش لوڈ کرنے میں دشواریوں کی وجہ سے سرور نے خود کام کرنا شروع نہیں کیا۔
- ایک علیحدہ پورٹ کے ساتھ تیاری کی تحقیقات کو منسلک کرنے سے یہ حقیقت سامنے آسکتی ہے کہ مین پورٹ پر اوورلوڈ ہیلتھ چیک میں ظاہر نہیں ہوگا (یعنی سرور پر تھریڈ پول بھرا ہوا ہے، لیکن ہیلتھ چیک پھر بھی ظاہر کرتا ہے کہ سب کچھ ٹھیک ہے۔ )۔
اس کی تسلی کر لیں ریڈی نیس پروب ڈیٹا بیس کی ابتداء/ہجرت کو قابل بناتا ہے۔;
- اس کو حاصل کرنے کا سب سے آسان طریقہ یہ ہے کہ ابتدائی طور پر مکمل ہونے کے بعد ہی HTTP سرور سے رابطہ کیا جائے (مثال کے طور پر، سے ڈیٹا بیس کو منتقل کرنا فلائی وے اور اسی طرح.)؛ یعنی، ہیلتھ چیک اسٹیٹس کو تبدیل کرنے کے بجائے، صرف اس وقت تک ویب سرور شروع نہ کریں جب تک کہ ڈیٹا بیس کی منتقلی مکمل نہ ہوجائے*۔
  * آپ پوڈ کے باہر init کنٹینرز سے ڈیٹا بیس کی منتقلی بھی چلا سکتے ہیں۔ میں اب بھی خود ساختہ ایپلی کیشنز کا پرستار ہوں، یعنی وہ جن میں ایپلی کیشن کنٹینر یہ جانتا ہے کہ ڈیٹا بیس کو بیرونی کوآرڈینیشن کے بغیر مطلوبہ حالت میں کیسے لانا ہے۔
استعمال کریں httpGet عام ہیلتھ چیک اینڈ پوائنٹس کے ذریعے تیاری کی جانچ کے لیے (مثال کے طور پر، /health).
ڈیفالٹ چیک پیرامیٹرز کو سمجھیں۔ (interval: 10s, timeout: 1s, successThreshold: 1, failureThreshold: 3):
- پہلے سے طے شدہ اختیارات کا مطلب ہے کہ پوڈ بن جائے گا۔ تیار نہیں تقریباً 30 سیکنڈ کے بعد (3 ناکامی سے متعلق چیکس)۔
اگر ٹکنالوجی اسٹیک (جیسے جاوا/اسپرنگ) صحت اور میٹرکس کے انتظام کو باقاعدہ ٹریفک سے الگ کرنے کی اجازت دیتا ہے تو "ایڈمن" یا "منیجمنٹ" کے لیے علیحدہ پورٹ استعمال کریں:
- لیکن نقطہ 2 کے بارے میں مت بھولنا.
اگر ضروری ہو تو، ریڈی نیس پروب کا استعمال کیشے کو گرم کرنے/لوڈ کرنے اور 503 اسٹیٹس کوڈ واپس کرنے کے لیے کیا جا سکتا ہے جب تک کہ کنٹینر گرم نہ ہو جائے:
- میں یہ بھی تجویز کرتا ہوں کہ آپ نیا چیک پڑھیں startupProbe, ورژن 1.16 میں شائع ہوا۔ (ہم نے اس کے بارے میں روسی میں لکھا ہے۔ یہاں - تقریبا. ترجمہ).

Caveats

بیرونی انحصار پر بھروسہ نہ کریں۔ (جیسے ڈیٹا گودام) جب تیاری / زندہ دلی کے ٹیسٹ چلا رہے ہیں - یہ جھرن کی ناکامیوں کا باعث بن سکتا ہے:
- مثال کے طور پر، آئیے ایک پوسٹگریس ڈیٹا بیس پر منحصر 10 پوڈز کے ساتھ ایک اسٹیٹفول REST سروس لیتے ہیں: جب چیک DB سے ورکنگ کنکشن پر منحصر ہوتا ہے، تو تمام 10 پوڈز ناکام ہو سکتے ہیں اگر نیٹ ورک/DB کی طرف تاخیر ہوتی ہے - عام طور پر یہ سب کچھ اس سے بھی بدتر ہوتا ہے
- براہ کرم نوٹ کریں کہ اسپرنگ ڈیٹا ڈیٹا بیس کنکشن کو بطور ڈیفالٹ چیک کرتا ہے*؛
  * یہ Spring Data Redis کا ڈیفالٹ رویہ ہے (کم از کم یہ آخری بار تھا جب میں نے چیک کیا تھا)، جس کی وجہ سے "تباہ کن" ناکامی ہوئی: جب Redis مختصر وقت کے لیے دستیاب نہیں تھا، تمام پوڈز "کریش" ہو گئے۔
- اس معنی میں "بیرونی" کا مطلب اسی ایپلی کیشن کے دوسرے پوڈز بھی ہو سکتے ہیں، یعنی مثالی طور پر چیک کا انحصار اسی کلسٹر کے دوسرے پوڈز کی حالت پر نہیں ہونا چاہیے تاکہ جھڑپوں کے کریشوں کو روکا جا سکے۔
  - تقسیم شدہ حالت کے ساتھ ایپلی کیشنز کے لیے نتائج مختلف ہو سکتے ہیں (مثال کے طور پر، پوڈز میں ان میموری کیشنگ)۔
جاندار تحقیقات کا استعمال نہ کریں۔ pods کے لیے (استثنیات ایسی صورتیں ہیں جب وہ واقعی ضروری ہوں اور آپ ان کے استعمال کی تفصیلات اور نتائج سے پوری طرح واقف ہوں):
- لائیونس پروب لٹکے ہوئے کنٹینرز کو بحال کرنے میں مدد کر سکتی ہے، لیکن چونکہ آپ کو اپنی درخواست پر مکمل کنٹرول ہے، اس لیے معلق عمل اور تعطل جیسی چیزیں مثالی طور پر نہیں ہونی چاہئیں: بہترین متبادل یہ ہے کہ جان بوجھ کر ایپلیکیشن کو کریش کیا جائے اور اسے سابقہ مستحکم حالت میں واپس لایا جائے۔
- ایک ناکام لائیونس پروب کنٹینر کو دوبارہ شروع کرنے کا سبب بنے گی، اس طرح ممکنہ طور پر لوڈنگ سے متعلق غلطیوں کے نتائج میں اضافہ ہو جائے گا: کنٹینر کو دوبارہ شروع کرنے کے نتیجے میں ڈاؤن ٹائم ہو گا (کم از کم ایپلیکیشن شروع ہونے کی مدت کے لیے، 30-XNUMX سیکنڈز کا کہنا ہے)، نئی خرابیاں پیدا ہوں گی۔ ، دوسرے کنٹینرز پر بوجھ بڑھانا اور ان کی ناکامی کا امکان بڑھانا، وغیرہ۔
- بیرونی انحصار کے ساتھ مل کر لائیونس چیکس کا سب سے برا امتزاج ہے، جس سے جھڑپوں کی ناکامیوں کا خطرہ ہے: ڈیٹا بیس کی طرف تھوڑی تاخیر آپ کے تمام کنٹینرز کو دوبارہ شروع کرنے کا باعث بنے گی۔
زندہ دلی اور تیاری کی جانچ کے پیرامیٹرز مختلف ہونا ضروری ہے:
- آپ اسی صحت کی جانچ کے ساتھ لائیونس پروب کا استعمال کر سکتے ہیں، لیکن جوابی حد سے زیادہ (failureThreshold)، مثال کے طور پر، حیثیت تفویض کریں۔ تیار نہیں 3 کوششوں کے بعد اور غور کریں کہ لائیونس پروب 10 کوششوں کے بعد ناکام ہو گئی ہے۔
exec چیک استعمال نہ کریں۔، چونکہ وہ معلوم مسائل سے وابستہ ہیں جو زومبی عمل کی ظاہری شکل کا باعث بنتے ہیں:
- تفصیلات: دیکھیں ڈیٹا ڈاگ ماہرین کی طرف سے پریزنٹیشن.

خلاصہ

اس بات کا تعین کرنے کے لیے تیاری کی تحقیقات کا استعمال کریں کہ جب کوئی پوڈ ٹریفک حاصل کرنے کے لیے تیار ہے۔
لائیونس پروب صرف اس وقت استعمال کریں جب ان کی واقعی ضرورت ہو۔
تیاری/جاندار تحقیقات کا غلط استعمال دستیابی میں کمی اور جھرنے کی ناکامی کا باعث بن سکتا ہے۔

موضوع پر اضافی مواد۔

Kubernetes docs: Liveness اور Readiness Probes کو ترتیب دیں۔;
Kubernetes Liveness اور تیاری کی تحقیقات پر نظرثانی کی گئی: اپنے آپ کو دوسرے پاؤں میں گولی مارنے سے کیسے بچیں;
NRE لیبز کی بندش پوسٹ مارٹم (وہ livenessProbe کے بارے میں بھی بات کرتا ہے)۔

1-2019-09 سے اپ ڈیٹ نمبر 29

ڈیٹا بیس کی منتقلی کے لیے init کنٹینرز کے بارے میں: فوٹ نوٹ شامل کیا گیا۔

EJ نے مجھے یاد دلایا PDB کے بارے میں: زندگی کی جانچ پڑتال کے ساتھ مسائل میں سے ایک پھلی کے درمیان ہم آہنگی کی کمی ہے۔ Kubernetes کے پاس ہے۔ پوڈ ڈسٹرکشن بجٹ (PDB) بیک وقت ناکامیوں کی تعداد کو محدود کرنے کے لیے جو ایک درخواست کا تجربہ کر سکتی ہے، تاہم چیک PDB کو مدنظر نہیں رکھتے۔ مثالی طور پر، ہم K8s کو کہہ سکتے ہیں کہ "اگر اس کا ٹیسٹ ناکام ہو جاتا ہے تو ایک پوڈ کو دوبارہ شروع کریں، لیکن چیزوں کو مزید خراب کرنے سے بچنے کے لیے ان سب کو دوبارہ شروع نہ کریں۔"

برائن نے اسے بالکل ٹھیک کیا۔: "جب آپ کو معلوم ہو کہ بالکل کیا ہے تو لائیونس پروبنگ کا استعمال کریں۔ سب سے بہتر کام ایپلی کیشن کو ختم کرنا ہے۔"(دوبارہ، بہہ نہ جانا)۔

2-2019-09 سے اپ ڈیٹ نمبر 29

استعمال سے پہلے دستاویزات کو پڑھنے کے بارے میں: میں نے متعلقہ درخواست بنائی (خصوصیت کی درخواست) زندہ رہنے کی تحقیقات کے بارے میں دستاویزات شامل کرنے کے لیے۔

مترجم سے PS

ہمارے بلاگ پر بھی پڑھیں:

ماخذ: www.habr.com

Kubernetes میں زندہ دلی کی تحقیقات خطرناک ہو سکتی ہیں۔