Pinterest پر kubernetes پلیٹ فارم بنانا

سالوں کے دوران، Pinterest کے 300 ملین صارفین نے 200 بلین سے زیادہ بورڈز پر 4 بلین سے زیادہ پن بنائے ہیں۔ صارفین کی اس فوج اور وسیع مواد کی بنیاد کی خدمت کرنے کے لیے، پورٹل نے ہزاروں خدمات تیار کی ہیں، جن میں مائیکرو سروسز سے لے کر چند CPUs کے ذریعے ہینڈل کیے جاسکتے ہیں، دیو ہیکل monoliths تک جو ورچوئل مشینوں کے پورے بیڑے پر چلتی ہیں۔ اور پھر وہ لمحہ آیا جب کمپنی کی نظر k8s پر پڑی۔ Pinterest پر "کیوب" کیوں اچھا لگ رہا تھا؟ آپ اس کے بارے میں ہمارے ایک حالیہ مضمون کے ترجمہ سے سیکھیں گے۔ بلاگ پنٹیرسٹ انجینئرنگ.

Pinterest پر kubernetes پلیٹ فارم بنانا

لہذا، لاکھوں صارفین اور سینکڑوں بلین پن۔ صارفین کی اس فوج اور وسیع مواد کی بنیاد کی خدمت کرنے کے لیے، ہم نے ہزاروں خدمات تیار کی ہیں، جن میں مائیکرو سروسز سے لے کر چند CPUs کے ذریعے ہینڈل کیا جا سکتا ہے، بڑے یک سنگی تک جو ورچوئل مشینوں کے پورے بیڑے پر چلتی ہیں۔ اس کے علاوہ، ہمارے پاس مختلف قسم کے فریم ورک ہیں جن کے لیے CPU، میموری، یا I/O رسائی کی بھی ضرورت پڑ سکتی ہے۔

ٹولز کے اس چڑیا گھر کو برقرار رکھنے میں، ترقیاتی ٹیم کو کئی چیلنجوں کا سامنا ہے:

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

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

Pinterest پر kubernetes پلیٹ فارم بنانا

شکل 1: بنیادی ڈھانچے کی ترجیحات (اعتماد، ڈویلپر کی پیداواری صلاحیت، اور کارکردگی)۔

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

آج تک، ہم نے Kops پر مبنی اپنے کلسٹر بوٹ ٹولز بنائے ہیں اور موجودہ انفراسٹرکچر کے اجزاء جیسے کہ نیٹ ورکنگ، سیکیورٹی، میٹرکس، لاگنگ، شناختی انتظام، اور ٹریفک کو Kubernetes میں منتقل کیا ہے۔ ہم نے اپنے وسائل کے لیے ایک ورک لوڈ ماڈلنگ سسٹم بھی نافذ کیا، جس کی پیچیدگی ڈیولپرز سے پوشیدہ ہے۔ اب ہم کلسٹر کے استحکام کو یقینی بنانے، اس کی پیمائش کرنے اور نئے کلائنٹس کو جوڑنے پر توجہ مرکوز کر رہے ہیں۔

Kubernetes: Pinterest راستہ

Kubernetes کے ساتھ Pinterest کے پیمانے پر ایک پلیٹ فارم کے طور پر شروع کرنا جسے ہمارے انجینئرز پسند کریں گے بہت سے چیلنجز کے ساتھ آئے۔

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

دوسری طرف، خود Kubernetes میں بوجھ کی پیشن گوئی کرنے والے ماڈل (جیسے کہ تعیناتی، نوکریاں، اور ڈیمون سیٹ) ہمارے پروجیکٹ کے لیے کافی نہیں ہیں۔ یہ استعمال کے مسائل Kubernetes میں جانے میں بہت بڑی رکاوٹ ہیں۔ مثال کے طور پر، ہم نے سروس ڈویلپرز کو لاپتہ یا غلط لاگ ان سیٹنگز کے بارے میں شکایت کرتے سنا ہے۔ ہمیں ٹیمپلیٹ انجنوں کے غلط استعمال کا بھی سامنا کرنا پڑا، جب ایک ہی تفصیلات اور کام کے ساتھ سینکڑوں کاپیاں بنائی گئیں، جس کے نتیجے میں ڈراؤنے خواب ڈیبگنگ کے مسائل پیدا ہوئے۔

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

Pinterest صارف کی خصوصیات اور کنٹرولرز

ہمارے انجینئرز کے لیے Kubernetes کو لاگو کرنا آسان بنانے کے لیے، اور اپنے بنیادی ڈھانچے کو آسان اور تیز کرنے کے لیے، ہم نے اپنی مرضی کے مطابق وسائل کی تعریفیں (CRDs) تیار کی ہیں۔

CRDs درج ذیل فعالیت فراہم کرتے ہیں:

  1. مختلف مقامی Kubernetes وسائل کو یکجا کرنا تاکہ وہ ایک کام کے بوجھ کے طور پر کام کریں۔ مثال کے طور پر، PinterestService وسائل میں ایک تعیناتی، ایک لاگ ان سروس، اور ایک ترتیب کا نقشہ شامل ہے۔ یہ ڈویلپرز کو DNS ترتیب دینے کے بارے میں فکر کرنے کی اجازت نہیں دیتا ہے۔
  2. ضروری درخواست کی مدد کو لاگو کریں۔ صارف کو اپنی کاروباری منطق کے مطابق صرف کنٹینر کی تفصیلات پر توجہ مرکوز کرنے کی ضرورت ہے، جبکہ CRD کنٹرولر تمام ضروری init کنٹینرز، ماحولیاتی متغیرات اور پوڈ کی وضاحتیں لاگو کرتا ہے۔ یہ ڈویلپرز کے لیے بنیادی طور پر مختلف سطح کا سکون فراہم کرتا ہے۔
  3. CRD کنٹرولرز مقامی وسائل کے لائف سائیکل کو بھی منظم کرتے ہیں اور ڈیبگ کی دستیابی کو بہتر بناتے ہیں۔ اس میں مطلوبہ اور حقیقی تصریحات کو ملانا، CRD اسٹیٹس کو اپ ڈیٹ کرنا اور ایونٹ کے لاگز کو برقرار رکھنا اور بہت کچھ شامل ہے۔ CRD کے بغیر، ڈویلپرز کو متعدد وسائل کا انتظام کرنے پر مجبور کیا جائے گا، جس سے غلطی کا امکان بڑھ جائے گا۔

یہاں ایک PinterestService اور اندرونی وسائل کی ایک مثال ہے جو ہمارے کنٹرولر کے زیر انتظام ہے:

Pinterest پر kubernetes پلیٹ فارم بنانا

جیسا کہ آپ اوپر دیکھ سکتے ہیں، ایک حسب ضرورت کنٹینر کو سپورٹ کرنے کے لیے ہمیں سیکیورٹی، مرئیت، اور نیٹ ورک ٹریفک فراہم کرنے کے لیے ایک init کنٹینر اور کئی ایڈ آنز کو مربوط کرنے کی ضرورت ہے۔ اس کے علاوہ، ہم نے کنفیگریشن میپ ٹیمپلیٹس بنائے اور بیچ جابز کے لیے PVC ٹیمپلیٹس کے لیے سپورٹ کو لاگو کیا، نیز شناخت، وسائل کی کھپت، اور کوڑے کے ذخیرے کو ٹریک کرنے کے لیے متعدد ماحولیاتی متغیرات کو ٹریک کرنا۔

یہ تصور کرنا مشکل ہے کہ ڈویلپرز ان کنفیگریشن فائلوں کو CRD سپورٹ کے بغیر ہاتھ سے لکھنا چاہیں گے، کنفیگریشنز کو مزید برقرار رکھنے اور ڈیبگ کرنے دیں۔

درخواست کی تعیناتی کا ورک فلو

Pinterest پر kubernetes پلیٹ فارم بنانا

اوپر کی تصویر دکھاتی ہے کہ پنٹیرسٹ کسٹم ریسورس کو کبرنیٹس کلسٹر میں کیسے تعینات کیا جائے:

  1. ڈیولپرز ہمارے Kubernetes کلسٹر کے ساتھ CLI اور یوزر انٹرفیس کے ذریعے تعامل کرتے ہیں۔
  2. CLI/UI ٹولز آرٹفیکٹری سے ورک فلو کنفیگریشن YAML فائلز اور دیگر بلڈ پراپرٹیز (ایک ہی ورژن ID) کو بازیافت کرتے ہیں اور پھر انہیں جاب سبمیشن سروس میں جمع کراتے ہیں۔ یہ قدم اس بات کو یقینی بناتا ہے کہ صرف پروڈکشن ورژن ہی کلسٹر کو پہنچائے جائیں۔
  3. JSS مختلف پلیٹ فارمز کے لیے ایک گیٹ وے ہے، بشمول Kubernetes۔ یہاں صارف کی تصدیق کی جاتی ہے، کوٹہ جاری کیا جاتا ہے اور ہمارے CRD کی ترتیب کو جزوی طور پر چیک کیا جاتا ہے۔
  4. JSS کی طرف CRD کو چیک کرنے کے بعد، معلومات k8s پلیٹ فارم API کو بھیجی جاتی ہے۔
  5. ہمارا CRD کنٹرولر صارف کے تمام وسائل پر واقعات کی نگرانی کرتا ہے۔ یہ CRs کو مقامی k8s وسائل میں تبدیل کرتا ہے، ضروری ماڈیولز کا اضافہ کرتا ہے، مناسب ماحول کے متغیرات کو سیٹ کرتا ہے، اور کنٹینرائزڈ صارف ایپلی کیشنز کو کافی انفراسٹرکچر سپورٹ حاصل کرنے کو یقینی بنانے کے لیے دیگر معاون کام انجام دیتا ہے۔
  6. اس کے بعد CRD کنٹرولر موصول ہونے والے ڈیٹا کو Kubernetes API کو منتقل کرتا ہے تاکہ اس پر شیڈولر کے ذریعے کارروائی کی جا سکے اور اسے پروڈکشن میں لایا جا سکے۔

نوٹ: تعیناتی کا یہ پری ریلیز ورک فلو نئے k8s پلیٹ فارم کے پہلے صارفین کے لیے بنایا گیا تھا۔ ہم فی الحال اپنے نئے CI/CD کے ساتھ مکمل طور پر انضمام کے لیے اس عمل کو بہتر بنانے کے عمل میں ہیں۔ اس کا مطلب ہے کہ ہم آپ کو Kubernetes سے متعلق ہر چیز نہیں بتا سکتے۔ ہم اپنی اگلی بلاگ پوسٹ، "Pinterest کے لیے CI/CD پلیٹ فارم کی تعمیر" میں اپنے تجربے اور اس سمت میں ٹیم کی پیشرفت کا اشتراک کرنے کے منتظر ہیں۔

خصوصی وسائل کی اقسام

Pinterest کی مخصوص ضروریات کی بنیاد پر، ہم نے مختلف ورک فلو کے مطابق درج ذیل CRDs تیار کیے ہیں:

  • PinterestService بے وطن خدمات ہیں جو ایک طویل عرصے سے چل رہی ہیں۔ ہمارے بہت سے بنیادی نظام ایسی خدمات کے سیٹ پر مبنی ہیں۔
  • PinterestJobSet ماڈل مکمل سائیکل بیچ جابز۔ Pinterest پر ایک عام منظر نامہ یہ ہے کہ متعدد ملازمتیں ایک جیسے کنٹینرز کو متوازی طور پر چلاتی ہیں، اس سے قطع نظر کہ دیگر اسی طرح کے عمل سے۔
  • PinterestCronJob بڑے پیمانے پر چھوٹے متواتر بوجھ کے ساتھ استعمال ہوتا ہے۔ یہ Pinterest سپورٹ میکانزم کے ساتھ مقامی کرون کے کام کے لیے ایک ریپر ہے جو سیکیورٹی، ٹریفک، لاگز اور میٹرکس کے لیے ذمہ دار ہیں۔
  • PinterestDaemon میں انفراسٹرکچر ڈیمون شامل ہے۔ یہ خاندان بڑھتا ہی جا رہا ہے کیونکہ ہم اپنے کلسٹرز میں مزید تعاون شامل کرتے ہیں۔
  • PinterestTrainingJob Tensorflow اور Pytorch کے عمل تک پھیلا ہوا ہے، جو کہ دیگر تمام CRDs کی طرح رن ٹائم سپورٹ فراہم کرتا ہے۔ چونکہ Pinterest فعال طور پر Tensorflow اور دیگر مشین لرننگ سسٹم کا استعمال کرتا ہے، اس لیے ہمارے پاس ان کے ارد گرد ایک علیحدہ CRD بنانے کی وجہ تھی۔

ہم PinterestStatefulSet پر بھی کام کر رہے ہیں، جسے جلد ہی ڈیٹا گوداموں اور دیگر ریاستی نظاموں کے لیے ڈھال لیا جائے گا۔

رن ٹائم سپورٹ

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

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

ٹیسٹنگ اور QA

ہم نے موجودہ Kubernetes ٹیسٹ انفراسٹرکچر کے سب سے اوپر ایک اختتام سے آخر تک ٹیسٹ پائپ لائن بنائی ہے۔ یہ ٹیسٹ ہمارے تمام کلسٹرز پر لاگو ہوتے ہیں۔ ہماری پائپ لائن پروڈکٹ کلسٹر کا حصہ بننے سے پہلے کئی نظرثانی سے گزری۔

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

متبادل

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

ایک میوٹیشنل ایڈمیشن کنٹرولر کا استعمال سائڈ کارز، ماحولیاتی متغیرات، اور دیگر رن ٹائم سپورٹ کو متعارف کرانے کے لیے کیا گیا تھا۔ تاہم، اسے مختلف مسائل کا سامنا کرنا پڑا، جیسے وسائل کی پابندی اور لائف سائیکل مینجمنٹ، جہاں CRD میں اس طرح کے مسائل پیدا نہیں ہوتے ہیں۔

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

آنے والا کام

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

  • کلسٹرز کا ایک مجموعہ اسکیل ایبلٹی اور استحکام کے لیے مختلف کلسٹرز میں بڑی ایپلی کیشنز کو تقسیم کرتا ہے۔
  • ایپلیکیشن کنیکٹیویٹی اور SLAs بنانے کے لیے کلسٹر استحکام، اسکیل ایبلٹی اور مرئیت کو یقینی بنانا۔
  • وسائل اور کوٹے کا انتظام کرنا تاکہ ایپلیکیشنز ایک دوسرے سے متصادم نہ ہوں، اور کلسٹر کا پیمانہ ہماری طرف سے کنٹرول کیا جاتا ہے۔
  • Kubernetes پر ایپلی کیشنز کی حمایت اور تعیناتی کے لیے ایک نیا CI/CD پلیٹ فارم۔

ماخذ: www.habr.com

نیا تبصرہ شامل کریں