🥇បង្កើតកម្មវិធីកំណត់ពេលវេលា kube បន្ថែមជាមួយនឹងសំណុំនៃច្បាប់កំណត់កាលវិភាគ

Kube-scheduler គឺជាសមាសធាតុសំខាន់មួយនៃ Kubernetes ដែលទទួលខុសត្រូវក្នុងការកំណត់កាលវិភាគ pods នៅទូទាំង nodes ដោយអនុលោមតាមគោលការណ៍ដែលបានបញ្ជាក់។ ជាញឹកញយ ក្នុងអំឡុងពេលប្រតិបត្តិការនៃចង្កោម Kubernetes យើងមិនចាំបាច់គិតអំពីគោលការណ៍ណាមួយដែលត្រូវបានប្រើដើម្បីកំណត់កាលវិភាគផតទេ ដោយសារសំណុំនៃគោលការណ៍នៃកម្មវិធីកំណត់ពេលវេលា kube-default គឺសមរម្យសម្រាប់កិច្ចការប្រចាំថ្ងៃភាគច្រើន។ ទោះយ៉ាងណាក៏ដោយ មានស្ថានភាពនៅពេលដែលវាមានសារៈសំខាន់សម្រាប់យើងក្នុងការកែសម្រួលដំណើរការនៃការបែងចែកផត ហើយមានវិធីពីរយ៉ាងដើម្បីសម្រេចកិច្ចការនេះ៖

បង្កើតកម្មវិធីកំណត់ពេលវេលា kube ជាមួយនឹងសំណុំច្បាប់ផ្ទាល់ខ្លួន
សរសេរកម្មវិធីកំណត់ពេលផ្ទាល់ខ្លួនរបស់អ្នក ហើយបង្រៀនវាឱ្យធ្វើការជាមួយសំណើម៉ាស៊ីនមេ API

នៅក្នុងអត្ថបទនេះ ខ្ញុំនឹងរៀបរាប់អំពីការអនុវត្តចំណុចទីមួយ ដើម្បីដោះស្រាយបញ្ហានៃការកំណត់ពេលមិនស្មើគ្នានៃ hearth លើគម្រោងមួយរបស់យើង។

ការណែនាំខ្លីៗអំពីរបៀបដែល kube-scheduler ដំណើរការ

វាគួរឱ្យកត់សម្គាល់ជាពិសេសចំពោះការពិតដែលថា kube-scheduler មិនទទួលខុសត្រូវចំពោះការកំណត់កាលវិភាគដោយផ្ទាល់ទេ - វាទទួលខុសត្រូវតែក្នុងការកំណត់ថ្នាំងដែលត្រូវដាក់ pods ប៉ុណ្ណោះ។ ម្យ៉ាងវិញទៀត លទ្ធផលនៃការងាររបស់ kube-scheduler គឺជាឈ្មោះថ្នាំង ដែលវាត្រឡប់ទៅម៉ាស៊ីនមេ API សម្រាប់ការស្នើសុំកំណត់ពេល ហើយនោះជាកន្លែងដែលការងាររបស់វាបញ្ចប់។

ដំបូង kube-scheduler ចងក្រងបញ្ជីថ្នាំងដែល pod អាចត្រូវបានកំណត់ពេលដោយអនុលោមតាមគោលការណ៍ predicates ។ បន្ទាប់មក ថ្នាំងនីមួយៗពីបញ្ជីនេះទទួលបានពិន្ទុជាក់លាក់មួយស្របតាមគោលការណ៍អាទិភាព។ ជាលទ្ធផល ថ្នាំងដែលមានចំនួនពិន្ទុអតិបរមាត្រូវបានជ្រើសរើស។ ប្រសិនបើមានថ្នាំងដែលមានពិន្ទុអតិបរមាដូចគ្នា ចៃដន្យមួយត្រូវបានជ្រើសរើស។ បញ្ជី និងការពិពណ៌នាអំពីគោលការណ៍ព្យាករណ៍ (ការត្រង) និងអាទិភាព (ការដាក់ពិន្ទុ) អាចរកបាននៅក្នុង ឯកសារ.

ការពិពណ៌នាអំពីរាងកាយបញ្ហា

ទោះបីជាមានចង្កោម Kubernetes ផ្សេងៗគ្នាជាច្រើនដែលកំពុងត្រូវបានរក្សានៅ Nixys ក៏ដោយ ក៏ដំបូងឡើយ យើងបានជួបប្រទះបញ្ហានៃការកំណត់កាលវិភាគនៅពេលថ្មីៗនេះ នៅពេលដែលគម្រោងមួយរបស់យើងត្រូវការដើម្បីដំណើរការកិច្ចការតាមកាលកំណត់មួយចំនួនធំ (~100 CronJob entities)។ ដើម្បីសម្រួលការពិពណ៌នាអំពីបញ្ហាឱ្យបានច្រើនតាមតែអាចធ្វើទៅបាន យើងនឹងលើកឧទាហរណ៍មួយ មីក្រូសឺវីស ដែលនៅក្នុងនោះកិច្ចការ cron ត្រូវបានដាក់ឱ្យដំណើរការម្តងក្នុងមួយនាទី ដោយបង្កើតបន្ទុកខ្លះនៅលើស៊ីភីយូ។ ដើម្បីដំណើរការកិច្ចការ cron ថ្នាំងបីដែលមានលក្ខណៈដូចគ្នាបេះបិទត្រូវបានបែងចែក (24 vCPUs នៅលើនីមួយៗ)។

ក្នុងពេលជាមួយគ្នានេះ វាមិនអាចទៅរួចទេក្នុងការនិយាយដោយភាពត្រឹមត្រូវថាតើរយៈពេលប៉ុន្មានដែល CronJob នឹងត្រូវអនុវត្តព្រោះថាបរិមាណនៃទិន្នន័យបញ្ចូលកំពុងផ្លាស់ប្តូរឥតឈប់ឈរ។ ជាមធ្យមក្នុងអំឡុងពេលប្រតិបត្តិការធម្មតារបស់ kube-scheduler ថ្នាំងនីមួយៗដំណើរការការងារ 3-4 ដែលបង្កើត ~ 20-30% នៃបន្ទុកនៅលើ CPU នៃ node នីមួយៗ៖

បញ្ហាដោយខ្លួនវាគឺថាពេលខ្លះ cron task pods ឈប់ត្រូវបានកំណត់ពេលនៅលើថ្នាំងមួយក្នុងចំណោមថ្នាំងទាំងបី។ នោះគឺនៅពេលណាមួយនោះ មិនមានផតតែមួយត្រូវបានគ្រោងទុកសម្រាប់ថ្នាំងមួយទេ ខណៈដែលនៅលើថ្នាំងពីរផ្សេងទៀត 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

វាអាចត្រូវបានគេមើលឃើញថាថ្នាំងមួយក្នុងចំណោមថ្នាំងទទួលបានពិន្ទុចុងក្រោយតិចជាងចំណុចផ្សេងទៀត ហើយដូច្នេះការគ្រោងទុកត្រូវបានអនុវត្តសម្រាប់តែថ្នាំងពីរប៉ុណ្ណោះដែលទទួលបានពិន្ទុអតិបរមា។ ដូច្នេះហើយ យើងពិតជាជឿជាក់ថា បញ្ហាគឺស្ថិតនៅលើការកំណត់ពេលវេលានៃកម្មវិធី។

ក្បួនដោះស្រាយបន្ថែមទៀតសម្រាប់ការដោះស្រាយបញ្ហាគឺជាក់ស្តែងសម្រាប់ពួកយើង - វិភាគកំណត់ហេតុ ស្វែងយល់ពីអ្វីដែលជាអាទិភាពដែលថ្នាំងមិនទទួលបានពិន្ទុ ហើយប្រសិនបើចាំបាច់ កែតម្រូវគោលនយោបាយរបស់កម្មវិធីកំណត់ពេលវេលា kube-default ។ ទោះយ៉ាងណាក៏ដោយ នៅទីនេះយើងប្រឈមមុខនឹងការលំបាកសំខាន់ៗចំនួនពីរ៖

នៅកម្រិតនៃការកត់ត្រាអតិបរមា (10) ពិន្ទុដែលទទួលបានសម្រាប់តែអាទិភាពមួយចំនួនត្រូវបានឆ្លុះបញ្ចាំង។ នៅក្នុងការដកស្រង់ខាងលើនៃកំណត់ហេតុ អ្នកអាចមើលឃើញថាសម្រាប់អាទិភាពទាំងអស់ដែលបានឆ្លុះបញ្ចាំងនៅក្នុងកំណត់ហេតុ ថ្នាំងទទួលបានពិន្ទុដូចគ្នាក្នុងការកំណត់កាលវិភាគធម្មតា និងបញ្ហា ប៉ុន្តែលទ្ធផលចុងក្រោយនៅក្នុងករណីនៃការរៀបចំផែនការបញ្ហាគឺខុសគ្នា។ ដូច្នេះហើយ យើងអាចសន្និដ្ឋានបានថា សម្រាប់អាទិភាពមួយចំនួន ការដាក់ពិន្ទុកើតឡើង "នៅពីក្រោយឆាក" ហើយយើងមិនមានវិធីយល់ថា អាទិភាពណាដែលថ្នាំងមិនទទួលបានពិន្ទុនោះទេ។ យើងបានពិពណ៌នាអំពីបញ្ហានេះយ៉ាងលំអិតនៅក្នុង issue ឃ្លាំង Kubernetes នៅលើ Github ។ នៅពេលសរសេរ ការឆ្លើយតបត្រូវបានទទួលពីអ្នកអភិវឌ្ឍន៍ថា ការគាំទ្រការកត់ត្រានឹងត្រូវបានបន្ថែមនៅក្នុងការអាប់ដេត Kubernetes v1.15,1.16, 1.17 និង XNUMX ។
មិនមានវិធីងាយស្រួលក្នុងការយល់ថាតើការកំណត់ជាក់លាក់ណាមួយនៃគោលនយោបាយ kube-scheduler បច្ចុប្បន្នកំពុងធ្វើការជាមួយនោះទេ។ បាទ នៅ ឯកសារ បញ្ជីនេះត្រូវបានរាយបញ្ជី ប៉ុន្តែវាមិនមានព័ត៌មានអំពីទម្ងន់ជាក់លាក់ណាមួយដែលត្រូវបានកំណត់ចំពោះគោលការណ៍អាទិភាពនីមួយៗនោះទេ។ អ្នកអាចមើលឃើញទម្ងន់ ឬកែសម្រួលគោលការណ៍របស់កម្មវិធីកំណត់កាលកំណត់ kube-schedule លំនាំដើមតែក្នុងប៉ុណ្ណោះ។ កូដប្រភព.

គួរកត់សម្គាល់ថានៅពេលដែលយើងអាចកត់ត្រាថាថ្នាំងមិនបានទទួលពិន្ទុយោងទៅតាមគោលការណ៍ ImageLocalityPriority ដែលផ្តល់រង្វាន់ចង្អុលទៅថ្នាំងប្រសិនបើវាមានរូបភាពដែលចាំបាច់សម្រាប់ដំណើរការកម្មវិធីរួចហើយ។ នោះគឺនៅពេលកំណែថ្មីនៃកម្មវិធីត្រូវបានដាក់ឱ្យដំណើរការ កិច្ចការ cron បានគ្រប់គ្រងដើម្បីដំណើរការលើថ្នាំងពីរ ដោយទាញយករូបភាពថ្មីពីបញ្ជីឈ្មោះ docker ទៅកាន់ពួកគេ ហើយដូច្នេះថ្នាំងពីរបានទទួលពិន្ទុចុងក្រោយខ្ពស់ជាងទាក់ទងទៅនឹងទីបី។ .

ដូចដែលខ្ញុំបានសរសេរខាងលើ នៅក្នុងកំណត់ហេតុ យើងមិនឃើញព័ត៌មានអំពីការវាយតម្លៃនៃគោលនយោបាយ ImageLocalityPriority ដូច្នេះដើម្បីពិនិត្យមើលការសន្មត់របស់យើង យើងបានបោះចោលរូបភាពជាមួយនឹងកំណែថ្មីនៃកម្មវិធីទៅលើថ្នាំងទីបី បន្ទាប់ពីនោះកាលវិភាគដំណើរការបានត្រឹមត្រូវ។ . វាច្បាស់ណាស់ដោយសារតែគោលការណ៍នៃ ImageLocalityPriority ដែលបញ្ហាកំណត់ពេលត្រូវបានគេសង្កេតឃើញកម្រណាស់ ជាញឹកញាប់វាត្រូវបានភ្ជាប់ជាមួយអ្វីផ្សេងទៀត។ ដោយសារតែការពិតដែលថាយើងមិនអាចបំបាត់កំហុសទាំងស្រុងនូវគោលការណ៍នីមួយៗនៅក្នុងបញ្ជីអាទិភាពនៃកម្មវិធីកំណត់ពេលវេលា kube លំនាំដើម យើងមានតម្រូវការសម្រាប់ការគ្រប់គ្រងដែលអាចបត់បែនបាននៃគោលការណ៍កំណត់ពេល pod ។

ការបង្កើតបញ្ហា

យើងចង់ឱ្យដំណោះស្រាយចំពោះបញ្ហាមានភាពជាក់លាក់តាមដែលអាចធ្វើបាន ពោលគឺអង្គភាពសំខាន់របស់ Kubernetes (នៅទីនេះយើងមានន័យថា default kube-scheduler) គួរតែនៅតែមិនផ្លាស់ប្តូរ។ យើងមិនចង់ដោះស្រាយបញ្ហានៅកន្លែងមួយ ហើយបង្កើតវានៅកន្លែងផ្សេងទេ។ ដូច្នេះហើយ យើងបានមកដល់ជម្រើសពីរសម្រាប់ការដោះស្រាយបញ្ហា ដែលត្រូវបានប្រកាសនៅក្នុងការណែនាំអំពីអត្ថបទ - បង្កើតកម្មវិធីកំណត់ពេលបន្ថែម ឬសរសេរដោយខ្លួនឯង។ តម្រូវការចម្បងសម្រាប់កំណត់ពេលភារកិច្ច cron គឺត្រូវចែកចាយបន្ទុកឱ្យស្មើៗគ្នាលើថ្នាំងបី។ តម្រូវការនេះអាចបំពេញបានដោយគោលការណ៍កម្មវិធីកំណត់ពេលវេលា kube ដែលមានស្រាប់ ដូច្នេះដើម្បីដោះស្រាយបញ្ហារបស់យើង វាគ្មានចំណុចណាក្នុងការសរសេរកម្មវិធីកំណត់ពេលផ្ទាល់ខ្លួនរបស់អ្នកទេ។

សេចក្តីណែនាំសម្រាប់បង្កើត និងដាក់ពង្រាយកម្មវិធីកំណត់ពេលវេលា kube បន្ថែមត្រូវបានពិពណ៌នានៅក្នុង ឯកសារ. ទោះបីជាយ៉ាងណាក៏ដោយ វាហាក់បីដូចជាពួកយើងដែលអង្គភាពដាក់ពង្រាយមិនគ្រប់គ្រាន់ដើម្បីធានាបាននូវការអត់ឱនចំពោះកំហុសក្នុងប្រតិបត្តិការនៃសេវាកម្មសំខាន់ដូចជា kube-scheduler ដូច្នេះយើងបានសម្រេចចិត្តដាក់ពង្រាយកម្មវិធី cube-scheduler ថ្មីមួយជា Static Pod ដែលនឹងត្រូវបានត្រួតពិនិត្យដោយផ្ទាល់។ ដោយ Kubelet ។ ដូច្នេះ យើងមានតម្រូវការដូចខាងក្រោមសម្រាប់កម្មវិធីកំណត់ពេលវេលា kube ថ្មី៖

សេវាកម្មនេះត្រូវតែដាក់ឱ្យប្រើប្រាស់ជា Static Pod លើអ្នកគ្រប់គ្រងចង្កោមទាំងអស់។
ការអត់ឱនចំពោះកំហុសត្រូវតែផ្តល់ជូនក្នុងករណីដែលផតសកម្មជាមួយឧបករណ៍កំណត់ពេលវេលា kube មិនអាចប្រើបាន
អាទិភាពចម្បងនៅពេលធ្វើផែនការគួរតែជាចំនួនធនធានដែលមាននៅលើថ្នាំង (LeastRequestedPriority)

ដំណោះស្រាយការអនុវត្ត

វាគួរឱ្យកត់សម្គាល់ភ្លាមៗថាយើងនឹងអនុវត្តការងារទាំងអស់នៅក្នុង Kubernetes v1.14.7 ពីព្រោះ នេះគឺជាកំណែដែលត្រូវបានប្រើនៅក្នុងគម្រោង។ ចូរចាប់ផ្តើមដោយការសរសេរ manifesto សម្រាប់កម្មវិធី kube-scheduler ថ្មីរបស់យើង។ ចូរយកលំនាំដើម manifest (/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 ហើយយើងមិនអាចប្រើច្រកដូចគ្នានឹង default kube-scheduler (10251 និង 10259)
ដោយប្រើប៉ារ៉ាម៉ែត្រ --config យើងបានបញ្ជាក់ឯកសារកំណត់រចនាសម្ព័ន្ធដែលសេវាកម្មគួរតែត្រូវបានចាប់ផ្តើម
ការដំឡើងឯកសារកំណត់រចនាសម្ព័ន្ធ (scheduler-custom.conf) និងឯកសារគោលការណ៍កំណត់ពេល (scheduler-custom-policy-config.json) ពីម៉ាស៊ីន

កុំភ្លេចថាកម្មវិធីកំណត់ពេលវេលា kube របស់យើងនឹងត្រូវការសិទ្ធិស្រដៀងនឹងលំនាំដើម។ កែសម្រួលតួនាទីចង្កោមរបស់វា៖

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"

សង្ខេបអំពីការផ្លាស់ប្តូរសំខាន់ៗ៖

យើងកំណត់ឈ្មោះកម្មវិធីកំណត់ពេលទៅជាឈ្មោះសេវាកម្ម kube-scheduler-cron របស់យើង។
នៅក្នុងប៉ារ៉ាម៉ែត្រ lockObjectName អ្នកក៏ត្រូវកំណត់ឈ្មោះសេវាកម្មរបស់យើង ហើយត្រូវប្រាកដថាប៉ារ៉ាម៉ែត្រនោះ។ leaderElect កំណត់ទៅពិត (ប្រសិនបើអ្នកមានថ្នាំងមេតែមួយ អ្នកអាចកំណត់វាទៅជាមិនពិត)។
បញ្ជាក់ផ្លូវទៅកាន់ឯកសារជាមួយនឹងការពិពណ៌នាអំពីគោលការណ៍កំណត់ពេលក្នុងប៉ារ៉ាម៉ែត្រ algorithmSource.

វាមានតម្លៃក្នុងការពិនិត្យមើលឱ្យកាន់តែដិតដល់នូវចំណុចទីពីរ ដែលយើងកែសម្រួលប៉ារ៉ាម៉ែត្រសម្រាប់សោ leaderElection. ដើម្បីធានាបាននូវការអត់ឱនចំពោះកំហុស យើងបានបើក (leaderElect(resourceLock) ដែលមានឈ្មោះថា kube-scheduler-cron (lockObjectName) នៅក្នុងលំហឈ្មោះប្រព័ន្ធ kube (lockObjectNamespace) របៀបដែល Kubernetes ធានាភាពអាចរកបានខ្ពស់នៃសមាសធាតុសំខាន់ៗ (រួមទាំងកម្មវិធីកំណត់ពេល kube) អាចរកបាននៅក្នុង អត្ថបទ.

ឯកសារគោលនយោបាយកំណត់ពេល (scheduler-custom-policy-config.json)
ដូចដែលខ្ញុំបានសរសេរមុននេះ យើងអាចស្វែងយល់ថាតើគោលការណ៍ជាក់លាក់ណាមួយដែលកម្មវិធីកំណត់ពេល kube-scheduler លំនាំដើមដំណើរការដោយគ្រាន់តែវិភាគកូដរបស់វាប៉ុណ្ណោះ។ នោះគឺយើងមិនអាចទទួលបានឯកសារដែលមានគោលការណ៍កំណត់ពេលសម្រាប់កម្មវិធីកំណត់ពេលវេលា kube-scheduler លំនាំដើមតាមរបៀបដូចគ្នានឹងឯកសារកំណត់រចនាសម្ព័ន្ធនោះទេ។ ចូរពណ៌នាអំពីគោលការណ៍កំណត់ពេលដែលយើងចាប់អារម្មណ៍នៅក្នុងឯកសារ /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 policy)។ ហើយបន្ទាប់មកថ្នាំងនីមួយៗត្រូវបានវាយតម្លៃដោយអនុលោមតាមការកំណត់គោលនយោបាយនៅក្នុងអារេអាទិភាព។ ដើម្បីបំពេញលក្ខខណ្ឌនៃកិច្ចការរបស់យើង យើងបានពិចារណាថា សំណុំនៃគោលនយោបាយបែបនេះ គឺជាដំណោះស្រាយដ៏ប្រសើរបំផុត។ ខ្ញុំសូមរំលឹកអ្នកថា សំណុំនៃគោលការណ៍ជាមួយនឹងការពិពណ៌នាលម្អិតរបស់ពួកគេមាននៅក្នុង ឯកសារ. ដើម្បីសម្រេចកិច្ចការរបស់អ្នក អ្នកគ្រាន់តែអាចផ្លាស់ប្តូរសំណុំគោលការណ៍ដែលបានប្រើ និងកំណត់ទម្ងន់សមស្របទៅពួកគេ។

ចូរហៅ manifest នៃ kube-scheduler ថ្មីដែលយើងបានបង្កើតនៅដើមជំពូក kube-scheduler-custom.yaml ហើយដាក់វាក្នុងផ្លូវខាងក្រោម /etc/kubernetes/manifests លើថ្នាំងមេបី។ ប្រសិនបើអ្វីៗគ្រប់យ៉ាងត្រូវបានធ្វើបានត្រឹមត្រូវ Kubelet នឹងបើកដំណើរការផតនៅលើថ្នាំងនីមួយៗ ហើយនៅក្នុងកំណត់ហេតុនៃកម្មវិធីកំណត់ពេលវេលា kube ថ្មីរបស់យើង យើងនឹងឃើញព័ត៌មានដែលឯកសារគោលការណ៍របស់យើងត្រូវបានអនុវត្តដោយជោគជ័យ៖

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 របស់យើងថារាល់សំណើសម្រាប់ការកំណត់ពេល pods របស់វាគួរតែត្រូវបានដំណើរការដោយកម្មវិធី kube-scheduler ថ្មីរបស់យើង:

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

សេចក្តីសន្និដ្ឋាន

នៅទីបំផុត យើងទទួលបានកម្មវិធីកំណត់ពេលវេលា kube បន្ថែមជាមួយនឹងសំណុំគោលការណ៍កំណត់ពេលវេលាតែមួយគត់ ដែលការងារនេះត្រូវបានត្រួតពិនិត្យដោយផ្ទាល់ដោយ kubelet ។ លើសពីនេះ យើងបានរៀបចំការបោះឆ្នោតជ្រើសរើសមេដឹកនាំថ្មីរវាងអ្នករៀបចំកម្មវិធី kube-scheduler របស់យើង ក្នុងករណីដែលមេដឹកនាំចាស់មិនអាចប្រើបានដោយហេតុផលមួយចំនួន។

កម្មវិធី និងសេវាកម្មធម្មតាបន្តត្រូវបានកំណត់ពេលតាមរយៈកម្មវិធី kube-scheduler លំនាំដើម ហើយកិច្ចការ cron ទាំងអស់ត្រូវបានផ្ទេរទាំងស្រុងទៅកម្មវិធីថ្មី។ បន្ទុកដែលបង្កើតឡើងដោយកិច្ចការ cron ឥឡូវនេះត្រូវបានចែកចាយស្មើៗគ្នានៅទូទាំងថ្នាំងទាំងអស់។ ដោយពិចារណាថាកិច្ចការ cron ភាគច្រើនត្រូវបានប្រតិបត្តិនៅលើថ្នាំងដូចគ្នាទៅនឹងកម្មវិធីសំខាន់នៃគម្រោង នេះបានកាត់បន្ថយហានិភ័យនៃការផ្លាស់ទី pods យ៉ាងខ្លាំងដោយសារតែកង្វះធនធាន។ បន្ទាប់ពីណែនាំកម្មវិធីកំណត់ពេលវេលា kube បន្ថែម បញ្ហាជាមួយនឹងការកំណត់ពេលមិនស្មើគ្នានៃកិច្ចការ cron លែងកើតឡើងទៀតហើយ។

សូមអានអត្ថបទផ្សេងទៀតនៅលើប្លក់របស់យើងផងដែរ៖

ប្រភព: www.habr.com

ការបង្កើតកម្មវិធីកំណត់ពេលវេលា kube បន្ថែមជាមួយនឹងសំណុំច្បាប់កំណត់ពេលវេលាផ្ទាល់ខ្លួន