په Kubernetes کې د اوږد مهاله اړیکو بار توازن او اندازه کول

دا مقاله به تاسو سره په دې پوهیدو کې مرسته وکړي چې په کبرنیټس کې د بار توازن څنګه کار کوي، څه پیښیږي کله چې د اوږدمهاله اړیکو اندازه کول، او ولې تاسو باید د مراجعینو اړخ توازن په پام کې ونیسئ که تاسو HTTP/2، gRPC، RSockets، AMQP، یا نور اوږد مهاله پروتوکولونه کاروئ. . 

د دې په اړه لږ څه چې په کوبرنیټس کې ترافیک له سره توزیع کیږي 

Kubernetes د غوښتنلیکونو د ځای پرځای کولو لپاره دوه مناسب خلاصون وړاندې کوي: خدمات او ځای پرځای کول.

ګمارنې تشریح کوي چې ستاسو د غوښتنلیک څومره او څومره کاپي باید په هر وخت کې پرمخ ولاړ شي. هر غوښتنلیک د پوډ په توګه ګمارل شوی او د IP پته ټاکل شوی.

خدمتونه په فعالیت کې د بار بیلنسر ته ورته دي. دوی ډیزاین شوي ترڅو په ډیری پوډونو کې ترافیک توزیع کړي.

راځئ چې وګورو چې دا څه ښکاري.

1. په لاندې انځور کې تاسو کولی شئ د ورته غوښتنلیک درې مثالونه او د بار بیلانسر وګورئ:

   

2. د بار بیلانسر ته خدمت ویل کیږي او د IP پته ټاکل شوې. هر راتلونکی غوښتنه د پوډ څخه یو ته لیږل کیږي:

   

3. د ګمارنې سناریو د غوښتنلیک د مثالونو شمیر ټاکي. تاسو به تقریبا هیڅکله اړتیا نلرئ مستقیم لاندې پراخه کړئ:

   

4. هر پوډ خپل IP پته ټاکل شوې ده:

   

دا ګټوره ده چې د IP پتې د ټولګې په توګه د خدماتو په اړه فکر وکړئ. هرکله چې تاسو خدمت ته لاسرسی ومومئ، د IP پتې څخه یو له لیست څخه غوره شوی او د منزل پته په توګه کارول کیږي.

دا داسې ښکاري.

1. د curl 10.96.45.152 غوښتنه خدمت ته ترلاسه کیږي:

   

2. خدمت د خپل منزل په توګه د دریو پوډ پتې څخه یو غوره کوي:

   

3. ترافیک یو ځانګړي پوډ ته لیږدول کیږي:

   

که ستاسو غوښتنلیک د فرنټ اینډ او بیک انډ څخه جوړ وي، نو تاسو به د هر یو لپاره خدمت او ګمارنه دواړه ولرئ.

کله چې فرنټ انډ بیک انډ ته غوښتنه کوي، دا اړتیا نلري چې دقیقا پوه شي چې پس منظر څومره پوډونه خدمت کوي: یو، لس، یا سل وي.

همچنان ، فرنټ اینډ د پوډونو پتې په اړه هیڅ نه پوهیږي چې شاته خدمت کوي.

کله چې فرنټ اینډ بیک انډ ته غوښتنه کوي، دا د بیک انډ خدمت IP پته کاروي، کوم چې بدلون نه کوي.

دا داسې ښکاري.

1. د 1 لاندې د داخلي پس منظر برخې غوښتنه کوي. د پس منظر لپاره د یو ځانګړي غوره کولو پرځای، دا خدمت ته غوښتنه کوي:

   

2. خدمت د منزل پته په توګه د شالید پوډونو څخه یو غوره کوي:

   

3. ټرافیک له Pod 1 څخه Pod 5 ته ځي، د خدماتو لخوا غوره شوی:

   

4. د 1 لاندې په سمه توګه نه پوهیږي چې څومره پوډونه لکه د 5 لاندې د خدماتو شاته پټ دي:

   

مګر څنګه واقعیا خدمت غوښتنې توزیع کوي؟ داسې ښکاري چې د راؤنډ رابین بیلانس کارول کیږي؟ راځئ چې دا معلومه کړو. 

د Kubernetes خدماتو کې توازن

د Kubernetes خدمتونه شتون نلري. د خدماتو لپاره هیڅ پروسه شتون نلري چې د IP پته او بندر ګمارل شوی وي.

تاسو کولی شئ دا په کلستر کې هر نوډ ته د ننوتلو او د netstat -ntlp کمانډ په چلولو سره تایید کړئ.

تاسو به حتی د دې توان ونلرئ چې خدمت ته ځانګړي شوي IP پته ومومئ.

د خدماتو IP پته د کنټرول پرت کې موقعیت لري، په کنټرولر کې، او په ډیټابیس کې ثبت شوی - etcd. ورته پته د بلې برخې لخوا کارول کیږي - kube-proxy.
کیوب پراکسي د ټولو خدماتو لپاره د IP پتې لیست ترلاسه کوي او په کلستر کې په هر نوډ کې د iptables مقرراتو سیټ رامینځته کوي.

دا قواعد وايي: "که موږ د خدماتو IP پته وګورو، موږ اړتیا لرو چې د غوښتنې ځای پته تعدیل کړو او یو پوډ ته یې واستوو."

د خدماتو IP پته یوازې د ننوتلو نقطې په توګه کارول کیږي او د دې IP پتې او پورټ اوریدلو هیڅ پروسې لخوا نه خدمت کیږي.

راځئ چې دا وګورو. 

1. د دریو نوډونو کلستر په پام کې ونیسئ. هر نوډ پوډونه لري:

   

2. تړل شوي پوزې رنګ شوي خنزیر د خدمت برخه ده. ځکه چې خدمت د پروسې په توګه شتون نلري، دا په خړ کې ښودل شوی:

   

3. لومړی پوډ د خدمت غوښتنه کوي او باید یو اړوند پوډ ته لاړ شي:

   

4. مګر خدمت شتون نلري، پروسه شتون نلري. دا څنګه کار کوی؟

   

5. مخکې لدې چې غوښتنه نوډ پریږدي ، دا د iptables قواعدو څخه تیریږي:

   

6. د iptables قواعد پوهیږي چې خدمت شتون نلري او خپل IP پته د دې خدمت سره تړلي پوډونو IP پتې سره بدلوي:

   

7. غوښتنه د منزل پته په توګه یو معتبر IP پته ترلاسه کوي او په نورمال ډول پروسس کیږي:

   

8. د شبکې ټوپولوژي پورې اړه لري، غوښتنه په پای کې پوډ ته رسیږي:

   

ایا iptables کولی شي بیلانس بار کړي؟

نه، iptables د فلټر کولو لپاره کارول کیږي او د توازن لپاره ډیزاین شوي ندي.

په هرصورت، دا ممکنه ده چې د قواعدو یوه مجموعه ولیکئ چې کار کوي pseudo-balancer.

او دا په حقیقت کې هغه څه دي چې په کبرنیټس کې پلي کیږي.

که تاسو درې پوډونه ولرئ، کیوب پراکسي به لاندې قواعد ولیکئ:

1. لومړی فرعي د 33٪ احتمال سره وټاکئ، که نه نو راتلونکي قاعدې ته لاړ شئ.
2. دوهم د 50٪ احتمال سره غوره کړئ ، که نه نو راتلونکي قاعدې ته لاړشئ.
3. لاندې دریم غوره کړئ.

د دې سیسټم په پایله کې هر پوډ د 33٪ احتمال سره غوره کیږي.

او هیڅ تضمین شتون نلري چې پوډ 2 به د پوډ 1 وروسته وروسته غوره شي.

تبصره: iptables د تصادفي توزیع سره احصایوي ماډل کاروي. په دې توګه، د انډول کولو الګوریتم د تصادفي انتخاب پر بنسټ والړ دی.

اوس چې تاسو پوهیږئ چې خدمات څنګه کار کوي، راځئ چې د خدماتو په زړه پورې سناریو وګورو.

په Kubernetes کې اوږدمهاله اړیکې په ډیفالټ اندازه نه کوي

هره HTTP غوښتنه له فرنټ اینډ څخه تر شاليد پورې د جلا TCP اتصال لخوا وړاندې کیږي ، کوم چې خلاص او تړل کیږي.

که فرنټ اینډ په هره ثانیه کې 100 غوښتنې بیکینډ ته واستوي، نو د 100 مختلف TCP اتصالونه خلاص او تړل کیږي.

تاسو کولی شئ د غوښتنې پروسس کولو وخت او بار کم کړئ د یو TCP اتصال په خلاصولو او د ټولو راتلونکو HTTP غوښتنو لپاره یې کارولو سره.

د HTTP پروتوکول یو ځانګړتیا لري چې د HTTP ساتل ژوندي یا د ارتباط بیا کارول په نوم یادیږي. په دې حالت کې، یو واحد TCP پیوستون د څو HTTP غوښتنو او ځوابونو لیږلو او ترلاسه کولو لپاره کارول کیږي:

دا فیچر د ډیفالټ په واسطه نه دی فعال شوی: دواړه سرور او پیرودونکي باید د دې مطابق تنظیم شي.

تنظیم پخپله ساده او د ډیری برنامو ژبو او چاپیریالونو لپاره د لاسرسي وړ دی.

دلته په مختلفو ژبو کې د مثالونو لپاره ځینې لینکونه دي:

• په Node.js کې ژوندي وساتئ
• د پسرلي په بوټ کې ژوندي وساتئ
• په Python کې ژوندی وساتئ
• په .NET کې ژوندي وساتئ

څه پیښیږي که چیرې موږ د کبرنیټس خدمت کې ژوندي ساتلو څخه کار واخلو؟
راځئ فرض کړو چې دواړه مخکښ او شاته ملاتړ ژوندي ساتي.

موږ د مخکینۍ برخې یوه کاپي او د شاتنۍ درې کاپي لرو. فرنټ اینډ لومړۍ غوښتنه کوي او شاته د TCP پیوستون خلاصوي. غوښتنه خدمت ته رسي ، د شاته پوډ څخه یو د منزل پته په توګه غوره شوی. شاته یو ځواب لیږي، او مخکینۍ برخه یې ترلاسه کوي.

د معمول حالت برخلاف چیرې چې د ځواب ترلاسه کولو وروسته د TCP اتصال بند شوی ، دا اوس د نورو HTTP غوښتنو لپاره خلاص ساتل شوی.

څه پیښیږي که فرنټ اینډ بیک انډ ته ډیرې غوښتنې واستوي؟

د دې غوښتنو د لیږلو لپاره ، د خلاص TCP پیوستون به وکارول شي ، ټولې غوښتنې به ورته شالید ته لاړ شي چیرې چې لومړۍ غوښتنه شوې وه.

ایا iptables باید ترافیک له سره توزیع نه کړي؟

په دې صورت کې نه.

کله چې د TCP پیوستون رامینځته شي ، نو دا د iptables قواعدو له لارې تیریږي ، کوم چې یو ځانګړی پس منظر غوره کوي چیرې چې ترافیک به ځي.

څنګه چې ټولې ورپسې غوښتنې د دمخه خلاص TCP اتصال کې دي ، نو د iptables قواعد نور نه ویل کیږي.

راځئ چې وګورو چې دا څه ښکاري.

1. لومړی پوډ خدمت ته غوښتنه لیږي:

   

2. تاسو دمخه پوهیږئ چې څه به پیښ شي. خدمت شتون نلري، مګر د iptables قواعد شتون لري چې غوښتنه به پروسس کړي:

   

3. د شاته پای پوډونو څخه یو به د منزل پته په توګه وټاکل شي:

   

4. غوښتنه پای ته رسیږي. په دې وخت کې، د دوو پوډونو ترمنځ د دوامداره TCP اړیکه به تاسیس شي:

   

5. د لومړي پوډ څخه هره بله غوښتنه به د دمخه رامینځته شوي پیوستون څخه تیریږي:

   

پایله د ګړندي غبرګون وخت او لوړ تولید دی ، مګر تاسو د شالید اندازه کولو وړتیا له لاسه ورکوئ.

حتی که تاسو په پس منظر کې دوه پوډونه ولرئ، د دوامداره اړیکو سره، ټرافيک به تل د دوی څخه یو ته ځي.

ایا دا ثابت کیدی شي؟

څرنګه چې کوبرنیټس نه پوهیږي چې څنګه دوامداره اړیکې توازن کړي، دا دنده تاسو ته رسیږي.

خدمتونه د IP پتې او بندرونو ټولګه ده چې د پای ټکي په نوم یادیږي.

ستاسو غوښتنلیک کولی شي د خدماتو څخه د پای ټکي لیست ترلاسه کړي او پریکړه وکړي چې څنګه د دوی ترمینځ غوښتنې توزیع کړي. تاسو کولی شئ د هر پوډ لپاره دوامداره پیوستون خلاص کړئ او د راؤنډ رابین په کارولو سره د دې اړیکو ترمینځ غوښتنې توازن کړئ.

یا نور درخواست وکړئ پیچلي توازن الګوریتم.

د پیرودونکي اړخ کوډ چې د توازن لپاره مسؤل دی باید دا منطق تعقیب کړي:

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
• gRPC
• RSockets
• AMQP

تاسو باید دمخه د دې ډیری پروتوکولونو سره آشنا اوسئ.

مګر که دا پروتوکولونه خورا مشهور وي، ولې د معیاري توازن حل شتون نلري؟ ولې د پیرودونکي منطق بدلون ته اړتیا لري؟ ایا د کوبرنیټس اصلي حل شتون لري؟

Kube-proxy او iptables د دې لپاره ډیزاین شوي چې ډیری عام استعمال قضیې پوښي کله چې کوبرنیټس ته ځای په ځای کیږي. دا د اسانتیا لپاره دی.

که تاسو یو ویب خدمت کاروئ چې د REST API افشا کوي ، تاسو په بخت کې یاست - پدې حالت کې ، دوامداره TCP اړیکې نه کارول کیږي ، تاسو کولی شئ د کوبرنیټس کوم خدمت وکاروئ.

مګر یوځل چې تاسو د دوامداره TCP اتصالاتو کارول پیل کړئ ، نو تاسو به دا معلومه کړئ چې څنګه په مساوي ډول د شالیدونو په اوږدو کې بار توزیع کړئ. Kubernetes د دې قضیې لپاره چمتو شوي حلونه نلري.

په هرصورت، یقینا داسې اختیارونه شتون لري چې مرسته کولی شي.

په Kubernetes کې د اوږدمهاله اړیکو توازن کول

په Kubernetes کې څلور ډوله خدمتونه شتون لري:

1. ClusterIP
2. نوډپورټ
3. LoadBlancer
4. بې سر

لومړی درې خدمتونه د مجازی IP پتې پراساس کار کوي، کوم چې د کیوب پراکسي لخوا د iptables قواعدو جوړولو لپاره کارول کیږي. مګر د ټولو خدماتو بنسټیز بنسټ بې سر خدمت دی.

بې سرې خدمت د دې سره تړلی هیڅ IP پته نلري او یوازې د IP پتې لیست ترلاسه کولو لپاره میکانیزم چمتو کوي او د پوډونو بندرونو (د پای ټکي) پورې تړاو لري.

ټول خدمتونه د بې سرې خدمت پر بنسټ دي.

د ClusterIP خدمت د ځینو اضافو سره بې سرې خدمت دی: 

1. د مدیریت پرت دې ته د IP پته ورکوي.
2. کیوب پراکسي د iptables اړین قواعد رامینځته کوي.

پدې توګه تاسو کولی شئ کیوب پراکسي له پامه غورځولی شئ او په مستقیم ډول د خپل غوښتنلیک بیلانس بار کولو لپاره د سر پرته خدمت څخه ترلاسه شوي پای ټکیو لیست وکاروئ.

مګر موږ څنګه کولی شو په کلستر کې ګمارل شوي ټولو غوښتنلیکونو ته ورته منطق اضافه کړو؟

که ستاسو غوښتنلیک لا دمخه ځای په ځای شوی وي، دا کار ممکن ناممکن ښکاري. په هرصورت، یو بدیل اختیار شتون لري.

د خدمت میش به ستاسو سره مرسته وکړي

تاسو شاید دمخه یادونه کړې وي چې د پیرودونکي اړخ بار بار توازن کولو ستراتیژي خورا معیاري ده.

کله چې غوښتنلیک پیل شي، دا:

1. د خدماتو څخه د IP پتې لیست ترلاسه کوي.
2. د اتصال پول خلاصوي او ساتي.
3. په دوره توګه د پای ټکی اضافه کولو یا لرې کولو سره حوض تازه کوي.

یوځل چې غوښتنلیک وغواړي غوښتنه وکړي، دا:

1. د ځینې منطق په کارولو سره یو موجود پیوستون غوره کوي (د بیلګې په توګه راؤنډ روبین).
2. غوښتنه اجرا کوي.

دا مرحلې د WebSockets، gRPC، او AMQP اړیکو لپاره کار کوي.

تاسو کولی شئ دا منطق په جلا کتابتون کې جلا کړئ او په خپلو غوښتنلیکونو کې یې وکاروئ.

په هرصورت، تاسو کولی شئ د خدماتو میشونه وکاروئ لکه اسټیو یا لینکرډ پرځای.

د خدماتو میش ستاسو غوښتنلیک د پروسې سره وده کوي چې:

1. په اتوماتيک ډول د خدماتو IP پتې لټوي.
2. اړیکې ازموي لکه WebSockets او gRPC.
3. د سم پروتوکول په کارولو سره غوښتنې توازن کړئ.

د خدماتو میش په کلستر کې د ټرافیک اداره کولو کې مرسته کوي، مګر دا خورا سرچینې لري. نور اختیارونه د دریمې ډلې کتابتونونه کاروي لکه Netflix ربن یا د پروګرام وړ پراکسي لکه Envoy.

که تاسو د توازن مسلو له پامه غورځوئ نو څه پیښیږي؟

تاسو کولی شئ غوره کړئ چې د بار توازن ونه کاروئ او لاهم هیڅ بدلون نه ګورئ. راځئ چې یو څو کاري سناریو وګورو.

که تاسو د سرورونو په پرتله ډیر پیرودونکي لرئ، دا دومره لویه ستونزه نده.

راځئ چې ووایو دلته پنځه پیرودونکي شتون لري چې دوه سرورونو سره وصل دي. حتی که چیرې توازن شتون ونلري، دواړه سرورونه به وکارول شي:

اړیکې ممکن په مساوي ډول توزیع نشي: شاید څلور پیرودونکي په ورته سرور سره وصل وي ، مګر یو ښه چانس شتون لري چې دواړه سرورونه به وکارول شي.

هغه څه چې ډیر ستونزمن دی مخالف سناریو ده.

که تاسو لږ پیرودونکي او ډیر سرورونه ولرئ، ستاسو سرچینې ممکن لږ کارول شي او احتمالي خنډ به څرګند شي.

راځئ چې ووایو دوه پیرودونکي او پنځه سرورونه شتون لري. په غوره حالت کې، له پنځو څخه دوه سرورونو ته به دوه دایمي اړیکې وي.

پاتې سرورونه به بې کاره وي:

که دا دوه سرورونه نشي کولی د پیرودونکي غوښتنې اداره کړي، افقی اندازه کول به مرسته ونه کړي.

پایلې

د Kubernetes خدمتونه د ډیری معیاري ویب غوښتنلیک سناریوګانو کې کار کولو لپاره ډیزاین شوي.

په هرصورت، یوځل چې تاسو د غوښتنلیک پروتوکولونو سره کار پیل کړئ کوم چې د دوامداره TCP اړیکې کاروي لکه ډیټابیسونه، gRPC یا WebSockets، خدمتونه نور مناسب ندي. Kubernetes د دوامداره TCP اړیکو توازن لپاره داخلي میکانیزمونه نه وړاندې کوي.

دا پدې مانا ده چې تاسو باید غوښتنلیکونه د پیرودونکي اړخ توازن سره په ذهن کې ولیکئ.

ژباړه د ټیم لخوا چمتو شوی Kubernetes aaS له Mail.ru څخه.

په موضوع نور څه لوستل:

1. په کبرنیټس کې د اتوماتیک کولو درې کچې او څنګه یې په مؤثره توګه کارول. 
2. Kubernetes د پلي کولو لپاره د یوې نمونې سره د سمندري غلو په روح کې.
3. د ډیجیټل بدلون په اړه زموږ د ټیلیګرام چینل.

سرچینه: www.habr.com