ڈاؤن ٹائم کے بغیر کبرنیٹس کلسٹر کو اپ گریڈ کرنا

اپنے Kubernetes کلسٹر کے لیے اپ گریڈ کا عمل

کسی وقت، کبرنیٹس کلسٹر کا استعمال کرتے وقت، چلنے والے نوڈس کو اپ ڈیٹ کرنے کی ضرورت ہوتی ہے۔ اس میں پیکیج اپ ڈیٹس، کرنل اپ ڈیٹس، یا نئی ورچوئل مشین امیجز کی تعیناتی شامل ہوسکتی ہے۔ Kubernetes کی اصطلاح میں اسے کہتے ہیں۔ "رضاکارانہ رکاوٹ".

یہ پوسٹ 4 پوسٹ سیریز کا حصہ ہے:

1. یہ پوسٹ۔
2. Kubernetes کلسٹر میں پھلیوں کا درست بند کرنا
3. پوڈ کے حذف ہونے پر اس کی تکمیل میں تاخیر
4. PodDisruptionBudgets کا استعمال کرتے ہوئے Kubernetes کلسٹر ڈاؤن ٹائم سے کیسے بچیں۔

(تقریباً مستقبل قریب میں سیریز کے باقی مضامین کے ترجمے کی توقع ہے)

اس مضمون میں، ہم ان تمام ٹولز کی وضاحت کریں گے جو آپ کے کلسٹر میں چلنے والے نوڈس کے لیے صفر ڈاؤن ٹائم حاصل کرنے کے لیے Kubernetes فراہم کرتا ہے۔

مسئلہ کی وضاحت

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

اپنا سفر شروع کرنے کے لیے، آئیے ایک ٹھوس مثال لیتے ہیں۔ ہم کہتے ہیں کہ ہمارے پاس دو نوڈس کا ایک Kubernetes کلسٹر ہے، جس میں ایک ایپلیکیشن چل رہی ہے جس کے پیچھے دو پوڈ ہیں۔ Service:

آئیے اپنے دو Kubernetes کلسٹر نوڈس پر چلنے والے Nginx اور Service کے ساتھ دو pods کے ساتھ شروع کریں۔

ہم اپنے کلسٹر میں دو ورکر نوڈس کے کرنل ورژن کو اپ ڈیٹ کرنا چاہتے ہیں۔ ہم یہ کیسے کرتے ہیں؟ ایک آسان حل یہ ہوگا کہ نئے نوڈس کو اپ ڈیٹ کردہ کنفیگریشن کے ساتھ بوٹ کیا جائے اور پھر نئے نوڈس کو شروع کرتے ہوئے پرانے نوڈس کو بند کردیا جائے۔ اگرچہ یہ کام کرے گا، اس نقطہ نظر کے ساتھ کچھ مسائل ہوں گے:

• جب آپ پرانے نوڈس کو بند کردیں گے تو ان پر چلنے والے پوڈز بھی بند ہوجائیں گے۔ کیا ہوگا اگر خوبصورت بند کے لیے پھلیوں کو صاف کرنے کی ضرورت ہے؟ آپ جو ورچوئلائزیشن سسٹم استعمال کر رہے ہیں ہو سکتا ہے صفائی کے عمل کے مکمل ہونے کا انتظار نہ کرے۔
• کیا ہوگا اگر آپ ایک ہی وقت میں تمام نوڈس بند کردیں؟ جب پوڈز نئے نوڈس میں منتقل ہوتے ہیں تو آپ کو مناسب وقت ملے گا۔

ہمیں پرانے نوڈس سے پوڈز کو خوبصورتی سے منتقل کرنے کے لیے ایک طریقہ کی ضرورت ہے اور اس بات کو یقینی بناتے ہوئے کہ جب ہم نوڈ میں تبدیلیاں کرتے ہیں تو ہمارا کوئی بھی کارکن عمل نہیں چل رہا ہے۔ یا جب ہم کلسٹر کی مکمل تبدیلی کرتے ہیں، جیسا کہ مثال کے طور پر (یعنی ہم VM امیجز کو تبدیل کرتے ہیں)، ہم چل رہی ایپلی کیشنز کو پرانے نوڈس سے نئے میں منتقل کرنا چاہتے ہیں۔ دونوں صورتوں میں، ہم نئے پوڈز کو پرانے نوڈس پر شیڈول ہونے سے روکنا چاہتے ہیں، اور پھر ان سے چلنے والے تمام پوڈز کو بے دخل کرنا چاہتے ہیں۔ ان مقاصد کو حاصل کرنے کے لیے ہم کمانڈ استعمال کر سکتے ہیں۔ kubectl drain.

نوڈ سے تمام پوڈس کو دوبارہ تقسیم کرنا

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

اگرچہ kubectl drain پوڈز کو بے دخل کرنے کا بہت اچھا کام کرے گا، دو دیگر عوامل ہیں جو ڈرین آپریشن کو ناکام بنا سکتے ہیں:

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

ڈاؤن ٹائم سے بچنا

رضاکارانہ رکاوٹ سے ڈاؤن ٹائم کو کم کرنے کے لیے، جیسے کہ نوڈ پر ڈرین آپریشن سے، Kubernetes ناکامی سے نمٹنے کے درج ذیل اختیارات فراہم کرتا ہے:

• مکرم خاتمہ
• لائف سائیکل ہکس
• PodDisruption Budgets

باقی سیریز میں، ہم Kubernetes کی ان خصوصیات کو منتقل کرنے والے پوڈز کے اثرات کو کم کرنے کے لیے استعمال کریں گے۔ مرکزی خیال کی پیروی کو آسان بنانے کے لیے، ہم مندرجہ ذیل وسائل کی ترتیب کے ساتھ اوپر دی گئی اپنی مثال استعمال کریں گے۔

---
apiVersion: apps/v1
kind: Deployment
metadata:
 name: nginx-deployment
 labels:
   app: nginx
spec:
 replicas: 2
 selector:
   matchLabels:
     app: nginx
 template:
   metadata:
     labels:
       app: nginx
   spec:
     containers:
     - name: nginx
       image: nginx:1.15
       ports:
       - containerPort: 80
---
kind: Service
apiVersion: v1
metadata:
 name: nginx-service
spec:
 selector:
   app: nginx
 ports:
 - protocol: TCP
   targetPort: 80
   port: 80

یہ ترتیب ایک کم سے کم مثال ہے۔ Deployment، جو کلسٹر میں nginx pods کا انتظام کرتا ہے۔ اس کے علاوہ، ترتیب وسائل کی وضاحت کرتی ہے۔ Service، جسے کلسٹر میں nginx pods تک رسائی کے لیے استعمال کیا جا سکتا ہے۔

پورے دور میں، ہم اس کنفیگریشن کو بار بار پھیلائیں گے تاکہ اس میں آخر کار وہ تمام صلاحیتیں شامل ہوں جو Kubernetes کی جانب سے ڈاؤن ٹائم کو کم کرنے کے لیے فراہم کی جاتی ہے۔

AWS اور اس سے آگے صفر ڈاؤن ٹائم کے لیے Kubernetes کلسٹر اپ ڈیٹس کے مکمل طور پر نافذ اور آزمائشی ورژن کے لیے، ملاحظہ کریں Gruntwork.io.

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

• زیرو ڈاؤن ٹائم تعیناتی اور ڈیٹا بیس
• کبرنیٹس: سسٹم ریسورس مینجمنٹ کو ترتیب دینا اتنا ضروری کیوں ہے؟
• ٹیکٹن پائپ لائن - Kubernetes - مقامی پائپ لائنز
• Nginx کے لیے متحرک ماڈیولز بنانا
• Hashicorp قونصل کے Kubernetes اتھارٹی کا تعارف
• ClickHouse سے بغیر اجازت کے ClickHouse کی اجازت کے ساتھ ہجرت سے کیا ہوا؟

ماخذ: www.habr.com