Kubernetes میں آٹو اسکیلنگ اور وسائل کا انتظام (جائزہ اور ویڈیو رپورٹ)

27 اپریل کو کانفرنس میں ہڑتال 2019، "DevOps" سیکشن کے حصے کے طور پر، رپورٹ "کوبرنیٹس میں آٹو اسکیلنگ اور وسائل کا انتظام" دی گئی تھی۔ یہ اس بارے میں بات کرتا ہے کہ آپ اپنی ایپلی کیشنز کی اعلی دستیابی کو یقینی بنانے اور اعلی کارکردگی کو یقینی بنانے کے لیے کس طرح K8s کا استعمال کر سکتے ہیں۔

روایت کے مطابق، ہم پیش کرنے کے لئے خوش ہیں رپورٹ کی ویڈیو (44 منٹ، مضمون سے کہیں زیادہ معلوماتی) اور متن کی شکل میں مرکزی خلاصہ۔ جاؤ!

آئیے رپورٹ کے عنوان کا لفظ بہ لفظ تجزیہ کرتے ہیں اور آخر سے شروع کرتے ہیں۔

Kubernetes

ہم کہتے ہیں کہ ہمارے پاس ہمارے میزبان پر ڈوکر کنٹینرز ہیں۔ کس لیے؟ دہرانے کی صلاحیت اور تنہائی کو یقینی بنانے کے لیے، جس کے نتیجے میں سادہ اور اچھی تعیناتی کی اجازت ملتی ہے، CI/CD۔ ہمارے پاس ایسی بہت سی گاڑیاں ہیں جن میں کنٹینرز ہیں۔

کوبرنیٹس اس معاملے میں کیا فراہم کرتا ہے؟

1. ہم ان مشینوں کے بارے میں سوچنا چھوڑ دیتے ہیں اور "کلاؤڈ" کے ساتھ کام کرنا شروع کر دیتے ہیں۔ کنٹینرز کا جھرمٹ یا پھلی (کنٹینرز کے گروپ)۔
2. مزید یہ کہ ہم انفرادی پوڈز کے بارے میں بھی نہیں سوچتے بلکہ مزید انتظام کرتے ہیں۔оبڑے گروپس. ایسے اعلی درجے کی قدیم چیزیں ہمیں یہ کہنے کی اجازت دیں کہ کام کے ایک خاص بوجھ کو چلانے کے لیے ایک ٹیمپلیٹ موجود ہے، اور اسے چلانے کے لیے مثالوں کی مطلوبہ تعداد یہ ہے۔ اگر ہم بعد میں ٹیمپلیٹ کو تبدیل کرتے ہیں، تو تمام مثالیں بدل جائیں گی۔
3. کے ساتھ اعلانیہ API مخصوص حکموں کی ترتیب پر عمل کرنے کے بجائے، ہم "دنیا کی ساخت" (YAML میں) کی وضاحت کرتے ہیں، جسے Kubernetes نے بنایا ہے۔ اور دوبارہ: جب تفصیل بدل جائے گی تو اس کا اصل ڈسپلے بھی بدل جائے گا۔

وسائل کے انتظام

CPU

آئیے ہم سرور پر nginx، php-fpm اور mysql چلاتے ہیں۔ ان خدمات میں درحقیقت اور بھی زیادہ عمل چل رہے ہوں گے، جن میں سے ہر ایک کو کمپیوٹنگ وسائل کی ضرورت ہوتی ہے:

(سلائیڈ پر نمبر "طوطے" ہیں، کمپیوٹنگ پاور کے لیے ہر عمل کی تجریدی ضرورت)

اس کے ساتھ کام کرنا آسان بنانے کے لیے، عمل کو گروپس میں جوڑنا منطقی ہے (مثال کے طور پر، تمام nginx عمل کو ایک گروپ "nginx" میں)۔ ایسا کرنے کا ایک آسان اور واضح طریقہ یہ ہے کہ ہر گروپ کو ایک کنٹینر میں ڈالا جائے:

جاری رکھنے کے لیے، آپ کو یاد رکھنا ہوگا کہ کنٹینر کیا ہے (لینکس میں)۔ ان کی ظاہری شکل دانا میں تین اہم خصوصیات کی بدولت ممکن ہوئی، جو کافی عرصہ پہلے نافذ کی گئی تھیں۔ صلاحیتوں, نام کی جگہیں и سی گروپس. اور مزید ترقی کو دیگر ٹیکنالوجیز کے ذریعے سہولت فراہم کی گئی تھی (بشمول آسان "شیلز" جیسے ڈوکر):

رپورٹ کے تناظر میں، ہم صرف دلچسپی رکھتے ہیں سی گروپس، کیونکہ کنٹرول گروپ کنٹینرز (ڈوکر، وغیرہ) کی فعالیت کا حصہ ہیں جو وسائل کے انتظام کو نافذ کرتے ہیں۔ گروپوں میں مل کر عمل، جیسا کہ ہم چاہتے تھے، کنٹرول گروپ ہیں۔

آئیے ان عملوں کے لیے CPU کی ضروریات پر واپس آتے ہیں، اور اب عمل کے گروپس کے لیے:

(میں دہراتا ہوں کہ تمام اعداد وسائل کی ضرورت کا خلاصہ اظہار ہیں)

ایک ہی وقت میں، سی پی یو کے پاس خود ایک مخصوص محدود وسائل ہیں۔ (مثال کے طور پر یہ 1000 ہے)، جس کی ہر ایک کو کمی ہو سکتی ہے (تمام گروپوں کی ضروریات کا مجموعہ 150+850+460=1460 ہے)۔ اس معاملے میں کیا ہوگا؟

دانا وسائل کی تقسیم شروع کرتا ہے اور اسے "منصفانہ" کرتا ہے، ہر گروپ کو وسائل کی ایک ہی مقدار دیتا ہے۔ لیکن پہلی صورت میں، ان میں سے ضرورت سے زیادہ ہیں (333> 150)، لہذا اضافی (333-150=183) ریزرو میں رہتا ہے، جو دو دیگر کنٹینرز کے درمیان بھی مساوی طور پر تقسیم کیا جاتا ہے:

نتیجے کے طور پر: پہلے کنٹینر کے پاس کافی وسائل تھے، دوسرا - اس کے پاس کافی وسائل نہیں تھے، تیسرا - اس کے پاس کافی وسائل نہیں تھے۔ یہ اعمال کا نتیجہ ہے۔ لینکس میں "ایماندار" شیڈولر - سییفایس. اس کے آپریشن کو اسائنمنٹ کا استعمال کرتے ہوئے ایڈجسٹ کیا جا سکتا ہے۔ وزن کنٹینرز میں سے ہر ایک. مثال کے طور پر، اس طرح:

آئیے دوسرے کنٹینر (php-fpm) میں وسائل کی کمی کے معاملے کو دیکھتے ہیں۔ تمام کنٹینر وسائل عمل کے درمیان یکساں طور پر تقسیم کیے جاتے ہیں۔ نتیجے کے طور پر، ماسٹر پروسیس اچھی طرح سے کام کرتا ہے، لیکن تمام کارکن سست ہوجاتے ہیں، اپنی ضرورت کے نصف سے بھی کم وصول کرتے ہیں:

CFS شیڈولر اس طرح کام کرتا ہے۔ ہم ان وزنوں کو مزید کال کریں گے جو ہم کنٹینرز کو تفویض کرتے ہیں۔ درخواستیں. ایسا کیوں ہے - مزید دیکھیں۔

آئیے پوری صورتحال کو دوسری طرف سے دیکھتے ہیں۔ جیسا کہ آپ جانتے ہیں، تمام سڑکیں روم کی طرف جاتی ہیں، اور کمپیوٹر کی صورت میں، CPU کی طرف۔ ایک سی پی یو، بہت سے کام - آپ کو ٹریفک لائٹ کی ضرورت ہے۔ وسائل کو منظم کرنے کا سب سے آسان طریقہ "ٹریفک لائٹ" ہے: انہوں نے ایک عمل کو سی پی یو تک رسائی کا مقررہ وقت دیا، پھر اگلا، وغیرہ۔

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

آئیے لینکس کرنل اور سی پی یو کے ساتھ اس کے تعامل پر واپس آتے ہیں - مجموعی تصویر مندرجہ ذیل ہے:

cgroup کی دو ترتیبات ہیں - بنیادی طور پر یہ دو سادہ "موڑ" ہیں جو آپ کو تعین کرنے کی اجازت دیتے ہیں:

1. کنٹینر (درخواستوں) کا وزن ہے۔ حصص;
2. کنٹینر کے کاموں پر کام کرنے کے لئے کل CPU وقت کا فیصد (حد) ہے۔ کوٹے.

سی پی یو کی پیمائش کیسے کریں؟

مختلف طریقے ہیں:

1. کیا ہے توتے، کوئی نہیں جانتا - آپ کو ہر بار گفت و شنید کرنے کی ضرورت ہے۔
2. دلچسپی واضح، لیکن رشتہ دار: 50 کور والے سرور کا 4٪ اور 20 کور کے ساتھ بالکل مختلف چیزیں ہیں۔
3. آپ پہلے ہی ذکر کردہ استعمال کرسکتے ہیں۔ وزن، جسے لینکس جانتا ہے، لیکن وہ رشتہ دار بھی ہیں۔
4. سب سے مناسب آپشن کمپیوٹنگ وسائل کی پیمائش کرنا ہے۔ سیکنڈ. وہ. پروسیسر ٹائم کے سیکنڈوں میں ریئل ٹائم کے سیکنڈز کے مقابلے میں: پروسیسر ٹائم کا 1 سیکنڈ فی 1 ریئل سیکنڈ دیا گیا - یہ ایک پورا CPU کور ہے۔

اسے بولنے میں اور بھی آسانی پیدا کرنے کے لیے، انہوں نے براہ راست اندر کی پیمائش شروع کی۔ دانا، ان کے ذریعہ معنی حقیقی کے مقابلے میں وہی سی پی یو وقت۔ چونکہ لینکس وزن کو سمجھتا ہے، لیکن اتنا زیادہ CPU ٹائم/کور نہیں، اس لیے ایک سے دوسرے میں ترجمہ کرنے کے لیے ایک طریقہ کار کی ضرورت تھی۔

آئیے 3 سی پی یو کور والے سرور کے ساتھ ایک سادہ مثال پر غور کریں، جہاں تین پوڈز کو وزن دیا جائے گا (500، 1000 اور 1500) جو آسانی سے ان کے لیے مختص کور کے متعلقہ حصوں (0,5، 1 اور 1,5) میں تبدیل ہو جاتے ہیں۔

اگر آپ دوسرا سرور لیں، جہاں دو گنا زیادہ کور (6) ہوں گے، اور ایک ہی پوڈ کو وہاں رکھیں تو، کور کی تقسیم کو آسانی سے 2 (1، 2 اور 3، بالترتیب) سے ضرب دے کر لگایا جا سکتا ہے۔ لیکن ایک اہم لمحہ اس وقت ہوتا ہے جب اس سرور پر چوتھا پوڈ ظاہر ہوتا ہے، جس کا وزن، سہولت کے لیے، 3000 ہوگا۔ یہ CPU وسائل (آدھے کور) کا کچھ حصہ لے جاتا ہے، اور بقیہ پوڈز کے لیے ان کی دوبارہ گنتی کی جاتی ہے (آدھی):

Kubernetes اور CPU وسائل

Kubernetes میں، CPU کے وسائل کو عام طور پر ماپا جاتا ہے۔ ملیڈریکس، یعنی 0,001 کور کو بنیادی وزن کے طور پر لیا جاتا ہے۔ (Linux/cgroups کی اصطلاح میں اسی چیز کو CPU شیئر کہا جاتا ہے، حالانکہ، زیادہ واضح طور پر، 1000 millicores = 1024 CPU شیئرز۔) K8s اس بات کو یقینی بناتا ہے کہ یہ تمام پوڈز کے وزن کے مجموعے کے لیے CPU وسائل سے زیادہ پوڈز کو سرور پر نہیں رکھتا ہے۔

یہ کیسے ہوتا ہے؟ جب آپ کوبرنیٹس کلسٹر میں سرور شامل کرتے ہیں، تو یہ بتایا جاتا ہے کہ اس کے پاس کتنے CPU کور دستیاب ہیں۔ اور ایک نیا پوڈ بناتے وقت، Kubernetes شیڈولر جانتا ہے کہ اس پوڈ کو کتنے کور کی ضرورت ہوگی۔ اس طرح، پوڈ کو ایک سرور کو تفویض کیا جائے گا جہاں کافی کور موجود ہوں۔

کیا ہو گا اگر کوئی درخواست کی وضاحت کی گئی ہے (یعنی پوڈ کے پاس مطلوبہ کور کی ایک متعین تعداد نہیں ہے)؟ آئیے یہ معلوم کریں کہ Kubernetes عام طور پر وسائل کو کس طرح شمار کرتا ہے۔

پوڈ کے لیے، آپ دونوں درخواستیں (CFS شیڈولر) اور حدود (ٹریفک لائٹ یاد رکھیں؟):

• اگر وہ برابر بتائے گئے ہیں، تو پوڈ کو ایک QoS کلاس تفویض کیا جاتا ہے۔ بات کی ضمانت. اس کے لیے ہمیشہ دستیاب کور کی یہ تعداد یقینی ہے۔
• اگر درخواست حد سے کم ہے - QoS کلاس پھٹنے کے قابل. وہ. ہم ایک پوڈ کی توقع کرتے ہیں، مثال کے طور پر، ہمیشہ 1 کور استعمال کرے، لیکن یہ قدر اس کے لیے کوئی حد نہیں ہے: کبھی کبھی پوڈ زیادہ استعمال کرسکتا ہے (جب سرور کے پاس اس کے لئے مفت وسائل ہوں)۔
• ایک QoS کلاس بھی ہے۔ بہترین کوشش - اس میں وہی پوڈ شامل ہیں جن کے لیے درخواست کی وضاحت نہیں کی گئی ہے۔ وسائل ان کو آخری دیے جاتے ہیں۔

یاد رکھیں

میموری کے ساتھ، صورت حال ایک جیسی ہے، لیکن تھوڑا سا مختلف - سب کے بعد، ان وسائل کی نوعیت مختلف ہے. عام طور پر، مشابہت مندرجہ ذیل ہے:

آئیے دیکھتے ہیں کہ میموری میں درخواستوں کو کیسے لاگو کیا جاتا ہے۔ پوڈز کو سرور پر رہنے دیں، میموری کی کھپت کو تبدیل کرتے ہوئے، یہاں تک کہ ان میں سے ایک اتنا بڑا ہو جائے کہ اس کی میموری ختم نہ ہو جائے۔ اس صورت میں، OOM قاتل ظاہر ہوتا ہے اور سب سے بڑے عمل کو ختم کرتا ہے:

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

آئیے CPU کی QoS کلاسز پر واپس آتے ہیں اور oom_score_adj اقدار کے ساتھ ایک مشابہت بنائیں جو پوڈز کے لیے میموری کی کھپت کی ترجیحات کا تعین کرتی ہیں:

• پوڈ کے لیے سب سے کم oom_score_adj ویلیو - -998 - کا مطلب ہے کہ ایسی پوڈ کو آخری بار مار دیا جائے، یہ بات کی ضمانت.
• سب سے زیادہ - 1000 - ہے بہترین کوششاس طرح کی پھلیوں کو پہلے مارا جاتا ہے۔
• باقی اقدار کا حساب لگانے کے لیے (پھٹنے کے قابل) ایک فارمولہ ہے، جس کا نچوڑ اس حقیقت پر ابلتا ہے کہ پوڈ نے جتنے زیادہ وسائل کی درخواست کی ہے، اس کے مارے جانے کا امکان اتنا ہی کم ہے۔

دوسرا "موڑ" - limit_in_bytes --.حدود کے لئے اس کے ساتھ، سب کچھ آسان ہے: ہم صرف جاری کردہ میموری کی زیادہ سے زیادہ مقدار تفویض کرتے ہیں، اور یہاں (سی پی یو کے برعکس) اس (میموری) کی پیمائش کرنے کا کوئی سوال نہیں ہے۔

مجموعی طور پر

Kubernetes میں ہر پوڈ دیا جاتا ہے requests и limits - سی پی یو اور میموری دونوں پیرامیٹرز:

1. درخواستوں کی بنیاد پر، Kubernetes شیڈولر کام کرتا ہے، جو سرورز کے درمیان پوڈ تقسیم کرتا ہے۔
2. تمام پیرامیٹرز کی بنیاد پر، پوڈ کی QoS کلاس کا تعین کیا جاتا ہے۔
3. سی پی یو کی درخواستوں کی بنیاد پر متعلقہ وزن کا حساب لگایا جاتا ہے۔
4. CFS شیڈیولر CPU درخواستوں کی بنیاد پر ترتیب دیا گیا ہے۔
5. OOM قاتل کو میموری کی درخواستوں کی بنیاد پر ترتیب دیا گیا ہے۔
6. ایک "ٹریفک لائٹ" سی پی یو کی حدود کی بنیاد پر ترتیب دی گئی ہے۔
7. میموری کی حدود کی بنیاد پر، سی گروپ کے لیے ایک حد ترتیب دی گئی ہے۔

عام طور پر، یہ تصویر ان تمام سوالات کے جوابات دیتی ہے کہ کس طرح وسائل کے انتظام کا اہم حصہ Kubernetes میں ہوتا ہے۔

آٹو اسکیلنگ

K8s کلسٹر آٹو اسکیلر

آئیے تصور کریں کہ پورے کلسٹر پر پہلے ہی قبضہ ہے اور ایک نیا پوڈ بنانے کی ضرورت ہے۔ جبکہ پوڈ ظاہر نہیں ہو سکتا، یہ حالت میں لٹکا رہتا ہے۔ زیر غور. اس کے ظاہر ہونے کے لیے، ہم ایک نئے سرور کو کلسٹر سے جوڑ سکتے ہیں یا... کلسٹر-آٹو اسکیلر انسٹال کر سکتے ہیں، جو یہ ہمارے لیے کرے گا: کلاؤڈ فراہم کنندہ سے ایک ورچوئل مشین کا آرڈر دیں (ایک API درخواست کا استعمال کرتے ہوئے) اور اسے کلسٹر سے جوڑیں۔ ، جس کے بعد پوڈ کو شامل کیا جائے گا۔

یہ Kubernetes کلسٹر کی آٹو اسکیلنگ ہے، جو بہت اچھا کام کرتا ہے (ہمارے تجربے میں)۔ تاہم، دوسری جگہوں کی طرح، یہاں بھی کچھ باریکیاں ہیں...

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

3 سرورز کے کلسٹر پر غور کریں جن میں تعیناتی ہے۔ اس میں 6 پوڈز ہیں: اب ہر سرور کے لیے 2 ہیں۔ کسی وجہ سے ہم سرورز میں سے ایک کو بند کرنا چاہتے تھے۔ ایسا کرنے کے لیے ہم کمانڈ استعمال کریں گے۔ kubectl drain، کونسا:

• اس سرور پر نئے پوڈ بھیجنے سے منع کرے گا۔
• سرور پر موجود پوڈز کو حذف کر دے گا۔

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

تاہم، یہاں بھی ایک nuance ہے. اسی طرح کی صورتحال میں، StatefulSet (تعیناتی کے بجائے) کے لیے، اعمال مختلف ہوں گے۔ اب ہمارے پاس پہلے سے ہی ایک اسٹیٹفول ایپلی کیشن ہے - مثال کے طور پر، MongoDB کے ساتھ تین پوڈز، جن میں سے ایک میں کسی قسم کا مسئلہ ہے (ڈیٹا کرپٹ ہو گیا ہے یا کوئی اور خرابی جو پوڈ کو صحیح طریقے سے شروع ہونے سے روکتی ہے)۔ اور ہم پھر سے ایک سرور کو غیر فعال کرنے کا فیصلہ کرتے ہیں۔ کیا ہو گا؟

منگو ڈی بی کر سکتا تھا die کیونکہ اسے ایک کورم کی ضرورت ہے: تین تنصیبات کے کلسٹر کے لیے، کم از کم دو کو کام کرنا چاہیے۔ تاہم، یہ نہیں ہو رہا - شکریہ PodDisruptionBudget. یہ پیرامیٹر کام کرنے والی پھلیوں کی کم از کم مطلوبہ تعداد کا تعین کرتا ہے۔ یہ جانتے ہوئے کہ MongoDB pods میں سے ایک اب کام نہیں کر رہا ہے، اور یہ دیکھتے ہوئے کہ PodDisruptionBudget MongoDB کے لیے سیٹ کیا گیا ہے۔ minAvailable: 2، Kubernetes آپ کو پوڈ کو حذف کرنے کی اجازت نہیں دے گا۔

پایان لائن: کلسٹر کے جاری ہونے پر پوڈز کی نقل و حرکت (اور حقیقت میں، دوبارہ تخلیق) کے صحیح طریقے سے کام کرنے کے لیے، PodDisruptionBudget کو ترتیب دینا ضروری ہے۔

افقی اسکیلنگ

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

آج Kubernetes میں اسے دستی طور پر کرنے کی ضرورت نہیں ہے: پوڈز کی تعداد میں خود بخود اضافہ/کمی کو ناپے ہوئے بوجھ اشاریوں کی قدروں کے لحاظ سے ترتیب دیا جاتا ہے۔

یہاں کے اہم سوالات یہ ہیں: بالکل کیا پیمائش کرنا ہے и تشریح کرنے کا طریقہ حاصل کردہ اقدار (پڈ کی تعداد کو تبدیل کرنے کا فیصلہ کرنے کے لئے)۔ آپ بہت زیادہ پیمائش کر سکتے ہیں:

تکنیکی طور پر یہ کیسے کریں - میٹرکس وغیرہ جمع کریں۔ - میں نے اس رپورٹ میں تفصیل سے بات کی۔ نگرانی اور Kubernetes. اور زیادہ سے زیادہ پیرامیٹرز کو منتخب کرنے کے لئے اہم مشورہ ہے تجربہ!

ہے طریقہ استعمال کریں۔ (استعمال سنترپتی اور غلطیاںجس کا مفہوم درج ذیل ہے۔ کس بنیاد پر اسکیل کرنا معنی رکھتا ہے، مثال کے طور پر، php-fpm؟ اس حقیقت کی بنیاد پر کہ کارکن ختم ہو رہے ہیں، یہ ہے۔ استعمال. اور اگر کارکن ختم ہو جائیں اور نئے کنکشن قبول نہ کیے جائیں تو یہ پہلے ہی ہے۔ سنترپتی. ان دونوں پیرامیٹرز کو ناپا جانا چاہیے، اور اقدار پر منحصر ہے، اسکیلنگ کی جانی چاہیے۔

اس کے بجائے کسی نتیجے کے

رپورٹ کا تسلسل ہے: عمودی پیمانے کے بارے میں اور صحیح وسائل کا انتخاب کیسے کریں۔ میں اس کے بارے میں آئندہ ویڈیوز میں بات کروں گا۔ ہمارا یوٹیوب - سبسکرائب کریں تاکہ آپ سے محروم نہ ہوں!

ویڈیوز اور سلائیڈز

کارکردگی سے ویڈیو (44 منٹ):

رپورٹ کی پیشکش:

PS

ہمارے بلاگ پر Kubernetes کے بارے میں دیگر رپورٹس:

• «Kubernetes کی توسیع اور تکمیل» (Andrey Polovov؛ 8 اپریل 2019 سینٹ ہائی لوڈ++ پر);
• «ڈیٹا بیس اور کبرنیٹس» (دمتری اسٹولیاروف؛ 8 نومبر 2018 ہائی لوڈ++ پر);
• «نگرانی اور Kubernetes» (دمتری اسٹولیاروف؛ 28 مئی 2018 کو روٹ کانف میں);
• «Kubernetes اور GitLab کے ساتھ CI/CD بہترین طرز عمل» (دمتری اسٹولیاروف؛ 7 نومبر 2017 ہائی لوڈ++ پر);
• «چھوٹے منصوبوں میں Kubernetes کے ساتھ ہمارا تجربہ» (دمتری اسٹولیاروف؛ 6 جون، 2017 روٹ کانف میں).

ماخذ: www.habr.com