اي حبر!
اسان نمائندگي ڪريون ٿا Exness پليٽ فارم ٽيم. اڳي، اسان جي ساٿين اڳ ۾ ئي هڪ مضمون لکيو آهي . اڄ اسان Kubernetes ڏانهن لڏپلاڻ جي خدمتن جو تجربو حصيداري ڪرڻ چاهيون ٿا.
شروع ڪرڻ سان، اسان توهان کي ڪجهه نمبر پيش ڪريون ٿا بهتر سمجھڻ لاءِ ته ڇا بحث ڪيو ويندو:
- اسان جو ڊولپمينٽ ڊپارٽمينٽ 100+ ماڻهن تي مشتمل آهي، جنهن ۾ 10 کان وڌيڪ مختلف ٽيمون شامل آهن جن ۾ پاڻمرادو QA، DevOps ۽ Scrum پروسيس شامل آهن. ڊولپمينٽ اسٽيڪ - پٿون، پي ايڇ پي، سي ++، جاوا ۽ گولانگ.
- ٽيسٽ ۽ پيداوار جي ماحول جو اندازو هر هڪ بابت 2000 ڪنٽينرز آهي. اهي هلائي رهيا آهن Rancher v1.6 انهن جي پنهنجي ورچوئلائيزيشن تي ۽ هيٺ VMware.
حرڪت
جيئن ته چوندا آهن، ڪجھ به نه هميشه لاء رهي ٿو، ۽ رينچر ڪافي وقت اڳ نسخو 1.6 جي حمايت جي خاتمي جو اعلان ڪيو. ها، ٽن سالن کان وڌيڪ عرصي ۾ اسان اهو سکيو آهي ته ان کي ڪيئن تيار ڪجي ۽ پيدا ٿيندڙ مسئلن کي حل ڪجي، پر گهڻو ڪري اسان کي انهن مسئلن سان منهن ڏيڻو پوي ٿو جيڪي ڪڏهن به درست نه ٿيندا. Rancher 1.6 پڻ حقن کي جاري ڪرڻ لاء هڪ ossified نظام آهي، جتي توهان يا ته تقريبا سڀ ڪجهه ڪري سگهو ٿا يا ڪجھ به نه.
جيتوڻيڪ ملڪيت جي ورچوئلائيزيشن ڊيٽا اسٽوريج ۽ ان جي سيڪيورٽي تي وڌيڪ ڪنٽرول مهيا ڪيو، اهو آپريٽنگ خرچن تي لاڳو ڪيو ويو جيڪي ڪمپني جي مسلسل ترقي، منصوبن جو تعداد ۽ انهن لاء گهربل ضرورتن کي قبول ڪرڻ ڏکيو هو.
اسان چاهيون ٿا IaC معيارن جي پيروي ڪرڻ ۽، جيڪڏهن ضروري هجي ته، ڪنهن به جاگرافيائي مقام ۾ ۽ وينڊر لاڪ جي بغير، جلدي صلاحيت حاصل ڪرڻ، ۽ انهي کي جلدي ڇڏڻ جي قابل پڻ.
پهريون قدم
سڀ کان پهريان، اسان جديد ٽيڪنالاجيز ۽ حلن تي ڀروسو ڪرڻ چاهيون ٿا جيڪي ٽيمن کي اجازت ڏين ٿيون تيز ترقي واري چڪر ۽ پليٽ فارم سان رابطو ڪرڻ لاءِ آپريشنل خرچن کي گھٽائي جيڪا طاقت فراهم ڪري ٿي.
يقينن، پهرين شيء جيڪا اسان جي ذهن ۾ آئي هئي Kubernetes، پر اسان پرجوش نه ٿيا ۽ ٿوري تحقيق ڪئي ته ڏسو ته اهو صحيح انتخاب هو. اسان صرف اوپن سورس حل جو جائزو ورتو، ۽ هڪ غير منصفانه جنگ ۾، ڪبرنيٽس غير مشروط طور تي کٽيو.
اڳيون سوال آيو ڪلستر ٺاهڻ لاءِ اوزار چونڊڻ جو. اسان سڀ کان وڌيڪ مقبول حلن جو مقابلو ڪيو: ڪوپس، ڪبيسپري، ڪبيڊم.
شروع ڪرڻ لاءِ، kubeadm اسان کي ڏاڍو پيچيدو رستو لڳي رهيو هو، بلڪه هڪ قسم جي ”سائيڪل“ جي موجد وانگر، ۽ ڪوپس وٽ ڪافي لچڪ نه هئي.
۽ فاتح هو:
اسان پنهنجي ورچوئلائيزيشن ۽ AWS سان تجربا ڪرڻ شروع ڪيا، ڪوشش ڪرڻ جي ڪوشش ڪئي ته اسان جي پوئين وسيلن جي انتظام جي نموني سان لڳ ڀڳ هڪجهڙائي، جتي هر ڪنهن هڪ ئي ”ڪلسٽر“ شيئر ڪيو. ۽ ھاڻي اسان وٽ 10 ننڍين ورچوئل مشينن جو پھريون ڪلستر آھي، جن مان ڪجھ AWS ۾ واقع آھن. اسان اتي ٽيمن کي لڏڻ جي ڪوشش ڪرڻ شروع ڪيو، سڀ ڪجهه "سٺو" ٿيڻ لڳي، ۽ ڪهاڻي ختم ٿي سگهي ٿي، پر ...
پهريون مسئلو
جواب اهو آهي ته ڪبسپري ڪهڙي بنياد تي ٺهيل آهي، اهو هڪ اوزار ناهي جيڪو توهان کي IaC جي پيروي ڪرڻ جي اجازت ڏئي ٿو: جڏهن نوڊس کي ڪم ڪرڻ / ختم ڪرڻ، ڪجهه مسلسل غلط ٿي ويو ۽ ڪجهه قسم جي مداخلت جي ضرورت هئي، ۽ جڏهن مختلف OS استعمال ڪندي، راند بڪ مختلف طريقي سان ڪم ڪيو. . جيئن جيئن ڪلستر ۾ ٽيمن ۽ نوڊس جو تعداد وڌندو ويو، تيئن تيئن اسان اهو محسوس ڪرڻ شروع ڪيو ته پلي بڪ مڪمل ٿيڻ ۾ گهڻو وقت وٺي رهيو آهي، ۽ نتيجي ۾ اسان جو رڪارڊ 3,5 ڪلاڪ هو، توهان جو ڇا؟ 🙂
۽ اهو لڳي ٿو kubespray صرف جوابي آهي، ۽ هر شيء پهرين نظر ۾ واضح آهي، پر:
سفر جي شروعات ۾، ڪم صرف AWS ۽ ورچوئلائيزيشن ۾ ظرفيت کي لانچ ڪرڻ هو، پر پوء، جيئن اڪثر ٿئي ٿو، گهرجون تبديل ٿي ويون.
ان جي روشنيءَ ۾، اهو واضح ٿيو ته وسيلن کي هڪ آرڪيسٽريشن سسٽم ۾ گڏ ڪرڻ جو اسان جو پراڻو نمونو مناسب نه هو - ان صورت ۾ جتي ڪلسٽر تمام پري آهن ۽ مختلف مهيا ڪندڙن پاران منظم ڪيا ويا آهن.
وڌيڪ وڌيڪ. جڏهن سڀئي ٽيمون هڪ ئي ڪلستر ۾ ڪم ڪن ٿيون، مختلف خدمتون غلط طور تي نصب ٿيل NodeSelectors سان پرواز ڪري سگهن ٿيون ڪنهن ٻئي ٽيم جي ”پرڏيهي“ ميزبان ڏانهن ۽ اتي وسيلن کي استعمال ڪري سگهي ٿي، ۽ جيڪڏهن داغ مقرر ڪيو ويو، اتي مسلسل درخواستون هيون ته هڪ يا ٻي خدمت ڪم نه ڪري رهي هئي، انساني عنصر جي ڪري صحيح طور تي ورهايل نه آهي. ٻيو مسئلو قيمت جي حساب سان، خاص طور تي نوڊس ۾ خدمتن کي ورهائڻ ۾ مسئلن تي غور ڪندي.
هڪ الڳ ڪهاڻي هئي ملازمن جي حقن جي جاري ڪرڻ: هر ٽيم ڪلستر جي "سر تي" ٿيڻ چاهي ٿي ۽ ان کي مڪمل طور تي منظم ڪري سگهي ٿي، جيڪو مڪمل طور تي تباهي جو سبب بڻجي سگهي ٿو، ڇو ته ٽيمون بنيادي طور تي هڪ ٻئي کان آزاد آهن.
ڪيئن ٿيو
مٿين ڳالهين ۽ ٽيمن جي خواهشن کي نظر ۾ رکندي وڌيڪ آزاد ٿيڻ لاءِ، اسان هڪ سادو نتيجو ڪڍيو: هڪ ٽيم - هڪ ڪلستر.
تنهنڪري اسان کي هڪ ٻيو مليو:
۽ پوءِ ٽيون ڪلستر:
پوءِ اسان سوچڻ شروع ڪيو: چئو ته هڪ سال ۾ اسان جون ٽيمون هڪ کان وڌيڪ ڪلسٽر هونديون؟ مختلف جغرافيائي علائقن ۾، مثال طور، يا مختلف مهيا ڪندڙن جي ڪنٽرول هيٺ؟ ۽ انهن مان ڪجهه چاهين ٿا ته جلدي ڪجهه ٽيسٽن لاءِ عارضي ڪلسٽر کي ترتيب ڏيڻ جي قابل ٿي وڃن.
مڪمل ڪبرنيٽس اچي ها! اهو ڪجهه قسم جو MultiKubernetes آهي، اهو نڪتو.
ساڳئي وقت، اسان سڀني کي ڪنهن نه ڪنهن طريقي سان انهن سڀني ڪلسٽرن کي برقرار رکڻ جي ضرورت پوندي، انهن تائين رسائي کي آساني سان منظم ڪرڻ جي قابل هوندو، انهي سان گڏ نوان ٺاهي سگهندا ۽ پراڻن کي دستي مداخلت کان سواء ختم ڪري ڇڏيندا.
Kubernetes جي دنيا ۾ اسان جي سفر جي شروعات کان وٺي ڪجهه وقت گذري چڪو آهي، ۽ اسان موجود حلن کي ٻيهر جانچڻ جو فيصلو ڪيو. اهو ظاهر ٿيو ته اهو اڳ ۾ ئي مارڪيٽ تي موجود آهي - Rancher 2.2.
اسان جي تحقيق جي پهرئين مرحلي تي، Rancher Labs اڳ ۾ ئي ورجن 2 جو پهريون رليز ڪري چڪو هو، پر جيتوڻيڪ اهو هڪ ڪنٽينر شروع ڪرڻ کان سواءِ خارجي انحصار کان سواءِ ڪجهه پيٽرولن سان يا سرڪاري HELM چارٽ استعمال ڪندي تمام تيز ٿي سگهي ٿو، اهو خام لڳي رهيو هو. اسان کي، ۽ اسان کي خبر نه هئي ته ڇا اسان هن فيصلي تي ڀروسو ڪري سگهون ٿا ته ڇا اهو ترقي يا جلدي ختم ڪيو ويندو. ڪلستر = ڪلڪس پيراڊم UI ۾ خود پڻ اسان کي مناسب نه ڪيو، ۽ اسان RKE سان ڳنڍيل ٿيڻ نٿا چاهيون، ڇاڪاڻ ته اهو هڪ بلڪه تنگ ڌيان وارو اوزار آهي.
نسخو Rancher 2.2 اڳ ۾ ئي هڪ وڌيڪ قابل عمل ظهور هو ۽، گڏو گڏ اڳوڻين سان گڏ، دٻي کان ٻاهر دلچسپ خاصيتن جو هڪ گروپ هو، جهڙوڪ ڪيترن ئي خارجي فراهم ڪندڙن سان انضمام، حقن جي ورهائڻ جو هڪ واحد نقطو ۽ kubeconfig فائلون، هڪ kubectl لانچ ڪرڻ. UI ۾ توهان جي حقن سان تصوير، nested namespaces aka projects.
اتي پڻ ھڪڙي ڪميونٽي اڳ ۾ ئي رينچر 2 جي چوڌاري ٺھيل ھئي، ۽ ھڪڙو مهيا ڪندڙ جنھن کي HashiCorp Terraform سڏيو ويندو ھو ان کي منظم ڪرڻ لاء، جنھن اسان کي ھر شيء کي گڏ ڪرڻ ۾ مدد ڪئي.
ڇا ٿيو
نتيجي طور، اسان ختم ڪيو ھڪڙو ننڍڙو ڪلستر ھلندڙ Rancher سان، ٻين سڀني ڪلسترن تائين رسائي لائق آھي، ۽ ان سان گڏ گھڻا ڪلستر ان سان ڳنڍيل آھن، جن مان ڪنھن تائين پھچڻ جي اجازت ڏني وڃي ٿي جيئن صارف کي ldap ڊاريڪٽري ۾ شامل ڪرڻ جي طور تي. اهو ڪٿي واقع آهي ۽ ڪهڙي فراهم ڪندڙ جا وسيلا استعمال ڪري ٿو.
استعمال ڪندي gitlab-ci ۽ Terraform، ھڪڙو سسٽم ٺاھيو ويو آھي جيڪو توھان کي اجازت ڏئي ٿو ڪنھن ھڪڙي ترتيب جو ڪلستر ٺاھيو ڪلائوڊ فراهم ڪندڙن ۾ يا اسان جي پنھنجي انفراسٽرڪچر ۾ ۽ انھن کي Rancher سان ڳنڍيو. اهو سڀ ڪجهه IaC انداز ۾ ڪيو ويو آهي، جتي هر ڪلستر کي مخزن جي ذريعي بيان ڪيو ويو آهي، ۽ ان جي حالت ورزن ٿيل آهي. ساڳئي وقت، اڪثر ماڊلز خارجي مخزنن مان ڳنڍيا ويندا آهن ته جيئن باقي رهي ٿو ته متغيرن کي پاس ڪرڻ يا مثالن لاءِ توهان جي ڪسٽم ترتيب جي وضاحت ڪرڻ، جيڪا ڪوڊ جي ورهاڱي جي سيڪڙو کي گهٽائڻ ۾ مدد ڪري ٿي.
يقينن، اسان جو سفر ختم ٿيڻ کان پري آهي ۽ اڃا تائين ڪيترائي دلچسپ ڪم آهن، جهڙوڪ ڪم جو هڪ نقطو لاگس ۽ ڪنهن ڪلسٽر جي ميٽرڪس، سروس ميش، هڪ ملٽي ڪلسٽر ۾ لوڊ مينيجمينٽ لاءِ گيٽپس ۽ گهڻو ڪجهه. اسان کي اميد آهي ته توهان اسان جو تجربو دلچسپ ڳوليندا!
مضمون لکيو ويو A. Antipov، A. Ganush، پليٽ فارم انجنيئرز.
جو ذريعو: www.habr.com