نوٽ. ترجمو: Omio جي هيءَ اکين کي کولڻ واري تاريخ- هڪ يورپي سفر جو مجموعو- پڙهندڙن کي بنيادي نظريي کان وٺي ڪبرنيٽس جي ترتيب جي دلچسپ عملي پيچيدگين ڏانهن وٺي وڃي ٿي. اهڙن ڪيسن سان واقفيت نه رڳو توهان جي افق کي وسيع ڪرڻ ۾ مدد ڪري ٿي، پر غير معمولي مسئلن کي روڪڻ ۾ پڻ.
ڇا توهان ڪڏهن ڪا درخواست ڪئي آهي جڳه تي بيٺو آهي، صحت جي چيڪن جو جواب ڏيڻ بند ڪيو، ۽ اهو معلوم ڪرڻ جي قابل ناهي ڇو؟ هڪ ممڪن وضاحت CPU وسيلن جي ڪوٽا جي حدن سان لاڳاپيل آهي. اهو آهي جيڪو اسان هن مضمون ۾ ڳالهائينداسين.
TL، ڊاڪٽر:
اسان زور ڀريون ٿا ته ڪبرنيٽس ۾ سي پي يو جي حدن کي غير فعال ڪرڻ (يا ڪوبيليٽ ۾ سي ايف ايس ڪوٽا کي غير فعال ڪرڻ) جيڪڏهن توهان استعمال ڪري رهيا آهيو لينڪس ڪنيل جو نسخو CFS ڪوٽا بگ سان. بنيادي ۾ سنجيده ۽ ھڪڙو بگ جيڪو گھڻو ڪري ٿو گھٻرائڻ ۽ دير ڪرڻ.
Omio ۾ سڄو زيربنا Kubernetes پاران منظم ڪيو ويو آهي. اسان جا سڀئي رياستي ۽ بي رياست ڪم لوڊ خاص طور تي ڪبرنيٽس تي هلن ٿا (اسان گوگل ڪبرنيٽس انجڻ استعمال ڪندا آهيون). گذريل ڇهن مهينن ۾، اسان بي ترتيب سستي جو مشاهدو ڪرڻ شروع ڪيو. ايپليڪيشنون منجمد ٿيڻ يا صحت جي چڪاس جو جواب ڏيڻ بند ڪرڻ، نيٽ ورڪ سان ڪنيڪشن وڃائڻ وغيره. ان رويي اسان کي ڪافي عرصي تائين حيران ڪيو، ۽ آخرڪار اسان ان مسئلي کي سنجيدگيءَ سان وٺڻ جو فيصلو ڪيو.
مضمون جو خلاصو:
- ڪنٽينر ۽ ڪبرنيٽس بابت ڪجھ لفظ؛
- سي پي يو جون درخواستون ۽ حدون ڪيئن لاڳو ٿين ٿيون؛
- ملٽي ڪور ماحول ۾ سي پي يو جي حد ڪيئن ڪم ڪري ٿي؛
- سي پي يو تھروٽلنگ کي ڪيئن ٽريڪ ڪجي؛
- مسئلو حل ۽ nuances.
ڪنٽينر ۽ ڪبرنيٽس بابت ڪجھ لفظ
Kubernetes بنيادي طور تي بنيادي طور تي جديد معيار آهي انفراسٹرڪچر جي دنيا ۾. ان جو بنيادي ڪم ڪنٽينر آرڪيسٽريشن آهي.
ڪنٽينر
ماضي ۾، اسان کي جاوا JARs/WARs، Python Eggs، يا سرورز تي هلائڻ لاءِ ايگزيڪيوٽوبلز جھڙوڪ نمونا ٺاھڻا پوندا ھئا. بهرحال، انهن کي ڪم ڪرڻ لاءِ، اضافي ڪم ڪرڻو پيو: رن ٽائم ماحول کي انسٽال ڪرڻ (جاوا/پٿون)، ضروري فائلن کي صحيح هنڌن تي رکڻ، آپريٽنگ سسٽم جي مخصوص ورزن سان مطابقت کي يقيني بڻائڻ وغيره. ٻين لفظن ۾، ترتيب ڏيڻ جي انتظام تي ڌيان ڏيڻو پوندو (جيڪو اڪثر ڪري ڊولپرز ۽ سسٽم منتظمين جي وچ ۾ تڪرار جو ذريعو هوندو هو).
ڪنٽينر سڀ ڪجهه بدلائي ڇڏيو. هاڻي آرٽيڪل هڪ ڪنٽينر تصوير آهي. اهو هڪ قسم جي وڌايل ايگزيڪيوٽو فائل جي طور تي پيش ڪري سگهجي ٿو جنهن ۾ نه صرف پروگرام، پر مڪمل عملدرآمد ماحول (Java/Python/...)، گڏوگڏ ضروري فائلون / پيڪيجز، اڳ ۾ نصب ٿيل ۽ تيار آهن. ڊوڙڻ ڪنٽينرز کي ترتيب ڏئي سگھجي ٿو ۽ مختلف سرورن تي ھلائي سگھجي ٿو بغير ڪنھن اضافي قدمن جي.
ان کان سواء، ڪنٽينرز پنهنجن سينڊ باڪس ماحول ۾ ڪم ڪن ٿا. انهن وٽ پنهنجو ورچوئل نيٽ ورڪ اڊاپٽر آهي، انهن جو پنهنجو فائيل سسٽم محدود رسائي سان، انهن جي پنهنجي عمل جو درجو، سي پي يو ۽ ميموري تي انهن جون پنهنجون حدون، وغيره. اهو سڀ ڪجهه لينڪس ڪرنل جي هڪ خاص سبسسٽم جي مهرباني سان لاڳو ڪيو ويو آهي - namespaces.
ڪوبنيٿس
جيئن اڳ بيان ڪيو ويو آهي، ڪبرنيٽس هڪ ڪنٽينر آرڪيسٽرٽر آهي. اهو هن طرح ڪم ڪري ٿو: توهان ان کي مشينن جو هڪ تلاءُ ڏيو، ۽ پوءِ چئو: ”اي، ڪبرنيٽس، اچو ته منهنجي ڪنٽينر جا ڏهه مثال لانچ ڪريون 2 پروسيسرز ۽ 3 GB ميموري سان، ۽ انهن کي هلايون! Kubernetes باقي سنڀاليندو. اهو مفت ظرفيت ڳوليندو، ڪنٽينر لانچ ڪندو ۽ جيڪڏهن ضروري هجي ته انهن کي ٻيهر شروع ڪيو، ورزن کي تبديل ڪرڻ دوران هڪ تازه ڪاري رول، وغيره. لازمي طور تي، ڪبرنيٽس توهان کي هارڊويئر جزو کي ختم ڪرڻ جي اجازت ڏئي ٿو ۽ مختلف قسم جي سسٽم کي ترتيب ڏيڻ ۽ ايپليڪيشنن کي هلائڻ لاء مناسب بڻائي ٿو.
عام ماڻهو جي نقطي نظر کان Kubernetes
ڪبرنيٽس ۾ درخواستون ۽ حدون ڇا آهن
ٺيڪ آهي، اسان ڪنٽينرز ۽ ڪبرنيٽس کي ڍڪي ڇڏيو آهي. اسان اهو پڻ ڄاڻون ٿا ته ڪيترن ئي ڪنٽينرز ساڳئي مشين تي رهجي سگهن ٿيون.
هڪ قياس هڪ ڪميونٽي اپارٽمنٽ سان ٺاهي سگهجي ٿو. هڪ وسيع احاطو (مشين / يونٽ) ورتو وڃي ٿو ۽ ڪيترن ئي نوڪررن (ڪنٽينر) کي ڪرائي تي ڏنو وڃي ٿو. Kubernetes هڪ حقيقي طور ڪم ڪري ٿو. سوال اهو ٿو پيدا ٿئي ته نوڪردارن کي هڪ ٻئي سان ٽڪراءَ کان ڪيئن روڪيو وڃي؟ ڇا جيڪڏهن انهن مان هڪ، چون ٿا، اڌ ڏينهن لاء غسل خانو قرض ڏيڻ جو فيصلو ڪيو؟
هي آهي جتي درخواستون ۽ حدون راند ۾ اچن ٿيون. سي پي يو درخواست صرف پلاننگ جي مقصدن لاء ضروري آهي. اهو ڪجهه آهي جهڙوڪ "خواهش جي فهرست" ڪنٽينر جي، ۽ اهو استعمال ڪيو ويندو آهي سڀ کان وڌيڪ مناسب نوڊ چونڊڻ لاء. ساڳئي وقت CPU حد ڪرائي تي ڏيڻ واري معاهدي سان مقابلو ڪري سگهجي ٿو - جيترو جلد اسان ڪنٽينر لاءِ هڪ يونٽ چونڊيو ٿا نه ٿو ڪري سگھجي قائم ڪيل حدن کان ٻاهر وڃو. ۽ اهو آهي جتي مسئلو پيدا ٿئي ٿو ...
ڪبرنيٽس ۾ ڪيئن درخواستون ۽ حدون لاڳو ٿين ٿيون
ڪبرنيٽس سي پي يو جي حدن کي لاڳو ڪرڻ لاءِ ڪرنل ۾ ٺهيل هڪ ٿلهي ڇڪڻ واري ميڪانيزم (گھڙي جي چڪر کي ڇڏڻ) استعمال ڪري ٿو. جيڪڏهن هڪ ايپليڪيشن حد کان وڌي ٿي، throttling کي فعال ڪيو ويندو آهي (يعني اهو گهٽ CPU چڪر وصول ڪري ٿو). ميموري لاءِ درخواستون ۽ حدون مختلف طرح سان ترتيب ڏنل آهن، تنهن ڪري انهن کي ڳولڻ آسان آهي. هن کي ڪرڻ لاءِ، صرف پوڊ جي آخري ريسٽارٽ اسٽيٽس چيڪ ڪريو: ڇا اهو آهي ”OOMKilled“. سي پي يو ٿروٽنگ ايترو سادو نه آهي، ڇاڪاڻ ته K8s صرف ميٽريز کي استعمال ذريعي دستياب بڻائي ٿو، نه سي گروپن طرفان.
سي پي يو جي درخواست
سي پي يو درخواست ڪيئن لاڳو ٿئي ٿي
سادگي لاءِ، اچو ته مثال طور 4-ڪور سي پي يو سان مشين استعمال ڪندي عمل کي ڏسو.
K8s وسيلن جي مختص کي ڪنٽرول ڪرڻ لاءِ ڪنٽرول گروپ ميڪانيزم (cgroups) استعمال ڪري ٿو (ميموري ۽ پروسيسر). هن لاء هڪ hierarchical ماڊل موجود آهي: ٻار کي والدين گروپ جي حدن وراثت. تقسيم جا تفصيل ورچوئل فائل سسٽم ۾ محفوظ ٿيل آهن (/sys/fs/cgroup). پروسيسر جي صورت ۾ اهو آهي /sys/fs/cgroup/cpu,cpuacct/*.
K8s فائل استعمال ڪري ٿو cpu.share پروسيسر وسيلن کي مختص ڪرڻ لاء. اسان جي صورت ۾، روٽ سي گروپ حاصل ڪري ٿو 4096 شيئرز سي پي يو وسيلن جو - موجود پروسيسر پاور جو 100٪ (1 ڪور = 1024؛ اهو هڪ مقرر ڪيل قدر آهي). روٽ گروپ وسيلا ورهائي ٿو تناسب جي لحاظ سان ورهايل اولاد جي حصيداري جي بنياد تي cpu.share، ۽ اھي، موڙ ۾، پنھنجي اولاد سان، وغيره. هڪ عام ڪبرنيٽس نوڊ تي، روٽ سي گروپ کي ٽي ٻار آهن: system.slice, user.slice и kubepods. پهرين ٻه ذيلي گروپ استعمال ڪيا ويندا آهن وسيلن کي ورهائڻ لاءِ نازڪ سسٽم لوڊ ۽ صارف پروگرامن جي وچ ۾ K8s کان ٻاهر. آخري - kubepods - ڪبرنيٽس پاران پيدا ڪيل وسيلن کي پوڊ جي وچ ۾ ورهائڻ لاء.
مٿي ڏنل ڊراگرام ڏيکاري ٿو ته پهريون ۽ ٻيو ذيلي گروپ هر هڪ وصول ڪيو 1024 حصص، kuberpod ذيلي گروپ سان مختص ڪيل 4096 شيئرز اهو ڪيئن ممڪن آهي: سڀ کان پوء، روٽ گروپ کي صرف رسائي آهي 4096 شيئرز، ۽ سندس اولاد جي حصص جو مجموعو خاص طور تي ھن نمبر کان وڌيڪ آھي (6144)؟ نقطي اهو آهي ته قيمت منطقي احساس پيدا ڪري ٿي، تنهنڪري لينڪس شيڊولر (CFS) ان کي استعمال ڪري ٿو متناسب طور تي سي پي يو وسيلن کي مختص ڪرڻ لاء. اسان جي صورت ۾، پهرين ٻن گروپن حاصل ڪري 680 حقيقي شيئرز (16,6 جو 4096٪)، ۽ kubepod باقي حاصل ڪري ٿو 2736 شيئرز بند ٿيڻ جي صورت ۾، پهريان ٻه گروپ مختص ڪيل وسيلن کي استعمال نه ڪندا.
خوشقسمتيءَ سان، شيڊولر وٽ هڪ ميکانيزم آهي ته جيئن غير استعمال ٿيل سي پي يو وسيلن کي ضايع ڪرڻ کان بچڻ لاءِ. اهو "بيڪار" گنجائش کي گلوبل پول ڏانهن منتقل ڪري ٿو، جتان اهو گروپن ۾ ورهايو ويو آهي جيڪي اضافي پروسيسر پاور جي ضرورت هونديون آهن (منتقلي بيچ ۾ ٿيندي آهي گولن جي نقصان کان بچڻ لاء). ساڳيو طريقو سڀني نسلن جي اولاد تي لاڳو ٿئي ٿو.
هي ميکانيزم پروسيسر پاور جي منصفانه ورڇ کي يقيني بڻائي ٿو ۽ انهي کي يقيني بڻائي ٿو ته ڪو به عمل ٻين کان "چوري" وسيلا ناهي.
سي پي يو جي حد
ان حقيقت جي باوجود ته K8s ۾ حدن ۽ درخواستن جون ترتيبون ساڳيون نظر اچن ٿيون، انهن تي عمل درآمد بلڪل مختلف آهي: هي سڀ کان وڌيڪ گمراهه ڪندڙ ۽ گهٽ ۾ گهٽ دستاويز ٿيل حصو.
K8s مشغول حدن کي لاڳو ڪرڻ لاء. انهن جون سيٽنگون فائلن ۾ بيان ٿيل آهن cfs_period_us и cfs_quota_us cgroup ڊاريڪٽري ۾ (فائل پڻ موجود آهي cpu.share).
وسنديون cpu.share، ڪوٽا تي ٻڌل آهي وقت جي معياد، ۽ دستياب پروسيسر پاور تي نه. cfs_period_us مدت جي مدت کي بيان ڪري ٿو (epoch) - اهو هميشه 100000 μs (100 ms) آهي. ھن قيمت کي K8s ۾ تبديل ڪرڻ لاء ھڪڙو اختيار آھي، پر اھو صرف الفا ۾ موجود آھي. شيڊولر استعمال ٿيل ڪوٽا ٻيهر شروع ڪرڻ لاء epoch استعمال ڪري ٿو. ٻيو فائيل cfs_quota_us، هر دور ۾ موجود وقت (ڪوٽا) بيان ڪري ٿو. نوٽ ڪريو ته اهو پڻ microseconds ۾ بيان ڪيو ويو آهي. ڪوٽا شايد دور جي ڊيگهه کان وڌي سگهي ٿي؛ ٻين لفظن ۾، اهو ٿي سگهي ٿو 100 ms کان وڌيڪ.
اچو ته 16-ڪور مشينن تي ٻه منظرنامو ڏسو (سڀ کان عام قسم جو ڪمپيوٽر اسان وٽ Omio تي آهي):
منظر 1: 2 سلسلا ۽ 200 ايم ايس جي حد. نه ٿڪجڻ
منظر 2: 10 سلسلا ۽ 200 ايم ايس جي حد. 20 ايم ايس کان پوءِ ٺهڪندڙ شروع ٿئي ٿو، پروسيسر وسيلن تائين رسائي ٻي 80 ايم ايس کان پوءِ ٻيهر شروع ٿئي ٿي
اچو ته چئو ته توهان سي پي يو جي حد مقرر ڪئي 2 دانا؛ Kubernetes هن قدر جو ترجمو ڪندو 200 ms. هن جو مطلب اهو آهي ته ڪنٽينر وڌ ۾ وڌ 200ms استعمال ڪري سگهي ٿو CPU وقت جي بغير بغير بغير.
۽ هي آهي جتي مزو شروع ٿئي ٿو. جيئن مٿي ڄاڻايل آهي، دستياب ڪوٽا 200 ايم ايس آهي. جيڪڏهن توهان متوازي ڪم ڪري رهيا آهيو ڏهن 12-ڪور مشين تي ڌاڙا (ڏسو منظرنامو 2 لاءِ مثال)، جڏهن ته ٻيا سڀئي پوڊ بيڪار هوندا، ڪوٽا صرف 20 ms ۾ ختم ٿي ويندو (10 * 20 ms = 200 ms کان وٺي)، ۽ هن پوڊ جا سڀئي ٿريڊ لٽڪندا » (تختيون) ايندڙ 80 ms لاءِ. اڳ ۾ ئي ذڪر ڪيو ويو آهي ، جنهن سبب حد کان وڌيڪ ٿلها لڳن ٿا ۽ ڪنٽينر موجوده ڪوٽا به پورو نه ٿو ڪري سگهي.
پوڊ ۾ throttling جو اندازو ڪيئن ڪجي؟
بس پوڊ ۾ لاگ ان ڪريو ۽ عمل ڪريو cat /sys/fs/cgroup/cpu/cpu.stat.
-
nr_periods- شيڊولر دورن جو ڪل تعداد؛ -
nr_throttled- ٺاھڻ ۾ ٺھيل دورن جو تعدادnr_periods; -
throttled_time- nanoseconds ۾ مجموعي throttled وقت.
ڇا واقعي ٿي رهيو آهي؟
نتيجي طور، اسان سڀني ايپليڪيشنن ۾ اعلي تختي حاصل ڪندا آهيون. ڪڏهن ڪڏهن هو اندر هوندو آهي هڪ ۽ اڌ ڀيرا حساب کان وڌيڪ مضبوط!
هي مختلف غلطين جي ڪري ٿو - تيارگي جي چڪاس جي ناڪامي، ڪنٽينر منجمد، نيٽ ورڪ ڪنيڪشن بريڪ، سروس ڪالن اندر وقت ختم ٿيڻ. اهو آخرڪار نتيجو وڌائي ويڪرائي ۽ اعلي غلطي جي شرح ۾.
فيصلا ۽ نتيجا
هتي سڀ ڪجھ سادو آهي. اسان سي پي يو جي حدن کي ڇڏي ڏنو ۽ او ايس ڪنيل کي ڪلسٽرز ۾ تازه ترين ورزن تائين اپڊيٽ ڪرڻ شروع ڪيو، جنهن ۾ بگ کي درست ڪيو ويو. اسان جي خدمتن ۾ غلطين جو تعداد (HTTP 5xx) فوري طور تي گھٽجي ويو:
HTTP 5xx غلطيون
هڪ نازڪ خدمت لاءِ HTTP 5xx غلطيون
جوابي وقت p95
نازڪ خدمت جي درخواست جي دير، 95 سيڪڙو
آپريٽنگ خرچ
مثال طور خرچ ڪيل ڪلاڪن جو تعداد
پڪڙي ڇا آهي؟
جيئن مضمون جي شروعات ۾ چيو ويو آهي:
هڪ مشابهت هڪ ڪميونل اپارٽمنٽ سان ٺاهي سگهجي ٿو... ڪبرنيٽس هڪ ريئلٽر طور ڪم ڪري ٿو. پر ڪيئن نوڪر هڪ ٻئي سان تڪرار کان بچائڻ لاء؟ ڇا جيڪڏهن انهن مان هڪ، چون ٿا، اڌ ڏينهن لاء غسل خانو قرض ڏيڻ جو فيصلو ڪيو؟
هتي پڪڙي آهي. هڪ بي پرواهه ڪنٽينر کائي سگھي ٿو سڀ موجود سي پي يو وسيلن کي مشين تي. جيڪڏهن توهان وٽ سمارٽ ايپليڪيشن اسٽيڪ آهي (مثال طور، JVM، Go، Node VM صحيح ترتيب ڏنل آهن)، پوء اهو مسئلو ناهي: توهان اهڙين حالتن ۾ ڊگهي وقت تائين ڪم ڪري سگهو ٿا. پر جيڪڏهن ايپليڪيشنون خراب طور تي بهتر ٿيل آهن يا بلڪل بهتر نه آهن (FROM java:latest)، صورتحال قابو کان ٻاهر ٿي سگهي ٿي. Omio تي اسان وٽ آهي خودڪار بنيادي ڊاکرفائلس وڏي ٻولي اسٽيڪ لاءِ مناسب ڊفالٽ سيٽنگون سان، تنهن ڪري اهو مسئلو موجود نه هو.
اسان ميٽرڪ جي نگراني ڪرڻ جي صلاح ڏيو ٿا (استعمال، saturation ۽ غلطيون)، API دير ۽ غلطي جي شرح. پڪ ڪريو ته نتيجا اميدن سان ملن ٿا.
حوالن
هي اسان جي ڪهاڻي آهي. هيٺ ڏنل مواد تمام گهڻي مدد ڪئي سمجھڻ ۾ ته ڇا ٿي رهيو آهي:
- ;
- ;
- ;
- ;
- - ڳوليو "cpu throttling".
Kubernetes بگ رپورٽون:
- ;
- ;
- .
ڇا توهان پنهنجي مشق ۾ ساڳيون مشڪلاتن سان منهن ڪيو آهي يا توهان کي ڪنٽينر ٿيل پيداوار ماحول ۾ ٺهڪندڙ سان لاڳاپيل تجربو آهي؟ تبصرن ۾ پنهنجي ڪهاڻي حصيداري ڪريو!
پي ايس مترجم کان
اسان جي بلاگ تي پڻ پڙهو:
- «"؛
- «"؛
- «».
جو ذريعو: www.habr.com