DomClick ۾ ڪبرنيٽس: 1000 مائڪرو سروسز جي ڪلسٽر کي منظم ڪندي پرامن ڪيئن سمهڻ

منهنجو نالو Viktor Yagofarov آهي، ۽ مان DomClick تي Kubernetes پليٽ فارم ٺاهي رهيو آهيان هڪ ٽيڪنيڪل ڊولپمينٽ مينيجر طور Ops (آپريشن) ٽيم ۾. مان ڳالهائڻ چاهيندس اسان جي Dev <-> Ops پروسيس جي جوڙجڪ، روس ۾ سڀ کان وڏي k8s ڪلسٽرن مان هڪ کي هلائڻ جي خاصيتن، ۽ گڏوگڏ DevOps/SRE عملن بابت جيڪي اسان جي ٽيم لاڳو ٿين ٿيون.

آپريشن ٽيم

Ops ٽيم ۾ هن وقت 15 ماڻهو آهن. انهن مان ٽي آفيس جا ذميوار آهن، ٻه ڪم مختلف وقت واري علائقي ۾ ۽ دستياب آهن، بشمول رات جو. اهڙيء طرح، Ops مان ڪو ماڻهو هميشه مانيٽر تي آهي ۽ ڪنهن به پيچيدگي جي واقعن جو جواب ڏيڻ لاء تيار آهي. اسان وٽ رات جي شفٽ نه آهي، جيڪا اسان جي نفسيات کي محفوظ ڪري ٿي ۽ هر ڪنهن کي ڪافي ننڊ حاصل ڪرڻ جو موقعو ڏئي ٿي ۽ نه رڳو ڪمپيوٽر تي فرصت جو وقت گذاريو.

هر ڪنهن وٽ مختلف صلاحيتون آهن: نيٽ ورڪرز، ڊي بي ايز، ايل ڪي اسٽيڪ ماهر، ڪبرنيٽس ايڊمن/ ڊولپرز، مانيٽرنگ، ورچوئلائيزيشن، هارڊويئر ماهر، وغيره. ھڪڙي شيءِ سڀني کي متحد ڪري ٿي - ھر ڪو اسان مان ڪنھن کي ڪنھن حد تائين مٽائي سگھي ٿو: مثال طور، k8s ڪلستر ۾ نوان نوڊ متعارف ڪرايا، PostgreSQL کي اپڊيٽ ڪريو، ھڪ CI/CD + جوابي پائپ لائن لکو، Python/Bash/Go ۾ ڪا شيءِ پاڻمرادو ڪريو، هارڊويئر سان ڳنڍيو ڊيٽا سينٽر. ڪنهن به علائقي ۾ مضبوط صلاحيتون توهان کي توهان جي سرگرمي جي رخ کي تبديل ڪرڻ ۽ ڪنهن ٻئي علائقي ۾ بهتر ٿيڻ شروع ڪرڻ کان روڪي نه ٿيون. مثال طور، مان پوسٽ گري ايس ايس ايل جي ماهر جي حيثيت سان هڪ ڪمپني ۾ شامل ٿيو آهيان، ۽ هاڻي منهنجي ذميواري جو مکيه علائقو Kubernetes ڪلسٽرز آهي. ٽيم ۾، ڪنهن به اونچائي خوش آمديد آهي ۽ احساس جو احساس تمام ترقي يافته آهي.

رستي ۾، اسان شڪار ڪري رهيا آهيون. اميدوارن لاءِ گهرجون ڪافي معياري آهن. مون لاء ذاتي طور تي، اهو ضروري آهي ته هڪ شخص ٽيم ۾ شامل ٿئي، غير تڪرار آهي، پر اهو پڻ ڄاڻي ٿو ته هن جي نقطي نظر جو دفاع ڪيئن ڪجي، ترقي ڪرڻ چاهي ٿو ۽ ڪجهه نئين ڪرڻ کان ڊپ نه آهي، پنهنجي خيالن کي پيش ڪري ٿو. انهي سان گڏ، اسڪرپٽنگ ٻولين ۾ پروگرامنگ صلاحيتن، لينڪس ۽ انگريزي جي بنيادي ڄاڻ جي ضرورت آهي. انگريزيءَ جي ضرورت صرف ان ڪري آهي ته جيئن ڪو ماڻهو فيڪاپ جي صورت ۾ گوگل کي 10 سيڪنڊن ۾ مسئلو حل ڪري سگهي نه 10 منٽن ۾. هاڻي لينڪس جي ڄاڻ رکندڙ ماهرن کي ڳولڻ تمام ڏکيو آهي: اها مذاق آهي، پر ٽن مان ٻه اميدوار ان سوال جو جواب نٿا ڏئي سگهن "لوڊ اوسط ڇا آهي؟ اهو ڇا مان ٺهيل آهي؟"، ۽ سوال "ڪيئن هڪ سي پروگرام مان بنيادي ڊمپ کي گڏ ڪرڻ" کي سپرمين جي دنيا مان ڪجهه سمجهيو ويندو آهي ... يا ڊائناسور. اسان کي ان سان گڏ رکڻو پوندو، ڇاڪاڻ ته عام طور تي ماڻهن ٻين صلاحيتن کي انتهائي ترقي ڪئي آهي، پر اسان لينڪس سيکارينداسين. سوال جو جواب "ڇو هڪ DevOps انجنيئر کي اهو سڀ ڪجهه ڄاڻڻ جي ضرورت آهي بادل جي جديد دنيا ۾" مضمون جي دائري کان ٻاهر ڇڏڻو پوندو، پر ٽن لفظن ۾: اهو سڀ ڪجهه گهربل آهي.

ٽيم جا اوزار

اوزار ٽيم آٽوميشن ۾ اهم ڪردار ادا ڪري ٿي. انهن جو بنيادي ڪم ڊولپرز لاءِ آسان گرافڪ ۽ CLI اوزار ٺاهڻ آهي. مثال طور، اسان جي اندروني ڊولپمينٽ ڪانفرنس توهان کي اجازت ڏئي ٿي لفظي طور تي ڪبرنيٽس لاءِ هڪ ايپليڪيشن رول آئوٽ ڪرڻ لاءِ صرف چند ماؤس ڪلڪن سان، ان جي وسيلن کي ترتيب ڏيو، والٽ مان ڪنجيون وغيره. اڳي، جينڪنز + هيلم 2 هو، پر مون کي ڪاپي پيسٽ کي ختم ڪرڻ ۽ سافٽ ويئر لائف سائيڪل ۾ هڪجهڙائي آڻڻ لاءِ پنهنجو اوزار ٺاهڻو هو.

Ops ٽيم ڊولپرز لاء پائپ لائن نه لکندو آهي، پر انهن جي لکڻين ۾ ڪنهن به مسئلن تي مشورو ڏئي سگهي ٿو (ڪجهه ماڻهو اڃا تائين هيلم 3 آهي).

DevOps

جيئن ته DevOps لاء، اسان ان کي هن طرح ڏسون ٿا:

ديو ٽيمون ڪوڊ لکن ٿيون، ان کي ڪنفر کان dev -> qa/stage -> prod ذريعي رول آئوٽ ڪريو. انهي ڳالهه کي يقيني بڻائڻ جي ذميواري آهي ته ڪوڊ سست نه ٿئي ۽ غلطين تي مشتمل نه هجي ديو ۽ اوپس ٽيمن جي آهي. ڏينهن جي وقت، اوپس ٽيم جي ڊيوٽي تي موجود شخص کي سڀ کان پهريان پنهنجي درخواست سان ڪنهن واقعي جو جواب ڏيڻ گهرجي، ۽ شام ۽ رات جي وقت، ڊيوٽي تي منتظم (Ops) کي ڊيوٽي تي ڊولپر کي جاڳائڻ گهرجي جيڪڏهن هو ڄاڻي ٿو. پڪ آهي ته مسئلو بنيادي ڍانچي ۾ نه آهي. مانيٽرنگ ۾ سڀ ميٽرڪ ۽ الرٽ پاڻمرادو يا نيم پاڻمرادو ظاهر ٿيندا آهن.

اوپس جي ذميواري واري علائقي جي شروعات ٿيندي آهي جڏهن کان ايپليڪيشن کي پيداوار ۾ شامل ڪيو ويندو آهي، پر ديو جي ذميواري اتي ختم نه ٿيندي آهي - اسان ساڳيو ڪم ڪندا آهيون ۽ ساڳئي ٻيڙيء ۾ آهيون.

ڊولپرز ايڊمن کي صلاح ڏين ٿا جيڪڏھن انھن کي ايڊمن مائڪرو سروس لکڻ ۾ مدد جي ضرورت آھي (مثال طور، Go backend + HTML5)، ۽ منتظم ڊولپرز کي صلاح ڏين ٿا ڪنھن انفراسٽرڪچر جي مسئلن تي يا k8s سان لاڳاپيل مسئلن تي.

رستي جي ذريعي، اسان وٽ هڪ واحد واحد نه آهي، صرف مائڪرو سروسز. انهن جو تعداد هن وقت تائين 900 ۽ 1000 جي وچ ۾ پروڊ k8s ڪلستر جي وچ ۾ آهي، جيڪڏهن انگ سان ماپيو وڃي نوڪريون. پوڊن جو تعداد 1700 ۽ 2000 جي وچ ۾ ڦري ٿو. ھن وقت پروڊ ڪلستر ۾ اٽڪل 2000 پوڊ آھن.

مان درست انگ نه ٿو ڏئي سگهان، ڇو ته اسان غير ضروري مائڪرو سروسز جي نگراني ڪندا آهيون ۽ انهن کي نيم خودڪار طريقي سان ڪٽيندا آهيون. K8s اسان کي غير ضروري ادارن جي ٽريڪ رکڻ ۾ مدد ڪري ٿي بيڪار آپريٽر، جيڪو ڪيترائي وسيلا ۽ پئسا بچائي ٿو.

وسيلن جو انتظام

مانيٽرنگ

چڱي طرح منظم ۽ معلوماتي نگراني وڏي ڪلستر جي آپريشن ۾ بنياد بڻجي ٿي. اسان اڃا تائين هڪ آفاقي حل نه مليو آهي جيڪو 100٪ سڀني نگراني جي ضرورتن کي پورو ڪري، تنهنڪري اسان وقتي طور تي هن ماحول ۾ مختلف ڪسٽم حل ٺاهيندا آهيون.

• زيبڪس. سٺي پراڻي نگراني، جنهن جو مقصد بنيادي طور تي انفراسٽرڪچر جي مجموعي حالت کي ٽريڪ ڪرڻ آهي. اهو اسان کي ٻڌائي ٿو جڏهن هڪ نوڊ پروسيسنگ، ميموري، ڊسڪ، نيٽ ورڪ، وغيره جي لحاظ کان مري ويندو آهي. ڪجھ به مافوق الفطرت نه آهي، پر اسان وٽ ايجنٽن جو هڪ الڳ DaemonSet پڻ آهي، جنهن جي مدد سان، مثال طور، اسان ڪلستر ۾ DNS جي حالت مانيٽر ڪريون ٿا: اسان بيوقوف ڪورڊنس پوڊز کي ڳوليندا آهيون، اسان ٻاهرين ميزبان جي دستيابي جي جانچ ڪندا آهيون. اهو لڳي ٿو ته هن سان پريشان ڇو، پر ٽرئفڪ جي وڏي مقدار سان، هي حصو ناڪامي جو هڪ سنگين نقطو آهي. مان اڳ ۾ ئي بيان ڪيل, مون ڪيئن جدوجهد ڪئي DNS ڪارڪردگي سان ڪلستر ۾.
• Prometheus آپريٽر. مختلف برآمد ڪندڙن جو هڪ سيٽ ڪلستر جي سڀني حصن جو هڪ وڏو جائزو ڏئي ٿو. اڳيون، اسان گرافانا ۾ وڏي ڊيش بورڊ تي هي سڀ ڏسون ٿا، ۽ الرٽ مئنيجر استعمال ڪريو الرٽ لاءِ.

اسان لاء هڪ ٻيو مفيد اوزار هو فهرست ۾ داخل ٿيڻ. اسان ان کي لکيو ته ڪيترائي ڀيرا اسان هڪ اهڙي صورتحال سان منهن ڪيو جتي هڪ ٽيم ٻي ٽيم جي داخل ٿيڻ جا رستا اوورليپ ڪئي، نتيجي ۾ 50x غلطيون. هاڻي پيداوار تي ترتيب ڏيڻ کان اڳ، ڊولپرز چيڪ ڪن ٿا ته ڪو به متاثر نه ٿيندو، ۽ منهنجي ٽيم لاء اهو هڪ سٺو اوزار آهي جيڪو Ingresses سان مسئلن جي ابتدائي تشخيص لاء. اها عجيب ڳالهه آهي ته شروع ۾ اهو ايڊمنز لاءِ لکيو ويو هو ۽ اهو ڏسڻ ۾ نهايت ”گندي“ لڳندو هو، پر ڊول ٽيمن کي ٽول سان پيار ٿيڻ کان پوءِ، اهو گهڻو بدلجي ويو ۽ ائين نه ڏسڻ لڳو ته ”هڪ منتظم منتظمين لاءِ ويب جو منهن ٺاهيو. ” جلد ئي اسان هن اوزار کي ڇڏي ڏينداسين ۽ اهڙين حالتن جي تصديق ڪئي ويندي جيتوڻيڪ پائيپ لائين رول ٿيڻ کان اڳ.

ڪعب ۾ ٽيم وسيلن

ان کان اڳ جو اسان مثالن ۾ وڃون، اهو بيان ڪرڻ جي قابل آهي ته اسان وسيلن کي ڪيئن مختص ڪريون ٿا microservices.

سمجھڻ لاءِ ڪھڙي ٽيمون ۽ ڪھڙي مقدار ۾ انھن کي استعمال ڪن ٿيون وسيلا (پروسيسر، ميموري، مقامي ايس ايس ڊي)، اسان هر حڪم کي پنهنجو پاڻ کي مختص ڪندا آهيون نالو "ڪيوب" ۾ ۽ پروسيسر، ميموري ۽ ڊسڪ جي لحاظ کان ان جي وڌ ۾ وڌ صلاحيتن کي محدود ڪريو، اڳ ۾ ٽيمن جي ضرورتن تي بحث ڪيو ويو. ان جي مطابق، هڪ حڪم، عام طور تي، سڄي ڪلستر کي ترتيب ڏيڻ لاء بلاڪ نه ڪندو، هزارين ڪور ۽ ميموري جي terabytes مختص ڪندي. نالي جي جڳھ تائين رسائي AD ذريعي ڏني وئي آھي (اسان استعمال ڪندا آھيون RBAC). نالا اسپيسز ۽ انهن جون حدون شامل ڪيون ويون آهن هڪ پل جي درخواست ذريعي GIT مخزن ڏانهن، ۽ پوءِ هر شيءِ پاڻمرادو جوابي پائپ لائن ذريعي ختم ٿي ويندي آهي.

ھڪڙي ٽيم کي وسيلن کي مختص ڪرڻ جو ھڪڙو مثال:

namespaces:

  chat-team:
    pods: 23
    limits:
      cpu: 11
      memory: 20Gi
    requests:
      cpu: 11
      memory: 20Gi

درخواستون ۽ حدون

ڪڇ" درخواست جي لاءِ ضمانت ٿيل محفوظ وسيلن جو تعداد آهي پوڊ (هڪ يا وڌيڪ ڊاکر ڪنٽينر) هڪ ڪلستر ۾. حد هڪ غير گارنٽيڊ وڌ ۾ وڌ آهي. توهان اڪثر گرافس تي ڏسي سگهو ٿا ته ڪيئن ڪجهه ٽيم پنهنجي سڀني ايپليڪيشنن لاءِ تمام گهڻيون درخواستون پاڻ کي سيٽ ڪيون آهن ۽ ايپليڪيشن کي ”ڪيوب“ ۾ ڊيپلائي نٿو ڪري سگهي، ڇاڪاڻ ته انهن جي نالي واري جاءِ هيٺ سڀ درخواستون اڳ ۾ ئي ”خرچ“ ٿي چڪيون آهن.

هن صورتحال مان نڪرڻ جو صحيح طريقو اهو آهي ته اصل وسيلن جي استعمال کي ڏسو ۽ ان کي گهربل رقم (درخواست) سان ڀيٽيو وڃي.

مٿي ڏنل اسڪرين شاٽ ۾ توهان ڏسي سگهو ٿا ته ”درخواست ڪيل“ سي پي يوز ٿريڊز جي حقيقي تعداد سان ملن ٿيون، ۽ حدون CPU ٿريڊز جي حقيقي تعداد کان وڌي سگهن ٿيون =)

هاڻي اچو ته ڪجهه نيمس اسپيس کي تفصيل سان ڏسون (مون نالو اسپيس ڪيوبي-سسٽم چونڊيو آهي - سسٽم جو نالو اسپيس پاڻ ”ڪيوب“ جي اجزاء لاءِ) ۽ ڏسو اصل ۾ استعمال ٿيل پروسيسر جي وقت ۽ ميموري جو تناسب درخواست ڪيل هڪ سان:

اهو ظاهر آهي ته گهڻو وڌيڪ ياداشت ۽ سي پي يو اصل ۾ استعمال ٿيل سسٽم جي خدمتن لاء محفوظ آهي. ڪيب-سسٽم جي صورت ۾، اهو جائز آهي: اهو ٿيو آهي ته نينڪس انگريس ڪنٽرولر يا نوڊيلوڪلڊنس پنهنجي چوٽي تي سي پي يو کي ماريو ۽ تمام گهڻو رام استعمال ڪيو، تنهنڪري هتي اهڙي رزرو جائز آهي. ان کان علاوه، اسين آخري 3 ڪلاڪن لاءِ چارٽ تي ڀروسو نٿا ڪري سگھون: اھو گھربل آھي ته تاريخي ماپن کي وڏي عرصي دوران ڏسڻ لاءِ.

"سفارش" جو هڪ نظام ٺاهي وئي. مثال طور، هتي توهان ڏسي سگهو ٿا ته ڪهڙا وسيلا بهتر هوندا ته ”حدود“ (مٿين اجازت واري بار) کي وڌائڻ لاءِ ته جيئن ”ٿڙڪڻ“ نه ٿئي: اهو لمحو جڏهن هڪ وسيلو اڳ ۾ ئي مختص ڪيل وقت جي سلائس ۾ سي پي يو يا ميموري خرچ ڪري چڪو آهي ۽ انتظار ڪري رهيو آهي جيستائين اهو "اڻ منجمد" ٿيندو:

۽ هتي اهي پوڊ آهن جيڪي انهن جي بک کي روڪڻ گهرجي:

تي گلا ڪرڻ + وسيلن جي نگراني، توهان هڪ کان وڌيڪ مضمون لکي سگهو ٿا، تنهن ڪري تبصرن ۾ سوال پڇو. ٿورن لفظن ۾، مان اهو چئي سگهان ٿو ته اهڙين ميٽرڪس کي خودڪار ڪرڻ جو ڪم تمام ڏکيو آهي ۽ تمام گهڻو وقت ۽ توازن جي عمل جي ضرورت آهي "ونڊو" افعال ۽ "CTE" Prometheus / VictoriaMetrics (اهي اصطلاح حوالن ۾ آهن، ڇاڪاڻ ته اتي تقريبا PromQL ۾ هن وانگر ڪجھ به ناهي، ۽ توهان کي خوفناڪ سوالن کي متن جي ڪيترن ئي اسڪرينن ۾ ورهائڻو پوندو ۽ انهن کي بهتر ڪرڻو پوندو).

نتيجي طور، ڊولپرز وٽ اوزار آھن انھن جي نالن جي جڳھن جي نگراني ڪرڻ لاءِ Cube ۾، ۽ اھي پاڻ لاءِ چونڊ ڪرڻ جي قابل آھن ته ڪٿي ۽ ڪھڙي وقت ڪھڙي ايپليڪيشنن وٽ سندن وسيلا ”ڪٽ“ ٿي سگھن ٿا، ۽ ڪھڙي سرور کي سڄي رات پوري سي پي يو ڏئي سگھجي ٿو.

طريقا

ڪمپني ۾ جيئن ته هاڻي آهي فيشن وارو، اسان DevOps تي عمل ڪريون ٿا- ۽ SRE- عملي جڏهن هڪ ڪمپني وٽ 1000 مائڪرو سروسز، اٽڪل 350 ڊولپرز ۽ 15 ايڊمنز پوري انفراسٽرڪچر لاءِ آهن، توهان کي ”فيشنيبل“ ٿيڻو پوندو: انهن سڀني ”بيسورڊس“ جي پويان هر شيءِ ۽ هر ڪنهن کي خودڪار ڪرڻ جي سخت ضرورت آهي، ۽ منتظمين کي رڪاوٽ نه هئڻ گهرجي. عملن ۾.

Ops جي طور تي، اسان خدمت جي جواب جي شرحن ۽ غلطين سان لاڳاپيل ڊولپرز لاءِ مختلف ميٽرڪس ۽ ڊيش بورڊ فراهم ڪندا آهيون.

اسان طريقا استعمال ڪندا آهيون جهڙوڪ: ڳاڙهو, USE и گولڊن سگنلانهن کي گڏ ڪرڻ سان. اسان ڪوشش ڪريون ٿا ته ڊيش بورڊن جو تعداد گھٽ ۾ گھٽ ڪيو وڃي ته جيئن هڪ نظر ۾ اهو واضح ٿئي ته ڪهڙي خدمت هن وقت خراب ٿي رهي آهي (مثال طور، جوابي ڪوڊس في سيڪنڊ، جوابي وقت 99 سيڪڙو جي حساب سان)، وغيره. جيئن ئي عام ڊيش بورڊ لاءِ ڪجهه نوان ميٽرڪس ضروري ٿي وڃن ٿا، اسان فوري طور تي ٺاهي ۽ شامل ڪريون ٿا.

مون هڪ مهيني تائين گراف نه ٺاهيا آهن. اهو شايد هڪ سٺي نشاني آهي: ان جو مطلب آهي ته "گهرڻ" مان گهڻا اڳ ۾ ئي محسوس ڪيا ويا آهن. اهو ٿيو ته هفتي دوران آئون ڏينهن ۾ گهٽ ۾ گهٽ هڪ ڀيرو ڪجهه نئون گراف ٺاهيندس.

نتيجو نتيجو قيمتي آهي ڇو ته هاڻي ڊولپر تمام گهٽ ئي سوالن سان منتظمين ڏانهن ويندا آهن "ڪٿي ڏسڻ لاء ڪنهن قسم جي ميٽرڪ."

عمل درآمد سروس ميش صرف ڪنڊ جي چوڌاري آهي ۽ هر ڪنهن لاءِ زندگي کي تمام گهڻو آسان بڻائڻ گهرجي، ٽولز جا ساٿي اڳ ۾ ئي خلاصي تي عمل ڪرڻ جي ويجهو آهن “هڪ صحتمند ماڻهو جو اسٽيو”: هر HTTP(ن) جي درخواست جي زندگي جي چڪر مانيٽرنگ ۾ نظر ايندي، ۽ اهو سمجھڻ لاءِ هميشه ممڪن ٿيندو ”ڪهڙي اسٽيج تي سڀ ڪجهه ٽٽي ويو“ انٽر سروس (۽ نه رڳو) رابطي دوران. DomClick هب کان خبرن جي رڪنيت حاصل ڪريو. =)

Kubernetes انفراسٹرڪچر سپورٽ

تاريخي طور تي، اسان پيچ ٿيل نسخو استعمال ڪندا آهيون ڪبي اسپري - ڪبرنيٽس کي ترتيب ڏيڻ، وڌائڻ ۽ اپڊيٽ ڪرڻ لاءِ جوابي ڪردار. ڪجهه نقطي تي، غير kubeadm تنصيب جي حمايت کي مکيه شاخ مان ڪٽيو ويو، ۽ kubeadm کي تبديل ڪرڻ جو عمل تجويز نه ڪيو ويو. نتيجي طور، سائوٿ برج ڪمپني پنهنجو پنهنجو فورڪ ٺاهيو (ڪيوبيڊم سپورٽ سان ۽ نازڪ مسئلن لاءِ تڪڙو حل).

سڀ k8s ڪلستر کي اپڊيٽ ڪرڻ جو عمل هن طرح نظر اچي ٿو:

• وٺ ڪبي اسپري Southbridge کان، اسان جي سلسلي سان چيڪ ڪريو، Merjim.
• اسان تازه ڪاري ڪري رهيا آهيون دٻاء- "ڪيوب".
• اسان ھڪ وقت ۾ ھڪڙي نوڊ کي اپڊيٽ ڪندا آھيون (جواب ۾ ھي آھي ”سيريل: 1“) ديو- "ڪيوب".
• اسان تازه ڪاري ڪريون ٿا Prod ڇنڇر جي شام تي هڪ وقت ۾ هڪ نوڊ.

مستقبل ۾ ان کي تبديل ڪرڻ جو منصوبو آهي ڪبي اسپري ڪجھ تيزيءَ لاءِ ۽ وڃو kubeadm.

مجموعي طور تي اسان وٽ ٽي "ڪيوب" آهن: دٻاء، ديو ۽ پروڊ. اسان هڪ ٻيو لانچ ڪرڻ جي منصوبابندي ڪري رهيا آهيون (گرم اسٽينڊ بائي) پروڊ- "ڪيوب" ٻئي ڊيٽا سينٽر ۾. دٻاء и ديو ”ورچوئل مشينن“ ۾ رهن ٿا (اوورٽ فار اسٽريس ۽ وي ايم ويئر ڪلائوڊ لاءِ ديو). Prod- ”ڪيوب“ ”ننگي ڌاتو“ تي رهي ٿو: اهي هڪجهڙا نوڊس آهن جن سان 32 سي پي يو ٿريڊز، 64-128 GB ميموري ۽ 300 GB SSD RAID 10- انهن مان ڪل 50 آهن. ٽي "پتلي" نوڊس "ماسٽرز" لاء وقف آهن Prod- "ڪيوبا": 16 GB ياداشت، 12 سي پي يو موضوع.

سيلز لاء، اسان "ننگي ڌاتو" استعمال ڪرڻ کي ترجيح ڏيندا آهيون ۽ غير ضروري پرتن کان بچڻ جهڙوڪ OpenStack: اسان کي ”شور پاڙيسري“ ۽ سي پي يو جي ضرورت ناهي وقت چوري ڪرڻ. ۽ انتظاميه جي پيچيدگي تقريبن ٻيڻو ٿي وڃي ٿي اندر جي صورت ۾ OpenStack جي صورت ۾.

CI/CD “ڪيوبڪ” ۽ ٻين انفراسٽرڪچر حصن لاءِ اسان هڪ الڳ GIT سرور استعمال ڪريون ٿا، هيلم 3 (هي هيلم 2 کان بلڪه دردناڪ منتقلي هئي، پر اسان اختيارن سان ڏاڍا خوش آهيون. جوهر)، جينڪنز، جوابي ۽ ڊڪر. اسان کي پسند آهي خصوصيت شاخون ۽ هڪ مخزن کان مختلف ماحول ۾ ترتيب ڏيڻ.

ٿڪل

اهو آهي، عام اصطلاحن ۾، ڊيو اوپس جو عمل ڇا نظر اچي ٿو DomClick تي هڪ آپريشن انجنيئر جي نقطه نظر کان. مضمون منهنجي توقع کان گهٽ ٽيڪنيڪل ثابت ٿيو: تنهن ڪري، Habré تي DomClick خبرن جي پيروي ڪريو: ڪبرنيٽس ۽ وڌيڪ بابت وڌيڪ ”سخت“ مضمون هوندا.

جو ذريعو: www.habr.com