نوٹ. ترجمہ: GitLab میں Kubernetes کو اپنانے کو کمپنی کی ترقی میں کردار ادا کرنے والے دو اہم عوامل میں سے ایک سمجھا جاتا ہے۔ تاہم، حال ہی میں، GitLab.com آن لائن سروس کا بنیادی ڈھانچہ ورچوئل مشینوں پر بنایا گیا تھا، اور صرف ایک سال قبل K8s میں اس کی منتقلی شروع ہوئی تھی، جو ابھی تک مکمل نہیں ہوئی۔ ہمیں GitLab SRE انجینئر کے حالیہ مضمون کا ترجمہ پیش کرتے ہوئے خوشی ہو رہی ہے کہ یہ کیسے ہوتا ہے اور پروجیکٹ میں حصہ لینے والے انجینئرز کیا نتیجہ اخذ کرتے ہیں۔
اب تقریباً ایک سال سے، ہمارا انفراسٹرکچر ڈویژن GitLab.com پر چلنے والی تمام سروسز کو Kubernetes میں منتقل کر رہا ہے۔ اس وقت کے دوران، ہمیں نہ صرف Kubernetes میں خدمات منتقل کرنے بلکہ منتقلی کے دوران ہائبرڈ تعیناتی کے انتظام سے متعلق چیلنجوں کا سامنا کرنا پڑا۔ ہم نے جو قیمتی سبق سیکھے ہیں ان پر اس مضمون میں بحث کی جائے گی۔
GitLab.com کے آغاز سے ہی، اس کے سرورز ورچوئل مشینوں پر کلاؤڈ میں چلتے تھے۔ یہ ورچوئل مشینیں شیف کے زیر انتظام ہیں اور ہمارے استعمال سے انسٹال کی جاتی ہیں۔ . اگر ایپلیکیشن کو اپ ڈیٹ کرنے کی ضرورت ہے، تو اس میں صرف CI پائپ لائن کا استعمال کرتے ہوئے مربوط، ترتیب وار انداز میں سرور کے بیڑے کو اپ ڈیٹ کرنا ہوتا ہے۔ یہ طریقہ - اگرچہ سست اور تھوڑا سا - اس بات کو یقینی بناتا ہے کہ GitLab.com وہی انسٹالیشن اور کنفیگریشن کے طریقوں کو استعمال کرتا ہے جو آف لائن صارفین استعمال کرتے ہیں۔ (خود منظم) اس کے لیے ہمارے لینکس پیکجز کا استعمال کرتے ہوئے GitLab تنصیبات۔
ہم یہ طریقہ استعمال کرتے ہیں کیونکہ ان تمام دکھوں اور خوشیوں کا تجربہ کرنا انتہائی ضروری ہے جو کمیونٹی کے عام ممبران GitLab کی اپنی کاپیاں انسٹال اور ترتیب دیتے وقت محسوس کرتے ہیں۔ اس نقطہ نظر نے کچھ عرصے تک اچھی طرح کام کیا، لیکن جب GitLab پر پروجیکٹس کی تعداد 10 ملین سے تجاوز کر گئی، تو ہم نے محسوس کیا کہ اب یہ اسکیلنگ اور تعیناتی کے لیے ہماری ضروریات کو پورا نہیں کرتا ہے۔
Kubernetes اور کلاؤڈ-آبائی GitLab کے پہلے اقدامات
یہ منصوبہ 2017 میں بنایا گیا تھا۔ کلاؤڈ تعیناتی کے لیے GitLab تیار کرنے کے لیے، اور صارفین کو Kubernetes کلسٹرز پر GitLab انسٹال کرنے کے قابل بنانے کے لیے۔ تب ہم جانتے تھے کہ GitLab کو Kubernetes میں منتقل کرنے سے SaaS پلیٹ فارم کی اسکیل ایبلٹی میں اضافہ ہوگا، تعیناتیوں کو آسان بنایا جائے گا، اور کمپیوٹنگ وسائل کی کارکردگی میں بہتری آئے گی۔ ایک ہی وقت میں، ہماری ایپلیکیشن کے بہت سے افعال کا انحصار NFS پارٹیشنز پر ہے، جو ورچوئل مشینوں سے منتقلی کو سست کر دیتے ہیں۔
کلاؤڈ مقامی اور Kubernetes کی طرف دھکیلنے نے ہمارے انجینئرز کو بتدریج منتقلی کی منصوبہ بندی کرنے کی اجازت دی، جس کے دوران ہم نے نئی خصوصیات تیار کرتے ہوئے نیٹ ورک اسٹوریج پر ایپلی کیشن کے کچھ انحصار کو ترک کر دیا۔ چونکہ ہم نے 2019 کے موسم گرما میں ہجرت کی منصوبہ بندی شروع کی تھی، ان میں سے بہت سی حدود کو حل کر دیا گیا ہے، اور GitLab.com کو Kubernetes میں منتقل کرنے کا عمل اب اچھی طرح سے جاری ہے!
Kubernetes میں GitLab.com کی خصوصیات
GitLab.com کے لیے، ہم ایک واحد علاقائی GKE کلسٹر استعمال کرتے ہیں جو تمام ایپلیکیشن ٹریفک کو ہینڈل کرتا ہے۔ (پہلے سے ہی مشکل) منتقلی کی پیچیدگی کو کم کرنے کے لیے، ہم ان خدمات پر توجہ مرکوز کرتے ہیں جو مقامی اسٹوریج یا NFS پر انحصار نہیں کرتی ہیں۔ GitLab.com بنیادی طور پر یک سنگی ریلوں کا کوڈ بیس استعمال کرتا ہے، اور ہم کام کے بوجھ کی خصوصیات کی بنیاد پر ٹریفک کو مختلف اختتامی مقامات تک پہنچاتے ہیں جو ان کے اپنے نوڈ پولز میں الگ تھلگ ہیں۔
فرنٹ اینڈ کے معاملے میں، ان اقسام کو ویب، API، Git SSH/HTTPS اور رجسٹری کی درخواستوں میں تقسیم کیا گیا ہے۔ پسدید کے معاملے میں، ہم مختلف خصوصیات کے مطابق قطار میں ملازمتوں کو تقسیم کرتے ہیں جو ہمیں مختلف کام کے بوجھ کے لیے سروس لیول کے مقاصد (SLOs) سیٹ کرنے کی اجازت دیتا ہے۔
یہ تمام GitLab.com سروسز ایک غیر ترمیم شدہ GitLab ہیلم چارٹ کا استعمال کرتے ہوئے ترتیب دی گئی ہیں۔ کنفیگریشن سب چارٹس میں کی جاتی ہے، جسے منتخب طور پر فعال کیا جا سکتا ہے کیونکہ ہم آہستہ آہستہ خدمات کو کلسٹر میں منتقل کرتے ہیں۔ اگرچہ ہم نے اپنی کچھ ریاستی خدمات کو منتقلی میں شامل نہ کرنے کا فیصلہ کیا ہے، جیسے Redis، Postgres، GitLab Pages اور Gitaly، Kubernetes کا استعمال ہمیں ان VMs کی تعداد کو یکسر کم کرنے کی اجازت دیتا ہے جن کا شیف فی الحال انتظام کرتا ہے۔
Kubernetes کنفیگریشن مرئیت اور انتظام
تمام ترتیبات کا انتظام خود GitLab کے ذریعے کیا جاتا ہے۔ اس کے لیے ٹیرافارم اور ہیلم پر مبنی تین کنفیگریشن پروجیکٹ استعمال کیے جاتے ہیں۔ ہم GitLab کو چلانے کے لیے جب بھی ممکن ہو خود GitLab استعمال کرنے کی کوشش کرتے ہیں، لیکن آپریشنل کاموں کے لیے ہمارے پاس الگ GitLab انسٹالیشن ہے۔ یہ یقینی بنانے کے لیے ضروری ہے کہ آپ GitLab.com کی تعیناتیوں اور اپ ڈیٹس کو انجام دیتے وقت GitLab.com کی دستیابی پر منحصر نہیں ہیں۔
اگرچہ Kubernetes کلسٹر کے لیے ہماری پائپ لائنز ایک علیحدہ GitLab انسٹالیشن پر چلتی ہیں، لیکن کوڈ ریپوزٹریز کے عکس موجود ہیں جو درج ذیل پتوں پر عوامی طور پر دستیاب ہیں:
- — GitLab.com کنفیگریشن فریم ورک GitLab ہیلم چارٹ کے لیے؛
- - ان خدمات کے لیے کنفیگریشنز پر مشتمل ہے جو براہ راست GitLab ایپلیکیشن سے وابستہ نہیں ہیں۔ ان میں لاگنگ اور کلسٹر مانیٹرنگ کے لیے کنفیگریشنز کے ساتھ ساتھ پلانٹ یو ایم ایل جیسے مربوط ٹولز شامل ہیں۔
- - Kubernetes اور Legacy VM انفراسٹرکچر کے لیے Terraform کنفیگریشن۔ یہاں آپ کلسٹر کو چلانے کے لیے ضروری تمام وسائل کو ترتیب دیتے ہیں، بشمول خود کلسٹر، نوڈ پول، سروس اکاؤنٹس، اور IP ایڈریس کے تحفظات۔
تبدیلیاں کیے جانے پر عوامی منظر دکھایا جاتا ہے۔ تفصیلی فرق کے لنک کے ساتھ جس کا SRE کلسٹر میں تبدیلیاں کرنے سے پہلے تجزیہ کرتا ہے۔
SRE کے لیے، لنک GitLab کی تنصیب میں ایک تفصیلی فرق کی طرف لے جاتا ہے، جو پیداوار کے لیے استعمال ہوتا ہے اور اس تک رسائی محدود ہے۔ یہ ملازمین اور کمیونٹی کو آپریشنل پروجیکٹ تک رسائی کے بغیر (جو صرف SREs کے لیے کھلا ہے) کی مجوزہ کنفیگریشن تبدیلیوں کو دیکھنے کی اجازت دیتا ہے۔ کوڈ کے لیے عوامی GitLab مثال کو CI پائپ لائنز کے لیے ایک نجی مثال کے ساتھ جوڑ کر، ہم کنفیگریشن اپ ڈیٹس کے لیے GitLab.com سے آزادی کو یقینی بناتے ہوئے ایک ہی ورک فلو کو برقرار رکھتے ہیں۔
جو ہمیں ہجرت کے دوران معلوم ہوا۔
اس اقدام کے دوران، تجربہ حاصل ہوا کہ ہم Kubernetes میں نئی نقل مکانی اور تعیناتیوں پر لاگو ہوتے ہیں۔
1. دستیابی والے علاقوں کے درمیان ٹریفک کی وجہ سے اخراجات میں اضافہ
GitLab.com پر گٹ ریپوزٹری فلیٹ کے لیے روزانہ اخراج کے اعدادوشمار (بائٹس فی دن)
گوگل اپنے نیٹ ورک کو علاقوں میں تقسیم کرتا ہے۔ وہ، بدلے میں، ایکسیسبیلٹی زونز (AZ) میں تقسیم ہوتے ہیں۔ گٹ ہوسٹنگ کا تعلق بڑی مقدار میں ڈیٹا سے ہے، اس لیے ہمارے لیے نیٹ ورک کے اخراج کو کنٹرول کرنا ضروری ہے۔ داخلی ٹریفک کے لیے، باہر نکلنا صرف اس صورت میں مفت ہے جب یہ ایک ہی دستیابی زون کے اندر رہے۔ اس تحریر کے مطابق، ہم ایک عام کام کے دن میں تقریباً 100 TB ڈیٹا فراہم کر رہے ہیں (اور یہ صرف Git repositories کے لیے ہے)۔ وہ خدمات جو ہماری پرانی VM پر مبنی ٹوپولوجی میں ایک ہی ورچوئل مشینوں میں رہتی تھیں اب مختلف Kubernetes pods میں چلتی ہیں۔ اس کا مطلب ہے کہ کچھ ٹریفک جو پہلے VM کے لیے مقامی تھی ممکنہ طور پر دستیابی والے علاقوں سے باہر سفر کر سکتی ہے۔
علاقائی GKE کلسٹرز آپ کو فالتو پن کے لیے ایک سے زیادہ دستیابی زونز کو پھیلانے کی اجازت دیتے ہیں۔ ہم امکان پر غور کر رہے ہیں۔ ایسی خدمات کے لیے جو بڑی تعداد میں ٹریفک پیدا کرتی ہیں۔ یہ کلسٹر سطح کی فالتو پن کو برقرار رکھتے ہوئے اخراج کے اخراجات کو کم کرے گا۔
2. حدود، وسائل کی درخواستیں اور اسکیلنگ
registry.gitlab.com پر نقل کی پروسیسنگ پروڈکشن ٹریفک کی تعداد۔ ~15:00 UTC پر ٹریفک عروج پر ہے۔
ہماری ہجرت کی کہانی اگست 2019 میں شروع ہوئی، جب ہم نے اپنی پہلی سروس GitLab کنٹینر رجسٹری کو Kubernetes میں منتقل کیا۔ یہ مشن اہم، ہائی ٹریفک سروس پہلی ہجرت کے لیے ایک اچھا انتخاب تھا کیونکہ یہ ایک بے وطن ایپلی کیشن ہے جس میں کچھ بیرونی انحصار ہیں۔ پہلا مسئلہ جس کا ہمیں سامنا ہوا وہ نوڈس پر میموری کی کمی کی وجہ سے بے دخل شدہ پوڈز کی ایک بڑی تعداد تھی۔ اس کی وجہ سے ہمیں درخواستوں اور حدود کو تبدیل کرنا پڑا۔
یہ دریافت کیا گیا کہ کسی ایپلی کیشن کی صورت میں جہاں وقت کے ساتھ ساتھ میموری کی کھپت بڑھ جاتی ہے، درخواستوں کے لیے کم قدریں (ہر پوڈ کے لیے میموری کو محفوظ کرنا) اور استعمال پر ایک "سخاوت مند" سخت حد کے ساتھ سنترپتی کا باعث بنتی ہے۔ (سنترپتی) نوڈس اور بے دخلی کی اعلیٰ سطح۔ اس مسئلے سے نمٹنے کے لئے، یہ تھا . اس سے نوڈس کا دباؤ ختم ہو گیا اور اس بات کو یقینی بنایا گیا کہ پوڈز کا لائف سائیکل ہے جو نوڈ پر زیادہ دباؤ نہیں ڈالتا ہے۔ اب ہم فراخدلی (اور تقریباً ایک جیسی) درخواست کے ساتھ ہجرت شروع کرتے ہیں اور قدروں کو محدود کرتے ہیں، انہیں حسب ضرورت ایڈجسٹ کرتے ہیں۔
3. میٹرکس اور لاگز
انفراسٹرکچر ڈویژن تاخیر، خرابی کی شرح اور انسٹال کے ساتھ سنترپتی پر توجہ مرکوز کرتا ہے۔ (SLO) سے منسلک .
پچھلے سال کے دوران، انفراسٹرکچر ڈویژن میں اہم واقعات میں سے ایک SLOs کے ساتھ نگرانی اور کام کرنے میں بہتری ہے۔ SLOs نے ہمیں انفرادی خدمات کے لیے اہداف مقرر کرنے کی اجازت دی جن کی ہم نے ہجرت کے دوران قریب سے نگرانی کی۔ لیکن اس بہتر مشاہدے کے باوجود، میٹرکس اور الرٹس کا استعمال کرتے ہوئے فوری طور پر مسائل کو دیکھنا ہمیشہ ممکن نہیں ہوتا۔ مثال کے طور پر، تاخیر اور خرابی کی شرحوں پر توجہ مرکوز کرتے ہوئے، ہم نقل مکانی سے گزرنے والی سروس کے استعمال کے تمام معاملات کو مکمل طور پر کور نہیں کرتے ہیں۔
یہ مسئلہ کلسٹر میں کچھ کام کے بوجھ کو منتقل کرنے کے فوراً بعد دریافت ہوا۔ یہ خاص طور پر شدید ہو گیا جب ہمیں ایسے فنکشنز کو چیک کرنا پڑا جن کے لیے درخواستوں کی تعداد کم تھی، لیکن جن میں بہت مخصوص کنفیگریشن انحصار تھا۔ ہجرت کے اہم اسباق میں سے ایک یہ تھا کہ نگرانی کرتے وقت نہ صرف میٹرکس بلکہ لاگ اور "لمبی دم" کو بھی مدنظر رکھا جائے۔ (یہ کے بارے میں ہے چارٹ پر - تقریبا. ترجمہ) غلطیاں اب ہر منتقلی کے لیے ہم لاگ کے سوالات کی تفصیلی فہرست شامل کرتے ہیں۔ (لاگ سوالات) اور واضح رول بیک طریقہ کار کی منصوبہ بندی کریں جنہیں مسائل پیدا ہونے پر ایک شفٹ سے دوسری شفٹ میں منتقل کیا جا سکتا ہے۔
پرانے VM انفراسٹرکچر اور نئے Kubernetes پر مبنی انفراسٹرکچر کے متوازی طور پر انہی درخواستوں کو پیش کرنا ایک منفرد چیلنج پیش کرتا ہے۔ لفٹ اور شفٹ ہجرت کے برعکس (ایک نئے انفراسٹرکچر میں ایپلیکیشنز کی فوری منتقلی "جیسے ہے"؛ مزید تفصیلات پڑھی جا سکتی ہیں، مثال کے طور پر، - تقریبا. ترجمہ), "پرانے" VMs اور Kubernetes پر متوازی کام کا تقاضا ہے کہ مانیٹرنگ ٹولز دونوں ماحول کے ساتھ ہم آہنگ ہوں اور میٹرکس کو ایک منظر میں جوڑنے کے قابل ہوں۔ یہ ضروری ہے کہ ہم منتقلی کی مدت کے دوران مستقل مشاہدہ حاصل کرنے کے لیے وہی ڈیش بورڈز اور لاگ سوالات استعمال کریں۔
4. ٹریفک کو نئے کلسٹر میں تبدیل کرنا
GitLab.com کے لیے، سرورز کا کچھ حصہ وقف ہے۔ . کینری پارک ہمارے اندرونی منصوبوں کی خدمت کرتا ہے اور کر بھی سکتا ہے۔ . لیکن یہ بنیادی طور پر بنیادی ڈھانچے اور اطلاق میں کی گئی تبدیلیوں کو جانچنے کے لیے ڈیزائن کیا گیا ہے۔ داخلی ٹریفک کی ایک محدود مقدار کو قبول کرتے ہوئے پہلی منتقلی کی سروس شروع ہوئی، اور ہم اس طریقہ کو استعمال کرتے رہتے ہیں تاکہ یہ یقینی بنایا جا سکے کہ تمام ٹریفک کو کلسٹر میں بھیجنے سے پہلے SLO کی تکمیل ہو جائے۔
ہجرت کے معاملے میں، اس کا مطلب ہے کہ اندرونی منصوبوں کی درخواستیں پہلے Kubernetes کو بھیجی جاتی ہیں، اور پھر ہم HAProxy کے ذریعے بیک اینڈ کے لیے وزن کو تبدیل کر کے آہستہ آہستہ باقی ٹریفک کو کلسٹر میں تبدیل کر دیتے ہیں۔ VM سے Kubernetes کی طرف ہجرت کے دوران، یہ واضح ہو گیا کہ پرانے اور نئے انفراسٹرکچر کے درمیان ٹریفک کو ری ڈائریکٹ کرنے کا ایک آسان طریقہ ہونا بہت فائدہ مند ہے اور اس کے مطابق، منتقلی کے بعد پہلے چند دنوں میں پرانے انفراسٹرکچر کو رول بیک کے لیے تیار رکھنا۔
5. پھلیوں کی محفوظ صلاحیتیں اور ان کے استعمال
تقریباً فوری طور پر درج ذیل مسئلے کی نشاندہی کی گئی: رجسٹری سروس کے لیے پوڈز تیزی سے شروع ہو گئے، لیکن سائڈکیک کے لیے پوڈز کو لانچ کرنے میں کافی وقت لگا۔ . Sidekiq pods کے لیے طویل آغاز کا وقت اس وقت ایک مسئلہ بن گیا جب ہم نے ورکرز کے لیے کام کے بوجھ کو Kubernetes میں منتقل کرنا شروع کیا جن کو ملازمتوں پر تیزی سے کارروائی کرنے اور تیزی سے پیمانے کی ضرورت تھی۔
اس معاملے میں، سبق یہ تھا کہ جب کہ Kubernetes کا Horizontal Pod Autoscaler (HPA) ٹریفک کی نمو کو اچھی طرح سے سنبھالتا ہے، یہ ضروری ہے کہ کام کے بوجھ کی خصوصیات کو مدنظر رکھا جائے اور پوڈز کے لیے فالتو گنجائش مختص کی جائے (خاص طور پر جب طلب غیر مساوی طور پر تقسیم ہو)۔ ہمارے معاملے میں، نوکریوں میں اچانک اضافہ ہوا، جس کی وجہ سے تیزی سے اسکیلنگ ہوئی، جس کی وجہ سے سی پی یو کے وسائل کی سنترپتی ہوئی اس سے پہلے کہ ہمارے پاس نوڈ پول کو اسکیل کرنے کا وقت ہو۔
ایک جھرمٹ میں سے زیادہ سے زیادہ نچوڑ لینے کا ہمیشہ لالچ ہوتا ہے، تاہم، ابتدائی طور پر کارکردگی کے مسائل کا سامنا کرنے کے بعد، ہم اب ایک فراخدلانہ پوڈ بجٹ کے ساتھ شروع کر رہے ہیں اور SLOs پر گہری نظر رکھتے ہوئے اسے بعد میں کم کر رہے ہیں۔ Sidekiq سروس کے لیے پوڈز کے آغاز میں کافی تیزی آئی ہے اور اب اس میں اوسطاً 40 سیکنڈ لگتے ہیں۔ GitLab.com اور سرکاری GitLab Helm چارٹ کے ساتھ کام کرنے والے خود انتظام شدہ تنصیبات کے ہمارے صارفین دونوں جیت گئے۔
حاصل يہ ہوا
ہر سروس کو منتقل کرنے کے بعد، ہمیں پیداوار میں Kubernetes کے استعمال کے فوائد پر خوشی ہوئی: تیز اور محفوظ ایپلیکیشن کی تعیناتی، اسکیلنگ، اور زیادہ موثر وسائل کی تقسیم۔ مزید برآں، منتقلی کے فوائد GitLab.com سروس سے آگے ہیں۔ سرکاری ہیلم چارٹ میں ہر بہتری اس کے صارفین کو فائدہ پہنچاتی ہے۔
مجھے امید ہے کہ آپ نے ہماری Kubernetes کی نقل مکانی کی مہم جوئی کی کہانی سے لطف اندوز ہوئے ہوں گے۔ ہم تمام نئی سروسز کو کلسٹر میں منتقل کرتے رہتے ہیں۔ اضافی معلومات درج ذیل اشاعتوں میں مل سکتی ہیں:
- «؛ "
- «؛ "
- .
مترجم سے PS
ہمارے بلاگ پر بھی پڑھیں:
- «؛ "
- «؛ "
- «؛ "
- «'.
ماخذ: www.habr.com