🥇திட்டமிடல் விதிகளின் தனிப்பயன் தொகுப்புடன் கூடுதல் க்யூப்-திட்டமிடலை உருவாக்குதல்

குபே-திட்டமிடல் என்பது குபெர்னெட்ஸின் ஒருங்கிணைந்த அங்கமாகும், இது குறிப்பிட்ட கொள்கைகளின்படி கணுக்கள் முழுவதும் பாட்களை திட்டமிடுவதற்கு பொறுப்பாகும். பெரும்பாலும், குபெர்னெட்டஸ் கிளஸ்டரின் செயல்பாட்டின் போது, காய்களை திட்டமிட எந்தக் கொள்கைகள் பயன்படுத்தப்படுகின்றன என்பதைப் பற்றி நாம் சிந்திக்க வேண்டியதில்லை, ஏனெனில் இயல்புநிலையான kube-scheduler இன் கொள்கைகளின் தொகுப்பு பெரும்பாலான அன்றாட பணிகளுக்கு ஏற்றது. எவ்வாறாயினும், காய்களை ஒதுக்கும் செயல்முறையை நன்றாக மாற்றியமைக்க வேண்டிய சூழ்நிலைகள் உள்ளன, மேலும் இந்த பணியை நிறைவேற்ற இரண்டு வழிகள் உள்ளன:

தனிப்பயன் விதிகளின் தொகுப்புடன் ஒரு குபே-திட்டமிடுதலை உருவாக்கவும்
உங்கள் சொந்த திட்டமிடலை எழுதி, API சர்வர் கோரிக்கைகளுடன் வேலை செய்ய கற்றுக்கொடுங்கள்

இந்த கட்டுரையில், எங்கள் திட்டங்களில் ஒன்றில் அடுப்புகளின் சீரற்ற திட்டமிடல் சிக்கலைத் தீர்ப்பதற்கான முதல் புள்ளியை செயல்படுத்துவதை விவரிப்பேன்.

kube-scheduler எவ்வாறு செயல்படுகிறது என்பதற்கான சுருக்கமான அறிமுகம்

காய்களை நேரடியாக திட்டமிடுவதற்கு kube-scheduler பொறுப்பேற்காது என்பது குறிப்பாக கவனிக்கத்தக்கது - இது காய்களை வைக்கும் முனையை தீர்மானிப்பதற்கு மட்டுமே பொறுப்பாகும். வேறு வார்த்தைகளில் கூறுவதானால், kube-scheduler இன் வேலையின் விளைவாக முனையின் பெயராகும், இது திட்டமிடல் கோரிக்கைக்காக API சேவையகத்திற்குத் திரும்புகிறது, அதன் பணி முடிவடைகிறது.

முதலாவதாக, kube-scheduler கணுக்களின் பட்டியலைத் தொகுக்கிறது, அதில் முன்கணிப்புக் கொள்கைகளுக்கு ஏற்ப பாட் திட்டமிடலாம். அடுத்து, இந்தப் பட்டியலில் இருந்து ஒவ்வொரு முனையும் முன்னுரிமைக் கொள்கைகளுக்கு ஏற்ப குறிப்பிட்ட எண்ணிக்கையிலான புள்ளிகளைப் பெறுகிறது. இதன் விளைவாக, அதிகபட்ச புள்ளிகள் கொண்ட முனை தேர்ந்தெடுக்கப்பட்டது. ஒரே அதிகபட்ச மதிப்பெண்ணைக் கொண்ட முனைகள் இருந்தால், சீரற்ற ஒன்று தேர்ந்தெடுக்கப்படும். முன்னறிவிப்புகள் (வடிகட்டுதல்) மற்றும் முன்னுரிமைகள் (மதிப்பீடு) கொள்கைகளின் பட்டியல் மற்றும் விளக்கத்தைக் காணலாம் ஆவணங்கள்.

பிரச்சனை உடலின் விளக்கம்

Nixys இல் பலவிதமான குபெர்னெட்ஸ் கிளஸ்டர்கள் பராமரிக்கப்பட்டு வந்த போதிலும், எங்களின் திட்டங்களில் ஒன்று அதிக எண்ணிக்கையிலான குறிப்பிட்ட பணிகளை (~100 CronJob நிறுவனங்கள்) இயக்க வேண்டியிருந்தபோது, சமீபத்தில்தான் காய்களை திட்டமிடுவதில் உள்ள சிக்கலை நாங்கள் முதலில் சந்தித்தோம். சிக்கலின் விளக்கத்தை முடிந்தவரை எளிமைப்படுத்த, ஒரு மைக்ரோ சர்வீஸை உதாரணமாக எடுத்துக்கொள்வோம், அதற்குள் நிமிடத்திற்கு ஒரு முறை கிரான் பணி தொடங்கப்பட்டு, CPU இல் சில சுமைகளை உருவாக்குகிறது. கிரான் பணியை இயக்க, முற்றிலும் ஒரே மாதிரியான குணாதிசயங்களைக் கொண்ட மூன்று முனைகள் ஒதுக்கப்பட்டன (ஒவ்வொன்றிலும் 24 vCPUகள்).

அதே நேரத்தில், உள்ளீட்டுத் தரவின் அளவு தொடர்ந்து மாறிக்கொண்டே இருப்பதால், CronJob செயல்படுத்த எவ்வளவு நேரம் எடுக்கும் என்பதைத் துல்லியமாகக் கூற முடியாது. சராசரியாக, kube-scheduler இன் இயல்பான செயல்பாட்டின் போது, ஒவ்வொரு முனையும் 3-4 வேலை நிகழ்வுகளை இயக்குகிறது, இது ஒவ்வொரு முனையின் CPU இல் ~20-30% சுமைகளை உருவாக்குகிறது:

பிரச்சனை என்னவென்றால், சில நேரங்களில் கிரான் டாஸ்க் பாட்கள் மூன்று முனைகளில் ஒன்றில் திட்டமிடப்படுவதை நிறுத்தியது. அதாவது, ஒரு கட்டத்தில், ஒரு முனைக்கு ஒரு பாட் கூட திட்டமிடப்படவில்லை, மற்ற இரண்டு முனைகளில் பணியின் 6-8 பிரதிகள் இயங்குகின்றன, இது CPU சுமையின் ~ 40-60% உருவாக்குகிறது:

சிக்கல் முற்றிலும் சீரற்ற அதிர்வெண்ணுடன் மீண்டும் மீண்டும் நிகழ்கிறது மற்றும் குறியீட்டின் புதிய பதிப்பு வெளியிடப்பட்ட தருணத்துடன் அவ்வப்போது தொடர்புடையது.

kube-scheduler logging level ஐ நிலை 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

இதிலிருந்து ஒரு முனை மற்றவற்றை விட குறைவான இறுதிப் புள்ளிகளைப் பெற்றதைக் காணலாம், எனவே அதிகபட்ச மதிப்பெண்ணைப் பெற்ற இரண்டு முனைகளுக்கு மட்டுமே திட்டமிடல் மேற்கொள்ளப்பட்டது. எனவே, காய்களின் திட்டமிடலில் துல்லியமாக சிக்கல் உள்ளது என்பதை நாங்கள் உறுதியாக நம்பினோம்.

சிக்கலைத் தீர்ப்பதற்கான கூடுதல் வழிமுறை எங்களுக்குத் தெளிவாகத் தெரிந்தது - பதிவுகளை பகுப்பாய்வு செய்யுங்கள், முனை எந்த முன்னுரிமையில் புள்ளிகளைப் பெறவில்லை என்பதைப் புரிந்து கொள்ளுங்கள் மற்றும் தேவைப்பட்டால், இயல்புநிலை kube-திட்டமிடலின் கொள்கைகளை சரிசெய்யவும். இருப்பினும், இங்கே நாம் இரண்டு குறிப்பிடத்தக்க சிரமங்களை எதிர்கொள்கிறோம்:

அதிகபட்ச பதிவு மட்டத்தில் (10), சில முன்னுரிமைகளுக்கு மட்டுமே பெறப்பட்ட புள்ளிகள் பிரதிபலிக்கப்படுகின்றன. பதிவுகளின் மேற்கூறிய பகுதியிலிருந்து, பதிவுகளில் பிரதிபலிக்கும் அனைத்து முன்னுரிமைகளுக்கும், கணுக்கள் இயல்பான மற்றும் சிக்கல் திட்டமிடலில் ஒரே எண்ணிக்கையிலான புள்ளிகளைப் பெறுவதை நீங்கள் காணலாம், ஆனால் சிக்கல் திட்டமிடல் விஷயத்தில் இறுதி முடிவு வேறுபட்டது. எனவே, சில முன்னுரிமைகளுக்கு, ஸ்கோரிங் "திரைக்குப் பின்னால்" நிகழ்கிறது என்று நாம் முடிவு செய்யலாம், மேலும் முனை எந்த முன்னுரிமைக்காக புள்ளிகளைப் பெறவில்லை என்பதைப் புரிந்துகொள்ள எங்களுக்கு வழி இல்லை. இந்த சிக்கலை நாங்கள் விரிவாக விவரித்தோம் பிரச்சினை கிதுப்பில் குபெர்னெட்ஸ் களஞ்சியம். எழுதும் நேரத்தில், குபெர்னெட்ஸ் v1.15,1.16, 1.17 மற்றும் XNUMX புதுப்பிப்புகளில் லாக்கிங் ஆதரவு சேர்க்கப்படும் என்று டெவலப்பர்களிடமிருந்து பதில் வந்தது.
kube-scheduler தற்போது எந்தக் குறிப்பிட்ட கொள்கைகளுடன் செயல்படுகிறது என்பதைப் புரிந்துகொள்ள எளிதான வழி எதுவுமில்லை. ஆம், உள்ளே ஆவணங்கள் இந்தப் பட்டியல் பட்டியலிடப்பட்டுள்ளது, ஆனால் முன்னுரிமைக் கொள்கைகள் ஒவ்வொன்றிற்கும் என்ன குறிப்பிட்ட எடைகள் ஒதுக்கப்பட்டுள்ளன என்பது பற்றிய தகவல் இதில் இல்லை. நீங்கள் எடைகளைக் காணலாம் அல்லது இயல்புநிலை kube-திட்டமிடலின் கொள்கைகளைத் திருத்தலாம் மூல குறியீடுகள்.

ImageLocalityPriority கொள்கையின்படி ஒரு முனை புள்ளிகளைப் பெறவில்லை என்பதை எங்களால் பதிவுசெய்ய முடிந்தது என்பது கவனிக்கத்தக்கது, இது பயன்பாட்டை இயக்குவதற்குத் தேவையான படத்தை ஏற்கனவே வைத்திருந்தால், ஒரு முனையை அது சுட்டிக்காட்டுகிறது. அதாவது, பயன்பாட்டின் புதிய பதிப்பு வெளியிடப்பட்ட நேரத்தில், கிரான் பணி இரண்டு முனைகளில் இயங்க முடிந்தது, டோக்கர் பதிவேட்டில் இருந்து ஒரு புதிய படத்தைப் பதிவிறக்குகிறது, இதனால் இரண்டு முனைகள் மூன்றாவதாக ஒப்பிடும்போது அதிக இறுதி மதிப்பெண்ணைப் பெற்றன. .

நான் மேலே எழுதியது போல், பதிவுகளில் ImageLocalityPriority கொள்கையின் மதிப்பீடு பற்றிய தகவலைப் பார்க்க முடியாது, எனவே எங்கள் அனுமானத்தைச் சரிபார்க்க, பயன்பாட்டின் புதிய பதிப்பைக் கொண்ட படத்தை மூன்றாவது முனையில் கொட்டினோம், அதன் பிறகு திட்டமிடல் சரியாக வேலை செய்தது. . துல்லியமாக ImageLocalityPriority கொள்கையின் காரணமாக, திட்டமிடல் பிரச்சனை மிகவும் அரிதாகவே காணப்பட்டது; பெரும்பாலும் இது வேறு ஏதாவது தொடர்புடையதாக இருந்தது. இயல்புநிலை kube-Scheduler இன் முன்னுரிமைகள் பட்டியலில் உள்ள கொள்கைகள் ஒவ்வொன்றையும் எங்களால் முழுமையாக பிழைத்திருத்த முடியவில்லை என்ற உண்மையின் காரணமாக, பாட் திட்டமிடல் கொள்கைகளின் நெகிழ்வான மேலாண்மை தேவைப்பட்டது.

பிரச்சனை அறிக்கை

சிக்கலுக்கான தீர்வு முடிந்தவரை குறிப்பிட்டதாக இருக்க வேண்டும் என்று நாங்கள் விரும்புகிறோம், அதாவது, குபெர்னெட்டஸின் முக்கிய நிறுவனங்கள் (இங்கு இயல்புநிலை kube-scheduler என்று அர்த்தம்) மாறாமல் இருக்க வேண்டும். ஒரு இடத்தில் பிரச்சனையை தீர்த்துவிட்டு அதை இன்னொரு இடத்தில் உருவாக்க நாங்கள் விரும்பவில்லை. எனவே, சிக்கலைத் தீர்ப்பதற்கான இரண்டு விருப்பங்களுக்கு நாங்கள் வந்தோம், அவை கட்டுரையின் அறிமுகத்தில் அறிவிக்கப்பட்டன - கூடுதல் திட்டமிடலை உருவாக்குதல் அல்லது சொந்தமாக எழுதுதல். கிரான் பணிகளை திட்டமிடுவதற்கான முக்கிய தேவை மூன்று முனைகளில் சுமைகளை சமமாக விநியோகிப்பதாகும். தற்போதுள்ள kube-scheduler கொள்கைகளால் இந்தத் தேவையைப் பூர்த்தி செய்ய முடியும், எனவே எங்கள் சிக்கலைத் தீர்க்க உங்கள் சொந்த திட்டமிடலை எழுதுவதில் எந்தப் பயனும் இல்லை.

கூடுதல் க்யூப்-திட்டமிடுதலை உருவாக்கி பயன்படுத்துவதற்கான வழிமுறைகள் விவரிக்கப்பட்டுள்ளன ஆவணங்கள். எவ்வாறாயினும், kube-scheduler போன்ற முக்கியமான சேவையின் செயல்பாட்டில் தவறு சகிப்புத்தன்மையை உறுதிசெய்ய வரிசைப்படுத்தல் நிறுவனம் போதுமானதாக இல்லை என்று எங்களுக்குத் தோன்றியது, எனவே ஒரு புதிய kube-scheduler ஐ Static Pod ஆக பயன்படுத்த முடிவு செய்தோம், இது நேரடியாக கண்காணிக்கப்படும். குபேலேட்டால். எனவே, புதிய kube-schedulerக்கான பின்வரும் தேவைகள் எங்களிடம் உள்ளன:

இந்த சேவையானது அனைத்து கிளஸ்டர் மாஸ்டர்களிலும் ஸ்டேடிக் பாடாக பயன்படுத்தப்பட வேண்டும்
க்யூப்-ஷெட்யூலருடன் செயலில் உள்ள பாட் கிடைக்கவில்லை என்றால் தவறு சகிப்புத்தன்மை வழங்கப்பட வேண்டும்
திட்டமிடும் போது முக்கிய முன்னுரிமை முனையில் கிடைக்கும் ஆதாரங்களின் எண்ணிக்கையாக இருக்க வேண்டும் (குறைந்த கோரிக்கை முன்னுரிமை)

நடைமுறை தீர்வுகள்

Kubernetes v1.14.7 இல் அனைத்து வேலைகளையும் நாங்கள் மேற்கொள்வோம் என்பது இப்போதே கவனிக்கத்தக்கது. இது திட்டத்தில் பயன்படுத்தப்பட்ட பதிப்பு. எங்களின் புதிய kube-schedulerக்கான அறிக்கையை எழுதுவதன் மூலம் ஆரம்பிக்கலாம். இயல்புநிலை மேனிஃபெஸ்டை (/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 இயல்புநிலை kube-scheduler (10251 மற்றும் 10259) போன்ற அதே போர்ட்களை எங்களால் பயன்படுத்த முடியாது.
--config அளவுருவைப் பயன்படுத்தி, சேவை தொடங்கப்பட வேண்டிய கட்டமைப்பு கோப்பைக் குறிப்பிட்டோம்.
உள்ளமைவு கோப்பின் கட்டமைக்கப்பட்ட மவுண்டிங் (scheduler-custom.conf) மற்றும் ஹோஸ்டில் இருந்து கொள்கை கோப்பு (scheduler-custom-policy-config.json) திட்டமிடல்

எங்களின் kube-schedulerக்கு இயல்புநிலையைப் போன்ற உரிமைகள் தேவைப்படும் என்பதை மறந்துவிடாதீர்கள். அதன் கிளஸ்டர் பாத்திரத்தை திருத்தவும்:

kubectl edit clusterrole system:kube-scheduler

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

இப்போது உள்ளமைவு கோப்பு மற்றும் திட்டமிடல் கொள்கை கோப்பில் என்ன இருக்க வேண்டும் என்பதைப் பற்றி பேசலாம்:

கட்டமைப்பு கோப்பு (scheduler-custom.conf)
இயல்புநிலை kube-திட்டமிடல் உள்ளமைவைப் பெற, நீங்கள் அளவுருவைப் பயன்படுத்த வேண்டும் --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"

முக்கிய மாற்றங்களைப் பற்றி சுருக்கமாக:

எங்கள் kube-scheduler-cron சேவையின் பெயருக்கு திட்டமிடல் பெயரை அமைத்துள்ளோம்.
அளவுருவில் lockObjectName நீங்கள் எங்கள் சேவையின் பெயரை அமைக்க வேண்டும் மற்றும் அளவுருவை உறுதி செய்ய வேண்டும் leaderElect உண்மைக்கு அமைக்கவும் (உங்களிடம் ஒரு முதன்மை முனை இருந்தால், அதை நீங்கள் தவறானதாக அமைக்கலாம்).
அளவுருவில் திட்டமிடல் கொள்கைகளின் விளக்கத்துடன் கோப்பிற்கான பாதையைக் குறிப்பிடுகிறது algorithmSource.

விசைக்கான அளவுருக்களை நாங்கள் திருத்தும் இரண்டாவது புள்ளியை உன்னிப்பாகக் கவனிப்பது மதிப்பு leaderElection. தவறு சகிப்புத்தன்மையை உறுதிப்படுத்த, நாங்கள் இயக்கியுள்ளோம் (leaderElect) எங்கள் குபே-திட்டமிடுபவர்களின் காய்களுக்கு இடையே ஒரு தலைவரை (மாஸ்டர்) தேர்ந்தெடுக்கும் செயல்முறை அவற்றுக்கான ஒற்றை இறுதிப் புள்ளியைப் பயன்படுத்தி (resourceLockkube-scheduler-cron என பெயரிடப்பட்டது (lockObjectName) kube-system பெயர்வெளியில் (lockObjectNamespace) முக்கிய கூறுகள் (குபே-செட்யூலர் உட்பட) அதிக அளவில் கிடைப்பதை குபெர்னெட்டஸ் எவ்வாறு உறுதிசெய்கிறது என்பதைக் காணலாம் கட்டுரை.

திட்டமிடல் கொள்கை கோப்பு (scheduler-custom-policy-config.json)
நான் முன்பு எழுதியது போல், இயல்புநிலை kube-scheduler எந்த குறிப்பிட்ட கொள்கைகளுடன் செயல்படுகிறது என்பதை அதன் குறியீட்டை பகுப்பாய்வு செய்வதன் மூலம் மட்டுமே கண்டறிய முடியும். அதாவது, உள்ளமைவு கோப்பைப் போலவே, இயல்புநிலை kube-திட்டமிடலுக்கான திட்டமிடல் கொள்கைகளைக் கொண்ட கோப்பை எங்களால் பெற முடியாது. /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 இன் மேனிஃபெஸ்ட்டை, kube-scheduler-custom.yaml என்று அழைப்போம், அதை பின்வரும் பாதையில் /etc/kubernetes/manifests மூன்று முதன்மை முனைகளில் வைப்போம். எல்லாவற்றையும் சரியாகச் செய்தால், குபெலெட் ஒவ்வொரு முனையிலும் ஒரு பாட் ஒன்றைத் தொடங்கும், மேலும் எங்கள் புதிய kube-scheduler இன் பதிவுகளில் எங்கள் கொள்கைக் கோப்பு வெற்றிகரமாகப் பயன்படுத்தப்பட்ட தகவலைக் காண்போம்:

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 இன் விவரக்குறிப்பில், அதன் காய்களை திட்டமிடுவதற்கான அனைத்து கோரிக்கைகளும் எங்கள் புதிய kube-scheduler மூலம் செயல்படுத்தப்பட வேண்டும்:

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

முடிவுக்கு

இறுதியில், க்யூப்லெட் மூலம் நேரடியாகக் கண்காணிக்கப்படும் தனிப்பட்ட திட்டமிடல் கொள்கைகளுடன் கூடிய கூடுதல் க்யூப்-திட்டமிடலைப் பெற்றுள்ளோம். கூடுதலாக, சில காரணங்களால் பழைய தலைவர் கிடைக்காமல் போனால், எங்கள் குபே-திட்டமிட்டவரின் காய்களுக்கு இடையே புதிய தலைவரைத் தேர்ந்தெடுப்பதை நாங்கள் அமைத்துள்ளோம்.

வழக்கமான பயன்பாடுகள் மற்றும் சேவைகள் இயல்புநிலை kube-scheduler மூலம் தொடர்ந்து திட்டமிடப்படும், மேலும் அனைத்து கிரான் பணிகளும் முற்றிலும் புதிய ஒன்றிற்கு மாற்றப்பட்டுள்ளன. கிரான் பணிகளால் உருவாக்கப்பட்ட சுமை இப்போது அனைத்து முனைகளிலும் சமமாக விநியோகிக்கப்படுகிறது. பெரும்பாலான கிரான் பணிகள் திட்டத்தின் முக்கிய பயன்பாடுகளின் அதே முனைகளில் செயல்படுத்தப்படுவதைக் கருத்தில் கொண்டு, இது வளங்களின் பற்றாக்குறையால் காய்களை நகர்த்துவதற்கான அபாயத்தை கணிசமாகக் குறைத்துள்ளது. கூடுதல் க்யூப்-திட்டமிடுதலை அறிமுகப்படுத்திய பிறகு, கிரான் பணிகளின் சீரற்ற திட்டமிடலில் சிக்கல்கள் எழவில்லை.

எங்கள் வலைப்பதிவில் உள்ள மற்ற கட்டுரைகளையும் படிக்கவும்:

ஆதாரம்: www.habr.com

திட்டமிடல் விதிகளின் தனிப்பயன் தொகுப்புடன் கூடுதல் kube-திட்டமிடலை உருவாக்குதல்