ڪبرنيٽس ڏانهن ٽينڊر جي منتقلي

نوٽ. ترجمو: دنيا جي مشهور ٽينڊر سروس جي ملازمن تازو ڪجهه ٽيڪنيڪل تفصيل شيئر ڪيا آهن انهن جي انفراسٽرڪچر کي Kubernetes ڏانهن منتقل ڪرڻ جي. ان عمل کي لڳ ڀڳ ٻه سال لڳي ويا ۽ نتيجي ۾ K8s تي تمام وڏي پيماني تي پليٽ فارم جي شروعات ٿي، جنهن ۾ 200 هزار ڪنٽينرز تي ميزباني ڪيل 48 سروسز شامل آهن. ٽينڊر انجنيئرن کي ڪهڙيون دلچسپ مشڪلاتون پيش آيون ۽ ڪهڙا نتيجا نڪتا؟ هي ترجمو پڙهو.

ڇو؟

لڳ ڀڳ ٻه سال اڳ، Tinder فيصلو ڪيو ته ان جي پليٽ فارم کي Kubernetes ڏانهن منتقل ڪيو وڃي. ڪبرنيٽس ٽينڊر ٽيم کي اجازت ڏيندو ته ڪنٽينر ڪرڻ ۽ پيداوار ڏانهن منتقل ڪرڻ جي لاءِ گهٽ ۾ گهٽ ڪوشش سان غير تبديل ٿيندڙ تعیناتي ذريعي (مٽڻ لائق مقرري). انهي صورت ۾، ايپليڪيشنن جي اسيمبلي، انهن جي ترتيب، ۽ انفراسٽرڪچر پاڻ کي منفرد طور تي ڪوڊ ذريعي بيان ڪيو ويندو.

اسان پڻ اسڪاليبلٽي ۽ استحڪام جي مسئلي جو حل ڳولي رهيا هئاسين. جڏهن اسڪيلنگ نازڪ بڻجي وئي، اسان کي اڪثر ڪري ڪيترن ئي منٽن جو انتظار ڪرڻو پوندو هو نئين EC2 مثالن لاءِ گھمڻ لاءِ. ڪنٽينر لانچ ڪرڻ ۽ منٽن بدران سيڪنڊن ۾ ٽريفڪ سروس شروع ڪرڻ جو خيال اسان لاءِ ڏاڍو پرڪشش ٿيو.

اهو عمل مشڪل ثابت ٿيو. 2019 جي شروعات ۾ اسان جي لڏپلاڻ دوران، ڪبرنيٽس ڪلستر نازڪ ماس تي پهچي ويو ۽ اسان ٽرئفڪ جي مقدار، ڪلستر جي سائيز، ۽ DNS جي ڪري مختلف مسئلن کي منهن ڏيڻ شروع ڪيو. رستي ۾، اسان 200 خدمتن جي لڏپلاڻ ۽ 1000 نوڊس، 15000 پوڊس ۽ 48000 هلندڙ ڪنٽينرز تي مشتمل Kubernetes ڪلستر کي برقرار رکڻ سان لاڳاپيل ڪيترائي دلچسپ مسئلا حل ڪيا.

ڪيئن؟

جنوري 2018 کان وٺي، اسان لڏپلاڻ جي مختلف مرحلن مان گذري چڪا آهيون. اسان پنهنجون سموريون خدمتون ڪنٽينر ڪرڻ سان شروع ڪيون ۽ انهن کي ڪبرنيٽس ٽيسٽ ڪلائوڊ ماحول ۾ ترتيب ڏيڻ سان. آڪٽوبر ۾ شروع ڪندي، اسان طريقي سان سڀني موجوده خدمتن کي Kubernetes ڏانهن منتقل ڪرڻ شروع ڪيو. ايندڙ سال جي مارچ تائين، اسان لڏپلاڻ مڪمل ڪئي ۽ ھاڻي Tinder پليٽ فارم خاص طور تي Kubernetes تي ھلندو آھي.

Kubernetes لاءِ عمارت جون تصويرون

اسان وٽ 30 کان وڌيڪ سورس ڪوڊ ريپوزٽريون آھن مائڪرو سروسز لاءِ جيڪي ڪبرنيٽس ڪلستر تي ھلنديون آھن. انهن مخزن ۾ ڪوڊ مختلف ٻولين ۾ لکيو ويو آهي (مثال طور، Node.js، Java، Scala، Go) هڪ ئي ٻولي لاءِ گھڻن رن ٽائم ماحول سان.

تعميراتي نظام هر مائڪرو سروس لاءِ مڪمل طور تي حسب ضرورت ”تعمير جي حوالي سان“ مهيا ڪرڻ لاءِ ٺهيل آهي. اهو عام طور تي هڪ Dockerfile ۽ شيل حڪمن جي هڪ فهرست تي مشتمل آهي. انهن جو مواد مڪمل طور تي حسب ضرورت آهي، ۽ ساڳئي وقت، اهي سڀئي تعميراتي حوالا هڪ معياري شڪل جي مطابق لکيل آهن. معيار جي تعمير جي حوالي سان هڪ واحد تعميراتي نظام کي سڀني مائڪرو سروسز کي سنڀالڻ جي اجازت ڏئي ٿي.

شڪل 1-1. بلڊر ڪنٽينر ذريعي معياري تعميراتي عمل

رن ٽائمز جي وچ ۾ وڌ کان وڌ استحڪام حاصل ڪرڻ لاءِ (رن ٽائم ماحول) ساڳئي تعمير جو عمل ترقي ۽ جاچ دوران استعمال ڪيو ويندو آهي. اسان هڪ تمام دلچسپ چئلينج کي منهن ڏنو: اسان کي پوري پليٽ فارم تي تعميراتي ماحول جي استحڪام کي يقيني بڻائڻ لاء هڪ طريقو ٺاهيو هو. هن کي حاصل ڪرڻ لاء، سڀني اسيمبليء جي عمل کي هڪ خاص ڪنٽينر اندر اندر ڪيو ويندو آهي. تعمير ڪرڻ وارو.

هن جي ڪنٽينر تي عمل درآمد جي ضرورت آهي جديد ڊاکر ٽيڪنالاجي. بلڊر کي وراثت ۾ ملي ٿو مقامي يوزر آئي ڊي ۽ راز (جهڙوڪ SSH ڪي، AWS سندون وغيره) پرائيويٽ ٽينڊر ريپوزٽريز تائين رسائي جي ضرورت آهي. اهو ماڳن تي مشتمل مقامي ڊائريڪٽرن تي مشتمل آهي قدرتي طور تي تعميراتي نمونن کي ذخيرو ڪرڻ لاء. اهو طريقو ڪارڪردگي کي بهتر بڻائي ٿو ڇو ته اهو بلڊر ڪنٽينر ۽ ميزبان جي وچ ۾ تعميراتي نمونن کي نقل ڪرڻ جي ضرورت کي ختم ڪري ٿو. ذخيرو ٿيل تعميراتي نمونا بغير اضافي ترتيبن جي ٻيهر استعمال ڪري سگھجن ٿيون.

ڪجهه خدمتن لاءِ، اسان کي هڪ ٻيو ڪنٽينر ٺاهڻو پيو ته ترتيب ڏيڻ واري ماحول کي رن ٽائم ماحول ۾ نقشو ڪرڻ لاءِ (مثال طور، Node.js bcrypt لائبريري انسٽاليشن دوران پليٽ فارم جي مخصوص بائنري نموني ٺاهي ٿي). تاليف جي عمل دوران، ضرورتون مختلف ٿي سگهن ٿيون خدمتن جي وچ ۾، ۽ حتمي ڊاکرفائل اڏام تي مرتب ڪيو ويو آهي.

ڪبرنيٽس ڪلستر آرڪيٽيڪچر ۽ لڏپلاڻ

ڪلستر سائيز جو انتظام

اسان استعمال ڪرڻ جو فيصلو ڪيو kube-aws Amazon EC2 مثالن تي خودڪار ڪلستر جي جوڙجڪ لاءِ. شروعات ۾، هر شيء هڪ عام تلاء جي نوڊس ۾ ڪم ڪيو. اسان جلدي محسوس ڪيو ڪم لوڊ کي سائيز ۽ مثال جي قسم جي لحاظ کان الڳ ڪرڻ جي ضرورت آهي وسيلن جو وڌيڪ موثر استعمال ڪرڻ لاءِ. منطق اهو هو ته ڪيترن ئي لوڊ ٿيل ملٽي-ٽيڊڊ پوڊز کي هلائڻ سان ڪارڪردگي جي لحاظ کان وڌيڪ پيش گوئي ٿي سگهي ٿي انهن جي هڪجهڙائي جي ڀيٽ ۾ هڪ وڏي تعداد ۾ واحد ٿريڊ پوڊس سان.

آخر ۾ اسان ٺهرايو:

• m5.4x وڏو - نگراني لاء (Prometheus)؛
• c5.4x وڏو - Node.js ڪم لوڊ لاءِ (اڪيلو موضوع وارو ڪم لوڊ)؛
• c5.2x وڏو - جاوا ۽ گو لاءِ (گهڻ ٿريڊ ٿيل ڪم لوڊ)؛
• c5.4x وڏو - ڪنٽرول پينل لاءِ (3 نوڊس).

لڏپلاڻ

پراڻي انفراسٽرڪچر کان Kubernetes ڏانهن لڏپلاڻ لاء تياري جي قدمن مان هڪ هو نئين لوڊ بيلنسرز (لچڪدار لوڊ بيلنسرز (ELB) ڏانهن خدمتن جي وچ ۾ موجوده سڌي رابطي کي ريڊائر ڪرڻ. اهي هڪ ورچوئل پرائيويٽ ڪلائوڊ (VPC) جي مخصوص ذيلي نيٽ تي ٺاهيا ويا. هي سب نيٽ ڪبرنيٽس VPC سان ڳنڍيل هو. هن اسان کي اجازت ڏني ته ماڊلز کي تدريجي طور تي لڏپلاڻ ڪري، بغير خدمت جي انحصار جي مخصوص ترتيب تي غور ڪرڻ جي.

اهي آخري پوائنٽون ٺاهيا ويا هئا وزن ٿيل سيٽ DNS ريڪارڊز جي استعمال سان جيڪي CNAMEs هر نئين ELB ڏانهن اشارو ڪندا هئا. مٽائڻ لاءِ، اسان ڪبرنيٽس سروس جي نئين ELB ڏانهن اشارو ڪندي هڪ نئين انٽري شامل ڪئي جنهن جو وزن 0 آهي. اسان ان کان پوءِ داخلا سيٽ جي ٽائم ٽو لائيو (TTL) کي 0 تي مقرر ڪيو. ان کان پوءِ، پراڻا ۽ نوان وزن هئا. آهستي آهستي ترتيب ڏني وئي، ۽ آخرڪار لوڊ جو 100٪ نئين سرور ڏانهن موڪليو ويو. سوئچنگ مڪمل ٿيڻ کان پوء، TTL قدر وڌيڪ مناسب سطح تي واپس آيو.

جاوا ماڊل جيڪي اسان وٽ هئا اهي گهٽ TTL DNS سان مقابلو ڪري سگھن ٿا، پر نوڊ ايپليڪيشنون نه ٿي سگھيون. انجنيئرن مان هڪ ڪنيڪشن پول ڪوڊ جو حصو ٻيهر لکيو ۽ ان کي مينيجر ۾ لپيٽيو جيڪو هر 60 سيڪنڊن ۾ تلاءَ کي اپڊيٽ ڪري ٿو. چونڊيل طريقو تمام سٺو ڪم ڪيو ۽ بغير ڪنهن قابل ذڪر ڪارڪردگي جي خرابي جي.

سبق

نيٽ ورڪ فيبرڪ جون حدون

8 جنوري 2019 جي صبح جو، ٽينڊر پليٽ فارم غير متوقع طور تي تباهه ٿي ويو. انهي صبح جو پليٽ فارم جي ويڪرائي ۾ اڻ لاڳاپيل اضافو جي جواب ۾، ڪلستر ۾ پوڊ ۽ نوڊس جو تعداد وڌي ويو. اهو اسان جي سڀني نوڊس تي ARP ڪيش ختم ٿيڻ جو سبب بڻيو.

ARP ڪيش سان لاڳاپيل ٽي لينڪس آپشن آهن:

(ذريعو)

gc_thresh3 - هي هڪ سخت حد آهي. لاگ ۾ ”پاڙيسري ٽيبل اوور فلو“ داخل ٿيڻ جو مطلب اهو ٿيو ته هم وقت ساز گاربيج ڪليڪيشن (GC) کان پوءِ به، ARP ڪيش ۾ ايتري جاءِ نه هئي ته پاڙيسري داخلا کي محفوظ ڪري سگهي. انهي حالت ۾، ڪنييل صرف پيڪٽ کي مڪمل طور تي رد ڪري ڇڏيو.

اسان استعمال ڪريون ٿا فلاليل Kubernetes ۾ نيٽ ورڪ جي ڪپڙي جي طور تي. پيڪيٽ VXLAN تي منتقل ڪيا ويا آهن. VXLAN هڪ L2 سرنگ آهي جيڪو L3 نيٽ ورڪ جي چوٽي تي اٿاريو ويو آهي. ٽيڪنالاجي MAC-in-UDP (MAC Address-in-User Datagram Protocol) encapsulation استعمال ڪري ٿي ۽ Layer 2 نيٽ ورڪ حصن جي توسيع جي اجازت ڏئي ٿي. جسماني ڊيٽا سينٽر نيٽ ورڪ تي ٽرانسپورٽ پروٽوڪول IP پلس UDP آهي.

شڪل 2-1. فلانيل خاڪو (ذريعو)

شڪل 2-2. VXLAN پيڪيج (ذريعو)

هر ڪبرنيٽس ڪم ڪندڙ نوڊ هڪ ورچوئل ايڊريس اسپيس مختص ڪري ٿو /24 ماسڪ سان وڏي /9 بلاڪ کان. هر نوڊ لاء هي آهي مطلب هڪ داخلا روٽنگ ٽيبل ۾، هڪ داخلا ARP ٽيبل ۾ (فلانيل.1 انٽرفيس تي)، ۽ هڪ داخلا سوئچنگ ٽيبل (FDB) ۾. اهي شامل ڪيا ويا آهن پهريون ڀيرو هڪ ورڪر نوڊ شروع ڪيو ويو آهي يا هر دفعي هڪ نئون نوڊ دريافت ڪيو ويو آهي.

اضافي طور تي، نوڊ-پوڊ (يا پوڊ-پوڊ) مواصلات آخرڪار انٽرفيس ذريعي وڃي ٿو eth0 (جيئن مٿي ڏيکاريل فلانيل ڊراگرام ۾). هي نتيجو هر هڪ لاڳاپيل ماخذ ۽ منزل جي ميزبان لاءِ ARP جدول ۾ اضافي داخل ٿيڻ ۾.

اسان جي ماحول ۾، هن قسم جي مواصلات تمام عام آهي. Kubernetes ۾ خدمت جي شين لاء، هڪ ELB ٺاهي وئي آهي ۽ Kubernetes هر نوڊ کي ELB سان رجسٽر ڪري ٿو. ELB پوڊ جي باري ۾ ڪجھ به نه ٿو ڄاڻي ۽ چونڊيل نوڊ پيڪيٽ جي آخري منزل نه ٿي سگھي. نقطو اهو آهي ته جڏهن هڪ نوڊ ELB کان هڪ پيڪٽ وصول ڪري ٿو، اهو سمجهي ٿو ته ان کي ضابطن ۾ رکڻ ۾. iptables هڪ مخصوص خدمت لاءِ ۽ بي ترتيب طور هڪ پوڊ کي ٻئي نوڊ تي چونڊيندو آهي.

ناڪامي جي وقت، ڪلستر ۾ 605 نوڊس موجود هئا. مٿي بيان ڪيل سببن جي ڪري، اها اهميت ختم ڪرڻ لاءِ ڪافي هئي gc_thresh3، جيڪو ڊفالٽ آهي. جڏهن ائين ٿئي ٿو، نه رڳو پيڪيٽ ڇڏڻ شروع ٿين ٿا، پر پوري فلانيل ورچوئل ايڊريس اسپيس هڪ /24 ماسڪ سان گڏ ARP ٽيبل تان غائب ٿي ويندي آهي. نوڊ-پڊ ڪميونيڪيشن ۽ ڊي اين ايس سوالن ۾ مداخلت ڪئي وئي آهي (ڊي اين ايس ڪلستر ۾ ميزباني ڪئي وئي آهي؛ تفصيل لاءِ هن مضمون ۾ بعد ۾ پڙهو).

هن مسئلي کي حل ڪرڻ لاء، توهان کي قيمت وڌائڻ جي ضرورت آهي gc_thresh1, gc_thresh2 и gc_thresh3 ۽ گم ٿيل نيٽ ورڪن کي ٻيهر رجسٽر ڪرڻ لاءِ فلانيل کي ٻيهر شروع ڪريو.

اڻڄاتل DNS اسڪيلنگ

لڏپلاڻ جي عمل دوران، اسان ٽريفڪ کي منظم ڪرڻ لاءِ فعال طور تي DNS استعمال ڪيو ۽ پراڻي انفراسٽرڪچر کان Kubernetes ڏانهن خدمتن کي آهستي آهستي منتقل ڪيو. اسان Route53 ۾ لاڳاپيل RecordSets لاءِ نسبتاً گھٽ TTL قدر مقرر ڪريون ٿا. جڏهن پراڻي انفراسٽرڪچر EC2 مثالن تي هلندو هو، اسان جي حل ڪندڙ ترتيب ڏانهن اشارو ڪيو ايمازون ڊي اين ايس. اسان هن کي تسليم ڪيو ۽ اسان جي خدمتن ۽ Amazon خدمتن تي گهٽ TTL جو اثر (جهڙوڪ DynamoDB) گهڻو ڪري ڪنهن جو به ڌيان نه ويو.

جيئن اسان Kubernetes ڏانهن خدمتون منتقل ڪيون، اسان ڏٺو ته DNS 250 هزار درخواستن تي في سيڪنڊ پروسيس ڪري رهيو هو. نتيجي طور، ايپليڪيشنون DNS سوالن لاء مسلسل ۽ سنجيده ٽائيم آئوٽ جو تجربو ڪرڻ شروع ڪيو. اهو DNS فراهم ڪندڙ کي CoreDNS کي بهتر ڪرڻ ۽ سوئچ ڪرڻ جي ناقابل اعتماد ڪوششن جي باوجود ٿيو (جيڪو چوٽي جي لوڊ تي 1000 ڪورز تي هلندڙ 120 پوڊ تي پهچي ويو).

ٻين ممڪن سببن ۽ حلن جي تحقيق ڪندي، اسان دريافت ڪيو مضمون، نسل جي حالتن کي بيان ڪندي پيڪٽ فلٽرنگ فريم ورڪ کي متاثر ڪري ٿو ناڻو لينڪس ۾. ٽائيم آئوٽ جيڪو اسان ڏٺو، وڌندڙ ڪائونٽر سان گڏ insert_failed Flannel انٽرفيس ۾ مضمون جي نتيجن سان مطابقت هئي.

مسئلو ماخذ ۽ منزل نيٽ ورڪ ايڊريس ٽرانسليشن (SNAT ۽ DNAT) جي اسٽيج تي ٿئي ٿو ۽ بعد ۾ ٽيبل ۾ داخل ٿيڻ ڪنٽرڪ. ھڪڙي ھڪڙي ڪم جي باري ۾ اندروني طور تي بحث ڪيو ويو ۽ ڪميونٽي پاران تجويز ڪيل ڊي اين ايس کي پاڻ کي ڪم ڪندڙ نوڊ ڏانھن منتقل ڪرڻ لاء. هن معاملي ۾:

• SNAT جي ضرورت ناهي ڇو ته ٽرئفڪ نوڊ اندر رهي ٿي. ان کي انٽرفيس ذريعي روٽ ڪرڻ جي ضرورت ناهي eth0.
• DNAT جي ضرورت نه آهي ڇو ته منزل IP نوڊ لاء مقامي آهي، ۽ ضابطن جي مطابق بي ترتيب طور تي منتخب ٿيل پوڊ ناهي iptables.

اسان هن طريقي سان لٺ ڪرڻ جو فيصلو ڪيو. CoreDNS Kubernetes ۾ DaemonSet جي طور تي لڳايو ويو ۽ اسان ان ۾ مقامي نوڊ DNS سرور لاڳو ڪيو solve.conf هر پوڊ هڪ پرچم قائم ڪندي --cluster-dns حڪم ڪوبلٽ . اهو حل DNS ٽائم آئوٽ لاءِ اثرائتو ثابت ٿيو.

بهرحال، اسان اڃا تائين پيڪٽ جي نقصان ۽ انسداد ۾ اضافو ڏٺو insert_failed Flannel انٽرفيس ۾. اهو ڪم جاري رکڻ کان پوءِ لاڳو ڪيو ويو ڇاڪاڻ ته اسان صرف DNS ٽرئفڪ لاءِ SNAT ۽/يا DNAT کي ختم ڪرڻ جي قابل هئاسين. ٻين قسمن جي ٽرئفڪ لاءِ ريس جون حالتون محفوظ ڪيون ويون. خوشقسمتيءَ سان، اسان جا گھڻا پيڪيٽ TCP آھن، ۽ جيڪڏھن ڪو مسئلو ٿئي ٿو ته اھي وري منتقل ڪيا وڃن ٿا. اسان اڃا تائين هر قسم جي ٽرئفڪ لاء مناسب حل ڳولڻ جي ڪوشش ڪري رهيا آهيون.

بهتر لوڊ بيلنسنگ لاءِ نمائندو استعمال ڪريو

جيئن ته اسان واپس لڏپلاڻ جون خدمتون Kubernetes ڏانهن منتقل ڪيون، اسان پوڊ جي وچ ۾ غير متوازن لوڊ جو شڪار ٿيڻ شروع ڪيو. اسان ڏٺا ته HTTP Keepalive سبب ELB ڪنيڪشن لٽجي ويا هر مقرري جي پهرين تيار ڪيل پوڊس تي. اهڙيء طرح، ٽريفڪ جو وڏو حصو موجود پوڊ جي هڪ ننڍڙي سيڪڙو ذريعي گذريو. پهريون حل جيڪو اسان آزمايو آهي ميڪس سرج کي 100٪ تي ترتيب ڏئي رهيو هو بدترين حالتن جي حالتن لاءِ نئين مقرري تي. ان جو اثر غير معمولي ۽ غيرمعمولي ثابت ٿيو، وڏي پيماني تي مقرري جي لحاظ کان.

ٻيو حل جيڪو اسان استعمال ڪيو هو مصنوعي طور تي نازڪ خدمتن لاءِ وسيلن جي درخواستن کي وڌائڻ لاءِ. انهي صورت ۾، ڀرسان رکيل پوڊن کي ٻين ڳري پوڊن جي مقابلي ۾ وڌيڪ ڪم ڪرڻ جي گنجائش هوندي. اهو يا ته ڊگهي عرصي ۾ ڪم نه ڪندو ڇو ته اهو وسيلن جو ضايع ٿيندو. ان کان سواء، اسان جا نوڊ ايپليڪيشنون واحد موضوع وارا هئا ۽، مطابق، صرف هڪ ڪور استعمال ڪري سگھن ٿا. صرف حقيقي حل بهتر لوڊ بيلنس استعمال ڪرڻ هو.

اسان ڊگهي عرصي کان مڪمل طور تي ساراهه ڪرڻ چاهيندا آهيون دوها. موجوده صورتحال اسان کي اجازت ڏني ته ان کي تمام محدود طريقي سان ترتيب ڏيو ۽ فوري نتيجا حاصل ڪريون. Envoy وڏي SOA ايپليڪيشنن لاءِ ٺهيل هڪ اعليٰ ڪارڪردگي، اوپن سورس، پراڪس-XNUMX پراڪسي آهي. اهو ترقي يافته لوڊ بيلنسنگ ٽيڪنالاجي کي لاڳو ڪري سگهي ٿو، بشمول خودڪار ريٽريز، سرڪٽ برڪرز، ۽ عالمي شرح محدود ڪرڻ. (نوٽ. ترجمو: توھان ان بابت وڌيڪ پڙھي سگھو ٿا اهو مضمون Istio بابت، جيڪو ايلچي تي ٻڌل آهي.)

اسان ھيٺ ڏنل ترتيب سان آيا آھيون: ھر پوڊ ۽ ھڪڙي رستي لاءِ ھڪڙو ايلچي سائڊ ڪار رکو، ۽ ڪلستر کي ڪنٽينر سان مقامي طور بندرگاھ ذريعي ڳنڍيو. امڪاني ڇڪتاڻ کي گھٽائڻ لاءِ ۽ هڪ ننڍڙو هٽ ريڊيس برقرار رکڻ لاءِ، اسان هر خدمت لاءِ اينوائي فرنٽ پراڪسي پوڊس جو هڪ فليٽ استعمال ڪيو، هڪ في دستيابي زون (AZ). اهي اسان جي انجنيئرن مان هڪ طرفان لکيل هڪ سادي سروس دريافت انجڻ تي ڀروسو ڪيو جيڪو صرف ڏنل خدمت لاءِ هر AZ ۾ پوڊ جي فهرست واپس ڪري ٿو.

سروس فرنٽ-اينوائيز ان کان پوء هن سروس دريافت ميڪانيزم کي هڪ اپ اسٽريم ڪلستر ۽ رستي سان استعمال ڪيو. اسان مناسب وقت مقرر ڪيو، سڀني سرڪٽ بريڪر سيٽنگن کي وڌايو، ۽ ھڪڙي ناڪامي جي مدد ڪرڻ لاء گھٽ ۾ گھٽ ٻيهر ڪوشش جي ترتيب شامل ڪئي ۽ آسان ترتيبن کي يقيني بڻائي. اسان انهن مان هر هڪ خدمت جي سامهون هڪ TCP ELB رکيا. ايستائين جو اسان جي مکيه پراڪسي پرت مان ڪيپليٽ ڪجهه اينوائي پوڊس تي بيٺا هئا، اهي اڃا به بهتر طريقي سان لوڊ کي سنڀالڻ جي قابل هئا ۽ پس منظر ۾ گهٽ ۾ گهٽ_request ذريعي بيلنس ڪرڻ لاءِ ترتيب ڏنل هئا.

تعیناتي لاءِ، اسان استعمال ڪيو پري اسٽاپ ٿلهو ٻنهي ايپليڪيشن پوڊس ۽ سائڊ ڪار پوڊس تي. ٿلهو سائڊ ڪار ڪنٽينر تي واقع ايڊمن اينڊ پوائنٽ جي اسٽيٽس کي چيڪ ڪرڻ ۾ هڪ غلطي پيدا ڪئي ۽ فعال ڪنيڪشن کي ختم ڪرڻ جي اجازت ڏيڻ لاءِ ڪجهه دير لاءِ سمهي پيو.

انهن مان هڪ سبب جيڪو اسان ايترو جلدي منتقل ڪرڻ جي قابل ٿي ويا هئاسين اهو تفصيلي ميٽرڪس جي ڪري آهي جنهن کي اسان آساني سان هڪ عام پروميٿيس تنصيب ۾ ضم ڪرڻ جي قابل هئاسين. اهو اسان کي ڏسڻ جي اجازت ڏئي ٿو ته ڇا ٿي رهيو آهي جڏهن اسان ترتيب ڏنل ترتيبن جي ماپ ۽ ٽرئفڪ کي ٻيهر ورهايو.

نتيجا فوري ۽ واضح هئا. اسان سڀ کان وڌيڪ غير متوازن خدمتن سان شروع ڪيو، ۽ هن وقت اهو ڪلستر ۾ 12 سڀ کان اهم خدمتن جي سامهون هلندي آهي. هن سال اسان هڪ مڪمل سروس ميش ڏانهن منتقلي جي منصوبابندي ڪري رهيا آهيون وڌيڪ ترقي يافته سروس دريافت، سرڪٽ برڪنگ، آئوٽ ليئر ڳولڻ، شرح محدود ڪرڻ ۽ ٽريڪنگ.

شڪل 3-1. هڪ خدمت جي سي پي يو ڪنورجنشن کي منتقلي دوران ايلچي ڏانهن

آخري نتيجو

هن تجربي ۽ اضافي تحقيق ذريعي، اسان هڪ مضبوط بنيادي ڍانچي ٽيم ٺاهي آهي، جنهن ۾ مضبوط صلاحيتن سان گڏ وڏن ڪبرنيٽس ڪلسٽرن کي ڊزائين ڪرڻ، ترتيب ڏيڻ ۽ هلائڻ ۾. سڀ Tinder انجنيئرن وٽ هاڻي ڄاڻ ۽ تجربو آهي ته ڪنٽينرز کي پيڪيج ڪرڻ ۽ ايپليڪيشنن کي ڪبرنيٽس ۾ ترتيب ڏيڻ لاءِ.

جڏهن پراڻي انفراسٽرڪچر تي اضافي ظرفيت جي ضرورت پيدا ٿي، اسان کي نئين EC2 مثالن کي شروع ڪرڻ لاء ڪيترن ئي منٽن جو انتظار ڪرڻو پيو. ھاڻي ڪنٽينر ھلڻ شروع ڪن ٿا ۽ منٽن جي بدران سيڪنڊن ۾ ٽرئفڪ کي پروسيس ڪرڻ شروع ڪن ٿا. هڪ واحد EC2 مثال تي ڪيترن ئي ڪنٽينرز جي شيڊول پڻ بهتر افقي ڪنسنٽريشن مهيا ڪري ٿي. نتيجي طور، اسان گذريل سال جي مقابلي ۾ 2019 ۾ EC2 جي قيمتن ۾ اهم گهٽتائي جي اڳڪٿي ڪئي.

لڏپلاڻ ۾ لڳ ڀڳ ٻه سال لڳا، پر اسان ان کي مارچ 2019 ۾ مڪمل ڪيو. في الحال، Tinder پليٽ فارم خاص طور تي Kubernetes ڪلستر تي هلندو آهي جنهن ۾ 200 خدمتون، 1000 نوڊس، 15 پوڊس ۽ 000 هلندڙ ڪنٽينرز شامل آهن. انفراسٹرڪچر هاڻي آپريشن ٽيمن جو واحد ڊومين ناهي. اسان جا سڀئي انجنيئر هن ذميواري کي حصيداري ڪن ٿا ۽ صرف ڪوڊ استعمال ڪندي انهن جي ايپليڪيشنن کي تعمير ۽ ترتيب ڏيڻ جي عمل کي ڪنٽرول ڪن ٿا.

پي ايس مترجم کان

اسان جي بلاگ تي آرٽيڪل جو هڪ سلسلو پڻ پڙهو:

• «Kubernetes پيداوار ۾ ڪامياب ڪهاڻيون. حصو 1: 4200 هارٿس ۽ ٽيس ماسٽر اي بي کان».
• «Kubernetes پيداوار ۾ ڪامياب ڪهاڻيون. حصو 2: اتفاق ۽ SAP».
• «Kubernetes پيداوار ۾ ڪامياب ڪهاڻيون. حصو 3: GitHub».
• «Kubernetes پيداوار ۾ ڪامياب ڪهاڻيون. حصو 4: SoundCloud (Prometheus پاران)».
• «Kubernetes پيداوار ۾ ڪامياب ڪهاڻيون. حصو 5: ڊجيٽل بئنڪ Monzo».
• «Kubernetes پيداوار ۾ ڪامياب ڪهاڻيون. حصو 6: بلا بولي».
• «Kubernetes پيداوار ۾ ڪامياب ڪهاڻيون. حصو 7: ڪاروڪ».
• «Kubernetes پيداوار ۾ ڪامياب ڪهاڻيون. حصو 8: Huawei».
• «Kubernetes پيداوار ۾ ڪامياب ڪهاڻيون. حصو 9: CERN ۽ 210 K8s ڪلستر».
• «Kubernetes پيداوار ۾ ڪامياب ڪهاڻيون. حصو 10: Reddit».

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