🥇K8S ملٹی کلسٹر سفر

ارے حبر!

ہم Exness پلیٹ فارم ٹیم کی نمائندگی کرتے ہیں۔ ہمارے ساتھیوں نے پہلے اس بارے میں ایک مضمون لکھا تھا۔ k8s کے لیے پروڈکشن کے لیے تیار تصاویرآج ہم Kubernetes پر منتقلی کی خدمات کا اپنا تجربہ شیئر کرنا چاہتے ہیں۔

شروع کرنے کے لیے، ہم آپ کو کچھ نمبر پیش کرتے ہیں تاکہ یہ بہتر طور پر سمجھ سکیں کہ ہم کس بات پر بات کریں گے:

ہمارا ڈیولپمنٹ ڈیپارٹمنٹ 100 سے زیادہ لوگوں پر مشتمل ہے، بشمول 10 سے زیادہ مختلف ٹیمیں جن میں خود کفیل QA، DevOps، اور Scrum پروسیس ہیں۔ ہمارے ترقیاتی اسٹیک میں Python، PHP، C++، Java، اور Golang شامل ہیں۔
ٹیسٹ اور پیداوار کے ماحول میں ہر ایک میں تقریباً 2000 کنٹینرز ہوتے ہیں۔ ان کا انتظام رینچر v1.6 کے ذریعہ اس کے اپنے ورچوئلائزیشن پلیٹ فارم پر اور VMware کے تحت کیا جاتا ہے۔

پریرتا

جیسا کہ کہاوت ہے، کچھ بھی ہمیشہ کے لیے نہیں رہتا، اور رینچر نے کچھ عرصہ قبل ورژن 1.6 کے لیے حمایت ختم کرنے کا اعلان کیا تھا۔ ہاں، تین سال سے زیادہ عرصے میں، ہم نے سیکھا ہے کہ اسے کیسے تیار کیا جائے اور پیدا ہونے والے کسی بھی مسائل کو حل کیا جائے، لیکن ہمیں تیزی سے ایسے مسائل کا سامنا کرنا پڑا ہے جو کبھی حل نہیں ہوں گے۔ Rancher 1.6 میں اجازت کا ایک سخت نظام بھی ہے، جہاں آپ یا تو تقریباً سب کچھ کر سکتے ہیں یا کچھ بھی نہیں۔

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

ہم IaC معیارات کی پیروی کرنا چاہتے تھے اور، اگر ضروری ہو تو، کسی بھی جغرافیائی مقام پر اور وینڈر لاک کے بغیر، تیزی سے صلاحیت حاصل کرنا چاہتے تھے، اور ساتھ ہی اسے فوری طور پر ترک کرنے کے قابل بھی تھے۔

پہلا قدم

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

بلاشبہ، ہمارے ذہن میں سب سے پہلی چیز Kubernetes تھی، لیکن ہم نے چیزوں میں جلدی نہیں کی اور اس بات کو یقینی بنانے کے لیے کچھ تحقیق کی کہ یہ صحیح انتخاب ہے۔ ہم نے صرف اوپن سورس حل کا جائزہ لیا، اور ایک غیر منصفانہ جنگ میں، Kubernetes واضح فاتح کے طور پر ابھرا۔

اگلا سوال آیا کہ کلسٹرز بنانے کے لیے ایک ٹول کا انتخاب کیا جائے۔ ہم نے سب سے زیادہ مقبول حلوں کا موازنہ کیا: kops، kubespray، اور kubeadm.

ایک آغاز کے لیے، کیوبیڈم بہت پیچیدہ لگ رہا تھا، جیسا کہ وہیل کو دوبارہ ایجاد کرنا تھا، اور کوپس میں لچک کی کمی تھی۔

اور فاتح تھا:

ہم نے اپنے اپنے ورچوئلائزیشن اور AWS کے ساتھ تجربہ کرنا شروع کیا، اپنے پچھلے وسائل کے انتظام کے پیٹرن کی طرح کچھ دوبارہ بنانے کی کوشش کی، جہاں ہر کوئی ایک ہی "کلسٹر" کا استعمال کرتا ہے۔ اور اب ہمارے پاس اپنا پہلا کلسٹر ہے، 10 چھوٹے۔ ورچوئل مشینیں، جن میں سے کچھ AWS میں واقع ہیں۔ ہم نے ٹیموں کو وہاں منتقل کرنے کی کوشش شروع کی، اور ایسا لگتا تھا کہ سب کچھ ٹھیک ہو رہا ہے، اور کہانی ختم ہو سکتی تھی، لیکن…

پہلے مسائل

جوابی، kubespray کی بنیاد، IaC کے لیے صحیح ٹول نہیں ہے: نوڈس کو آن لائن اور آف لائن لاتے وقت کچھ مسلسل غلط ہو جاتا ہے، جس میں کسی قسم کی مداخلت کی ضرورت ہوتی ہے، اور پلے بک مختلف آپریٹنگ سسٹمز میں مختلف طریقے سے برتاؤ کرتی ہے۔ جیسے جیسے کلسٹر میں ٹیموں اور نوڈس کی تعداد بڑھتی گئی، ہم نے دیکھا کہ پلے بک کو چلنے میں زیادہ وقت لگ رہا ہے۔ ہمارا بہترین وقت اب 3,5 گھنٹے ہے۔ تمہارا کیا ہے؟ 🙂

اور ایسا لگتا ہے کہ kubespray صرف جواب دہ ہے، اور سب کچھ پہلی نظر میں واضح ہے، لیکن:

سفر کے آغاز میں، مقصد صرف AWS میں اور ورچوئلائزیشن پر صلاحیتوں کو شروع کرنا تھا، لیکن پھر، جیسا کہ اکثر ہوتا ہے، ضروریات بدل جاتی ہیں۔

اس کی روشنی میں، یہ واضح ہو گیا کہ وسائل کو ایک واحد آرکیسٹریشن سسٹم میں یکجا کرنے کا ہمارا پرانا نمونہ ان صورتوں کے لیے موزوں نہیں تھا جہاں کلسٹرز کو مختلف فراہم کنندگان کے ذریعے وسیع پیمانے پر تقسیم اور منظم کیا جاتا تھا۔

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

ملازمین کو حقوق دینا ایک الگ کہانی تھی: ہر ٹیم کلسٹر کے "سر پر" رہنا چاہتی تھی اور اسے مکمل طور پر منظم کرنا چاہتی تھی، جو مکمل طور پر تباہی کا باعث بن سکتی تھی، کیونکہ ٹیمیں زیادہ تر ایک دوسرے سے آزاد ہوتی ہیں۔

کیا کیا جائے؟

مندرجہ بالا اور ٹیموں کی زیادہ خود مختار ہونے کی خواہشات کو مدنظر رکھتے ہوئے، ہم ایک سادہ نتیجے پر پہنچے: ایک ٹیم - ایک کلسٹر۔

تو ہمیں دوسرا ملا:

اور پھر تیسرا کلسٹر:

یہاں ہم نے سوچنا شروع کیا: اگر، ایک سال میں، ہماری ٹیموں کے پاس ایک سے زیادہ کلسٹر ہوں؟ مختلف جغرافیائی زونز میں، مثال کے طور پر، یا مختلف فراہم کنندگان کے زیر انتظام؟ اور ان میں سے کچھ کچھ ٹیسٹنگ کے لیے فوری طور پر ایک عارضی کلسٹر تعینات کرنے کے قابل ہونا چاہیں گے۔

یہ مکمل Kubernetes ہو گا! یہ ملٹی کوبرنیٹس کی ایک قسم ہے، یہ پتہ چلتا ہے۔

ایک ہی وقت میں، ہم سب کو کسی نہ کسی طرح ان تمام کلسٹرز کو برقرار رکھنے، ان تک آسانی سے رسائی کا انتظام کرنے کے ساتھ ساتھ نئے بنانے اور پرانے کو دستی مداخلت کے بغیر ختم کرنے کی ضرورت ہوگی۔

Kubernetes کی دنیا میں ہمارا سفر شروع کیے ہوئے کچھ وقت گزر چکا ہے، اس لیے ہم نے دستیاب حلوں کا دوبارہ جائزہ لینے کا فیصلہ کیا۔ یہ پتہ چلتا ہے کہ مارکیٹ میں پہلے سے ہی ایک ہے: رینچر 2.2۔

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

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

Rancher 2 کے ارد گرد پہلے سے ہی ایک کمیونٹی بھی بن رہی تھی، اور اسے منظم کرنے کے لیے ایک HashiCorp Terraform فراہم کنندہ بنایا گیا تھا، جس نے ہر چیز کو ایک ساتھ رکھنے میں ہماری مدد کی۔

کیا ہوا

نتیجے کے طور پر، ہمارے پاس Rancher چلانے والا ایک چھوٹا کلسٹر ہے، جو دوسرے تمام کلسٹرز کے لیے قابل رسائی ہے، نیز اس سے منسلک بہت سے کلسٹرز، جن میں سے کسی تک بھی رسائی اتنی ہی آسانی سے دی جا سکتی ہے جتنی آسانی سے LDAP ڈائرکٹری میں صارف کو شامل کرنا، اس بات سے قطع نظر کہ وہ کہاں واقع ہے اور وہ کون سے فراہم کنندہ کے وسائل استعمال کرتا ہے۔

gitlab-ci اور Terraform کا استعمال کرتے ہوئے، ہم نے ایک ایسا نظام بنایا جو ہمیں کلاؤڈ فراہم کنندگان یا ہمارے اپنے انفراسٹرکچر پر کسی بھی ترتیب کے کلسٹرز بنانے اور انہیں Rancher سے منسلک کرنے کی اجازت دیتا ہے۔ یہ سب ایک IaC طرز میں لاگو کیا جاتا ہے، جہاں ہر کلسٹر کو ایک ذخیرہ کے ذریعہ بیان کیا جاتا ہے اور اس کی حالت کو ورژن بنایا جاتا ہے۔ زیادہ تر ماڈیولز بیرونی ذخیروں سے جڑے ہوتے ہیں، اس لیے جو کچھ کرنا باقی ہے وہ ہے متغیرات کو پاس کرنا یا مثالوں کے لیے اپنی مرضی کے مطابق ترتیب کی وضاحت کرنا، جو کوڈ کی تکرار کو کم کرنے میں مدد کرتا ہے۔

یقیناً، ہمارا سفر ختم ہونے سے بہت دور ہے، اور بہت سے دلچسپ چیلنجز سامنے ہیں، جیسے تمام کلسٹرز میں لاگ اور میٹرکس کے لیے رسائی کا ایک نقطہ، سروس میش، ملٹی کلسٹر ورک لوڈ مینجمنٹ کے لیے گیٹپس، اور بہت کچھ۔ ہمیں امید ہے کہ آپ کو ہمارا سفر دلچسپ لگے گا!