Kubernetes میں طویل المدتی رابطوں کو لوڈ بیلنس اور اسکیلنگ کرنا

یہ مضمون آپ کو یہ سمجھنے میں مدد کرے گا کہ کبرنیٹس میں لوڈ بیلنس کیسے کام کرتا ہے، طویل المدت کنکشنز کو اسکیل کرنے پر کیا ہوتا ہے، اور اگر آپ HTTP/2، gRPC، RSockets، AMQP، یا دیگر طویل المدتی پروٹوکول استعمال کرتے ہیں تو آپ کو کلائنٹ سائیڈ بیلنسنگ پر کیوں غور کرنا چاہیے۔ . 

Kubernetes میں ٹریفک کو کس طرح دوبارہ تقسیم کیا جاتا ہے اس کے بارے میں تھوڑا سا 

Kubernetes ایپلی کیشنز کی تعیناتی کے لیے دو آسان خلاصہ فراہم کرتا ہے: خدمات اور تعیناتیاں۔

تعیناتیاں بیان کرتی ہیں کہ کسی بھی وقت آپ کی درخواست کی کتنی اور کتنی کاپیاں چلنی چاہئیں۔ ہر ایپلیکیشن کو پوڈ کے طور پر تعینات کیا جاتا ہے اور اسے ایک IP ایڈریس تفویض کیا جاتا ہے۔

خدمات لوڈ بیلنسر کی طرح کام کرتی ہیں۔ انہیں متعدد پوڈز میں ٹریفک کو تقسیم کرنے کے لیے ڈیزائن کیا گیا ہے۔

آئیے دیکھتے ہیں کہ یہ کیسا لگتا ہے۔.

1. نیچے دیے گئے خاکے میں آپ ایک ہی ایپلیکیشن اور لوڈ بیلنس کی تین مثالیں دیکھ سکتے ہیں۔

   

2. لوڈ بیلنسر کو سروس کہا جاتا ہے اور اسے ایک IP ایڈریس تفویض کیا جاتا ہے۔ کسی بھی آنے والی درخواست کو کسی ایک پوڈ پر بھیج دیا جاتا ہے:

   

3. تعیناتی کا منظر نامہ درخواست کی مثالوں کی تعداد کا تعین کرتا ہے۔ آپ کو تقریبا کبھی بھی براہ راست اس کے تحت توسیع نہیں کرنا پڑے گی:

   

4. ہر پوڈ کو اپنا IP پتہ تفویض کیا جاتا ہے:

   

خدمات کو IP پتوں کے مجموعہ کے طور پر سوچنا مفید ہے۔ ہر بار جب آپ سروس تک رسائی حاصل کرتے ہیں، IP پتے میں سے ایک کو فہرست سے منتخب کیا جاتا ہے اور اسے منزل کے پتے کے طور پر استعمال کیا جاتا ہے۔

ایسا لگتا ہے۔.

1. سروس کو ایک curl 10.96.45.152 کی درخواست موصول ہوئی ہے:

   

2. سروس اپنی منزل کے طور پر تین پوڈ پتوں میں سے ایک کا انتخاب کرتی ہے:

   

3. ٹریفک کو ایک مخصوص پوڈ پر ری ڈائریکٹ کیا جاتا ہے:

   

اگر آپ کی درخواست فرنٹ اینڈ اور بیک اینڈ پر مشتمل ہے، تو آپ کے پاس ہر ایک کے لیے ایک سروس اور ایک تعیناتی دونوں ہوگی۔

جب فرنٹ اینڈ بیک اینڈ سے درخواست کرتا ہے، تو اسے یہ جاننے کی ضرورت نہیں ہوتی ہے کہ بیک اینڈ کتنے پوڈز کی خدمت کرتا ہے: ایک، دس یا سو ہو سکتے ہیں۔

نیز، فرنٹ اینڈ کو پسدید کی خدمت کرنے والے پوڈز کے پتوں کے بارے میں کچھ نہیں معلوم۔

جب فرنٹ اینڈ بیک اینڈ سے درخواست کرتا ہے، تو یہ بیک اینڈ سروس کا آئی پی ایڈریس استعمال کرتا ہے، جو تبدیل نہیں ہوتا ہے۔

ایسا ہی لگتا ہے.

1. 1 کے تحت اندرونی پسدید جزو کی درخواست کرتا ہے۔ پسدید کے لیے مخصوص کو منتخب کرنے کے بجائے، یہ خدمت سے درخواست کرتا ہے:

   

2. سروس منزل کے پتے کے طور پر بیک اینڈ پوڈز میں سے ایک کو منتخب کرتی ہے:

   

3. ٹریفک Pod 1 سے Pod 5 تک جاتی ہے، سروس کے ذریعے منتخب کردہ:

   

4. انڈر 1 بالکل نہیں جانتا ہے کہ سروس کے پیچھے 5 سے کم کی طرح کتنے پوڈ چھپے ہوئے ہیں:

   

لیکن سروس درخواستوں کو کس طرح تقسیم کرتی ہے؟ ایسا لگتا ہے جیسے راؤنڈ رابن بیلنس استعمال کیا جاتا ہے؟ آئیے اس کا پتہ لگائیں۔ 

Kubernetes خدمات میں توازن

Kubernetes سروسز موجود نہیں ہیں۔ آئی پی ایڈریس اور پورٹ تفویض کردہ سروس کے لیے کوئی عمل نہیں ہے۔

آپ کلسٹر میں کسی بھی نوڈ میں لاگ ان کرکے اور netstat -ntlp کمانڈ چلا کر اس کی تصدیق کر سکتے ہیں۔

آپ سروس کے لیے مختص کردہ IP ایڈریس بھی تلاش نہیں کر پائیں گے۔

سروس کا آئی پی ایڈریس کنٹرول لیئر میں، کنٹرولر میں، اور ڈیٹا بیس میں ریکارڈ کیا جاتا ہے - وغیرہ۔ اسی ایڈریس کو ایک اور جزو - kube-proxy استعمال کرتا ہے۔
Kube-proxy تمام خدمات کے لیے IP پتوں کی فہرست حاصل کرتا ہے اور کلسٹر میں ہر نوڈ پر iptables کے قواعد کا ایک سیٹ تیار کرتا ہے۔

یہ اصول کہتے ہیں: "اگر ہم سروس کا IP ایڈریس دیکھتے ہیں، تو ہمیں درخواست کی منزل کے پتے میں ترمیم کرکے اسے کسی ایک پوڈ پر بھیجنا ہوگا۔"

سروس IP ایڈریس صرف ایک انٹری پوائنٹ کے طور پر استعمال ہوتا ہے اور اس IP ایڈریس اور پورٹ کو سننے والے کسی بھی عمل کے ذریعے پیش نہیں کیا جاتا ہے۔

آئیے اس کو دیکھتے ہیں۔. 

1. تین نوڈس کے کلسٹر پر غور کریں۔ ہر نوڈ میں پوڈ ہوتے ہیں:

   

2. بندھے ہوئے پوڈ پینٹ شدہ خاکستری خدمت کا حصہ ہیں۔ کیونکہ سروس ایک عمل کے طور پر موجود نہیں ہے، یہ سرمئی رنگ میں دکھایا گیا ہے:

   

3. پہلا پوڈ سروس کی درخواست کرتا ہے اور اسے متعلقہ پوڈ میں سے کسی ایک پر جانا چاہیے:

   

4. لیکن سروس موجود نہیں ہے، عمل موجود نہیں ہے. یہ کیسے کام کرتا ہے؟

   

5. اس سے پہلے کہ درخواست نوڈ سے نکل جائے، یہ iptables کے قواعد سے گزرتی ہے:

   

6. iptables کے قواعد جانتے ہیں کہ سروس موجود نہیں ہے اور اس کے IP ایڈریس کو اس سروس سے منسلک پوڈز کے IP پتوں میں سے کسی ایک سے بدل دیں:

   

7. درخواست کو منزل کے پتے کے طور پر ایک درست IP پتہ موصول ہوتا ہے اور اس پر عام طور پر کارروائی ہوتی ہے:

   

8. نیٹ ورک ٹوپولوجی پر منحصر ہے، درخواست بالآخر پوڈ تک پہنچ جاتی ہے:

   

کیا iptables بیلنس لوڈ کر سکتے ہیں؟

نہیں، iptables فلٹرنگ کے لیے استعمال ہوتے ہیں اور توازن کے لیے ڈیزائن نہیں کیے گئے تھے۔

تاہم، اس طرح کام کرنے والے قواعد کا ایک مجموعہ لکھنا ممکن ہے۔ چھدم توازن کرنے والا.

اور یہ بالکل وہی ہے جو Kubernetes میں لاگو کیا جاتا ہے.

اگر آپ کے پاس تین پوڈ ہیں، تو kube-proxy درج ذیل اصول لکھے گا:

1. 33% کے امکان کے ساتھ پہلا ذیلی منتخب کریں، بصورت دیگر اگلے اصول پر جائیں۔
2. 50% کے امکان کے ساتھ دوسرا انتخاب کریں، ورنہ اگلے اصول پر جائیں۔
3. نیچے تیسرے کو منتخب کریں۔

اس سسٹم کے نتیجے میں ہر پوڈ کو 33% کے امکان کے ساتھ منتخب کیا جاتا ہے۔

اور اس بات کی کوئی گارنٹی نہیں ہے کہ Pod 2 کا انتخاب Pod 1 کے بعد کیا جائے گا۔

نوٹ: iptables بے ترتیب تقسیم کے ساتھ شماریاتی ماڈیول استعمال کرتا ہے۔ اس طرح، بیلنسنگ الگورتھم بے ترتیب انتخاب پر مبنی ہے۔

اب جب کہ آپ سمجھ گئے ہیں کہ سروسز کیسے کام کرتی ہیں، آئیے مزید دلچسپ سروس کے منظرنامے دیکھیں۔

Kubernetes میں طویل عرصے تک رہنے والے کنکشن پہلے سے طے شدہ طور پر پیمانہ نہیں ہوتے ہیں۔

فرنٹ اینڈ سے بیک اینڈ تک ہر HTTP درخواست کو ایک علیحدہ TCP کنکشن کے ذریعے پیش کیا جاتا ہے، جو کھلا اور بند ہوتا ہے۔

اگر فرنٹ اینڈ بیک اینڈ کو فی سیکنڈ 100 درخواستیں بھیجتا ہے، تو 100 مختلف TCP کنکشن کھلے اور بند ہو جاتے ہیں۔

آپ ایک TCP کنکشن کھول کر اور بعد میں آنے والی تمام HTTP درخواستوں کے لیے اسے استعمال کر کے درخواست پر کارروائی کے وقت اور لوڈ کو کم کر سکتے ہیں۔

HTTP پروٹوکول میں ایک خصوصیت ہے جسے HTTP Keep-alive، یا کنکشن کا دوبارہ استعمال کہا جاتا ہے۔ اس صورت میں، متعدد HTTP درخواستیں اور جوابات بھیجنے اور وصول کرنے کے لیے ایک واحد TCP کنکشن استعمال کیا جاتا ہے:

یہ خصوصیت بطور ڈیفالٹ فعال نہیں ہے: سرور اور کلائنٹ دونوں کو اسی کے مطابق ترتیب دیا جانا چاہیے۔

سیٹ اپ خود ہی آسان اور زیادہ تر پروگرامنگ زبانوں اور ماحول کے لیے قابل رسائی ہے۔

یہاں مختلف زبانوں میں مثالوں کے کچھ لنکس ہیں:

• Node.js میں زندہ رکھیں
• اسپرنگ بوٹ میں زندہ رکھیں
• پائتھون میں زندہ رکھیں
• .NET میں زندہ رکھیں

اگر ہم Kubernetes سروس میں Keep-alive استعمال کریں تو کیا ہوگا؟
آئیے فرض کریں کہ دونوں فرنٹ اینڈ اور بیک اینڈ سپورٹ زندہ رہتے ہیں۔

ہمارے پاس فرنٹ اینڈ کی ایک کاپی اور بیک اینڈ کی تین کاپیاں ہیں۔ فرنٹ اینڈ پہلی درخواست کرتا ہے اور بیک اینڈ سے TCP کنکشن کھولتا ہے۔ درخواست سروس تک پہنچ جاتی ہے، پسدید پوڈز میں سے ایک کو منزل کے پتے کے طور پر منتخب کیا جاتا ہے۔ پسدید ایک جواب بھیجتا ہے، اور فرنٹ اینڈ اسے وصول کرتا ہے۔

معمول کی صورتحال کے برعکس جہاں جواب موصول ہونے کے بعد TCP کنکشن بند ہو جاتا ہے، اب اسے مزید HTTP درخواستوں کے لیے کھلا رکھا گیا ہے۔

اگر فرنٹ اینڈ بیک اینڈ کو مزید درخواستیں بھیجتا ہے تو کیا ہوتا ہے؟

ان درخواستوں کو آگے بڑھانے کے لیے، ایک کھلا TCP کنکشن استعمال کیا جائے گا، تمام درخواستیں اسی بیک اینڈ پر جائیں گی جہاں پہلی درخواست کی گئی تھی۔

کیا iptables کو ٹریفک کو دوبارہ تقسیم نہیں کرنا چاہئے؟

اس معاملے میں نہیں۔

جب ایک TCP کنکشن بنتا ہے، تو یہ iptables کے اصولوں سے گزرتا ہے، جو ایک مخصوص بیک اینڈ کو منتخب کرتا ہے جہاں ٹریفک جائے گی۔

چونکہ اس کے بعد کی تمام درخواستیں پہلے سے کھلے TCP کنکشن پر ہیں، لہذا iptables کے قواعد کو مزید نہیں کہا جاتا ہے۔

آئیے دیکھتے ہیں کہ یہ کیسا لگتا ہے۔.

1. پہلا پوڈ سروس کو ایک درخواست بھیجتا ہے:

   

2. آپ پہلے ہی جانتے ہیں کہ آگے کیا ہوگا۔ سروس موجود نہیں ہے، لیکن iptables کے قواعد موجود ہیں جو درخواست پر کارروائی کریں گے:

   

3. پسدید پوڈز میں سے ایک کو منزل کے پتے کے طور پر منتخب کیا جائے گا:

   

4. درخواست پوڈ تک پہنچ جاتی ہے۔ اس مقام پر، دو پوڈز کے درمیان ایک مستقل TCP کنکشن قائم ہو جائے گا:

   

5. پہلے پوڈ سے کسی بھی بعد کی درخواست پہلے سے قائم کنکشن کے ذریعے جائے گی:

   

نتیجہ تیز تر رسپانس ٹائم اور زیادہ تھرو پٹ ہے، لیکن آپ بیک اینڈ کو پیمانہ کرنے کی صلاحیت کھو دیتے ہیں۔

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

کیا یہ ٹھیک کیا جا سکتا ہے؟

چونکہ Kubernetes مسلسل رابطوں کو متوازن کرنا نہیں جانتا ہے، اس لیے یہ کام آپ پر آتا ہے۔

سروسز آئی پی ایڈریسز اور پورٹس کا مجموعہ ہیں جنہیں اینڈ پوائنٹس کہتے ہیں۔

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

یا مزید درخواست دیں۔ پیچیدہ توازن الگورتھم.

کلائنٹ سائیڈ کوڈ جو توازن کے لیے ذمہ دار ہے اسے اس منطق کی پیروی کرنی چاہیے:

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

یہ ایسا ہی نظر آئے گا۔.

1. سروس کو درخواست بھیجنے والے پہلے پوڈ کے بجائے، آپ کلائنٹ کی طرف سے درخواستوں میں توازن رکھ سکتے ہیں:

   

2. آپ کو کوڈ لکھنے کی ضرورت ہے جو پوچھے کہ کون سی پوڈ سروس کا حصہ ہیں:

   

3. ایک بار جب آپ کے پاس فہرست ہو تو، اسے کلائنٹ کی طرف محفوظ کریں اور اسے پوڈ سے منسلک کرنے کے لیے استعمال کریں:

   

4. آپ لوڈ بیلنسنگ الگورتھم کے ذمہ دار ہیں:

   

اب سوال یہ پیدا ہوتا ہے کہ کیا یہ مسئلہ صرف HTTP کیپ لائیو پر لاگو ہوتا ہے؟

کلائنٹ سائیڈ لوڈ بیلنسنگ

HTTP واحد پروٹوکول نہیں ہے جو مستقل TCP کنکشن استعمال کرسکتا ہے۔

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

اس کے بجائے، ڈیٹا بیس سے ایک مستقل TCP کنکشن کھولا اور استعمال کیا جاتا ہے۔

اگر آپ کا ڈیٹا بیس Kubernetes پر تعینات ہے اور رسائی بطور سروس فراہم کی گئی ہے، تو آپ کو انہی مسائل کا سامنا کرنا پڑے گا جو پچھلے حصے میں بیان کی گئی ہیں۔

ایک ڈیٹا بیس کی نقل دوسروں کے مقابلے میں زیادہ بھری ہوئی ہوگی۔ Kube-proxy اور Kubernetes کنکشن کو متوازن کرنے میں مدد نہیں کریں گے۔ آپ کو اپنے ڈیٹا بیس میں سوالات کو متوازن کرنے کا خیال رکھنا چاہیے۔

ڈیٹابیس سے جڑنے کے لیے آپ کونسی لائبریری استعمال کرتے ہیں اس پر انحصار کرتے ہوئے، آپ کے پاس اس مسئلے کو حل کرنے کے لیے مختلف اختیارات ہوسکتے ہیں۔

ذیل میں Node.js سے MySQL ڈیٹا بیس کلسٹر تک رسائی کی ایک مثال ہے۔

var mysql = require('mysql');
var poolCluster = mysql.createPoolCluster();

var endpoints = /* retrieve endpoints from the Service */

for (var [index, endpoint] of endpoints) {
  poolCluster.add(`mysql-replica-${index}`, endpoint);
}

// Make queries to the clustered MySQL database

بہت سے دوسرے پروٹوکول ہیں جو مستقل TCP کنکشن استعمال کرتے ہیں:

• WebSockets اور محفوظ WebSockets
• HTTP / 2
• جی آر پی سی
• RSockets
• AMQP۔

آپ کو ان میں سے زیادہ تر پروٹوکولز سے پہلے ہی واقف ہونا چاہئے۔

لیکن اگر یہ پروٹوکول بہت مقبول ہیں، تو کوئی معیاری توازن حل کیوں نہیں ہے؟ کلائنٹ کی منطق کو تبدیل کرنے کی ضرورت کیوں ہے؟ کیا کوئی مقامی کبرنیٹس حل ہے؟

Kube-proxy اور iptables کو Kubernetes میں تعینات کرتے وقت استعمال کے زیادہ تر عام معاملات کا احاطہ کرنے کے لیے ڈیزائن کیا گیا ہے۔ یہ سہولت کے لیے ہے۔

اگر آپ ایک ایسی ویب سروس استعمال کر رہے ہیں جو REST API کو ظاہر کرتی ہے، تو آپ کی خوش قسمتی ہے - اس صورت میں، مستقل TCP کنکشن استعمال نہیں کیے جاتے ہیں، آپ کوئی بھی Kubernetes سروس استعمال کر سکتے ہیں۔

لیکن ایک بار جب آپ مسلسل TCP کنکشن استعمال کرنا شروع کر دیتے ہیں، تو آپ کو یہ معلوم کرنا پڑے گا کہ بیک اینڈ پر بوجھ کو یکساں طور پر کیسے تقسیم کیا جائے۔ Kubernetes اس کیس کے لیے تیار حل پر مشتمل نہیں ہے۔

تاہم، یقینی طور پر ایسے اختیارات ہیں جو مدد کر سکتے ہیں.

Kubernetes میں طویل المدت روابط کو متوازن کرنا

Kubernetes میں چار قسم کی خدمات ہیں:

1. کلسٹر آئی پی
2. نوڈ پورٹ
3. لوڈ بیلنسر
4. بے سر

پہلی تین خدمات ورچوئل آئی پی ایڈریس کی بنیاد پر کام کرتی ہیں، جسے کیوب پراکسی iptables کے قوانین بنانے کے لیے استعمال کرتی ہے۔ لیکن تمام خدمات کی بنیادی بنیاد بغیر سر کے سروس ہے۔

ہیڈ لیس سروس کا اس کے ساتھ کوئی IP ایڈریس منسلک نہیں ہوتا ہے اور یہ صرف آئی پی ایڈریس کی فہرست اور اس سے منسلک پوڈز (اینڈ پوائنٹس) کی بندرگاہوں کو بازیافت کرنے کا طریقہ کار فراہم کرتی ہے۔

تمام خدمات سر کے بغیر خدمات پر مبنی ہیں۔

ClusterIP سروس کچھ اضافے کے ساتھ ایک ہیڈ لیس سروس ہے: 

1. مینجمنٹ پرت اسے ایک IP ایڈریس تفویض کرتی ہے۔
2. Kube-proxy ضروری iptables قواعد تیار کرتا ہے۔

اس طرح آپ kube-proxy کو نظر انداز کر سکتے ہیں اور اپنی ایپلیکیشن کو بیلنس لوڈ کرنے کے لیے بغیر ہیڈ لیس سروس سے حاصل کردہ اینڈ پوائنٹس کی فہرست کو براہ راست استعمال کر سکتے ہیں۔

لیکن ہم کلسٹر میں تعینات تمام ایپلی کیشنز میں اسی طرح کی منطق کیسے شامل کر سکتے ہیں؟

اگر آپ کی درخواست پہلے ہی تعینات ہے، تو یہ کام ناممکن لگ سکتا ہے۔ تاہم، ایک متبادل آپشن موجود ہے۔

سروس میش آپ کی مدد کرے گا۔

آپ نے شاید پہلے ہی دیکھا ہوگا کہ کلائنٹ سائیڈ لوڈ بیلنسنگ کی حکمت عملی کافی معیاری ہے۔

جب درخواست شروع ہوتی ہے، یہ:

1. سروس سے IP پتوں کی فہرست حاصل کرتا ہے۔
2. کنکشن پول کھولتا اور برقرار رکھتا ہے۔
3. وقفے وقفے سے اینڈ پوائنٹس کو شامل یا ہٹا کر پول کو اپ ڈیٹ کرتا ہے۔

ایک بار جب درخواست درخواست کرنا چاہتی ہے، تو یہ:

1. کچھ منطق کا استعمال کرتے ہوئے دستیاب کنکشن کا انتخاب کرتا ہے (مثلاً راؤنڈ رابن)۔
2. درخواست پر عمل کرتا ہے۔

یہ اقدامات WebSockets، gRPC، اور AMQP کنکشن دونوں کے لیے کام کرتے ہیں۔

آپ اس منطق کو ایک علیحدہ لائبریری میں الگ کر سکتے ہیں اور اسے اپنی ایپلی کیشنز میں استعمال کر سکتے ہیں۔

تاہم، آپ اس کے بجائے Istio یا Linkerd جیسے سروس میشز استعمال کر سکتے ہیں۔

سروس میش آپ کی درخواست کو اس عمل کے ساتھ بڑھاتا ہے جو:

1. خودکار طور پر سروس کے IP پتے تلاش کرتا ہے۔
2. کنکشن ٹیسٹ کرتا ہے جیسے WebSockets اور gRPC۔
3. درست پروٹوکول کا استعمال کرتے ہوئے درخواستوں کو بیلنس کرتا ہے۔

سروس میش کلسٹر کے اندر ٹریفک کو منظم کرنے میں مدد کرتا ہے، لیکن یہ کافی وسائل پر مشتمل ہے۔ دوسرے اختیارات تیسری پارٹی کی لائبریریوں جیسے Netflix ربن یا پروگرام کے قابل پراکسی جیسے ایلچی کا استعمال کر رہے ہیں۔

اگر آپ توازن کے مسائل کو نظر انداز کرتے ہیں تو کیا ہوتا ہے؟

آپ لوڈ بیلنسنگ کا استعمال نہ کرنے کا انتخاب کر سکتے ہیں اور پھر بھی کوئی تبدیلی محسوس نہیں کرتے۔ آئیے کام کے چند منظرنامے دیکھتے ہیں۔

اگر آپ کے پاس سرورز سے زیادہ کلائنٹ ہیں تو یہ اتنا بڑا مسئلہ نہیں ہے۔

ہم کہتے ہیں کہ پانچ کلائنٹ ہیں جو دو سرورز سے جڑتے ہیں۔ یہاں تک کہ اگر کوئی توازن نہیں ہے، دونوں سرورز استعمال کیے جائیں گے:

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

جو زیادہ پریشانی کا باعث ہے وہ اس کے برعکس ہے۔

اگر آپ کے پاس کم کلائنٹس اور زیادہ سرور ہیں تو، آپ کے وسائل کو کم استعمال کیا جا سکتا ہے اور ممکنہ رکاوٹ ظاہر ہو جائے گی۔

ہم کہتے ہیں کہ دو کلائنٹ اور پانچ سرورز ہیں۔ بہترین صورت میں، پانچ میں سے دو سرورز سے دو مستقل کنکشن ہوں گے۔

باقی سرورز بیکار ہوں گے:

اگر یہ دو سرور کلائنٹ کی درخواستوں کو نہیں سنبھال سکتے ہیں، تو افقی اسکیلنگ مدد نہیں کرے گی۔

حاصل يہ ہوا

Kubernetes سروسز کو زیادہ تر معیاری ویب ایپلیکیشن کے منظرناموں میں کام کرنے کے لیے ڈیزائن کیا گیا ہے۔

تاہم، ایک بار جب آپ ایپلیکیشن پروٹوکولز کے ساتھ کام کرنا شروع کر دیتے ہیں جو مستقل TCP کنکشن استعمال کرتے ہیں، جیسے کہ ڈیٹا بیس، gRPC یا WebSockets، خدمات اب موزوں نہیں رہیں گی۔ Kubernetes مستقل TCP کنکشن کو متوازن کرنے کے لیے اندرونی میکانزم فراہم نہیں کرتا ہے۔

اس کا مطلب ہے کہ آپ کو کلائنٹ سائیڈ بیلنسنگ کو ذہن میں رکھتے ہوئے ایپلیکیشنز لکھنی چاہئیں۔

ٹیم کے ذریعہ تیار کردہ ترجمہ Mail.ru سے Kubernetes aaS.

موضوع پر اور کیا پڑھنا ہے۔:

1. Kubernetes میں آٹو اسکیلنگ کے تین درجے اور ان کو مؤثر طریقے سے استعمال کرنے کا طریقہ. 
2. قزاقی کی روح میں Kubernetes نفاذ کے لیے ایک ٹیمپلیٹ کے ساتھ.
3. ڈیجیٹل تبدیلی کے بارے میں ہمارا ٹیلیگرام چینل.

ماخذ: www.habr.com