🥇 هڪ اضافي ڪوبي شيڊيولر ٺاهڻ سان گڏ مقرر ڪيل ضابطن جي ڪسٽم سيٽ

Kube-scheduler Kubernetes جو هڪ لازمي حصو آهي، جيڪو مقرر ڪيل پاليسين جي مطابق نوڊس ۾ پوڊس کي شيڊول ڪرڻ جو ذميوار آهي. گهڻو ڪري، ڪبرنيٽس ڪلستر جي آپريشن دوران، اسان کي اهو سوچڻ جي ضرورت ناهي ته ڪهڙيون پاليسيون پوڊ کي شيڊول ڪرڻ لاءِ استعمال ڪيون وينديون آهن، ڇو ته ڊفالٽ ڪبي-شيڊيولر جي پاليسين جو سيٽ اڪثر روزمره جي ڪمن لاءِ موزون هوندو آهي. بهرحال، حالتون آهن جڏهن اسان لاء ضروري آهي ته پوڊ مختص ڪرڻ جي عمل کي بهتر ڪرڻ لاء، ۽ هن ڪم کي پورو ڪرڻ جا ٻه طريقا آهن:

قاعدن جي ڪسٽم سيٽ سان ڪوبي شيڊولر ٺاهيو
پنهنجو شيڊولر لکو ۽ ان کي سيکاريو API سرور جي درخواستن سان ڪم ڪرڻ

هن آرٽيڪل ۾، آئون وضاحت ڪندس ته پهرين نقطي تي عمل ڪرڻ لاء اسان جي منصوبن مان هڪ تي هارٿن جي غير برابر شيڊول جي مسئلي کي حل ڪرڻ لاء.

هڪ مختصر تعارف ته ڪيئن ڪبي شيڊيولر ڪم ڪري ٿو

اهو خاص طور تي ياد رکڻ جي قابل آهي ته ڪوب-شيڊيولر سڌو سنئون شيڊولنگ پوڊ لاء ذميوار نه آهي - اهو صرف نوڊ کي طئي ڪرڻ جو ذميوار آهي جنهن تي پوڊ کي رکڻو پوندو. ٻين لفظن ۾، kube-scheduler جي ڪم جو نتيجو نوڊ جو نالو آهي، جيڪو اهو شيڊولنگ جي درخواست لاء API سرور ڏانهن موٽندو آهي، ۽ اهو آهي جتي ان جو ڪم ختم ٿئي ٿو.

پهريون، kube-scheduler نوڊس جي هڪ فهرست مرتب ڪري ٿو جنهن تي پوڊ کي مقرر ڪري سگهجي ٿو اڳڪٿين جي پاليسين جي مطابق. اڳيون، هن فهرست مان هر نوڊ حاصل ڪري ٿو پوائنٽن جو هڪ خاص تعداد ترجيحن جي پاليسين جي مطابق. نتيجي طور، نوڊ چونڊيو ويو آھي پوائنٽن جي وڌ ۾ وڌ تعداد سان. جيڪڏهن اهڙا نوڊس آهن جيڪي ساڳيا وڌ ۾ وڌ نمبر آهن، هڪ بي ترتيب هڪ چونڊيو ويو آهي. اڳڪٿيون (فلٽرنگ) ۽ ترجيحات (اسڪورنگ) پاليسين جي هڪ فهرست ۽ وضاحت هن ۾ ملي سگهي ٿي. دستاويز.

مسئلي جي جسم جي وضاحت

Nixys تي مختلف ڪبرنيٽس ڪلسٽرز جي وڏي تعداد کي برقرار رکڻ جي باوجود، اسان کي پهريون ڀيرو پوڊ جي شيڊول ڪرڻ جي مسئلي کي صرف تازو ئي سامهون آيو، جڏهن اسان جي منصوبن مان هڪ کي وڏي تعداد ۾ وقتي ڪمن (~ 100 CronJob ادارن) کي هلائڻ جي ضرورت هئي. جيترو ممڪن ٿي سگهي مسئلي جي وضاحت کي آسان ڪرڻ لاءِ، اسان مثال طور وٺنداسين هڪ مائيڪرو سروس، جنهن ۾ هڪ منٽ ۾ هڪ ڀيرو ڪرون ٽاسڪ شروع ڪيو ويندو آهي، سي پي يو تي ڪجهه لوڊ ٺاهيندي. ڪرون ٽاسڪ کي هلائڻ لاءِ، ٽن نوڊس کي مختص ڪيا ويا جن سان بلڪل هڪجهڙائي هئي (هر هڪ تي 24 وي سي پي يو).

ساڳئي وقت، اهو ناممڪن آهي ته درستيءَ سان اهو چوڻ ته CronJob ڪيترو وقت وٺندو ان تي عمل ڪرڻ ۾، ڇاڪاڻ ته ان پٽ ڊيٽا جو حجم مسلسل تبديل ٿي رهيو آهي. سراسري طور تي، ڪوبي شيڊولر جي عام آپريشن دوران، هر نوڊ 3-4 نوڪري جا مثال هلائي ٿو، جيڪي هر نوڊ جي سي پي يو تي لوڊ جو ~ 20-30٪ ٺاهيندا آهن:

مسئلو پاڻ اهو آهي ته ڪڏهن ڪڏهن ڪرون ٽاسڪ پوڊ ٽن نوڊس مان هڪ تي شيڊول ٿيڻ بند ٿي ويا. اهو آهي، ڪنهن وقت ۾، ڪنهن هڪ نوڊس لاءِ هڪ به پوڊ پلان نه ڪيو ويو هو، جڏهن ته ٻين ٻن نوڊس تي ٽاسڪ جون 6-8 ڪاپيون هلنديون هيون، سي پي يو لوڊ جو ~ 40-60٪ ٺاهيندي:

مسئلو بلڪل بي ترتيب واري تعدد سان ٻيهر ورجائي ٿو ۽ ڪڏهن ڪڏهن ان وقت سان لاڳاپيل آهي جڏهن ڪوڊ جو هڪ نئون ورزن رول ڪيو ويو هو.

kube-scheduler لاگنگ ليول کي 10 (-v=10) تائين وڌائڻ سان، اسان رڪارڊ ڪرڻ شروع ڪيو ته هر نوڊ ڪيترا پوائنٽ حاصل ڪيا تشخيص جي عمل دوران. عام پلاننگ آپريشن دوران، هيٺين معلومات لاگن ۾ ڏسي سگھجي ٿي:

resource_allocation.go:78] cronjob-1574828880-mn7m4 -> Node03: BalancedResourceAllocation, capacity 23900 millicores 67167186944 memory bytes, total request 1387 millicores 4161694720 memory bytes, score 9
resource_allocation.go:78] cronjob-1574828880-mn7m4 -> Node02: BalancedResourceAllocation, capacity 23900 millicores 67167186944 memory bytes, total request 1347 millicores 4444810240 memory bytes, score 9
resource_allocation.go:78] cronjob-1574828880-mn7m4 -> Node03: LeastResourceAllocation, capacity 23900 millicores 67167186944 memory bytes, total request 1387 millicores 4161694720 memory bytes, score 9
resource_allocation.go:78] cronjob-1574828880-mn7m4 -> Node01: BalancedResourceAllocation, capacity 23900 millicores 67167186944 memory bytes, total request 1687 millicores 4790840320 memory bytes, score 9
resource_allocation.go:78] cronjob-1574828880-mn7m4 -> Node02: LeastResourceAllocation, capacity 23900 millicores 67167186944 memory bytes, total request 1347 millicores 4444810240 memory bytes, score 9
resource_allocation.go:78] cronjob-1574828880-mn7m4 -> Node01: LeastResourceAllocation, capacity 23900 millicores 67167186944 memory bytes, total request 1687 millicores 4790840320 memory bytes, score 9
generic_scheduler.go:726] cronjob-1574828880-mn7m4_project-stage -> Node01: NodeAffinityPriority, Score: (0)                                                                                       
generic_scheduler.go:726] cronjob-1574828880-mn7m4_project-stage -> Node02: NodeAffinityPriority, Score: (0)                                                                                       
generic_scheduler.go:726] cronjob-1574828880-mn7m4_project-stage -> Node03: NodeAffinityPriority, Score: (0)                                                                                       
interpod_affinity.go:237] cronjob-1574828880-mn7m4 -> Node01: InterPodAffinityPriority, Score: (0)                                                                                                        
generic_scheduler.go:726] cronjob-1574828880-mn7m4_project-stage -> Node01: TaintTolerationPriority, Score: (10)                                                                                   
interpod_affinity.go:237] cronjob-1574828880-mn7m4 -> Node02: InterPodAffinityPriority, Score: (0)                                                                                                        
generic_scheduler.go:726] cronjob-1574828880-mn7m4_project-stage -> Node02: TaintTolerationPriority, Score: (10)                                                                                   
selector_spreading.go:146] cronjob-1574828880-mn7m4 -> Node01: SelectorSpreadPriority, Score: (10)                                                                                                        
interpod_affinity.go:237] cronjob-1574828880-mn7m4 -> Node03: InterPodAffinityPriority, Score: (0)                                                                                                        
generic_scheduler.go:726] cronjob-1574828880-mn7m4_project-stage -> Node03: TaintTolerationPriority, Score: (10)                                                                                   
selector_spreading.go:146] cronjob-1574828880-mn7m4 -> Node02: SelectorSpreadPriority, Score: (10)                                                                                                        
selector_spreading.go:146] cronjob-1574828880-mn7m4 -> Node03: SelectorSpreadPriority, Score: (10)                                                                                                        
generic_scheduler.go:726] cronjob-1574828880-mn7m4_project-stage -> Node01: SelectorSpreadPriority, Score: (10)                                                                                    
generic_scheduler.go:726] cronjob-1574828880-mn7m4_project-stage -> Node02: SelectorSpreadPriority, Score: (10)                                                                                    
generic_scheduler.go:726] cronjob-1574828880-mn7m4_project-stage -> Node03: SelectorSpreadPriority, Score: (10)                                                                                    
generic_scheduler.go:781] Host Node01 => Score 100043                                                                                                                                                                        
generic_scheduler.go:781] Host Node02 => Score 100043                                                                                                                                                                        
generic_scheduler.go:781] Host Node03 => Score 100043

اهي. لاگز مان حاصل ڪيل معلومات جي مطابق، هر هڪ نوڊس هڪ جيتري تعداد ۾ فائنل پوائنٽ حاصل ڪيا ۽ منصوبابندي لاء بي ترتيب هڪ چونڊيو ويو. مشڪلاتي منصوبابندي جي وقت، لاگ ان وانگر نظر اچن ٿا:

resource_allocation.go:78] cronjob-1574211360-bzfkr -> Node02: BalancedResourceAllocation, capacity 23900 millicores 67167186944 memory bytes, total request 1587 millicores 4581125120 memory bytes, score 9
resource_allocation.go:78] cronjob-1574211360-bzfkr -> Node03: BalancedResourceAllocation, capacity 23900 millicores 67167186944 memory bytes, total request 1087 millicores 3532549120 memory bytes, score 9
resource_allocation.go:78] cronjob-1574211360-bzfkr -> Node02: LeastResourceAllocation, capacity 23900 millicores 67167186944 memory bytes, total request 1587 millicores 4581125120 memory bytes, score 9
resource_allocation.go:78] cronjob-1574211360-bzfkr -> Node01: BalancedResourceAllocation, capacity 23900 millicores 67167186944 memory bytes, total request 987 millicores 3322833920 memory bytes, score 9
resource_allocation.go:78] cronjob-1574211360-bzfkr -> Node01: LeastResourceAllocation, capacity 23900 millicores 67167186944 memory bytes, total request 987 millicores 3322833920 memory bytes, score 9 
resource_allocation.go:78] cronjob-1574211360-bzfkr -> Node03: LeastResourceAllocation, capacity 23900 millicores 67167186944 memory bytes, total request 1087 millicores 3532549120 memory bytes, score 9
interpod_affinity.go:237] cronjob-1574211360-bzfkr -> Node03: InterPodAffinityPriority, Score: (0)                                                                                                        
interpod_affinity.go:237] cronjob-1574211360-bzfkr -> Node02: InterPodAffinityPriority, Score: (0)                                                                                                        
interpod_affinity.go:237] cronjob-1574211360-bzfkr -> Node01: InterPodAffinityPriority, Score: (0)                                                                                                        
generic_scheduler.go:726] cronjob-1574211360-bzfkr_project-stage -> Node03: TaintTolerationPriority, Score: (10)                                                                                   
selector_spreading.go:146] cronjob-1574211360-bzfkr -> Node03: SelectorSpreadPriority, Score: (10)                                                                                                        
selector_spreading.go:146] cronjob-1574211360-bzfkr -> Node02: SelectorSpreadPriority, Score: (10)                                                                                                        
generic_scheduler.go:726] cronjob-1574211360-bzfkr_project-stage -> Node02: TaintTolerationPriority, Score: (10)                                                                                   
selector_spreading.go:146] cronjob-1574211360-bzfkr -> Node01: SelectorSpreadPriority, Score: (10)                                                                                                        
generic_scheduler.go:726] cronjob-1574211360-bzfkr_project-stage -> Node03: NodeAffinityPriority, Score: (0)                                                                                       
generic_scheduler.go:726] cronjob-1574211360-bzfkr_project-stage -> Node03: SelectorSpreadPriority, Score: (10)                                                                                    
generic_scheduler.go:726] cronjob-1574211360-bzfkr_project-stage -> Node02: SelectorSpreadPriority, Score: (10)                                                                                    
generic_scheduler.go:726] cronjob-1574211360-bzfkr_project-stage -> Node01: TaintTolerationPriority, Score: (10)                                                                                   
generic_scheduler.go:726] cronjob-1574211360-bzfkr_project-stage -> Node02: NodeAffinityPriority, Score: (0)                                                                                       
generic_scheduler.go:726] cronjob-1574211360-bzfkr_project-stage -> Node01: NodeAffinityPriority, Score: (0)                                                                                       
generic_scheduler.go:726] cronjob-1574211360-bzfkr_project-stage -> Node01: SelectorSpreadPriority, Score: (10)                                                                                    
generic_scheduler.go:781] Host Node03 => Score 100041                                                                                                                                                                        
generic_scheduler.go:781] Host Node02 => Score 100041                                                                                                                                                                        
generic_scheduler.go:781] Host Node01 => Score 100038

جنهن مان اهو ڏسي سگهجي ٿو ته هڪ نوڊس ٻين جي ڀيٽ ۾ گهٽ فائنل پوائنٽ اسڪور ڪيو، ۽ ان ڪري منصوبه بندي صرف ٻن نوڊس لاءِ ڪئي وئي جيڪي وڌ ۾ وڌ اسڪور ڪن. ان ڪري، اسان کي پڪ سان پڪ ٿي ويو ته مسئلو بلڪل صحيح طور تي پوڊ جي شيڊول ۾ آهي.

مسئلو حل ڪرڻ لاءِ وڌيڪ الورورٿم اسان لاءِ واضح هو - لاگن جو تجزيو ڪريو، سمجھو ته ڪهڙي ترجيح سان نوڊ پوائنٽ اسڪور نه ڪيو ۽، جيڪڏھن ضروري ھجي ته، ڊفالٽ ڪبي-شيڊيولر جي پاليسين کي ترتيب ڏيو. بهرحال، هتي اسان کي ٻه اهم مشڪلاتن سان منهن ڏيڻو پوي ٿو:

وڌ ۾ وڌ لاگنگ جي سطح تي (10)، حاصل ڪيل پوائنٽون صرف ڪجهه ترجيحن لاءِ ظاهر ٿين ٿيون. لاگز جي مٿين اقتباس ۾، توهان ڏسي سگهو ٿا ته لاگز ۾ ظاهر ڪيل سڀني ترجيحن لاءِ، نوڊس ساڳئي نمبر پوائنٽن کي عام ۽ مسئلي جي شيڊول ۾ سکور ڪن ٿا، پر مسئلي جي رٿابندي جي صورت ۾ حتمي نتيجو مختلف آهي. اهڙيء طرح، اسان اهو نتيجو ڪري سگهون ٿا ته ڪجهه ترجيحن لاء، اسڪورنگ "پردي جي پويان" ٿئي ٿي، ۽ اسان کي اهو سمجهڻ جو ڪو طريقو ناهي ته ڪهڙي ترجيح لاء نوڊ پوائنٽ حاصل نه ڪيو. اسان هن مسئلي کي تفصيل سان بيان ڪيو آهي مسئلو Github تي Kubernetes مخزن. لکڻ جي وقت تي، ڊولپرز کان هڪ جواب ملي ويو ته لاگنگ سپورٽ شامل ڪئي ويندي Kubernetes v1.15,1.16، 1.17 ۽ XNUMX اپڊيٽ ۾.
اهو سمجهڻ جو ڪو به آسان طريقو ناهي ته پاليسين جي ڪهڙي مخصوص سيٽ ڪبي شيڊيولر هن وقت ڪم ڪري رهيو آهي. ها، ۾ دستاويز هي فهرست ڏنل آهي، پر ان ۾ اها معلومات نه آهي ته هر هڪ ترجيحي پاليسين لاءِ ڪهڙا مخصوص وزن مقرر ڪيا ويا آهن. توهان وزن ڏسي سگهو ٿا يا صرف ڊفالٽ ڪبي-شيڊيولر جي پاليسين کي ايڊٽ ڪري سگهو ٿا ذريعو ڪوڊ.

اهو نوٽ ڪرڻ جي قابل آهي ته هڪ دفعو اسان اهو رڪارڊ ڪرڻ جي قابل ٿي چڪا هئاسين ته هڪ نوڊ کي پوائنٽس حاصل نه ڪيو ويو ImageLocalityPriority پاليسي جي مطابق، جيڪو انعام ڏئي ٿو هڪ نوڊ ڏانهن پوائنٽون جيڪڏهن ان وٽ اڳ ۾ ئي ايپليڪيشن کي هلائڻ لاء ضروري تصوير آهي. اهو آهي، جنهن وقت ايپليڪيشن جو هڪ نئون ورزن رول آئوٽ ڪيو ويو هو، ڪرون ٽاسڪ ٻن نوڊس تي هلائڻ ۾ ڪامياب ٿي ويو، ڊاڪر رجسٽري مان هڪ نئين تصوير ڊائون لوڊ ڪري انهن ڏانهن، ۽ اهڙيءَ طرح ٻن نوڊس ٽئين نمبر جي مقابلي ۾ وڌيڪ فائنل اسڪور حاصل ڪيو. .

جيئن مون مٿي لکيو آهي، لاگز ۾ اسان کي تصويري لوڪلٽي پرائيويٽ پاليسي جي تشخيص بابت معلومات نظر نه ايندي آهي، تنهنڪري اسان جي مفروضي کي جانچڻ لاء، اسان تصوير کي ايپليڪيشن جي نئين ورزن سان ٽئين نوڊ تي ڊمپ ڪيو، جنهن کان پوء شيڊولنگ صحيح طريقي سان ڪم ڪيو. . اهو خاص طور تي ImageLocalityPriority پاليسي جي ڪري هو ته شيڊولنگ جو مسئلو تمام گهٽ ڏٺو ويو آهي؛ گهڻو ڪري اهو ڪنهن ٻئي سان لاڳاپيل هوندو هو. ان حقيقت جي ڪري ته اسان ڊفالٽ ڪبي شيڊيولر جي ترجيحن جي فهرست ۾ هر هڪ پاليسين کي مڪمل طور تي ڊيبگ نه ڪري سگهياسين، اسان کي پوڊ شيڊولنگ پاليسين جي لچڪدار انتظام جي ضرورت هئي.

مسئلو جي ترتيب

اسان چاهيون ٿا ته مسئلي جو حل ممڪن حد تائين مخصوص هجي، يعني Kubernetes جا مکيه ادارا (هتي اسان جو مطلب آهي ڊفالٽ kube-scheduler) اڻ مٽجڻ گهرجي. اسان نه ٿا چاهيون ته مسئلو هڪ جاءِ تي حل ڪجي ۽ ٻئي هنڌ پيدا ڪجي. اهڙيء طرح، اسان مسئلي کي حل ڪرڻ لاء ٻه اختيارن تي آيا، جن جو اعلان مضمون جي تعارف ۾ ڪيو ويو آهي - هڪ اضافي شيڊولر ٺاهڻ يا پنهنجو پاڻ کي لکڻ. ڪرون ڪمن کي شيڊول ڪرڻ لاءِ بنيادي گهربل لوڊ کي برابر طور تي ٽن نوڊس ۾ ورهائڻ آهي. اها گهرج موجوده ڪوبي شيڊيولر پاليسين ذريعي پوري ٿي سگهي ٿي، تنهنڪري اسان جي مسئلي کي حل ڪرڻ لاءِ پنهنجو شيڊيولر لکڻ جو ڪو به فائدو ناهي.

هڪ اضافي ڪوب شيڊيولر ٺاهڻ ۽ ترتيب ڏيڻ لاءِ هدايتون بيان ڪيون ويون آهن دستاويز. بهرحال، اسان کي اهو محسوس ٿيو ته ڊيپلائيمينٽ ادارو ڪافي نه هو ته جيئن هڪ نازڪ سروس جي آپريشن ۾ ڪوب-شيڊيولر جي عمل ۾ غلطي برداشت کي يقيني بڻائي، تنهنڪري اسان هڪ نئون ڪوب-شيڊيولر کي هڪ مستحڪم پوڊ طور مقرر ڪرڻ جو فيصلو ڪيو، جيڪو سڌو سنئون مانيٽر ڪيو ويندو. ڪوبيليٽ طرفان. اهڙيء طرح، اسان کي نئين ڪوب-شيڊيولر لاء هيٺيون گهرجون آهن:

خدمت لازمي طور تي سڀني ڪلستر ماسٽرز تي جامد پوڊ طور مقرر ڪيو وڃي
غلطي برداشت ڪرڻ لازمي آهي ان صورت ۾ جڏهن فعال پوڊ ڪوبي شيڊولر موجود نه هجي
بنيادي ترجيح جڏهن رٿابندي ڪرڻ گهرجي نوڊ تي موجود وسيلن جو تعداد (LeastRequestedPriority)

حل لاڳو ڪرڻ

اهو فوري طور تي نوٽ ڪرڻ جي قابل آهي ته اسان سڀ ڪم ڪبرنيٽس v1.14.7 ۾ ڪنداسين، ڇاڪاڻ ته اھو اھو نسخو آھي جيڪو منصوبي ۾ استعمال ڪيو ويو. اچو ته شروع ڪريون پنهنجي نئين ڪوبي شيڊيولر لاءِ منشور لکڻ سان. اچو ته ڊفالٽ مينيفيسٽ (/etc/kubernetes/manifests/kube-scheduler.yaml) کي بنياد بڻايون ۽ ان کي ھيٺ ڏنل شڪل ۾ آڻيون:

kind: Pod
metadata:
  labels:
    component: scheduler
    tier: control-plane
  name: kube-scheduler-cron
  namespace: kube-system
spec:
      containers:
      - command:
        - /usr/local/bin/kube-scheduler
        - --address=0.0.0.0
        - --port=10151
        - --secure-port=10159
        - --config=/etc/kubernetes/scheduler-custom.conf
        - --authentication-kubeconfig=/etc/kubernetes/scheduler.conf
        - --authorization-kubeconfig=/etc/kubernetes/scheduler.conf
        - --v=2
        image: gcr.io/google-containers/kube-scheduler:v1.14.7
        imagePullPolicy: IfNotPresent
        livenessProbe:
          failureThreshold: 8
          httpGet:
            host: 127.0.0.1
            path: /healthz
            port: 10151
            scheme: HTTP
          initialDelaySeconds: 15
          timeoutSeconds: 15
        name: kube-scheduler-cron-container
        resources:
          requests:
            cpu: '0.1'
        volumeMounts:
        - mountPath: /etc/kubernetes/scheduler.conf
          name: kube-config
          readOnly: true
        - mountPath: /etc/localtime
          name: localtime
          readOnly: true
        - mountPath: /etc/kubernetes/scheduler-custom.conf
          name: scheduler-config
          readOnly: true
        - mountPath: /etc/kubernetes/scheduler-custom-policy-config.json
          name: policy-config
          readOnly: true
      hostNetwork: true
      priorityClassName: system-cluster-critical
      volumes:
      - hostPath:
          path: /etc/kubernetes/scheduler.conf
          type: FileOrCreate
        name: kube-config
      - hostPath:
          path: /etc/localtime
        name: localtime
      - hostPath:
          path: /etc/kubernetes/scheduler-custom.conf
          type: FileOrCreate
        name: scheduler-config
      - hostPath:
          path: /etc/kubernetes/scheduler-custom-policy-config.json
          type: FileOrCreate
        name: policy-config

مختصر طور تي بنيادي تبديلين بابت:

پوڊ ۽ ڪنٽينر جو نالو تبديل ڪري kube-scheduler-cron
بيان ڪيو ويو بندرگاهن جو استعمال 10151 ۽ 10159 جيئن اختيار بيان ڪيو ويو آهي hostNetwork: true ۽ اسان ساڳي بندرگاهن کي ڊفالٽ ڪوبي شيڊيولر (10251 ۽ 10259) جي طور تي استعمال نٿا ڪري سگھون.
استعمال ڪندي --config پيٽرول، اسان وضاحت ڪئي ته ترتيب واري فائل جنهن سان خدمت شروع ٿيڻ گهرجي
ميزبان کان ترتيب واري فائيل (scheduler-custom.conf) ۽ شيڊولنگ پاليسي فائل (scheduler-custom-policy-config.json) جي ترتيب ڏنل چڙهڻ

اهو نه وساريو ته اسان جي ڪوب-شيڊيولر کي ڊفالٽ وانگر حقن جي ضرورت پوندي. ان جي ڪلسٽر ڪردار کي تبديل ڪريو:

kubectl edit clusterrole system:kube-scheduler

...
   resourceNames:
    - kube-scheduler
    - kube-scheduler-cron
...

هاڻي اچو ته ان بابت ڳالهايون ته ڪنفيگريشن فائل ۽ شيڊيولنگ پاليسي فائل ۾ ڇا هجڻ گهرجي:

ٺاھ جوڙ واري فائيل (scheduler-custom.conf)
ڊفالٽ kube-scheduler جي ٺاھ جوڙ حاصل ڪرڻ لاء، توھان کي لازمي طور استعمال ڪرڻ گھرجي --write-config-to کان دستاويز. اسان نتيجي واري ترتيب کي فائل ۾ رکنداسين /etc/kubernetes/scheduler-custom.conf ۽ ان کي ھيٺ ڏنل شڪل ۾ گھٽائينداسين:

apiVersion: kubescheduler.config.k8s.io/v1alpha1
kind: KubeSchedulerConfiguration
schedulerName: kube-scheduler-cron
bindTimeoutSeconds: 600
clientConnection:
  acceptContentTypes: ""
  burst: 100
  contentType: application/vnd.kubernetes.protobuf
  kubeconfig: /etc/kubernetes/scheduler.conf
  qps: 50
disablePreemption: false
enableContentionProfiling: false
enableProfiling: false
failureDomains: kubernetes.io/hostname,failure-domain.beta.kubernetes.io/zone,failure-domain.beta.kubernetes.io/region
hardPodAffinitySymmetricWeight: 1
healthzBindAddress: 0.0.0.0:10151
leaderElection:
  leaderElect: true
  leaseDuration: 15s
  lockObjectName: kube-scheduler-cron
  lockObjectNamespace: kube-system
  renewDeadline: 10s
  resourceLock: endpoints
  retryPeriod: 2s
metricsBindAddress: 0.0.0.0:10151
percentageOfNodesToScore: 0
algorithmSource:
   policy:
     file:
       path: "/etc/kubernetes/scheduler-custom-policy-config.json"

مختصر طور تي بنيادي تبديلين بابت:

اسان مقرر ڪيو SchedulerName اسان جي kube-scheduler-cron سروس جي نالي تي.
پيراگراف ۾ lockObjectName توھان کي پڻ اسان جي خدمت جو نالو مقرر ڪرڻ جي ضرورت آھي ۽ پڪ ڪريو ته پيٽرولر leaderElect سچ تي سيٽ ڪريو (جيڪڏهن توهان وٽ هڪ ماسٽر نوڊ آهي، توهان ان کي غلط تي سيٽ ڪري سگهو ٿا).
وضاحت ڪريو فائل ڏانهن رستو وضاحت سان شيڊول جي پاليسين جي وضاحت سان پيراميٽر ۾ algorithmSource.

اهو ٻئي نقطي تي هڪ ويجهي نظر وٺڻ جي قابل آهي، جتي اسان ڪيئي لاء پيٽرولر کي تبديل ڪندا آهيون leaderElection. غلطي رواداري کي يقيني بڻائڻ لاء، اسان فعال ڪيو آهي (leaderElect) ليڊر (ماسٽر) کي چونڊڻ جو عمل اسان جي ڪوبي شيڊيولر جي پوڊز جي وچ ۾ انهن لاءِ هڪ واحد آخري پوائنٽ استعمال ڪندي (resourceLock) نالي kube-scheduler-cron (lockObjectName) kube-system namespace ۾ (lockObjectNamespace). ڪئين ڪبرنيٽس بنيادي اجزاء جي اعلي دستيابي کي يقيني بڻائي ٿو (بشمول ڪوب-شيڊيولر) ۾ ڳولي سگھجي ٿو مضمون.

شيڊيولنگ پاليسي فائل (scheduler-custom-policy-config.json)
جيئن مون اڳ ۾ لکيو آهي، اسان اهو ڳولي سگهون ٿا ته ڪهڙن مخصوص پاليسين سان ڊفالٽ ڪبي-شيڊيولر ڪم ڪري ٿو صرف ان جي ڪوڊ جو تجزيو ڪندي. اھو آھي، اسان ھڪڙي فائل حاصل نه ڪري سگھون ٿا شيڊولنگ پاليسين سان ڊفالٽ ڪبي-شيڊيولر لاءِ ساڳي طرح ھڪڙي ترتيب واري فائل جي طور تي. اچو ته شيڊيولنگ پاليسين کي بيان ڪريون جن ۾ اسان دلچسپي رکون ٿا /etc/kubernetes/scheduler-custom-policy-config.json فائل هن ريت:

{
  "kind": "Policy",
  "apiVersion": "v1",
  "predicates": [
    {
      "name": "GeneralPredicates"
    }
  ],
  "priorities": [
    {
      "name": "ServiceSpreadingPriority",
      "weight": 1
    },
    {
      "name": "EqualPriority",
      "weight": 1
    },
    {
      "name": "LeastRequestedPriority",
      "weight": 1
    },
    {
      "name": "NodePreferAvoidPodsPriority",
      "weight": 10000
    },
    {
      "name": "NodeAffinityPriority",
      "weight": 1
    }
  ],
  "hardPodAffinitySymmetricWeight" : 10,
  "alwaysCheckAllPredicates" : false
}

اهڙيء طرح، kube-scheduler پهريون ڀيرو نوڊس جي هڪ فهرست مرتب ڪري ٿو جنهن ۾ هڪ پوڊ مقرر ڪري سگهجي ٿو GeneralPredicates پاليسي (جنهن ۾ PodFitsResources، PodFitsHostPorts، HostName، ۽ MatchNodeSelector پاليسين جو هڪ سيٽ شامل آهي). ۽ پوءِ هر نوڊ جو جائزو ورتو ويندو آهي پاليسين جي سيٽ جي مطابق ترجيحن جي صف ۾. اسان جي ڪم جي شرطن کي پورو ڪرڻ لاء، اسان سمجهيو ته پاليسين جو هڪ سيٽ بهترين حل هوندو. مون کي توهان کي ياد ڏياريو ته پاليسين جو هڪ سيٽ انهن جي تفصيلي وضاحت سان موجود آهي دستاويز. توهان جي ڪم کي مڪمل ڪرڻ لاء، توهان صرف استعمال ڪيل پاليسين جو سيٽ تبديل ڪري سگهو ٿا ۽ انهن کي مناسب وزن تفويض ڪري سگهو ٿا.

اچو ته نئين kube-scheduler جي manifest کي سڏيون، جيڪو اسان باب جي شروعات ۾ ٺاهيو، kube-scheduler-custom.yaml ۽ ان کي ھيٺئين رستي ۾ رکون /etc/kubernetes/manifests ٽن ماسٽر نوڊس تي. جيڪڏهن سڀ ڪجهه صحيح طريقي سان ڪيو ويو آهي، Kubelet هر نوڊ تي هڪ پوڊ شروع ڪندو، ۽ اسان جي نئين ڪوب-شيڊيولر جي لاگن ۾ اسان معلومات ڏسندا سين ته اسان جي پاليسي فائل ڪاميابي سان لاڳو ڪئي وئي هئي:

Creating scheduler from configuration: {{ } [{GeneralPredicates <nil>}] [{ServiceSpreadingPriority 1 <nil>} {EqualPriority 1 <nil>} {LeastRequestedPriority 1 <nil>} {NodePreferAvoidPodsPriority 10000 <nil>} {NodeAffinityPriority 1 <nil>}] [] 10 false}
Registering predicate: GeneralPredicates
Predicate type GeneralPredicates already registered, reusing.
Registering priority: ServiceSpreadingPriority
Priority type ServiceSpreadingPriority already registered, reusing.
Registering priority: EqualPriority
Priority type EqualPriority already registered, reusing.
Registering priority: LeastRequestedPriority
Priority type LeastRequestedPriority already registered, reusing.
Registering priority: NodePreferAvoidPodsPriority
Priority type NodePreferAvoidPodsPriority already registered, reusing.
Registering priority: NodeAffinityPriority
Priority type NodeAffinityPriority already registered, reusing.
Creating scheduler with fit predicates 'map[GeneralPredicates:{}]' and priority functions 'map[EqualPriority:{} LeastRequestedPriority:{} NodeAffinityPriority:{} NodePreferAvoidPodsPriority:{} ServiceSpreadingPriority:{}]'

هاڻي باقي رهي ٿو ته اسان جي CronJob جي وضاحت ۾ اشارو ڪيو وڃي ته ان جي پوڊ کي شيڊول ڪرڻ لاءِ سڀني درخواستن تي عمل ڪيو وڃي اسان جي نئين ڪوبي شيڊيولر:

...
 jobTemplate:
    spec:
      template:
        spec:
          schedulerName: kube-scheduler-cron
...

ٿڪل

آخرڪار، اسان کي هڪ اضافي ڪوب-شيڊيولر مليو جنهن سان شيڊيولنگ پاليسين جي هڪ منفرد سيٽ آهي، جنهن جي ڪم کي سڌو سنئون ڪبيليٽ مانيٽر ڪيو ويندو آهي. ان کان علاوه، اسان نئين ليڊر جي چونڊ کي اسان جي ڪبي-شيڊيولر جي پوڊز جي وچ ۾ مقرر ڪيو آهي، جيڪڏهن پراڻي ليڊر ڪنهن سببن جي دستياب نه ٿي وڃي.

باقاعده ايپليڪيشنون ۽ خدمتون ڊفالٽ ڪوب-شيڊيولر جي ذريعي شيڊول جاري آهن، ۽ سڀني ڪرون ڪمن کي مڪمل طور تي نئين کي منتقل ڪيو ويو آهي. ڪرون ڪمن پاران ٺاهيل لوڊ هاڻي سڀني نوڊس ۾ برابر طور تي ورهايل آهي. انهي ڳالهه تي غور ڪندي ته ڪرون جا گهڻا ڪم ساڳيا نوڊس تي عمل ڪيا ويندا آهن جيئن پروجيڪٽ جي مکيه ايپليڪيشنن تي، هن وسيلن جي کوٽ جي ڪري پوڊ کي منتقل ڪرڻ جي خطري کي خاص طور تي گهٽائي ڇڏيو آهي. اضافي ڪوب شيڊيولر متعارف ڪرائڻ کان پوءِ، ڪرون ڪمن جي اڻ برابري شيڊول سان مسئلا هاڻي پيدا نه ٿيا.

اسان جي بلاگ تي ٻيا مضمون پڻ پڙهو:

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

شيڊيولنگ قاعدن جي ڪسٽم سيٽ سان گڏ هڪ اضافي ڪوبي شيڊولر ٺاهڻ

هڪ مختصر تعارف ته ڪيئن ڪبي شيڊيولر ڪم ڪري ٿو

مسئلي جي جسم جي وضاحت

مسئلو جي ترتيب

حل لاڳو ڪرڻ

ٿڪل

اسان جي بلاگ تي ٻيا مضمون پڻ پڙهو:

تبصرو شامل ڪريو جواب منسوخ

شيڊيولنگ ​​قاعدن جي ڪسٽم سيٽ سان گڏ هڪ اضافي ڪوبي شيڊولر ٺاهڻ

هڪ مختصر تعارف ته ڪيئن ڪبي شيڊيولر ڪم ڪري ٿو

مسئلي جي جسم جي وضاحت

مسئلو جي ترتيب

حل لاڳو ڪرڻ

ٿڪل

اسان جي بلاگ تي ٻيا مضمون پڻ پڙهو:

تبصرو شامل ڪريو جواب منسوخ

شيڊيولنگ قاعدن جي ڪسٽم سيٽ سان گڏ هڪ اضافي ڪوبي شيڊولر ٺاهڻ