نوٽ. ترجمو: GitLab تي Kubernetes اپنائڻ کي ڪمپني جي ترقي ۾ حصو وٺندڙ ٻن مکيه عنصرن مان هڪ سمجهيو ويندو آهي. بهرحال، تازو ئي، GitLab.com آن لائن سروس جو بنيادي ڍانچو مجازي مشينن تي تعمير ڪيو ويو، ۽ صرف هڪ سال اڳ K8s ڏانهن لڏپلاڻ شروع ٿي، جيڪو اڃا تائين مڪمل نه ٿيو آهي. اسان کي GitLab SRE انجنيئر پاران تازو مضمون جو ترجمو پيش ڪرڻ تي خوشي ٿي آهي ته اهو ڪيئن ٿئي ٿو ۽ پروجيڪٽ ۾ حصو وٺندڙ انجنيئر ڪهڙا نتيجا ڪڍيا آهن.
ھاڻي اٽڪل ھڪ سال کان، اسان جو انفراسٽرڪچر ڊويزن GitLab.com تي ھلندڙ سڀني خدمتن کي Kubernetes ڏانھن منتقل ڪري رھيو آھي. هن عرصي دوران، اسان کي نه صرف Kubernetes ڏانهن خدمتن کي منتقل ڪرڻ، پر منتقلي دوران هائبرڊ جي ترتيب کي منظم ڪرڻ سان لاڳاپيل چئلينجن کي منهن ڏيڻو پيو. اسان سکيو قيمتي سبق هن مضمون ۾ بحث ڪيو ويندو.
GitLab.com جي شروعات کان وٺي، ان جا سرور ورچوئل مشينن تي ڪلائوڊ ۾ هليا ويا. اهي مجازي مشينون شيف پاران منظم ڪيا ويا آهن ۽ اسان جي استعمال سان نصب ٿيل آهن . جي صورت ۾ ايپليڪيشن کي اپڊيٽ ڪرڻ جي ضرورت آهي، صرف هڪ CI پائيپ لائين استعمال ڪندي ترتيب ڏنل، ترتيب واري انداز ۾ سرور جي فليٽ کي تازه ڪاري ڪرڻ تي مشتمل آهي. اهو طريقو - جيتوڻيڪ سست ۽ ٿورو - انهي ڳالهه کي يقيني بڻائي ٿو ته GitLab.com ساڳئي انسٽاليشن ۽ ترتيب جي طريقن کي استعمال ڪري ٿو جيئن آف لائن صارفين (پاڻ سنڀال) هن لاءِ اسان جي لينڪس پيڪيجز کي استعمال ڪندي GitLab تنصيب.
اسان هي طريقو استعمال ڪريون ٿا ڇاڪاڻ ته اهو تمام ضروري آهي ته انهن سڀني ڏکن ۽ خوشين جو تجربو ڪيو جيڪي ڪميونٽي جا عام ميمبر GitLab جون ڪاپيون انسٽال ڪرڻ ۽ ترتيب ڏيڻ وقت محسوس ڪندا آهن. اهو طريقو ڪجهه وقت لاءِ سٺو ڪم ڪيو، پر جڏهن GitLab تي منصوبن جو تعداد 10 ملين کان وڌي ويو، اسان محسوس ڪيو ته اهو هاڻي اسان جي اسڪيلنگ ۽ ترتيب ڏيڻ جي ضرورتن کي پورو نٿو ڪري.
Kubernetes ۽ ڪلائوڊ-آبائي GitLab ڏانهن پهريون قدم
پروجيڪٽ 2017 ۾ ٺاهي وئي GitLab تيار ڪرڻ لاءِ ڪلائوڊ ڊيپلائيمينٽ لاءِ، ۽ صارفين کي ڪبرنيٽس ڪلسٽرز تي GitLab انسٽال ڪرڻ جي قابل ڪرڻ لاءِ. اسان کي پوءِ خبر پئي ته GitLab کي Kubernetes ڏانهن منتقل ڪرڻ سان SaaS پليٽ فارم جي اسڪاليبلٽي ۾ اضافو ٿيندو، ترتيب ڏيڻ کي آسان بڻائيندو، ۽ ڪمپيوٽنگ وسيلن جي ڪارڪردگي کي بهتر بڻائيندو. ساڳي ئي وقت، اسان جي ايپليڪيشن جا ڪيترائي ڪم نصب ٿيل NFS ورهاڱي تي منحصر آهن، جيڪي ورچوئل مشينن کان منتقلي کي سست ڪن ٿا.
بادل جي ڏيهي ۽ ڪبرنيٽس ڏانهن ڌڪ اسان جي انجنيئرن کي بتدريج منتقلي جي منصوبابندي ڪرڻ جي اجازت ڏني، جنهن دوران اسان نيٽ ورڪ اسٽوريج تي ايپليڪيشن جي ڪجهه انحصار کي ڇڏي ڏنو جڏهن ته نئين خاصيتن کي ترقي ڪرڻ جاري رکندي. جتان اسان 2019 جي اونهاري ۾ لڏپلاڻ جي منصوبابندي شروع ڪئي، انهن مان ڪيتريون ئي حدون حل ٿي چڪيون آهن، ۽ GitLab.com کي Kubernetes ڏانهن لڏڻ جو عمل هاڻي چڱي ريت جاري آهي!
Kubernetes ۾ GitLab.com جون خاصيتون
GitLab.com لاءِ، اسان هڪ واحد علائقائي GKE ڪلستر استعمال ڪندا آهيون جيڪو سڀني ايپليڪيشن ٽرئفڪ کي سنڀاليندو آهي. (اڳ ۾ ئي مشڪل) لڏپلاڻ جي پيچيدگي کي گهٽائڻ لاءِ، اسان انهن خدمتن تي ڌيان ڏيون ٿا جيڪي مقامي اسٽوريج يا NFS تي ڀروسو نه ڪن. GitLab.com استعمال ڪري ٿو هڪ خاص طور تي monolithic ريل ڪوڊ بيس، ۽ اسان ڪم لوڊ جي خاصيتن جي بنياد تي ٽرئفڪ کي مختلف آخري پوائنٽن ڏانهن روانو ڪندا آهيون جيڪي انهن جي پنهنجي نوڊ پولز ۾ الڳ ٿيل آهن.
فرنٽ اينڊ جي صورت ۾، اهي قسمون ويب، API، Git SSH/HTTPS ۽ رجسٽري جي درخواستن ۾ ورهايل آهن. پس منظر جي صورت ۾، اسان قطار ۾ نوڪرين کي ورهايو مختلف خاصيتن جي مطابق ، جيڪي اسان کي مختلف ڪم لوڊ ڪرڻ لاءِ خدمت-سطح جا مقصد (SLOs) مقرر ڪرڻ جي اجازت ڏين ٿا.
اهي سڀئي GitLab.com خدمتون ترتيب ڏنل آهن هڪ غير تبديل ٿيل GitLab هيلم چارٽ استعمال ڪندي. ڪنفيگريشن ذيلي چارٽس ۾ ڪئي ويندي آهي، جنهن کي چونڊيل طور تي چالو ڪري سگهجي ٿو جيئن اسين آهستي آهستي خدمتن کي ڪلستر ڏانهن منتقل ڪريون ٿا. جيتوڻيڪ اسان فيصلو ڪيو ته اسان جي ڪجهه رياستي خدمتن کي لڏپلاڻ ۾ شامل نه ڪيو وڃي، جهڙوڪ Redis، Postgres، GitLab Pages ۽ Gitaly، Kubernetes استعمال ڪندي اسان کي بنيادي طور تي VMs جو تعداد گهٽائڻ جي اجازت ڏئي ٿو جيڪي شيف في الحال منظم ڪري ٿو.
Kubernetes ترتيب جي نمائش ۽ انتظام
سڀئي سيٽنگون GitLab پاران منظم ڪيون ويون آهن. هن لاء، ٽيرافارم ۽ هيلم تي ٻڌل ٽي ترتيب واري منصوبن کي استعمال ڪيو ويو آهي. اسان GitLab کي استعمال ڪرڻ جي ڪوشش ڪندا آهيون جڏهن به ممڪن هجي GitLab هلائڻ لاءِ، پر آپريشنل ڪمن لاءِ اسان وٽ الڳ GitLab تنصيب آهي. انهي کي يقيني بڻائڻ جي ضرورت آهي ته توهان GitLab.com جي دستيابي تي منحصر نه آهيو جڏهن GitLab.com جي ترتيب ۽ تازه ڪاريون انجام ڏيو.
جيتوڻيڪ ڪبرنيٽس ڪلستر لاءِ اسان جون پائپ لائنون الڳ GitLab تنصيب تي هلن ٿيون، اتي موجود ڪوڊ ريپوزٽريز جا آئينا آهن جيڪي هيٺ ڏنل پتي تي عوامي طور تي موجود آهن:
- - GitLab.com جي ترتيب واري فريم ورڪ لاءِ GitLab هيلم چارٽ؛
- - خدمتن لاءِ ٺاھ جوڙ تي مشتمل آھي جيڪي سڌو سنئون GitLab ايپليڪيشن سان لاڳاپيل نه آھن. انهن ۾ لاگنگ ۽ ڪلسٽر مانيٽرنگ لاءِ ترتيبون شامل آهن، گڏوگڏ مربوط اوزار جهڙوڪ PlantUML؛
- - ڪبرنيٽس ۽ ورثي VM انفراسٽرڪچر لاءِ Terraform ترتيب. هتي توهان ڪلستر کي هلائڻ لاءِ ضروري سڀني وسيلن کي ترتيب ڏيو، بشمول ڪلسٽر پاڻ، نوڊ پول، سروس اڪائونٽس، ۽ IP پتي جي رزرويشنز.
عوامي منظر ڏيکاريو ويندو آهي جڏهن تبديليون ڪيون وينديون آهن. تفصيلي فرق جي لنڪ سان جيڪو SRE ڪلستر ۾ تبديليون ڪرڻ کان اڳ تجزيو ڪري ٿو.
SRE لاءِ، لنڪ GitLab تنصيب ۾ تفصيلي فرق ڏانهن وٺي ٿي، جيڪا پيداوار لاءِ استعمال ٿئي ٿي ۽ ان تائين رسائي محدود آهي. هي ملازمن ۽ ڪميونٽي کي اجازت ڏئي ٿو، بغير ڪنهن آپريشنل پروجيڪٽ تائين پهچ (جيڪو صرف SREs لاءِ کليل آهي)، تجويز ڪيل ترتيب جي تبديلين کي ڏسڻ لاءِ. ڪوڊ لاءِ عوامي GitLab مثال کي گڏ ڪندي CI پائپ لائنز لاءِ هڪ خانگي مثال سان، اسان هڪ واحد ورڪ فلو برقرار رکون ٿا جڏهن ته GitLab.com کان آزاديءَ کي يقيني بڻائڻ لاءِ ترتيب جي تازه ڪارين لاءِ.
جيڪو اسان کي لڏپلاڻ دوران معلوم ٿيو
منتقلي دوران، تجربو حاصل ڪيو ويو ته اسان ڪبرنيٽس ۾ نئين لڏپلاڻ ۽ تعیناتين تي لاڳو ٿين ٿا.
1. دستيابي زونن جي وچ ۾ ٽرئفڪ جي ڪري وڌندڙ خرچ
GitLab.com تي گيٽ ريپوزٽري فليٽ لاءِ روزاني نڪرندڙ انگ اکر (في ڏينهن بائيٽ)
گوگل پنھنجي نيٽ ورڪ کي علائقن ۾ ورهائي ٿو. اهي، موڙ ۾، پهچ وارن علائقن (AZ) ۾ ورهايل آهن. Git هوسٽنگ ڊيٽا جي وڏي مقدار سان جڙيل آهي، تنهنڪري اهو ضروري آهي ته اسان جي نيٽ ورڪ جي نڪرڻ کي ڪنٽرول ڪرڻ لاء. اندروني ٽرئفڪ لاء، نڪرڻ صرف مفت آهي جيڪڏهن اهو ساڳيو دستيابي علائقي جي اندر رهي ٿو. هن لکڻ جي طور تي، اسان هڪ عام ڪم جي ڏينهن ۾ تقريبن 100 TB ڊيٽا جي خدمت ڪري رهيا آهيون (۽ اهو صرف Git repositories لاءِ آهي). خدمتون جيڪي اسان جي پراڻي VM-بنياد ٽوپولاجيءَ ۾ ساڳين ورچوئل مشينن ۾ رھيون آھن ھاڻي مختلف ڪبرنيٽس پوڊس ۾ ھلنديون آھن. هن جو مطلب آهي ته ڪجهه ٽرئفڪ جيڪا اڳ ۾ مقامي هئي VM ڏانهن ممڪن طور تي دستيابي زونن کان ٻاهر سفر ڪري سگهي ٿي.
علائقائي GKE ڪلسٽرز توهان کي اجازت ڏين ٿا ڪيترن ئي دستيابي زونن کي فالتو لاءِ. اسان امڪان تي غور ڪري رهيا آهيون خدمتن لاءِ جيڪي وڏي مقدار ۾ ٽرئفڪ پيدا ڪن ٿيون. هي ڪلستر-سطح جي بيڪارگي کي برقرار رکڻ دوران خارجي خرچن کي گھٽائي ڇڏيندو.
2. حدون، وسيلن جي درخواست ۽ اسڪيلنگ
registry.gitlab.com تي ريپليڪس پروسيسنگ پيداوار ٽرئفڪ جو تعداد. ٽريفڪ جي چوٽي تي ~15:00 UTC.
اسان جي لڏپلاڻ جي ڪهاڻي آگسٽ 2019 ۾ شروع ٿي، جڏهن اسان لڏپلاڻ ڪئي اسان جي پهرين سروس، GitLab ڪنٽينر رجسٽري، Kubernetes ڏانهن. هي مشن-نازڪ، اعلي-ٽريفڪ سروس پهرين لڏپلاڻ لاءِ سٺو انتخاب هو ڇو ته اها ڪجهه خارجي انحصار سان هڪ بي رياست درخواست آهي. پهريون مسئلو جيڪو اسان کي سامهون آيو هو، نوڊس تي ميموري جي کوٽ سبب بيدخل ٿيل پوڊ جو وڏو تعداد هو. ان جي ڪري، اسان کي درخواستون ۽ حدون تبديل ڪرڻو پيو.
اهو دريافت ڪيو ويو ته هڪ ايپليڪيشن جي صورت ۾ جتي ياداشت جو استعمال وقت سان وڌي ٿو، درخواستن لاء گهٽ قدر (هر پوڊ لاء ميموري محفوظ ڪرڻ) سان گڏ استعمال تي "سخاوت" سخت حد سان سنترپتي جو سبب بڻيا. (سنترپشن) نوڊس ۽ هڪ اعلي سطحي بي دخل. هن مسئلي کي منهن ڏيڻ لاء، اهو هو . اهو دٻاءُ بند ڪري ڇڏيو نوڊس ۽ پڪ ڪيو ته پوڊس هڪ لائف سائيڪل هئي جيڪا نوڊ تي تمام گهڻو دٻاءُ نه وجهي. هاڻي اسان لڏپلاڻ شروع ڪريون ٿا سخي (۽ لڳ ڀڳ هڪجهڙائي) درخواستن ۽ حدن جي قدرن سان، انهن کي ضرورت مطابق ترتيب ڏيو.
3. ميٽرڪس ۽ لاگس
انفراسٽرڪچر ڊويزن ويڪرائي، غلطي جي شرح ۽ نصب سان سنترپشن تي ڌيان ڏئي ٿو (SLO) سان ڳنڍيل .
گذريل سال دوران، انفراسٽرڪچر ڊويزن ۾ اهم واقعن مان هڪ آهي SLOs جي نگراني ۽ ڪم ڪرڻ ۾ بهتري. SLOs اسان کي انفرادي خدمتن لاءِ مقصد مقرر ڪرڻ جي اجازت ڏني جيڪا اسان لڏپلاڻ دوران ويجھي نگراني ڪئي. پر ان جي باوجود هن بهتر مشاهدي سان، اهو هميشه ممڪن ناهي ته فوري طور تي ميٽرڪس ۽ الرٽ استعمال ڪندي مسئلا ڏسڻ لاء. مثال طور، ويڪرائي ۽ نقص جي شرحن تي ڌيان ڏيڻ سان، اسان لڏپلاڻ کان گذرندڙ خدمت لاءِ استعمال جي سڀني ڪيسن کي مڪمل طور تي ڍڪي نه ٿا ڏيون.
اهو مسئلو دريافت ڪيو ويو تقريبا فوري طور تي لڏپلاڻ کان پوء ڪجهه ڪم لوڊ ڪلستر ڏانهن. اهو خاص طور تي شديد ٿي ويو جڏهن اسان کي انهن ڪمن جي جانچ ڪرڻي هئي جنهن لاءِ درخواستن جو تعداد ننڍڙو هو، پر جن ۾ تمام مخصوص تشڪيل جي انحصار هئي. لڏپلاڻ مان هڪ اهم سبق اهو هو ته مانيٽرنگ ڪرڻ وقت نه رڳو ميٽرڪس کي، پر لاگ ۽ ”ڊگهي دم“ کي به نظر ۾ رکڻو پوندو. (هي بابت آهي چارٽ تي - تقريبن. ترجمو.) غلطيون. ھاڻي ھر لڏپلاڻ لاءِ اسان لاگ سوالن جي تفصيلي لسٽ شامل ڪريون ٿا (لاگ سوال) ۽ واضح رول بيڪ طريقيڪار جو منصوبو ٺاهيو جيڪو هڪ شفٽ کان ٻئي ڏانهن منتقل ڪري سگهجي ٿو جيڪڏهن مسئلا پيدا ٿين ٿا.
ساڳئي درخواستن جي خدمت ڪندي متوازي ۾ پراڻي VM انفراسٽرڪچر ۽ نئين Kubernetes-based infrastructure هڪ منفرد چئلينج پيش ڪيو. لفٽ ۽ شفٽ لڏپلاڻ جي برعڪس (ايپليڪيشن جي جلدي منتقلي "جيئن آهي" نئين انفراسٽرڪچر ڏانهن؛ وڌيڪ تفصيل پڙهي سگهجن ٿا، مثال طور، - لڳ ڀڳ ترجمو.)"پراڻي" VMs ۽ Kubernetes تي متوازي ڪم جي ضرورت آهي ته مانيٽرنگ ٽولز ٻنهي ماحولن سان مطابقت رکندڙ هجن ۽ ميٽرڪس کي هڪ نظر ۾ گڏ ڪرڻ جي قابل هجن. اهو ضروري آهي ته اسان ساڳئي ڊيش بورڊ ۽ لاگ سوالن کي استعمال ڪريون ته جيئن منتقلي واري عرصي دوران مسلسل مشاهدو حاصل ٿئي.
4. نئين ڪلستر ڏانھن ٽرئفڪ کي تبديل ڪرڻ
GitLab.com لاءِ، سرورز جو حصو وقف ڪيو ويو آھي . ڪينري پارڪ اسان جي اندروني منصوبن جي خدمت ڪري ٿو ۽ پڻ ڪري سگھي ٿو . پر اهو بنيادي طور تي ٺهيل آهي بنيادي طور تي انفراسٽرڪچر ۽ ايپليڪيشن ۾ ڪيل تبديلين کي جانچڻ لاءِ. پهرين لڏپلاڻ واري خدمت هڪ محدود مقدار ۾ اندروني ٽرئفڪ کي قبول ڪندي شروع ڪئي، ۽ اسان اهو طريقو استعمال ڪرڻ جاري رکون ٿا ته يقيني بڻائين ته SLOs کي ڪلستر ڏانهن موڪلڻ کان اڳ پورا ڪيو وڃي.
لڏپلاڻ جي صورت ۾، هن جو مطلب اهو آهي ته اندروني منصوبن لاء درخواستون پهريون ڀيرو ڪبرنيٽس ڏانهن موڪليا ويا آهن، ۽ پوء اسان HAProxy ذريعي پس منظر جي وزن کي تبديل ڪندي ڪلستر جي باقي ٽريفڪ کي آهستي آهستي تبديل ڪندا آهيون. وي ايم کان ڪبرنيٽس ڏانهن لڏپلاڻ دوران، اهو واضح ٿيو ته اهو تمام گهڻو فائدي وارو هو ته پراڻي ۽ نئين انفراسٽرڪچر جي وچ ۾ ٽريفڪ کي ريڊائريڪٽ ڪرڻ جو آسان رستو ۽، مطابق، لڏپلاڻ کان پوءِ پهرين ڪجهه ڏينهن ۾ پراڻي انفراسٽرڪچر کي رولبڪ لاءِ تيار رکو.
5. پوڊ جي گنجائش ۽ انهن جي استعمال کي محفوظ ڪريو
تقريبن فوري طور تي هيٺين مسئلي جي نشاندهي ڪئي وئي: رجسٽري سروس لاءِ پوڊز جلدي شروع ٿي ويا، پر سائڊڪيڪ لاءِ پوڊز کي لانچ ڪرڻ ۾ دير ٿي وئي. . Sidekiq pods لاءِ ڊگھو شروعاتي وقت ھڪڙو مسئلو بڻجي ويو جڏھن اسان ڪم لوڊ ڪرڻ شروع ڪيو Kubernetes ڏانھن مزدورن لاءِ جن کي نوڪرين تي جلدي پروسيس ڪرڻ جي ضرورت ھئي ۽ جلدي ماپي.
هن معاملي ۾، سبق اهو هو ته جڏهن Kubernetes' Horizontal Pod Autoscaler (HPA) ٽرئفڪ جي واڌ کي چڱي طرح سنڀاليندو آهي، اهو ضروري آهي ته ڪم لوڊ جي خاصيتن تي غور ڪيو وڃي ۽ پوڊز لاء اضافي گنجائش مختص ڪرڻ (خاص طور تي جڏهن مطالبو غير مساوي طور تي ورهايو وڃي). اسان جي صورت ۾، نوڪرين ۾ اوچتو اضافو ٿيو، تيز رفتار اسڪيلنگ جي ڪري، جنهن جي نتيجي ۾ سي پي يو وسيلن جي سنترپشن کان اڳ اسان وٽ نوڊ پول کي ماپڻ جو وقت هو.
هتي هميشه هڪ لالچ هوندي آهي جيترو ممڪن حد تائين ڪلستر مان نچوض ڪيو وڃي، جڏهن ته، شروعاتي طور تي ڪارڪردگي جي مسئلن کي منهن ڏيڻ، اسان هاڻي هڪ سخي پوڊ بجيٽ سان شروع ڪري رهيا آهيون ۽ بعد ۾ ان کي گهٽائي رهيا آهيون، SLOs تي ويجهي نظر رکندي. Sidekiq سروس لاءِ پوڊز کي لانچ ڪرڻ تمام تيز ٿي چڪو آھي ۽ ھاڻي تقريباً 40 سيڪنڊ لڳن ٿا. GitLab.com ۽ سرڪاري GitLab هيلم چارٽ سان ڪم ڪندڙ خود منظم تنصيب جي اسان جي صارفين ٻنهي کي فتح ڪيو.
ٿڪل
هر سروس لڏپلاڻ ڪرڻ کان پوء، اسان پيداوار ۾ ڪبرنيٽس استعمال ڪرڻ جي فائدن تي خوش ٿيا: تيز ۽ محفوظ ايپليڪيشن جي ترتيب، اسڪيلنگ، ۽ وڌيڪ موثر وسيلن جي مختص ڪرڻ. ان کان علاوه، لڏپلاڻ جا فائدا GitLab.com سروس کان ٻاهر آهن. سرڪاري هيلم چارٽ ۾ هر سڌارو ان جي استعمال ڪندڙن کي فائدو ڏئي ٿو.
مون کي اميد آهي ته توهان اسان جي ڪبرنيٽس لڏپلاڻ واري مهم جي ڪهاڻي کي لطف اندوز ڪيو. اسان سڀني نئين خدمتن کي ڪلستر ڏانهن منتقل ڪرڻ جاري رکون ٿا. اضافي معلومات هيٺ ڏنل اشاعتن ۾ ملي سگهي ٿي:
- «"؛
- «"؛
- .
پي ايس مترجم کان
اسان جي بلاگ تي پڻ پڙهو:
- «"؛
- «"؛
- «"؛
- «».
جو ذريعو: www.habr.com