27 اپريل ڪانفرنس ۾ "DevOps" سيڪشن جي حصي جي طور تي، رپورٽ "آٽو اسڪيلنگ ۽ وسيلن جو انتظام ڪبرنيٽس ۾" ڏنو ويو. اهو توهان جي ايپليڪيشنن جي اعلي دستيابي کي يقيني بڻائڻ ۽ اعلي ڪارڪردگي کي يقيني بڻائڻ لاء K8s ڪيئن استعمال ڪري سگهو ٿا بابت ڳالهائيندو آهي.
روايت موجب، اسان پيش ڪرڻ تي راضي آهيون (44 منٽ، مضمون کان گهڻو وڌيڪ معلوماتي) ۽ بنيادي خلاصو متن جي شڪل ۾. وڃ!
اچو ته رپورٽ جي موضوع جو لفظ لفظ ذريعي تجزيو ڪريون ۽ آخر کان شروع ڪريون.
ڪوبنيٿس
اچو ته اسان وٽ اسان جي ميزبان تي ڊڪر ڪنٽينرز آهن. ڇا جي لاءِ؟ ورجائڻ ۽ اڪيلائي کي يقيني بڻائڻ لاءِ، جنهن جي نتيجي ۾ سادو ۽ سٺي ترتيب ڏيڻ جي اجازت ڏئي ٿي، CI/CD. اسان وٽ ڪيتريون ئي اهڙيون گاڏيون آهن جن وٽ ڪنٽينر آهن.
ڪبرنيٽس هن معاملي ۾ ڇا مهيا ڪري ٿو؟
- اسان انهن مشينن جي باري ۾ سوچڻ بند ڪريون ٿا ۽ ”ڪلائوڊ“ سان ڪم ڪرڻ شروع ڪريون ٿا. ڪنٽينرز جو ڪلستر يا پوڊ (ڪنٽينر جا گروپ).
- ان کان علاوه، اسان انفرادي پوڊ بابت به نه سوچيو، پر وڌيڪ انتظام ڪريوоوڏا گروپ. اهڙو اعليٰ درجي جا پراڻا اسان کي اهو چوڻ جي اجازت ڏيو ته ڪنهن خاص ڪم لوڊ کي هلائڻ لاءِ هڪ ٽيمپليٽ آهي، ۽ هتي ان کي هلائڻ لاءِ مثالن جو گهربل تعداد آهي. جيڪڏهن اسان بعد ۾ ٽيمپليٽ کي تبديل ڪريون ٿا، سڀ صورتون تبديل ٿي وينديون.
- جي مدد سان بيان ڪندڙ API مخصوص حڪمن جي ھڪڙي ترتيب تي عمل ڪرڻ جي بدران، اسان بيان ڪريون ٿا "دنيا جي جوڙجڪ" (YAML ۾)، جيڪو ڪبرنيٽس پاران ٺاھيو ويو آھي. ۽ ٻيهر: جڏهن وضاحت تبديل ٿيندي، ان جي حقيقي ڊسپلي پڻ تبديل ٿيندي.
وسيلن جو انتظام
سي پي يو
اچو ته هلائيون nginx، php-fpm ۽ mysql سرور تي. اهي خدمتون اصل ۾ اڃا به وڌيڪ عملن تي هلندا آهن، جن مان هر هڪ ڪمپيوٽنگ وسيلن جي ضرورت آهي:
(سلائڊ تي انگ ”طوطا“ آهن، ڪمپيوٽنگ پاور لاءِ هر عمل جي تجريدي ضرورت)
انهي سان ڪم ڪرڻ آسان بڻائڻ لاءِ، اهو منطقي آهي ته عملن کي گروپن ۾ گڏ ڪيو وڃي (مثال طور، سڀني نينڪس پروسيسز کي هڪ گروپ ۾ "nginx"). اهو ڪرڻ لاء هڪ سادي ۽ واضح طريقو آهي هر گروپ کي هڪ ڪنٽينر ۾ رکڻ لاء:
جاري رکڻ لاء، توهان کي ياد رکڻ جي ضرورت آهي ته ڪنٽينر ڇا آهي (لينڪس ۾). انهن جي ظهور کي ممڪن ڪيو ويو آهي ته ڪنيل ۾ ٽن اهم خاصيتن جي مهرباني، جيڪو گهڻو وقت اڳ لاڳو ڪيو ويو آهي: , и . ۽ وڌيڪ ترقي ٻين ٽيڪنالاجيز جي مدد ڪئي وئي (بشمول آسان "شيل" جهڙوڪ ڊڪر):
رپورٽ جي حوالي سان، اسان کي صرف دلچسپي آهي گروپ، ڇاڪاڻ ته ڪنٽرول گروپ ڪنٽينرز جي ڪارڪردگي جو حصو آهن (ڊاڪر، وغيره) جيڪي وسيلن جي انتظام کي لاڳو ڪن ٿا. پروسيس گروپن ۾ گڏيل، جيئن اسان چاهيون ٿا، ڪنٽرول گروپ آهن.
اچو ته واپس وڃون سي پي يو جي ضرورتن لاءِ انھن پروسيس لاءِ، ۽ ھاڻي عملن جي گروپن لاءِ:
(مان ورجائي ٿو ته سڀئي انگ وسيلن جي ضرورت جو هڪ خلاصو اظهار آهن)
ساڳئي وقت، سي پي يو پاڻ وٽ هڪ خاص محدود وسيلو آهي (مثال طور هي 1000 آهي), جنهن جي هر ڪنهن کي کوٽ هجي (سڀني گروپن جي ضرورتن جو مجموعو 150+850+460=1460 آهي). هن معاملي ۾ ڇا ٿيندو؟
ڪنييل وسيلن کي ورهائڻ شروع ڪري ٿو ۽ اهو "منصفانه" ڪري ٿو، هر گروپ کي وسيلن جي ساڳئي رقم ڏئي ٿو. پر پهرين صورت ۾، انهن مان ضرورت کان وڌيڪ آهن (333> 150)، تنهنڪري اضافي (333-150 = 183) رزرو ۾ رهي ٿو، جيڪو پڻ برابر طور تي ٻن ٻين ڪنٽينرز جي وچ ۾ ورهايو ويو آهي:
نتيجي طور: پهرين ڪنٽينر وٽ ڪافي وسيلا هئا، ٻيو - ان وٽ ڪافي وسيلا نه هئا، ٽيون - ان وٽ ڪافي وسيلا نه هئا. اهو عملن جو نتيجو آهي لينڪس ۾ "ايماندار" شيڊولر - . ان جي آپريشن کي استعمال ڪندي ترتيب ڏئي سگهجي ٿو وزنَ هر هڪ ڪنٽينر. مثال طور، هن طرح:
اچو ته ٻئي ڪنٽينر (php-fpm) ۾ وسيلن جي کوٽ جي صورت ۾ ڏسو. سڀني ڪنٽينر وسيلن کي پروسيس جي وچ ۾ برابر ورهايو ويو آهي. نتيجي طور، ماسٽر پروسيس سٺو ڪم ڪري ٿو، پر سڀ مزدور سست ٿي ويندا آهن، جيڪي انهن جي ضرورتن جي اڌ کان گهٽ حاصل ڪندا آهن:
اهو ڪيئن آهي CFS شيڊولر ڪم ڪري ٿو. اسان وڌيڪ وزن سڏينداسين جيڪي اسان ڪنٽينرز کي تفويض ڪندا آهيون درخواستون. اهو ڇو آهي - وڌيڪ ڏسو.
اچو ته سڄي صورتحال کي ٻئي پاسي کان ڏسو. جيئن توهان ڄاڻو ٿا، سڀئي رستا روم ڏانهن ويندا آهن، ۽ ڪمپيوٽر جي صورت ۾، سي پي يو ڏانهن. ھڪڙو سي پي يو، ڪيترائي ڪم - توھان کي ٽريفڪ لائيٽ جي ضرورت آھي. وسيلن کي منظم ڪرڻ جو آسان طريقو آهي ”ٽريفڪ لائٽ“: انهن هڪ پروسيس کي سي پي يو تائين هڪ مقرر وقت تائين رسائي ڏني، پوءِ ٻئي کي، وغيره.
هن طريقي کي سخت ڪوٽا سڏيو ويندو آهي (سخت حد بندي). اچو ته ان کي صرف طور تي ياد رکون حدون. بهرحال، جيڪڏهن توهان سڀني ڪنٽينرز تي حدون ورهايو ٿا، هڪ مسئلو پيدا ٿئي ٿو: mysql روڊ تي ڊرائيونگ ڪري رهيو هو ۽ ڪجهه وقت تي ان جي سي پي يو جي ضرورت ختم ٿي وئي، پر ٻيا سڀئي عمل انتظار ڪرڻ تي مجبور آهن جيستائين سي پي يو بيڪار.
اچو ته لينڪس ڪنيل ڏانهن واپس وڃون ۽ ان جي سي پي يو سان رابطي - مجموعي تصوير هن ريت آهي:
cgroup ۾ ٻه سيٽنگون آهن - بنيادي طور تي اهي ٻه سادي "موڙ" آهن جيڪي توهان کي طئي ڪرڻ جي اجازت ڏين ٿا:
- ڪنٽينر لاء وزن (درخواستون) آهي حصا;
- ڪنٽينر ڪمن تي ڪم ڪرڻ لاءِ ڪل CPU وقت جو سيڪڙو (حدود) آھي ڪوٽا.
سي پي يو جو اندازو ڪيئن ڪجي؟
اتي مختلف طريقا آهن:
- ڇا طوفان، ڪو به نٿو ڄاڻي - توهان کي هر وقت ڳالهين جي ضرورت آهي.
- دلچسپي صاف، پر لاڳاپو: 50٪ سرور جو 4 ڪور سان ۽ 20 ڪور سان مڪمل طور تي مختلف شيون آهن.
- توھان استعمال ڪري سگھوٿا جيڪي اڳ ۾ ئي ذڪر ڪيل آھن وزنَ، جيڪو لينڪس ڄاڻي ٿو، پر اهي پڻ لاڳاپيل آهن.
- سڀ کان وڌيڪ مناسب اختيار آھي ڪمپيوٽر جي وسيلن کي ماپڻ لاء سيڪنڊ. اهي. حقيقي وقت جي سيڪنڊن جي ڀيٽ ۾ پروسيسر جي وقت جي سيڪنڊن ۾: پروسيسر جي وقت جو 1 سيڪنڊ في 1 حقيقي سيڪنڊ ڏنو ويو - اهو هڪ سڄو سي پي يو ڪور آهي.
ان کي ڳالهائڻ ۾ اڃا به آسان ڪرڻ لاء، اهي سڌو سنئون ماپ ڪرڻ شروع ڪيو دانا، مطلب ته انهن جي طرفان ساڳيو سي پي يو وقت حقيقي سان واسطو رکندڙ. جيئن ته لينڪس وزن سمجهي ٿو، پر ايترو گهڻو نه سي پي يو وقت / ڪور، هڪ ميکانيزم جي ضرورت هئي هڪ کان ٻئي ڏانهن ترجمو ڪرڻ لاء.
اچو ته هڪ سادي مثال تي غور ڪريون هڪ سرور سان 3 سي پي يو ڪور، جتي ٽن پوڊن کي وزن ڏنو ويندو (500، 1000 ۽ 1500) جيڪي آساني سان انهن کي مختص ڪيل ڪور جي لاڳاپيل حصن ۾ تبديل ڪيا ويندا آهن (0,5، 1 ۽ 1,5).
جيڪڏهن توهان هڪ ٻيو سرور وٺو، جتي ٻه ڀيرا ڪيترائي ڪور (6) هوندا، ۽ اتي ساڳيا پوڊ رکيا ويندا، ڪور جي ورهاڱي کي آساني سان حساب ڪري سگهجي ٿو صرف 2 (1، 2 ۽ 3، ترتيب سان) سان ضرب ڪندي. پر هڪ اهم لمحو تڏهن ٿيندو آهي جڏهن چوٿون پوڊ هن سرور تي ظاهر ٿئي ٿو، جنهن جو وزن، سهولت لاءِ، 3000 هوندو. اهو CPU وسيلن جو حصو (اڌ ڪور) وٺي ٿو، ۽ باقي پوڊز لاءِ اهي ٻيهر ڳڻيا وڃن ٿا (اڌ ۾):
ڪبرنيٽس ۽ سي پي يو وسيلن
ڪبرنيٽس ۾، سي پي يو وسيلن کي عام طور تي ماپي ويندي آهي مليڊراڪس، i.e. 0,001 ڪور بنيادي وزن طور ورتو وڃي ٿو. (لينڪس/سي گروپس جي اصطلاحن ۾ ساڳي شيء کي سي پي يو شيئر سڏيو ويندو آهي، جيتوڻيڪ، وڌيڪ واضح طور تي، 1000 مليڪورس = 1024 سي پي يو شيئرز.) K8s انهي ڳالهه کي يقيني بڻائي ٿو ته اهو سرور تي وڌيڪ پوڊ نٿو رکي ان کان سواءِ سي پي يو وسيلا موجود آهن سڀني پوڊس جي وزن جي مجموعن لاءِ.
اهو ڪيئن ٿو ٿئي؟ جڏهن توهان ڪبرنيٽس ڪلستر ۾ سرور شامل ڪيو ٿا، اهو ٻڌايو ويو آهي ته ڪيترا سي پي يو ڪور موجود آهن. ۽ جڏهن هڪ نئون پوڊ ٺاهيو، ڪبرنيٽس شيڊولر ڄاڻي ٿو ته هن پوڊ کي ڪيترا ڪور جي ضرورت هوندي. اهڙيء طرح، پوڊ هڪ سرور تي لڳايو ويندو جتي ڪافي ڪور آهن.
ته ڇا ٿيندو نه درخواست بيان ڪئي وئي آهي (يعني پوڊ وٽ ڪورز جو ڪو مقرر تعداد نه آهي جنهن جي ضرورت آهي)؟ اچو ته ڄاڻون ته ڪبرنيٽس عام طور تي وسيلن کي ڪيئن ڳڻيندو آهي.
هڪ پوڊ لاءِ توهان ٻنهي درخواستن جي وضاحت ڪري سگهو ٿا (سي ايف ايس شيڊولر) ۽ حدون (ٽريفڪ لائيٽ ياد رکو؟):
- جيڪڏهن اهي برابر بيان ڪيا ويا آهن، پوء پوڊ هڪ QoS ڪلاس مقرر ڪيو ويو آهي ضمانت ڪيل آهي. هن cores جو تعداد هميشه ان لاء موجود ضمانت آهي.
- جيڪڏهن درخواست حد کان گهٽ آهي - QoS ڪلاس ڦاٽڻ لائق. اهي. اسان هڪ پوڊ جي اميد رکون ٿا، مثال طور، هميشه 1 ڪور استعمال ڪرڻ لاء، پر هي قدر ان لاء حد نه آهي: ڪڏهن ڪڏهن پوڊ وڌيڪ استعمال ڪري سگھي ٿو (جڏھن سرور وٽ مفت وسيلا آھن ھن لاءِ).
- هتي پڻ هڪ QoS ڪلاس آهي بهترين ڪوشش - ان ۾ اهي تمام پوڊ شامل آهن جن لاءِ درخواست بيان نه ڪئي وئي آهي. وسيلا انهن کي آخري ڏنيون وڃن ٿيون.
هوندي آهي
ياداشت سان، صورتحال ساڳي آهي، پر ٿورڙي مختلف - سڀ کان پوء، انهن وسيلن جي فطرت مختلف آهي. عام طور تي، قياس هيٺ ڏنل آهي:
اچو ته ڏسو ته ميموري ۾ درخواستون ڪيئن لاڳو ٿين ٿيون. پوڊز کي سرور تي رهڻ ڏيو، ياداشت جي استعمال کي تبديل ڪندي، جيستائين انهن مان هڪ تمام وڏو ٿي وڃي ته اهو ميموري ختم ٿي وڃي. انهي حالت ۾، OOM قاتل ظاهر ٿئي ٿو ۽ سڀ کان وڏي عمل کي ماريندو آهي:
اهو هميشه اسان کي مناسب ناهي، تنهنڪري اهو ممڪن آهي ته ضابطو ڪرڻ لاء ڪهڙا عمل اسان لاء اهم آهن ۽ انهن کي قتل نه ڪيو وڃي. هن کي ڪرڻ لاء، پيٽرولر استعمال ڪريو oom_score_adj.
اچو ته CPU جي QoS ڪلاسز ڏانھن واپس وڃون ۽ oom_score_adj قدرن سان ھڪڙو مشابہت ٺاھيون جيڪي پوڊز لاءِ ياداشت جي استعمال جي ترجيحن جو تعين ڪن ٿا:
- پوڊ لاءِ گھٽ ۾ گھٽ oom_score_adj قدر - -998 - مطلب ته اهڙي پوڊ کي آخري ڀيرو ماريو وڃي، هي ضمانت ڪيل آهي.
- سڀ کان وڌيڪ - 1000 - آهي بهترين ڪوشش، اهڙيون ٻڪريون پهرين ماريا ويندا آهن.
- باقي قدرن کي ڳڻڻ لاءِ (ڦاٽڻ لائق) ھڪڙو فارمولا آھي، جنھن جو خلاصو ھن حقيقت تي پھچي ٿو ته پوڊ جي وڌيڪ وسيلن جي درخواست ڪئي وئي آھي، گھٽ ۾ گھٽ ان کي مارڻ جو امڪان آھي.
ٻيو "موڙ" - limit_in_bytes - حدن لاء. ان سان گڏ، سڀ ڪجھ آسان آھي: اسان صرف جاري ڪيل ميموري جي وڌ ۾ وڌ مقدار کي تفويض ڪريون ٿا، ۽ ھتي (سي پي يو جي برعڪس) ڪو به سوال نه آھي ته ان کي ڪيئن ماپڻ (ياداشت).
ڪل
Kubernetes ۾ هر پوڊ ڏنو ويو آهي requests и limits - سي پي يو ۽ ميموري لاءِ ٻئي پيٽرول:
- درخواستن جي بنياد تي، ڪبرنيٽس شيڊولر ڪم ڪري ٿو، جيڪو سرور جي وچ ۾ پوڊ ورهائي ٿو.
- سڀني ماپن جي بنياد تي، پوڊ جي QoS ڪلاس مقرر ڪئي وئي آهي؛
- لاڳاپا وزن سي پي يو جي درخواستن جي بنياد تي ڳڻيا ويا آهن؛
- سي ايف ايس شيڊولر سي پي يو جي درخواستن جي بنياد تي ترتيب ڏنل آهي؛
- OOM قاتل ميموري درخواستن جي بنياد تي ترتيب ڏنل آهي؛
- هڪ "ٽريفڪ لائيٽ" سي پي يو جي حدن جي بنياد تي ترتيب ڏنل آهي؛
- ياداشت جي حدن جي بنياد تي، هڪ حد ترتيب ڏنل آهي cgroup لاءِ.
عام طور تي، هي تصوير سڀني سوالن جو جواب ڏئي ٿو ته ڪبرنيٽس ۾ وسيلن جي انتظام جو بنيادي حصو ڪيئن ٿئي ٿو.
خودڪار اسڪيلنگ
K8s ڪلستر-آٽو اسڪيلر
اچو ته تصور ڪريو ته سڄو ڪلستر اڳ ۾ ئي قبضو ڪيو ويو آهي ۽ هڪ نئين پوڊ ٺاهڻ جي ضرورت آهي. جڏهن ته پوڊ ظاهر نه ٿو ڪري سگھجي، اهو حالت ۾ پھان ٿو انتظار ۾. ان جي ظاهر ٿيڻ لاءِ، اسان نئين سرور کي ڪلسٽر سان ڳنڍي سگھون ٿا يا... ڪلسٽر-آٽو اسڪيلر انسٽال ڪري سگھون ٿا، جيڪو اھو اسان لاءِ ڪندو: ڪلائوڊ فراهم ڪندڙ کان ھڪ ورچوئل مشين آرڊر ڪريو (اي پي آئي درخواست استعمال ڪندي) ۽ ان کي ڪلستر سان ڳنڍيو ، جنهن کان پوءِ پوڊ شامل ڪيو ويندو.
هي ڪبرنيٽس ڪلستر جو خودڪار اسڪيلنگ آهي، جيڪو تمام سٺو ڪم ڪري ٿو (اسان جي تجربي ۾). بهرحال، ٻين هنڌن وانگر، هتي ڪجهه nuances آهن ...
جيستائين اسان ڪلستر جي سائيز کي وڌايو، سڀ ڪجھ ٺيڪ هو، پر ڇا ٿيندو جڏهن ڪلستر پاڻ کي آزاد ڪرڻ لڳو؟ مسئلو اهو آهي ته لڏپلاڻ پوڊ (ميزبان کي آزاد ڪرڻ) وسيلن جي لحاظ کان تمام ٽيڪنالاجي طور ڏکيو ۽ قيمتي آهي. Kubernetes هڪ مڪمل طور تي مختلف طريقو استعمال ڪري ٿو.
3 سرورن جي ڪلستر تي غور ڪريو جن ۾ ڊيپلائيمينٽ آھي. ھن ۾ 6 پوڊ آھن: ھاڻي ھر سرور لاءِ 2 آھن. ڪجھ سببن لاءِ اسان ھڪڙي سرور کي بند ڪرڻ چاھيو ٿا. ائين ڪرڻ لاءِ اسان ڪمانڊ استعمال ڪنداسين kubectl drain، ڪھڙي:
- هن سرور تي نوان پوڊ موڪلڻ کان منع ڪندو؛
- سرور تي موجود پوڊز کي حذف ڪندو.
جيئن ته ڪبرنيٽس پوڊس (6) جي تعداد کي برقرار رکڻ جو ذميوار آهي، اهو آسان آهي ٻيهر ٺاهيندو انھن کي ٻين نوڊس تي، پر ھڪڙي تي ناھي، جنھن کي غير فعال ڪيو ويو آھي، ڇاڪاڻتہ اھو اڳ ۾ ئي نشان لڳل آھي غير موجود آھي نون پوڊس کي ھوسٽ ڪرڻ لاءِ. هي Kubernetes لاء هڪ بنيادي ميڪيڪل آهي.
بهرحال، هتي پڻ هڪ nuance آهي. ساڳي صورتحال ۾، StatefulSet لاءِ (تعمير جي بدران)، ڪارناما مختلف ٿيندا. ھاڻي اسان وٽ اڳ ۾ ئي ھڪ رياستي ايپليڪيشن آھي - مثال طور، مونگو ڊي بي سان ٽي پوڊ، جن مان ھڪڙو ھڪڙو مسئلو آھي (ڊيٽا خراب ٿي وئي آھي يا ٻي غلطي جيڪا پوڊ کي صحيح طور تي شروع ٿيڻ کان روڪي ٿي). ۽ اسان وري هڪ سرور کي بند ڪرڻ جو فيصلو ڪيو. ڇا ٿيندو؟
منڊو ڊي سگهي die ڇاڪاڻ ته ان کي ڪورم جي ضرورت آهي: ٽن تنصيبن جي ڪلستر لاءِ، گهٽ ۾ گهٽ ٻه ڪم ڪرڻ گهرجن. بهرحال، هن نه ٿي رهيو آهي - مهرباني هن جي PodDisruption Budget. هي پيٽرولر ڪم ڪندڙ پوڊ جي گھٽ ۾ گھٽ گهربل تعداد کي طئي ڪري ٿو. اهو ڄاڻڻ ته مونگو ڊي بي پوڊ مان هڪ هاڻي ڪم نه ڪري رهيو آهي، ۽ اهو ڏسي رهيو آهي ته PodDisruptionBudget MongoDB لاءِ سيٽ ڪيو ويو آهي minAvailable: 2, Kubernetes توهان کي هڪ پوڊ کي ختم ڪرڻ جي اجازت نه ڏيندو.
هيٺيون لڪير: پوڊس جي حرڪت (۽ حقيقت ۾، ٻيهر ٺاهڻ) لاءِ صحيح طريقي سان ڪم ڪرڻ لاءِ جڏهن ڪلسٽر جاري ڪيو وڃي ٿو، اهو ضروري آهي ته PodDisruptionBudget کي ترتيب ڏيو.
افقي اسڪيلنگ
اچو ته هڪ ٻي صورتحال تي غور ڪريون. ڪوبرنيٽس ۾ ڊيپلائيمينٽ جي طور تي هلندڙ ايپليڪيشن آهي. يوزر ٽريفڪ ان جي پوڊز تي اچي ٿو (مثال طور، انهن مان ٽي آهن)، ۽ اسان انهن ۾ هڪ خاص اشاري کي ماپيندا آهيون (چئو، سي پي يو لوڊ). جڏهن لوڊ وڌندو آهي، اسان هن کي شيڊول تي رڪارڊ ڪيو ۽ درخواستن کي ورهائڻ لاء پوڊ جو تعداد وڌايو.
اڄ Kubernetes ۾ اهو دستي طور تي ڪرڻ جي ضرورت ناهي: پوڊ جي تعداد ۾ هڪ خودڪار اضافو / گهٽتائي ماپ ٿيل لوڊ اشارن جي قدرن جي بنياد تي ترتيب ڏنل آهي.
هتي اهم سوال آهن: ڇا صحيح اندازو ڪرڻ لاء и تفسير ڪيئن ڪجي حاصل ڪيل قدر (پوڊ جي تعداد کي تبديل ڪرڻ تي فيصلو ڪرڻ لاء). توھان تمام گھڻو ماپ ڪري سگھو ٿا:
هن کي ٽيڪنيڪل طور تي ڪيئن ڪجي - ميٽريس گڏ ڪريو، وغيره. - مون تفصيل سان رپورٽ ۾ ڳالهايو . ۽ بهترين پيٽرولر چونڊڻ لاء بنيادي صلاح آهي تجربو!
ڪري سگهو ٿا (استعمال سنترپت ۽ غلطيون)، جنهن جي معنيٰ هن ريت آهي. ڪهڙي بنياد تي ان کي ماپڻ جو مطلب آهي، مثال طور، php-fpm؟ انهي حقيقت جي بنياد تي ته مزدور ختم ٿي رهيا آهن، هي آهي استعمال. ۽ جيڪڏهن مزدور ختم ٿي ويا آهن ۽ نوان ڪنيڪشن قبول نه ڪيا ويا آهن، اهو اڳ ۾ ئي آهي تندرستگي. انهن ٻنهي پيٽرولن کي ماپڻ گهرجي، ۽ قدرن تي منحصر ڪري، اسڪيلنگ کي انجام ڏيڻ گهرجي.
سوچيم ته هڪ ٿڪل جي
رپورٽ ۾ هڪ تسلسل آهي: عمودي اسڪيلنگ بابت ۽ صحيح وسيلن کي ڪيئن چونڊيو. مان ان بابت مستقبل جي وڊيوز ۾ ڳالهائيندس - رڪنيت حاصل ڪريو تنهنڪري توهان کي نه وڃايو!
وڊيوز ۽ سلائڊ
ڪارڪردگي کان وڊيو (44 منٽ):
رپورٽ جي پيشڪش:
پي ايس
اسان جي بلاگ تي Kubernetes بابت ٻيون رپورٽون:
- «» (ايندري پولوفوف؛ 8 اپريل 2019 سينٽ هاءِ لوڊ++ تي);
- «» (دمتري اسٽوليروف؛ نومبر 8، 2018 HighLoad++ تي);
- «» (دمتري اسٽولياروف؛ 28 مئي 2018 تي RootConf);
- «» (دمتري اسٽوليروف؛ نومبر 7، 2017 HighLoad++ تي);
- «» (دمتري اسٽولياروف؛ 6 جون، 2017 تي RootConf).
جو ذريعو: www.habr.com