🥇 ٹنڈر کوبرنیٹس میں منتقلی

نوٹ. ترجمہ: دنیا کی مشہور ٹنڈر سروس کے ملازمین نے حال ہی میں اپنے انفراسٹرکچر کو Kubernetes میں منتقل کرنے کی کچھ تکنیکی تفصیلات شیئر کیں۔ اس عمل میں تقریباً دو سال لگے اور اس کے نتیجے میں K8s پر ایک بہت بڑے پیمانے پر پلیٹ فارم کا آغاز ہوا، جو 200 ہزار کنٹینرز پر 48 سروسز پر مشتمل ہے۔ ٹنڈر انجینئرز کو کن دلچسپ مشکلات کا سامنا کرنا پڑا اور ان کے کیا نتائج آئے؟ یہ ترجمہ پڑھیں۔

کیوں؟

تقریباً دو سال پہلے، ٹنڈر نے اپنا پلیٹ فارم کوبرنیٹس میں منتقل کرنے کا فیصلہ کیا۔ Kubernetes Tinder ٹیم کو ناقابل تبدیل تعیناتی کے ذریعے کم سے کم کوشش کے ساتھ کنٹینرائز کرنے اور پیداوار میں جانے کی اجازت دے گا۔ (غیر متغیر تعیناتی). اس صورت میں، ایپلی کیشنز کی اسمبلی، ان کی تعیناتی، اور بنیادی ڈھانچہ خود کوڈ کے ذریعہ منفرد طور پر بیان کیا جائے گا۔

ہم اسکیل ایبلٹی اور استحکام کے مسئلے کا حل بھی تلاش کر رہے تھے۔ جب اسکیلنگ اہم ہو گئی، ہمیں اکثر نئے EC2 مثالوں کے گھومنے کے لیے کئی منٹ انتظار کرنا پڑتا تھا۔ کنٹینرز کو لانچ کرنے اور منٹوں کے بجائے سیکنڈوں میں ٹریفک کی سروس شروع کرنے کا خیال ہمارے لیے بہت پرکشش بنا۔

عمل مشکل نکلا۔ 2019 کے اوائل میں ہماری ہجرت کے دوران، Kubernetes کلسٹر بہت بڑے پیمانے پر پہنچ گیا اور ہمیں ٹریفک کے حجم، کلسٹر سائز، اور DNS کی وجہ سے مختلف مسائل کا سامنا کرنا پڑا۔ راستے میں، ہم نے 200 سروسز کو منتقل کرنے اور 1000 نوڈس، 15000 پوڈز اور 48000 چلنے والے کنٹینرز پر مشتمل Kubernetes کلسٹر کو برقرار رکھنے سے متعلق بہت سے دلچسپ مسائل کو حل کیا۔

کس طرح؟

جنوری 2018 سے، ہم ہجرت کے مختلف مراحل سے گزرے ہیں۔ ہم نے اپنی تمام خدمات کو کنٹینرائز کرکے اور انہیں Kubernetes ٹیسٹ کلاؤڈ ماحول میں تعینات کرکے شروع کیا۔ اکتوبر میں شروع کرتے ہوئے، ہم نے طریقہ کار سے تمام موجودہ سروسز کوبرنیٹس میں منتقل کرنا شروع کیا۔ اگلے سال مارچ تک، ہم نے ہجرت مکمل کر لی اور اب Tinder پلیٹ فارم خصوصی طور پر Kubernetes پر چلتا ہے۔

Kubernetes کے لیے تصاویر بنانا

ہمارے پاس Kubernetes کلسٹر پر چلنے والی مائیکرو سروسز کے لیے 30 سے زیادہ سورس کوڈ ریپوزٹریز ہیں۔ ان ذخیروں میں کوڈ مختلف زبانوں میں لکھا جاتا ہے (مثال کے طور پر، Node.js، Java، Scala، Go) ایک ہی زبان کے لیے متعدد رن ٹائم ماحول کے ساتھ۔

تعمیراتی نظام کو ہر مائیکرو سروس کے لیے مکمل طور پر حسب ضرورت "تعمیراتی تناظر" فراہم کرنے کے لیے ڈیزائن کیا گیا ہے۔ یہ عام طور پر ایک ڈاکر فائل اور شیل کمانڈز کی فہرست پر مشتمل ہوتا ہے۔ ان کا مواد مکمل طور پر حسب ضرورت ہے، اور ایک ہی وقت میں، یہ تمام تعمیراتی سیاق و سباق ایک معیاری شکل کے مطابق لکھے گئے ہیں۔ تعمیراتی سیاق و سباق کو معیاری بنانا ایک ہی تعمیراتی نظام کو تمام مائیکرو سروسز کو سنبھالنے کی اجازت دیتا ہے۔

شکل 1-1۔ بلڈر کنٹینر کے ذریعے معیاری تعمیر کا عمل

رن ٹائمز کے درمیان زیادہ سے زیادہ مستقل مزاجی حاصل کرنے کے لیے (رن ٹائم ماحول) اسی تعمیراتی عمل کو ترقی اور جانچ کے دوران استعمال کیا جاتا ہے۔ ہمیں ایک بہت ہی دلچسپ چیلنج کا سامنا کرنا پڑا: ہمیں پورے پلیٹ فارم پر تعمیراتی ماحول کی مستقل مزاجی کو یقینی بنانے کے لیے ایک طریقہ تیار کرنا تھا۔ اس کو حاصل کرنے کے لئے، تمام اسمبلی کے عمل ایک خاص کنٹینر کے اندر کئے جاتے ہیں. بلڈر.

اس کے کنٹینر کے نفاذ کے لیے ڈوکر کی جدید تکنیک کی ضرورت تھی۔ بلڈر کو مقامی صارف ID اور راز (جیسے SSH کلید، AWS اسناد وغیرہ) وراثت میں ملتے ہیں جو نجی ٹنڈر کے ذخیروں تک رسائی کے لیے درکار ہوتے ہیں۔ یہ قدرتی طور پر تعمیراتی نمونوں کو ذخیرہ کرنے کے لیے ذرائع پر مشتمل مقامی ڈائریکٹریز کو ماؤنٹ کرتا ہے۔ یہ نقطہ نظر کارکردگی کو بہتر بناتا ہے کیونکہ یہ بلڈر کنٹینر اور میزبان کے درمیان تعمیراتی نمونے کاپی کرنے کی ضرورت کو ختم کرتا ہے۔ ذخیرہ شدہ تعمیراتی نمونے بغیر کسی اضافی ترتیب کے دوبارہ استعمال کیے جا سکتے ہیں۔

کچھ خدمات کے لیے، ہمیں تالیف کے ماحول کو رن ٹائم ماحول سے نقشہ بنانے کے لیے ایک اور کنٹینر بنانا پڑا (مثال کے طور پر، Node.js bcrypt لائبریری تنصیب کے دوران پلیٹ فارم کے لیے مخصوص بائنری نمونے تیار کرتی ہے)۔ تالیف کے عمل کے دوران، خدمات کے درمیان تقاضے مختلف ہو سکتے ہیں، اور حتمی ڈاکر فائل فلائی پر مرتب ہو جاتی ہے۔

Kubernetes کلسٹر آرکیٹیکچر اور ہجرت

کلسٹر سائز کا انتظام

ہم نے استعمال کرنے کا فیصلہ کیا۔ kube-aws Amazon EC2 مثالوں پر خودکار کلسٹر تعیناتی کے لیے۔ بالکل شروع میں، سب کچھ نوڈس کے ایک مشترکہ پول میں کام کرتا تھا۔ ہم نے وسائل کا زیادہ موثر استعمال کرنے کے لیے کام کے بوجھ کو سائز اور مثال کی قسم کے لحاظ سے الگ کرنے کی ضرورت کو تیزی سے محسوس کیا۔ منطق یہ تھی کہ متعدد بھری ہوئی ملٹی تھریڈڈ پوڈز کو چلانا کارکردگی کے لحاظ سے زیادہ قابل پیشن گوئی ثابت ہوا اس سے زیادہ تعداد میں سنگل تھریڈڈ پوڈز کے ساتھ ان کے بقائے باہمی سے۔

آخر میں ہم نے طے کیا:

m5.4x بڑا - نگرانی کے لیے (Prometheus)؛
c5.4x بڑا - Node.js کام کے بوجھ کے لیے (سنگل تھریڈڈ کام کا بوجھ)؛
c5.2x بڑا - جاوا اور گو کے لیے (ملٹی تھریڈڈ کام کا بوجھ)؛
c5.4x بڑا - کنٹرول پینل کے لیے (3 نوڈس)۔

ہجرت

پرانے انفراسٹرکچر سے Kubernetes کی طرف ہجرت کے لیے ایک تیاری کا مرحلہ یہ تھا کہ خدمات کے درمیان موجودہ براہ راست رابطے کو نئے لوڈ بیلنسرز (ایلاسٹک لوڈ بیلنسرز (ELB) تک پہنچایا جائے۔ وہ ورچوئل پرائیویٹ کلاؤڈ (VPC) کے مخصوص ذیلی نیٹ پر بنائے گئے تھے۔ یہ سب نیٹ ایک Kubernetes VPC سے منسلک تھا۔ اس سے ہمیں سروس انحصار کی مخصوص ترتیب پر غور کیے بغیر بتدریج ماڈیولز کو منتقل کرنے کی اجازت ملی۔

یہ اختتامی پوائنٹس DNS ریکارڈز کے وزنی سیٹوں کا استعمال کرتے ہوئے بنائے گئے تھے جن میں CNAMEs ہر نئے ELB کی طرف اشارہ کرتے تھے۔ سوئچ اوور کرنے کے لیے، ہم نے 0 کے وزن کے ساتھ نئی Kubernetes سروس ELB کی طرف اشارہ کرتے ہوئے ایک نیا اندراج شامل کیا۔ پھر ہم نے انٹری سیٹ کے ٹائم ٹو لائیو (TTL) کو 0 پر سیٹ کیا۔ اس کے بعد، پرانے اور نئے وزن کو آہستہ آہستہ ایڈجسٹ کیا گیا۔ ، اور آخر کار 100% بوجھ ایک نئے سرور کو بھیج دیا گیا۔ سوئچنگ مکمل ہونے کے بعد، TTL قدر زیادہ مناسب سطح پر واپس آ گئی۔

ہمارے پاس موجود جاوا ماڈیول کم ٹی ٹی ایل ڈی این ایس کا مقابلہ کر سکتے تھے، لیکن نوڈ ایپلی کیشنز نہیں کر سکیں۔ انجینئرز میں سے ایک نے کنکشن پول کوڈ کا کچھ حصہ دوبارہ لکھا اور اسے ایک مینیجر میں لپیٹ دیا جو ہر 60 سیکنڈ میں پول کو اپ ڈیٹ کرتا ہے۔ منتخب کردہ نقطہ نظر نے بہت اچھی طرح سے کام کیا اور کارکردگی میں کسی بھی نمایاں کمی کے بغیر۔

اسباق

نیٹ ورک فیبرک کی حدود

8 جنوری 2019 کی صبح، ٹنڈر پلیٹ فارم غیر متوقع طور پر کریش ہو گیا۔ اس صبح کے اوائل میں پلیٹ فارم کی تاخیر میں غیر متعلقہ اضافے کے جواب میں، کلسٹر میں پوڈز اور نوڈس کی تعداد میں اضافہ ہوا۔ اس کی وجہ سے اے آر پی کیشے ہمارے تمام نوڈس پر ختم ہو گئے۔

اے آر پی کیشے سے متعلق لینکس کے تین اختیارات ہیں:

(ذرائع)

gc_thresh3 - یہ ایک مشکل حد ہے۔ لاگ میں "پڑوسی ٹیبل اوور فلو" اندراجات کی ظاہری شکل کا مطلب یہ تھا کہ ہم وقتی کچرا جمع کرنے (GC) کے بعد بھی، پڑوسی اندراج کو ذخیرہ کرنے کے لیے ARP کیش میں کافی جگہ نہیں تھی۔ اس صورت میں، دانا نے صرف پیکٹ کو مکمل طور پر ضائع کر دیا۔

ہم استعمال کرتے ہیں فلالین Kubernetes میں نیٹ ورک کے تانے بانے کے طور پر۔ پیکٹ VXLAN پر منتقل کیے جاتے ہیں۔ VXLAN ایک L2 سرنگ ہے جو L3 نیٹ ورک کے اوپر اٹھی ہوئی ہے۔ یہ ٹیکنالوجی MAC-in-UDP (MAC Address-in-User Datagram Protocol) encapsulation کا استعمال کرتی ہے اور لیئر 2 نیٹ ورک سیگمنٹس کی توسیع کی اجازت دیتی ہے۔ فزیکل ڈیٹا سینٹر نیٹ ورک پر ٹرانسپورٹ پروٹوکول IP پلس UDP ہے۔

شکل 2-1۔ فلالین ڈایاگرام (ذرائع)

شکل 2-2۔ VXLAN پیکیج (ذرائع)

ہر Kubernetes کارکن نوڈ ایک بڑے /24 بلاک سے /9 ماسک کے ساتھ ایک ورچوئل ایڈریس کی جگہ مختص کرتا ہے۔ ہر نوڈ کے لیے یہ ہے۔ کا مطلب ہے کہ روٹنگ ٹیبل میں ایک انٹری، اے آر پی ٹیبل میں ایک انٹری (فلالین۔1 انٹرفیس پر)، اور ایک انٹری سوئچنگ ٹیبل (FDB) میں۔ جب پہلی بار ورکر نوڈ شروع ہوتا ہے یا ہر بار نیا نوڈ دریافت ہوتا ہے تو انہیں شامل کیا جاتا ہے۔

مزید برآں، نوڈ پوڈ (یا پوڈ پوڈ) مواصلت بالآخر انٹرفیس سے ہوتی ہے۔ eth0 (جیسا کہ اوپر فلالین ڈایاگرام میں دکھایا گیا ہے)۔ اس کے نتیجے میں ہر متعلقہ ماخذ اور منزل کے میزبان کے لیے ARP ٹیبل میں ایک اضافی اندراج ہوتا ہے۔

ہمارے ماحول میں، اس قسم کی بات چیت بہت عام ہے۔ Kubernetes میں سروس اشیاء کے لیے، ایک ELB بنایا جاتا ہے اور Kubernetes ہر نوڈ کو ELB کے ساتھ رجسٹر کرتا ہے۔ ELB پوڈز کے بارے میں کچھ نہیں جانتا ہے اور ہو سکتا ہے کہ منتخب نوڈ پیکٹ کی آخری منزل نہ ہو۔ بات یہ ہے کہ جب نوڈ کو ELB سے ایک پیکٹ ملتا ہے، تو وہ اسے قواعد کو مدنظر رکھتے ہوئے سمجھتا ہے۔ iptables ایک مخصوص سروس کے لیے اور تصادفی طور پر کسی دوسرے نوڈ پر پوڈ کا انتخاب کرتا ہے۔

ناکامی کے وقت، کلسٹر میں 605 نوڈس تھے۔ اوپر بیان کردہ وجوہات کی بناء پر، یہ اہمیت پر قابو پانے کے لیے کافی تھا۔ gc_thresh3، جو پہلے سے طے شدہ ہے۔ جب ایسا ہوتا ہے تو، نہ صرف پیکٹ گرنا شروع ہو جاتے ہیں، بلکہ ARP ٹیبل سے /24 ماسک والی فلالین ورچوئل ایڈریس کی جگہ غائب ہو جاتی ہے۔ نوڈ-پوڈ کمیونیکیشن اور DNS سوالات میں خلل پڑتا ہے (DNS ایک کلسٹر میں ہوسٹ کیا جاتا ہے؛ تفصیلات کے لیے اس مضمون میں بعد میں پڑھیں)۔

اس مسئلے کو حل کرنے کے لیے، آپ کو اقدار کو بڑھانے کی ضرورت ہے۔ gc_thresh1, gc_thresh2 и gc_thresh3 اور گمشدہ نیٹ ورکس کو دوبارہ رجسٹر کرنے کے لیے Flannel کو دوبارہ شروع کریں۔

غیر متوقع DNS اسکیلنگ

نقل مکانی کے عمل کے دوران، ہم نے ٹریفک کو منظم کرنے کے لیے DNS کا فعال طور پر استعمال کیا اور آہستہ آہستہ پرانے انفراسٹرکچر سے Kubernetes میں خدمات کی منتقلی کی۔ ہم نے Route53 میں متعلقہ RecordSets کے لیے نسبتاً کم TTL قدریں سیٹ کیں۔ جب پرانا بنیادی ڈھانچہ EC2 مثالوں پر چل رہا تھا، تو ہماری حل کنفیگریشن نے Amazon DNS کی طرف اشارہ کیا۔ ہم نے اسے قدر کی نگاہ سے دیکھا اور ہماری سروسز اور ایمیزون سروسز (جیسے DynamoDB) پر کم TTL کا اثر بڑی حد تک کسی کا دھیان نہیں گیا۔

جیسا کہ ہم نے خدمات کوبرنیٹس میں منتقل کیا، ہم نے پایا کہ DNS فی سیکنڈ 250 ہزار درخواستوں پر کارروائی کر رہا ہے۔ نتیجے کے طور پر، ایپلی کیشنز نے DNS سوالات کے لیے مستقل اور سنجیدہ ٹائم آؤٹ کا تجربہ کرنا شروع کیا۔ یہ DNS فراہم کنندہ کو بہتر بنانے اور CoreDNS میں تبدیل کرنے کی ناقابل یقین کوششوں کے باوجود ہوا (جو چوٹی کے بوجھ پر 1000 cores پر چلنے والے 120 pods تک پہنچ گیا)۔

دیگر ممکنہ وجوہات اور حل کی تحقیق کرتے ہوئے، ہم نے دریافت کیا۔ مضمون, پیکٹ فلٹرنگ فریم ورک کو متاثر کرنے والی نسل کے حالات کو بیان کرنا netfilter لینکس میں. ہم نے جس ٹائم آؤٹ کا مشاہدہ کیا، اس کے ساتھ بڑھتے ہوئے کاؤنٹر insert_failed فلالین انٹرفیس میں مضمون کے نتائج کے مطابق تھے۔

مسئلہ سورس اور ڈیسٹینیشن نیٹ ورک ایڈریس ٹرانسلیشن (SNAT اور DNAT) اور اس کے بعد ٹیبل میں داخل ہونے کے مرحلے پر ہوتا ہے۔ کنٹریک. اندرونی طور پر زیر بحث آنے والے اور کمیونٹی کی طرف سے تجویز کردہ ورک آراؤنڈز میں سے ایک DNS کو ورکر نوڈ میں ہی منتقل کرنا تھا۔ اس معاملے میں:

SNAT کی ضرورت نہیں ہے کیونکہ ٹریفک نوڈ کے اندر رہتی ہے۔ اسے انٹرفیس کے ذریعے روٹ کرنے کی ضرورت نہیں ہے۔ eth0.
DNAT کی ضرورت نہیں ہے کیونکہ منزل کا IP نوڈ کے لیے مقامی ہے، اور قواعد کے مطابق تصادفی طور پر منتخب کردہ پوڈ نہیں ہے۔ iptables.

ہم نے اس نقطہ نظر پر قائم رہنے کا فیصلہ کیا۔ CoreDNS کو کبرنیٹس میں ڈیمون سیٹ کے طور پر تعینات کیا گیا تھا اور ہم نے مقامی نوڈ DNS سرور کو لاگو کیا solve.conf ہر ایک جھنڈا لگا کر --cluster-dns ٹیمیں کیوبلیٹ . یہ حل DNS ٹائم آؤٹ کے لیے کارگر ثابت ہوا۔

تاہم، ہم نے پھر بھی پیکٹ کا نقصان اور کاؤنٹر میں اضافہ دیکھا insert_failed فلالین انٹرفیس میں۔ یہ کام کے نفاذ کے بعد بھی جاری رہا کیونکہ ہم صرف DNS ٹریفک کے لیے SNAT اور/یا DNAT کو ختم کرنے کے قابل تھے۔ دوسری قسم کی ٹریفک کے لیے ریس کے حالات محفوظ تھے۔ خوش قسمتی سے، ہمارے زیادہ تر پیکٹ TCP ہیں، اور اگر کوئی مسئلہ پیش آتا ہے تو وہ آسانی سے دوبارہ بھیجے جاتے ہیں۔ ہم اب بھی ہر قسم کی ٹریفک کے لیے مناسب حل تلاش کرنے کی کوشش کر رہے ہیں۔

بہتر لوڈ بیلنسنگ کے لیے ایلچی کا استعمال

جیسا کہ ہم نے بیک اینڈ سروسز کوبرنیٹس میں منتقل کیا، ہم پھلیوں کے درمیان غیر متوازن بوجھ کا شکار ہونے لگے۔ ہم نے پایا کہ HTTP Keepalive کی وجہ سے ELB کنکشنز ہر تعیناتی کے پہلے تیار پوڈ پر لٹک جاتے ہیں۔ اس طرح، ٹریفک کا بڑا حصہ دستیاب پوڈز کی ایک چھوٹی سی فیصد سے گزرا۔ پہلا حل جس کا ہم نے تجربہ کیا وہ بدترین صورت حال کے لیے نئی تعیناتیوں پر MaxSurge کو 100% پر سیٹ کر رہا تھا۔ بڑی تعیناتیوں کے لحاظ سے یہ اثر غیر معمولی اور ناگوار نکلا۔

ایک اور حل جو ہم نے استعمال کیا وہ تھا مصنوعی طور پر اہم خدمات کے لیے وسائل کی درخواستوں کو بڑھانا۔ اس صورت میں، دیگر بھاری پھلیوں کے مقابلے میں قریب میں رکھی ہوئی پھلیوں میں پینتریبازی کے لیے زیادہ گنجائش ہوگی۔ یہ طویل مدت میں کام نہیں کرے گا کیونکہ یہ وسائل کا ضیاع ہوگا۔ اس کے علاوہ، ہماری نوڈ ایپلی کیشنز سنگل تھریڈڈ تھیں اور، اس کے مطابق، صرف ایک کور استعمال کر سکتی تھیں۔ واحد حقیقی حل بہتر لوڈ بیلنسنگ کا استعمال کرنا تھا۔

ہم طویل عرصے سے پوری طرح تعریف کرنا چاہتے ہیں۔ ایلچی. موجودہ صورتحال نے ہمیں اسے انتہائی محدود انداز میں تعینات کرنے اور فوری نتائج حاصل کرنے کی اجازت دی۔ ایلچی ایک اعلیٰ کارکردگی، اوپن سورس، لیئر XNUMX پراکسی ہے جو بڑی SOA ایپلی کیشنز کے لیے ڈیزائن کی گئی ہے۔ یہ لوڈ بیلنسنگ کی جدید تکنیکوں کو نافذ کر سکتا ہے، بشمول خودکار دوبارہ کوششیں، سرکٹ بریکرز، اور عالمی شرح کو محدود کرنا۔ (نوٹ. ترجمہ: آپ اس کے بارے میں مزید پڑھ سکتے ہیں۔ یہ مضمون اسٹیو کے بارے میں، جو ایلچی پر مبنی ہے۔)

ہم مندرجہ ذیل کنفیگریشن لے کر آئے ہیں: ہر پوڈ اور ایک ہی راستے کے لیے ایک ایلچی سائڈ کار رکھیں، اور کلسٹر کو پورٹ کے ذریعے مقامی طور پر کنٹینر سے جوڑیں۔ ممکنہ جھڑپ کو کم سے کم کرنے اور ایک چھوٹا سا ہٹ رداس برقرار رکھنے کے لیے، ہم نے اینوائے فرنٹ پراکسی پوڈز کا ایک بیڑا استعمال کیا، ہر ایک سروس کے لیے فی دستیابی زون (AZ)۔ انہوں نے ہمارے انجینئرز میں سے ایک کے ذریعہ لکھے گئے ایک سادہ سروس دریافت انجن پر انحصار کیا جس نے دی گئی سروس کے لئے ہر AZ میں پوڈز کی فہرست واپس کردی۔

سروس فرنٹ اینوائسز نے پھر ایک اپ اسٹریم کلسٹر اور روٹ کے ساتھ اس سروس کی دریافت کا طریقہ کار استعمال کیا۔ ہم نے مناسب ٹائم آؤٹ سیٹ کیا، تمام سرکٹ بریکر سیٹنگز میں اضافہ کیا، اور واحد ناکامیوں میں مدد کرنے اور ہموار تعیناتیوں کو یقینی بنانے کے لیے کم سے کم دوبارہ کوشش کی ترتیب شامل کی۔ ہم نے ایک TCP ELB ان میں سے ہر ایک سروس فرنٹ اینوائس کے سامنے رکھا۔ یہاں تک کہ اگر ہماری مرکزی پراکسی پرت سے کیپ لائیو کچھ اینوائے پوڈز پر پھنس گیا تھا، تب بھی وہ بوجھ کو بہت بہتر طریقے سے ہینڈل کرنے کے قابل تھے اور بیک اینڈ میں less_request کے ذریعے توازن قائم کرنے کے لیے ترتیب دیے گئے تھے۔

تعیناتی کے لیے، ہم نے ایپلیکیشن پوڈز اور سائڈ کار پوڈز دونوں پر پری اسٹاپ ہک کا استعمال کیا۔ ہک نے سائڈ کار کنٹینر پر واقع ایڈمن اینڈ پوائنٹ کی حیثیت کو چیک کرنے میں ایک خرابی پیدا کی اور فعال کنکشن کو ختم کرنے کی اجازت دینے کے لیے تھوڑی دیر کے لیے سو گیا۔

ان وجوہات میں سے ایک وجہ جو ہم اتنی تیزی سے آگے بڑھنے کے قابل تھے وہ تفصیلی میٹرکس کی وجہ سے ہے کہ ہم آسانی سے ایک عام پرومیٹیس انسٹالیشن میں ضم کرنے کے قابل ہو گئے۔ اس سے ہمیں یہ دیکھنے کی اجازت ملی کہ کیا ہو رہا ہے جب ہم نے کنفیگریشن پیرامیٹرز کو ایڈجسٹ کیا اور ٹریفک کو دوبارہ تقسیم کیا۔

نتائج فوری اور واضح تھے۔ ہم نے سب سے زیادہ غیر متوازن خدمات کے ساتھ شروعات کی تھی، اور اس وقت یہ کلسٹر میں 12 اہم ترین خدمات کے سامنے کام کرتی ہے۔ اس سال ہم ایک مکمل سروس میش میں منتقلی کی منصوبہ بندی کر رہے ہیں جس میں مزید جدید سروس دریافت، سرکٹ بریکنگ، آؤٹ لیئر ڈیٹیکشن، ریٹ محدود اور ٹریسنگ شامل ہیں۔

شکل 3-1۔ ایلچی میں منتقلی کے دوران ایک سروس کا CPU کنورژن

حتمی نتیجہ

اس تجربے اور اضافی تحقیق کے ذریعے، ہم نے بڑے Kubernetes کلسٹروں کو ڈیزائن کرنے، تعینات کرنے اور چلانے میں مضبوط مہارت کے ساتھ ایک مضبوط انفراسٹرکچر ٹیم بنائی ہے۔ تمام ٹنڈر انجینئرز کے پاس اب کنٹینرز پیک کرنے اور کوبرنیٹس پر ایپلیکیشنز تعینات کرنے کا علم اور تجربہ ہے۔

جب پرانے انفراسٹرکچر پر اضافی صلاحیت کی ضرورت پیش آئی، تو ہمیں نئے EC2 کے آغاز کے لیے کئی منٹ انتظار کرنا پڑا۔ اب کنٹینرز چلنے لگتے ہیں اور منٹوں کے بجائے سیکنڈوں میں ٹریفک پر کارروائی شروع کر دیتے ہیں۔ ایک ہی EC2 مثال پر ایک سے زیادہ کنٹینرز کو شیڈول کرنا بھی افقی ارتکاز کو بہتر بناتا ہے۔ نتیجے کے طور پر، ہم نے گزشتہ سال کے مقابلے 2019 میں EC2 کے اخراجات میں نمایاں کمی کی پیش گوئی کی ہے۔

ہجرت میں تقریباً دو سال لگے، لیکن ہم نے اسے مارچ 2019 میں مکمل کیا۔ فی الحال، Tinder پلیٹ فارم خصوصی طور پر Kubernetes کلسٹر پر چلتا ہے جس میں 200 سروسز، 1000 نوڈس، 15 pods اور 000 کنٹینرز شامل ہیں۔ انفراسٹرکچر اب آپریشن ٹیموں کا واحد ڈومین نہیں ہے۔ ہمارے تمام انجینئرز اس ذمہ داری کا اشتراک کرتے ہیں اور صرف کوڈ کا استعمال کرتے ہوئے اپنی ایپلی کیشنز بنانے اور تعینات کرنے کے عمل کو کنٹرول کرتے ہیں۔

مترجم سے PS

ہمارے بلاگ پر مضامین کی ایک سیریز بھی پڑھیں:

ماخذ: www.habr.com

ٹنڈر کی کوبرنیٹس میں منتقلی۔