لوڊ بيلنسنگ ۽ اسڪيلنگ ڊگھي عرصي تائين ڪنيڪشن ڪبرنيٽس ۾

هي آرٽيڪل توهان کي سمجهڻ ۾ مدد ڏيندو ته ڪبرنيٽس ۾ لوڊ بيلنس ڪيئن ڪم ڪندو آهي، ڇا ٿيندو آهي جڏهن ڊگھي رهندڙ ڪنيڪشنن کي اسڪيل ڪيو ويندو آهي، ۽ جيڪڏهن توهان HTTP/2، gRPC، RSockets، AMQP، يا ٻيا ڊگھي زندگي پروٽوڪول استعمال ڪندا آهيو ته توهان کي ڪلائنٽ سائڊ بيلنسنگ تي ڇو غور ڪرڻ گهرجي. . 

ڪبرنيٽس ۾ ٽرئفڪ کي ٻيهر ورهائڻ بابت ٿورڙو 

ڪبرنيٽس ايپليڪيشنن کي ترتيب ڏيڻ لاءِ ٻه آسان خلاصا فراهم ڪري ٿو: خدمتون ۽ ترتيبون.

تعیناتيون بيان ڪن ٿيون ته توهان جي ايپليڪيشن جون ڪيتريون ڪاپيون ڪنهن به وقت تي هلڻ گهرجن. هر ايپليڪيشن کي پوڊ طور لڳايو ويو آهي ۽ هڪ IP پتو لڳايو ويو آهي.

خدمتون لوڊ بيلنس جي ڪم ۾ ساڳيون آهن. اهي ٺهيل آهن ٽرئفڪ کي ورهائڻ لاءِ ڪيترن ئي پوڊن ۾.

اچو ته ڏسو ته اهو ڇا ٿو لڳي.

1. هيٺ ڏنل آريگرام ۾ توهان هڪ ئي ايپليڪيشن جا ٽي مثال ۽ لوڊ بيلنس ڏسي سگهو ٿا:

   

2. لوڊ بيلنس کي خدمت سڏيو ويندو آهي ۽ هڪ IP پتو لڳايو ويو آهي. ڪا به ايندڙ درخواست پوڊ مان هڪ ڏانهن موڪلي وئي آهي:

   

3. ترتيب ڏيڻ واري صورتحال ايپليڪيشن جي مثالن جو تعداد طئي ڪري ٿي. توهان کي تقريبن ڪڏهن به سڌو سنئون هيٺ نه وڌائڻو پوندو:

   

4. هر پوڊ کي پنهنجو IP پتو لڳايو ويو آهي:

   

IP پتي جي مجموعن جي طور تي خدمتن کي سوچڻ لاء مفيد آهي. هر دفعي توهان خدمت تائين رسائي ڪريو ٿا، IP پتي مان هڪ فهرست مان چونڊيو ويو آهي ۽ منزل جي پتي طور استعمال ڪيو ويندو آهي.

اهو ڏسڻ ۾ اچي ٿو.

1. هڪ curl 10.96.45.152 درخواست ملي ٿي خدمت ڏانهن:

   

2. خدمت منزل جي طور تي ٽن پوڊ پتي مان هڪ کي چونڊيندو آهي:

   

3. ٽرئفڪ کي هڪ مخصوص پوڊ ڏانهن منتقل ڪيو ويو آهي:

   

جيڪڏهن توهان جي درخواست هڪ فرنٽ اينڊ ۽ هڪ پس منظر تي مشتمل آهي، ته پوءِ توهان وٽ هر هڪ لاءِ هڪ خدمت ۽ هڪ مقرري هوندي.

جڏهن فرنٽ اينڊ پس منظر کي درخواست ڪري ٿو، ان کي اهو ڄاڻڻ جي ضرورت ناهي ته پس منظر ۾ ڪيترا پوڊ ڪم ڪري ٿو: اتي هڪ، ڏهه، يا سئو ٿي سگهي ٿو.

انهي سان گڏ، فرنٽ اينڊ کي پوڊ جي پتي جي باري ۾ ڪجھ به نه ڄاڻندو آهي پس منظر جي خدمت ڪندي.

جڏهن فرنٽ اينڊ هڪ درخواست ڪري ٿو پس منظر ڏانهن، اهو استعمال ڪري ٿو IP پتي جو پس منظر سروس، جيڪو تبديل نٿو ڪري.

اهو ڪيئن ڏسڻ ۾ اچي ٿو.

1. 1 جي تحت اندروني پس منظر جزو جي درخواست ڪري ٿو. پس منظر لاءِ هڪ مخصوص چونڊڻ بدران، اها خدمت لاءِ درخواست ڪري ٿي:

   

2. خدمت ھڪڙي ھڪڙي پس منظر واري پوڊ کي منزل جي پتي جي طور تي چونڊيندي آھي:

   

3. ٽريفڪ پوڊ 1 کان پوڊ 5 تائين وڃي ٿي، خدمت پاران چونڊيل:

   

4. 1 کان هيٺ اهو نه ٿو ڄاڻي ته 5 کان گهٽ وانگر ڪيترا پوڊ سروس جي پويان لڪيل آهن:

   

پر حقيقت ۾ خدمت ڪيئن درخواستن کي ورهائي ٿي؟ اهو لڳي ٿو گول رابن بيلنس استعمال ڪيو ويو آهي؟ اچو ته ان جو اندازو لڳايو. 

Kubernetes خدمتن ۾ توازن

Kubernetes خدمتون موجود نه آهن. خدمت لاءِ ڪو به عمل نه آهي جنهن کي IP پتي ۽ بندرگاهه لڳايو ويو آهي.

توھان ان جي تصديق ڪري سگھوٿا ڪلستر ۾ ڪنھن به نوڊ ۾ لاگ ان ڪري ۽ netstat -ntlp ڪمانڊ هلائڻ سان.

توهان اڃا به نه ڳولي سگهندا ته IP پتي کي مختص ڪيل خدمت لاءِ.

خدمت جو 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 فلٽرنگ لاء استعمال ڪيا ويا آهن ۽ توازن لاء ٺهيل نه هئا.

تنهن هوندي، اهو ممڪن آهي ته ضابطن جو هڪ سيٽ لکڻ لاء جيڪو ڪم ڪري ٿو pseudo-balancer.

۽ اھو اھو آھي جيڪو ڪبرنيٽس ۾ لاڳو ڪيو ويو آھي.

جيڪڏھن توھان وٽ ٽي پوڊ آھن، kube-proxy ھيٺ ڏنل قاعدا لکندو.

1. 33٪ جي امڪان سان پهريون ذيلي چونڊيو، ٻي صورت ۾ ايندڙ قاعدي ڏانهن وڃو.
2. 50٪ جي امڪان سان ٻيو چونڊيو، ٻي صورت ۾ ايندڙ قاعدي ڏانهن وڃو.
3. هيٺيون ٽيون چونڊيو.

هن سسٽم جي نتيجي ۾ هر پوڊ کي 33٪ جي امڪان سان چونڊيو وڃي ٿو.

۽ ڪا به گارنٽي نه آهي ته پوڊ 2 پوڊ 1 کان پوءِ چونڊيو ويندو.

ويچاري: iptables هڪ شمارياتي ماڊل استعمال ڪري ٿو بي ترتيب تقسيم سان. اهڙيء طرح، بيلنسنگ الگورتھم بي ترتيب جي چونڊ تي ٻڌل آهي.

هاڻي ته توهان سمجهو ٿا ته خدمتون ڪيئن ڪم ڪن ٿيون، اچو ته ڏسو وڌيڪ دلچسپ سروس منظرنامو.

ڪبرنيٽس ۾ ڊگھي رھندڙ رابطا ڊفالٽ طور ماپ نه ڪندا آھن

فرنٽ اينڊ کان پس منظر تائين هر HTTP درخواست هڪ الڳ TCP ڪنيڪشن ذريعي پيش ڪيو ويندو آهي، جيڪو کوليو ۽ بند ڪيو ويندو آهي.

جيڪڏهن فرنٽ اينڊ موڪلي ٿو 100 درخواستون في سيڪنڊ پس منظر ڏانهن، پوءِ 100 مختلف TCP ڪنيڪشن کوليا ۽ بند ڪيا ويندا.

توهان هڪ TCP ڪنيڪشن کولڻ ۽ ان کي ايندڙ سڀني HTTP درخواستن لاءِ استعمال ڪندي درخواست جي پروسيسنگ وقت ۽ لوڊ کي گهٽائي سگهو ٿا.

HTTP پروٽوڪول ۾ هڪ خاصيت آهي جنهن کي HTTP Keep-alive، يا ڪنيڪشن ٻيهر استعمال ڪيو ويندو آهي. انهي صورت ۾، هڪ واحد TCP ڪنيڪشن ڪيترن ئي HTTP درخواستن ۽ جوابن کي موڪلڻ ۽ وصول ڪرڻ لاءِ استعمال ڪيو ويندو آهي:

ھي خصوصيت ڊفالٽ طور فعال نه ڪئي وئي آھي: ٻئي سرور ۽ ڪلائنٽ کي ترتيب ڏنل ھجڻ گھرجي.

سيٽ اپ پاڻ کي سادو آهي ۽ اڪثر پروگرامنگ ٻولين ۽ ماحول لاءِ رسائي لائق آهي.

هتي مختلف ٻولين ۾ مثالن جا ڪجهه لنڪ آهن:

• Node.js ۾ زندهه رکو
• بهار جي بوٽ ۾ زنده رکو
• پٿون ۾ زندهه رکو
• .NET ۾ زندهه رکو

ڇا ٿيندو جيڪڏهن اسان ڪبرنيٽس سروس ۾ Keep-alive استعمال ڪريون؟
اچو ته فرض ڪريون ته ٻئي فرنٽ اينڊ ۽ پس منظر جي حمايت زندهه رکو.

اسان وٽ فرنٽ اينڊ جي هڪ ڪاپي ۽ پسمنظر جون ٽي ڪاپيون آهن. فرنٽ اينڊ پهرين درخواست ڪري ٿو ۽ کولي ٿو TCP ڪنيڪشن کي پس منظر ڏانهن. درخواست خدمت تائين پهچندي آهي، پسمانده پوڊ مان هڪ کي منزل جي پتي طور چونڊيو ويندو آهي. پس منظر هڪ جواب موڪلي ٿو، ۽ فرنٽ اينڊ ان کي وصول ڪري ٿو.

معمولي صورتحال جي برعڪس جتي جواب ملڻ کان پوءِ TCP ڪنيڪشن بند ڪيو وڃي ٿو، ان کي هاڻي وڌيڪ HTTP درخواستن لاءِ کليل رکيو ويو آهي.

ڇا ٿيندو جيڪڏهن فرنٽ اينڊ پس منظر ڏانهن وڌيڪ درخواستون موڪلي ٿو؟

انهن درخواستن کي اڳتي وڌائڻ لاءِ، هڪ کليل TCP ڪنيڪشن استعمال ڪيو ويندو، سڀ درخواستون ساڳي پٺاڻ ڏانهن وينديون جتي پهرين درخواست هلي هئي.

ڇا iptables کي ٽرئفڪ کي ٻيهر ورهائڻ نه گهرجي؟

هن معاملي ۾ نه.

جڏهن هڪ TCP ڪنيڪشن ٺاهيو ويندو آهي، اهو iptables جي ضابطن ذريعي هلندو آهي، جيڪو هڪ مخصوص پس منظر چونڊيو جتي ٽرئفڪ ويندي.

جيئن ته سڀئي ايندڙ درخواستون اڳ ۾ ئي کليل TCP ڪنيڪشن تي آهن، iptables ضابطن کي هاڻي نه سڏيو ويندو آهي.

اچو ته ڏسو ته اهو ڇا ٿو لڳي.

1. پهرين پوڊ سروس ڏانهن هڪ درخواست موڪلي ٿو:

   

2. توهان اڳ ۾ ئي ڄاڻو ٿا ته اڳتي ڇا ٿيندو. خدمت موجود ناهي، پر اتي موجود آهن iptables ضابطا جيڪي درخواست تي عمل ڪندا:

   

3. ھڪڙي پس منظر واري پوڊ کي منزل جي پتي طور چونڊيو ويندو:

   

4. درخواست پوڊ تائين پهچي ٿي. هن نقطي تي، ٻن پوڊ جي وچ ۾ هڪ مسلسل TCP ڪنيڪشن قائم ڪيو ويندو:

   

5. پهرين پوڊ کان ايندڙ ڪنهن به درخواست اڳ ۾ ئي قائم ڪيل ڪنيڪشن ذريعي ويندي:

   

نتيجو تيز جوابي وقت ۽ اعليٰ ذريعي آهي، پر توهان پس منظر کي ماپڻ جي صلاحيت وڃائي ڇڏيو.

جيتوڻيڪ توهان وٽ پس منظر ۾ ٻه پوڊ آهن، مسلسل ڪنيڪشن سان، ٽرئفڪ هميشه انهن مان هڪ ڏانهن ويندي.

thisا اهو درست ٿي سگهي ٿو؟

جيئن ته ڪبرنيٽس کي خبر ناهي ته مسلسل ڪنيڪشن کي ڪيئن توازن ڪجي، اهو ڪم توهان تي پوي ٿو.

خدمتون IP پتي ۽ بندرگاهن جو مجموعو آهن جن کي آخري پوائنٽ سڏيو ويندو آهي.

توهان جي ايپليڪيشن سروس مان آخري پوائنٽن جي هڪ فهرست حاصل ڪري سگهي ٿي ۽ فيصلو ڪري سگهي ٿي ته انهن جي وچ ۾ درخواستون ڪيئن ورهائجن. توھان ھر پوڊ سان مسلسل ڪنيڪشن کولي سگھو ٿا ۽ انھن ڪنيڪشنن جي وچ ۾ بيلنس جي درخواستن کي گول-روبن استعمال ڪندي.

يا وڌيڪ لاڳو ڪريو پيچيده توازن algorithms.

ڪلائنٽ سائڊ ڪوڊ جيڪو توازن لاء ذميوار آهي هن منطق جي پيروي ڪرڻ گهرجي:

1. خدمت مان آخري پوائنٽن جي هڪ فهرست حاصل ڪريو.
2. هر آخري پوائنٽ لاء هڪ مسلسل ڪنيڪشن کوليو.
3. جڏهن هڪ درخواست ڪرڻ جي ضرورت آهي، استعمال ڪريو کليل ڪنيڪشن مان هڪ.
4. آخري پوائنٽن جي لسٽ کي باقاعده طور تي تازه ڪاري ڪريو، نوان ٺاھيو يا پراڻا لڳاتار ڪنيڪشن بند ڪريو جيڪڏھن لسٽ تبديل ٿي وڃي.

اھو اھو آھي جيڪو اھو نظر ايندو.

1. خدمت ڏانهن درخواست موڪلڻ واري پهرين پوڊ جي بدران، توهان ڪلائنٽ جي طرف درخواستن کي بيلنس ڪري سگهو ٿا:

   

2. توهان کي ڪوڊ لکڻ جي ضرورت آهي جيڪو پڇي ٿو ته ڪهڙا پوڊ سروس جو حصو آهن:

   

3. هڪ دفعو توهان وٽ لسٽ آهي، ان کي ڪلائنٽ جي پاسي تي محفوظ ڪريو ۽ پوڊ سان ڳنڍڻ لاء استعمال ڪريو:

   

4. توهان لوڊ بيلنسنگ الگورتھم جا ذميوار آهيو:

   

هاڻي سوال پيدا ٿئي ٿو: ڇا اهو مسئلو صرف HTTP کي زنده رکڻ تي لاڳو ٿئي ٿو؟

ڪلائنٽ طرف لوڊ توازن

HTTP واحد پروٽوڪول نه آهي جيڪو استعمال ڪري سگهي ٿو مسلسل TCP ڪنيڪشن.

جيڪڏهن توهان جي ايپليڪيشن ڊيٽابيس استعمال ڪري ٿي، ته پوءِ هڪ TCP ڪنيڪشن نه کوليندو آهي هر وقت توهان کي ڊيٽابيس مان ڪا درخواست ڪرڻ يا ٻيهر حاصل ڪرڻ جي ضرورت آهي. 

ان جي بدران، ڊيٽابيس سان مسلسل TCP ڪنيڪشن کوليو ۽ استعمال ڪيو ويو آهي.

جيڪڏهن توهان جو ڊيٽابيس ڪبرنيٽس تي لڳايو ويو آهي ۽ رسائي هڪ خدمت جي طور تي مهيا ڪئي وئي آهي، ته پوءِ توهان ساڳئي مسئلن کي منهن ڏيندا جيڪي اڳئين حصي ۾ بيان ڪيا ويا آهن.

ھڪڙي ڊيٽابيس جي نقل ٻين کان وڌيڪ لوڊ ٿي ويندي. 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
• ايم پي پي

توھان کي انھن مان گھڻا پروٽوڪول کان واقف ٿيڻ گھرجي.

پر جيڪڏهن اهي پروٽوڪول تمام مشهور آهن، اتي هڪ معياري توازن حل ڇو نه آهي؟ ڪلائنٽ منطق کي تبديل ڪرڻ جي ضرورت ڇو آهي؟ ڇا ھڪڙو اصلي Kubernetes حل آھي؟

Kube-proxy ۽ iptables ٺهيل آهن اڪثر عام استعمال جي ڪيسن کي ڍڪڻ لاءِ جڏهن ڪبرنيٽس کي ترتيب ڏيو. هي سهولت لاءِ آهي.

جيڪڏهن توهان هڪ ويب سروس استعمال ڪري رهيا آهيو جيڪا هڪ REST API کي ظاهر ڪري ٿي، توهان قسمت ۾ آهيو - انهي صورت ۾، مسلسل TCP ڪنيڪشن استعمال نه ڪيا ويا آهن، توهان ڪنهن به ڪبرنيٽس سروس استعمال ڪري سگهو ٿا.

پر هڪ دفعو توهان لڳاتار TCP ڪنيڪشن استعمال ڪرڻ شروع ڪيو، توهان کي اهو معلوم ڪرڻو پوندو ته لوڊ کي پس منظر ۾ هڪجهڙائي سان ڪيئن ورهايو وڃي. ڪبرنيٽس هن ڪيس لاءِ تيار ڪيل حل تي مشتمل ناهي.

تنهن هوندي، يقينا، اهڙا اختيار آهن جيڪي مدد ڪري سگهن ٿيون.

ڪبرنيٽس ۾ ڊگھي رهندڙ رابطن کي بيلنس ڪرڻ

ڪبرنيٽس ۾ چار قسم جون خدمتون آهن:

1. ڪلستر پي
2. نوڊ پورٽ
3. لوڊ بيلنسر
4. بي نياز

پهرين ٽي خدمتون هڪ مجازي IP پتي جي بنياد تي هلن ٿيون، جيڪو iptables قاعدن کي ٺاهڻ لاء kube-proxy پاران استعمال ڪيو ويندو آهي. پر سڀني خدمتن جو بنيادي بنياد بغير سر جي خدمت آهي.

هيڊ بيس سروس ان سان لاڳاپيل ڪو به IP پتو نه آهي ۽ صرف IP پتي جي فهرست ۽ ان سان لاڳاپيل پوڊس (آخري پوائنٽس) جي بندرگاهن کي ٻيهر حاصل ڪرڻ لاءِ هڪ ميکانيزم مهيا ڪري ٿي.

سڀئي خدمتون سر جي بغير خدمت تي ٻڌل آهن.

ClusterIP سروس ڪجھ اضافن سان گڏ ھڪڙو بي سر سروس آھي: 

1. انتظامي پرت ان کي هڪ IP پتو تفويض ڪري ٿو.
2. Kube-proxy ضروري iptables ضابطا ٺاهي ٿو.

هن طريقي سان توهان kube-proxy کي نظر انداز ڪري سگهو ٿا ۽ سڌو سنئون استعمال ڪري سگهو ٿا آخري پوائنٽس جي لسٽ حاصل ڪيل هيڊ لیس سروس مان توهان جي ايپليڪيشن کي بيلنس لوڊ ڪرڻ لاءِ.

پر اسان ڪلستر ۾ مقرر ڪيل سڀني ايپليڪيشنن ۾ ساڳيو منطق ڪيئن شامل ڪري سگهون ٿا؟

جيڪڏهن توهان جي اپليڪيشن اڳ ۾ ئي ترتيب ڏني وئي آهي، اهو ڪم ناممڪن لڳي سگهي ٿو. تنهن هوندي به، اتي هڪ متبادل اختيار آهي.

خدمت Mesh توهان جي مدد ڪندو

توهان شايد اڳ ۾ ئي محسوس ڪيو آهي ته ڪلائنٽ-سائڊ لوڊ بيلنسنگ حڪمت عملي ڪافي معياري آهي.

جڏهن اپليڪيشن شروع ٿئي ٿي، اهو:

1. خدمت مان IP پتي جي لسٽ حاصل ڪري ٿي.
2. ڪنيڪشن پول کولي ٿو ۽ برقرار رکي ٿو.
3. وقتي طور تي آخري پوائنٽ شامل ڪرڻ يا ختم ڪندي پول کي اپڊيٽ ڪري ٿو.

هڪ دفعو ايپليڪيشن هڪ درخواست ڪرڻ چاهي ٿي، اهو:

1. ڪجھ منطق استعمال ڪندي دستياب ڪنيڪشن کي چونڊيو (مثال طور راؤنڊ-رابن).
2. درخواست تي عمل ڪري ٿو.

اهي مرحلا ٻنهي WebSockets، gRPC، ۽ AMQP ڪنيڪشن لاءِ ڪم ڪن ٿا.

توھان ھن منطق کي الڳ لائبريري ۾ الڳ ڪري سگھوٿا ۽ ان کي پنھنجي ايپليڪيشنن ۾ استعمال ڪريو.

تنهن هوندي، توهان استعمال ڪري سگهو ٿا سروس ميش وانگر Istio يا Linkerd بدران.

سروس ميش توهان جي ايپليڪيشن کي هڪ عمل سان وڌايو آهي جيڪو:

1. خودڪار طور تي سروس IP پتي جي ڳولا ڪري ٿو.
2. ٽيسٽ ڪنيڪشن جهڙوڪ WebSockets ۽ gRPC.
3. صحيح پروٽوڪول استعمال ڪندي درخواستن کي بيلنس ڪري ٿو.

سروس ميش ڪلستر جي اندر ٽرئفڪ کي منظم ڪرڻ ۾ مدد ڪري ٿي، پر اهو ڪافي وسيلا-گھڻي آهي. ٻيا اختيار استعمال ڪري رهيا آهن ٽئين پارٽي لائبريريون جهڙوڪ Netflix ربن يا پروگرام لائق پراڪسز جهڙوڪ Envoy.

ڇا ٿيندو جيڪڏهن توهان توازن جي مسئلن کي نظرانداز ڪيو؟

توھان چونڊي سگھوٿا لوڊ بيلنس استعمال نه ڪرڻ ۽ اڃا تائين ڪا به تبديلي محسوس نه ڪئي. اچو ته ڪجھ ڪم جي منظرنامي تي نظر رکون.

جيڪڏهن توهان وٽ سرور کان وڌيڪ گراهڪ آهن، اهو هڪ وڏو مسئلو ناهي.

اچو ته چوندا آھن پنج ڪلائنٽ آھن جيڪي ٻن سرورن سان ڳنڍيندا آھن. جيتوڻيڪ اتي ڪو توازن نه آهي، ٻئي سرور استعمال ڪيا ويندا:

ڪنيڪشن شايد برابر طور تي ورهايل نه هجن: شايد چار ڪلائنٽ هڪ ئي سرور سان ڳنڍيل آهن، پر اتي هڪ سٺو موقعو آهي ته ٻئي سرور استعمال ڪيا ويندا.

ڇا وڌيڪ مسئلو آهي سامهون واري صورتحال آهي.

جيڪڏهن توهان وٽ گهٽ ڪلائنٽ ۽ وڌيڪ سرور آهن، توهان جا وسيلا گهٽ استعمال ڪيا ويندا ۽ هڪ امڪاني رڪاوٽ ظاهر ٿيندي.

اچو ته چوندا آهن ٻه ڪلائنٽ ۽ پنج سرور. بهترين صورت ۾، پنجن مان ٻن سرورن سان ٻه مستقل ڪنيڪشن هوندا.

باقي سرورز بيڪار ٿي ويندا:

جيڪڏهن اهي ٻه سرور ڪلائنٽ جي درخواستن کي سنڀالي نٿا سگهن، افقي اسڪيلنگ مدد نه ڪندي.

ٿڪل

Kubernetes خدمتون تمام معياري ويب ايپليڪيشن منظرنامي ۾ ڪم ڪرڻ لاءِ ٺهيل آهن.

تنهن هوندي، هڪ دفعو توهان ايپليڪيشن پروٽوڪولن سان ڪم ڪرڻ شروع ڪيو جيڪي مسلسل TCP ڪنيڪشن استعمال ڪن ٿا، جهڙوڪ ڊيٽابيس، gRPC يا WebSockets، خدمتون هاڻي مناسب نه آهن. Kubernetes مسلسل TCP ڪنيڪشن کي توازن ڪرڻ لاءِ اندروني ميڪانيزم مهيا نٿو ڪري.

هن جو مطلب آهي ته توهان کي ذهن ۾ ڪلائنٽ پاسي جي توازن سان ايپليڪيشنون لکڻ گهرجن.

ٽيم پاران تيار ڪيل ترجمو Mail.ru کان Kubernetes aaS.

موضوع تي ٻيو ڇا پڙهو:

1. ڪبرنيٽس ۾ آٽو اسڪيلنگ جا ٽي سطح ۽ انهن کي ڪيئن موثر طريقي سان استعمال ڪجي. 
2. قزاق جي روح ۾ ڪبرنيٽس عملدرآمد لاءِ ٽيمپليٽ سان.
3. ڊجيٽل تبديليءَ بابت اسان جو ٽيليگرام چينل.

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