ການສ້າງຕົວກໍານົດເວລາ kube ເພີ່ມເຕີມດ້ວຍຊຸດກົດລະບຽບການກໍານົດເວລາ

Kube-scheduler ເປັນອົງປະກອບທີ່ສໍາຄັນຂອງ Kubernetes, ເຊິ່ງຮັບຜິດຊອບສໍາລັບການກໍານົດເວລາ pods ໃນທົ່ວ nodes ຕາມນະໂຍບາຍທີ່ກໍານົດໄວ້. ເລື້ອຍໆ, ໃນລະຫວ່າງການປະຕິບັດງານຂອງກຸ່ມ Kubernetes, ພວກເຮົາບໍ່ຈໍາເປັນຕ້ອງຄິດກ່ຽວກັບນະໂຍບາຍໃດທີ່ຖືກນໍາໃຊ້ເພື່ອຈັດຕາຕະລາງ pods, ເນື່ອງຈາກວ່າຊຸດນະໂຍບາຍຂອງ kube-scheduler ເລີ່ມຕົ້ນແມ່ນເຫມາະສົມສໍາລັບວຽກງານປະຈໍາວັນສ່ວນໃຫຍ່. ຢ່າງໃດກໍ່ຕາມ, ມີສະຖານະການໃນເວລາທີ່ມັນສໍາຄັນສໍາລັບພວກເຮົາທີ່ຈະປັບຂະບວນການຈັດສັນຝັກ, ແລະມີສອງວິທີທີ່ຈະເຮັດສໍາເລັດວຽກງານນີ້:

1. ສ້າງຕົວກໍານົດເວລາ kube ດ້ວຍຊຸດກົດລະບຽບທີ່ກໍາຫນົດເອງ
2. ຂຽນກໍານົດເວລາຂອງທ່ານເອງແລະສອນໃຫ້ມັນເຮັດວຽກກັບການຮ້ອງຂໍຂອງເຄື່ອງແມ່ຂ່າຍ API

ໃນບົດຄວາມນີ້, ຂ້າພະເຈົ້າຈະອະທິບາຍການປະຕິບັດຈຸດທໍາອິດເພື່ອແກ້ໄຂບັນຫາການກໍານົດເວລາທີ່ບໍ່ສະເຫມີກັນຂອງ hearths ໃນໂຄງການຫນຶ່ງຂອງພວກເຮົາ.

ການແນະນໍາສັ້ນໆກ່ຽວກັບວິທີການ kube-scheduler ເຮັດວຽກ

ມັນເປັນມູນຄ່າໂດຍສະເພາະແມ່ນສັງເກດເຫັນຄວາມຈິງທີ່ວ່າ kube-scheduler ບໍ່ຮັບຜິດຊອບສໍາລັບການກໍານົດເວລາຝັກໂດຍກົງ - ມັນເປັນພຽງແຕ່ຮັບຜິດຊອບສໍາລັບການກໍານົດຂໍ້ທີ່ຈະວາງຝັກ. ໃນຄໍາສັບຕ່າງໆອື່ນໆ, ຜົນໄດ້ຮັບຂອງການເຮັດວຽກຂອງ kube-scheduler ແມ່ນຊື່ຂອງ node, ເຊິ່ງມັນກັບຄືນໄປຫາເຄື່ອງແມ່ຂ່າຍຂອງ API ສໍາລັບການຮ້ອງຂໍການກໍານົດເວລາ, ແລະນັ້ນແມ່ນບ່ອນທີ່ການເຮັດວຽກຂອງມັນສິ້ນສຸດລົງ.

ທໍາອິດ, kube-scheduler ລວບລວມບັນຊີລາຍຊື່ຂອງ nodes ທີ່ pod ສາມາດຖືກກໍານົດໂດຍສອດຄ່ອງກັບນະໂຍບາຍ predicates. ຕໍ່ໄປ, ແຕ່ລະ node ຈາກບັນຊີລາຍຊື່ນີ້ໄດ້ຮັບຈໍານວນຈຸດທີ່ແນ່ນອນຕາມນະໂຍບາຍບູລິມະສິດ. ດັ່ງນັ້ນ, node ທີ່ມີຈໍານວນສູງສຸດຂອງຈຸດໄດ້ຖືກເລືອກ. ຖ້າມີ nodes ທີ່ມີຄະແນນສູງສຸດດຽວກັນ, ເປັນອັນສຸ່ມເລືອກ. ບັນຊີລາຍຊື່ແລະລາຍລະອຽດຂອງ predicates (ການກັ່ນຕອງ) ແລະຄວາມສໍາຄັນ (ການໃຫ້ຄະແນນ) ນະໂຍບາຍສາມາດພົບເຫັນຢູ່ໃນ ເອກະສານ.

ລາຍ​ລະ​ອຽດ​ຂອງ​ຮ່າງ​ກາຍ​ຂອງ​ບັນ​ຫາ​

ເຖິງວ່າຈະມີຈໍານວນຫຼາຍຂອງກຸ່ມ Kubernetes ທີ່ແຕກຕ່າງກັນໄດ້ຖືກຮັກສາໄວ້ຢູ່ Nixys, ພວກເຮົາທໍາອິດພົບບັນຫາຂອງການກໍານົດເວລາ pods ພຽງແຕ່ບໍ່ດົນມານີ້, ໃນເວລາທີ່ຫນຶ່ງໃນໂຄງການຂອງພວກເຮົາຈໍາເປັນຕ້ອງດໍາເນີນການຈໍານວນຫຼາຍຂອງວຽກງານແຕ່ລະໄລຍະ (~100 CronJob entities). ເພື່ອເຮັດໃຫ້ລາຍລະອຽດຂອງບັນຫາງ່າຍຂຶ້ນຫຼາຍເທົ່າທີ່ເປັນໄປໄດ້, ພວກເຮົາຈະເອົາເປັນຕົວຢ່າງຫນຶ່ງ microservice, ພາຍໃນທີ່ວຽກງານ cron ໄດ້ຖືກເປີດຕົວຫນຶ່ງຄັ້ງຕໍ່ນາທີ, ການສ້າງການໂຫຼດບາງຢ່າງໃນ CPU. ເພື່ອດໍາເນີນການວຽກງານ cron, ສາມ nodes ທີ່ມີລັກສະນະດຽວກັນຢ່າງແທ້ຈິງໄດ້ຖືກຈັດສັນ (24 vCPUs ໃນແຕ່ລະ).

ໃນເວລາດຽວກັນ, ມັນເປັນໄປບໍ່ໄດ້ທີ່ຈະເວົ້າໄດ້ຢ່າງຖືກຕ້ອງວ່າ CronJob ຈະໃຊ້ເວລາດົນປານໃດເພື່ອປະຕິບັດ, ເນື່ອງຈາກວ່າປະລິມານຂອງຂໍ້ມູນປ້ອນເຂົ້າມີການປ່ຽນແປງຢ່າງຕໍ່ເນື່ອງ. ໂດຍສະເລ່ຍແລ້ວ, ໃນລະຫວ່າງການເຮັດວຽກປົກກະຕິຂອງ kube-scheduler, ແຕ່ລະ node ເຮັດວຽກ 3-4 ຕົວຢ່າງ, ເຊິ່ງສ້າງ ~ 20-30% ຂອງການໂຫຼດໃນ CPU ຂອງແຕ່ລະ node:

ບັນຫາຕົວມັນເອງແມ່ນວ່າບາງຄັ້ງ cron task pods ຢຸດເຊົາການກໍານົດເວລາຫນຶ່ງໃນສາມ nodes. ນັ້ນແມ່ນ, ໃນບາງເວລາ, ບໍ່ແມ່ນຝັກດຽວໄດ້ຖືກວາງແຜນໄວ້ສໍາລັບຫນຶ່ງຂອງ nodes, ໃນຂະນະທີ່ອີກສອງ nodes 6-8 ສໍາເນົາຂອງຫນ້າວຽກກໍາລັງແລ່ນ, ສ້າງ ~ 40-60% ຂອງການໂຫຼດ CPU:

ບັນຫາເກີດຂຶ້ນກັບຄວາມຖີ່ແບບສຸ່ມຢ່າງແທ້ຈິງ ແລະເປັນບາງໂອກາດທີ່ກ່ຽວຂ້ອງກັນກັບຊ່ວງເວລາທີ່ລະຫັດສະບັບໃໝ່ຖືກເປີດຕົວ.

ໂດຍການເພີ່ມລະດັບການບັນທຶກ kube-scheduler ເປັນລະດັບ 10 (-v=10), ພວກເຮົາເລີ່ມບັນທຶກວ່າແຕ່ລະ node ໄດ້ຮັບຫຼາຍປານໃດໃນລະຫວ່າງຂະບວນການປະເມີນຜົນ. ໃນ​ລະ​ຫວ່າງ​ການ​ດໍາ​ເນີນ​ງານ​ການ​ວາງ​ແຜນ​ປົກ​ກະ​ຕິ​, ຂໍ້​ມູນ​ດັ່ງ​ຕໍ່​ໄປ​ນີ້​ສາ​ມາດ​ເຫັນ​ໄດ້​ໃນ​ບັນ​ທຶກ​:

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

ຈາກທີ່ມັນສາມາດເຫັນໄດ້ວ່າຫນຶ່ງໃນ nodes ໄດ້ຄະແນນສຸດທ້າຍຫນ້ອຍກ່ວາອື່ນໆ, ແລະດັ່ງນັ້ນການວາງແຜນໄດ້ຖືກປະຕິບັດພຽງແຕ່ສໍາລັບສອງ nodes ທີ່ໄດ້ຄະແນນສູງສຸດ. ດັ່ງນັ້ນ, ພວກເຮົາເຊື່ອຫມັ້ນຢ່າງແນ່ນອນວ່າບັນຫາແມ່ນຢູ່ໃນການກໍານົດເວລາຂອງຝັກ.

ສູດການຄິດໄລ່ເພີ່ມເຕີມສໍາລັບການແກ້ໄຂບັນຫາແມ່ນເຫັນໄດ້ຊັດເຈນສໍາລັບພວກເຮົາ - ວິເຄາະບັນທຶກ, ເຂົ້າໃຈສິ່ງທີ່ບູລິມະສິດຂອງ node ບໍ່ໄດ້ຄະແນນຈຸດແລະ, ຖ້າຈໍາເປັນ, ປັບນະໂຍບາຍຂອງຄ່າເລີ່ມຕົ້ນ kube-scheduler. ຢ່າງໃດກໍຕາມ, ໃນທີ່ນີ້ພວກເຮົາປະເຊີນກັບສອງຄວາມຫຍຸ້ງຍາກທີ່ສໍາຄັນ:

1. ໃນລະດັບການບັນທຶກສູງສຸດ (10), ຈຸດທີ່ໄດ້ຮັບພຽງແຕ່ສໍາລັບບາງບູລິມະສິດແມ່ນສະທ້ອນໃຫ້ເຫັນ. ໃນບົດບັນທຶກຂ້າງເທິງ, ທ່ານສາມາດເຫັນໄດ້ວ່າສໍາລັບບູລິມະສິດທັງຫມົດທີ່ສະທ້ອນໃຫ້ເຫັນຢູ່ໃນບັນທຶກ, nodes ຄະແນນດຽວກັນຂອງຈຸດດຽວກັນໃນການກໍານົດເວລາປົກກະຕິແລະບັນຫາ, ແຕ່ຜົນໄດ້ຮັບສຸດທ້າຍໃນກໍລະນີຂອງການວາງແຜນບັນຫາແມ່ນແຕກຕ່າງກັນ. ດັ່ງນັ້ນ, ພວກເຮົາສາມາດສະຫຼຸບໄດ້ວ່າສໍາລັບບາງບູລິມະສິດ, ການໃຫ້ຄະແນນເກີດຂື້ນ "ຢູ່ເບື້ອງຫຼັງ", ແລະພວກເຮົາບໍ່ມີທາງທີ່ຈະເຂົ້າໃຈວ່າບູລິມະສິດໃດທີ່ໂຫນດບໍ່ໄດ້ຮັບຈຸດ. ພວກເຮົາໄດ້ອະທິບາຍບັນຫານີ້ຢ່າງລະອຽດໃນ ບັນຫາ Kubernetes repository ໃນ Github. ໃນເວລາຂຽນ, ໄດ້ຮັບການຕອບຮັບຈາກນັກພັດທະນາວ່າການສະຫນັບສະຫນູນການບັນທຶກຈະຖືກເພີ່ມເຂົ້າໃນການປັບປຸງ Kubernetes v1.15,1.16, 1.17 ແລະ XNUMX.
2. ບໍ່ມີວິທີງ່າຍໆທີ່ຈະເຂົ້າໃຈວ່າຊຸດນະໂຍບາຍສະເພາະໃດທີ່ kube-scheduler ກຳລັງເຮັດວຽກຢູ່. ແມ່ນແລ້ວ, ໃນ ເອກະສານ ບັນຊີລາຍຊື່ນີ້ແມ່ນຢູ່ໃນລາຍຊື່, ແຕ່ມັນບໍ່ມີຂໍ້ມູນກ່ຽວກັບນ້ໍາຫນັກສະເພາະໃດທີ່ຖືກມອບຫມາຍໃຫ້ແຕ່ລະນະໂຍບາຍບູລິມະສິດ. ທ່ານ​ສາ​ມາດ​ເບິ່ງ​ນ​້​ໍາ​ຫນັກ​ຫຼື​ແກ້​ໄຂ​ນະ​ໂຍ​ບາຍ​ຂອງ​ຄ່າ​ເລີ່ມ​ຕົ້ນ kube-scheduler ພຽງ​ແຕ່​ໃນ ລະຫັດແຫຼ່ງ.

ມັນເປັນມູນຄ່າທີ່ສັງເກດວ່າເມື່ອພວກເຮົາສາມາດບັນທຶກວ່າ node ບໍ່ໄດ້ຮັບຈຸດຕາມນະໂຍບາຍ ImageLocalityPriority, ເຊິ່ງໃຫ້ລາງວັນຊີ້ໄປຫາ node ຖ້າມັນມີຮູບພາບທີ່ຈໍາເປັນເພື່ອດໍາເນີນການແອັບພລິເຄຊັນ. ນັ້ນແມ່ນ, ໃນເວລາທີ່ຄໍາຮ້ອງສະຫມັກສະບັບໃຫມ່ໄດ້ເປີດຕົວ, ວຽກງານ cron ໄດ້ຖືກຄຸ້ມຄອງເພື່ອດໍາເນີນການໃນສອງ nodes, ດາວໂຫລດຮູບພາບໃຫມ່ຈາກ docker registry ໃຫ້ພວກເຂົາ, ແລະດັ່ງນັ້ນທັງສອງ nodes ໄດ້ຮັບຄະແນນສຸດທ້າຍທີ່ສູງກວ່າທຽບກັບທີສາມ. .

ດັ່ງທີ່ຂ້າພະເຈົ້າຂຽນໄວ້ຂ້າງເທິງ, ໃນບັນທຶກພວກເຮົາບໍ່ເຫັນຂໍ້ມູນກ່ຽວກັບການປະເມີນຜົນຂອງນະໂຍບາຍ ImageLocalityPriority, ດັ່ງນັ້ນ, ເພື່ອກວດເບິ່ງສົມມຸດຕິຖານຂອງພວກເຮົາ, ພວກເຮົາຖິ້ມຮູບພາບທີ່ມີຄໍາຮ້ອງສະຫມັກຮຸ່ນໃຫມ່ໃສ່ໂຫນດທີສາມ, ຫຼັງຈາກນັ້ນການກໍານົດເວລາເຮັດວຽກຢ່າງຖືກຕ້ອງ. . ມັນເປັນທີ່ຊັດເຈນຍ້ອນນະໂຍບາຍ ImageLocalityPriority ທີ່ບັນຫາການກໍານົດເວລາໄດ້ຖືກສັງເກດເຫັນຂ້ອນຂ້າງບໍ່ຄ່ອຍ; ເລື້ອຍໆມັນກ່ຽວຂ້ອງກັບສິ່ງອື່ນ. ເນື່ອງຈາກຄວາມຈິງທີ່ວ່າພວກເຮົາບໍ່ສາມາດແກ້ບັນຫາໄດ້ຢ່າງເຕັມສ່ວນແຕ່ລະນະໂຍບາຍໃນບັນຊີລາຍຊື່ບູລິມະສິດຂອງຄ່າເລີ່ມຕົ້ນ kube-scheduler, ພວກເຮົາຈໍາເປັນຕ້ອງມີການຄຸ້ມຄອງແບບຍືດຫຍຸ່ນຂອງນະໂຍບາຍການກໍານົດເວລາ pod.

ການສ້າງບັນຫາ

ພວກເຮົາຕ້ອງການການແກ້ໄຂບັນຫາສະເພາະເທົ່າທີ່ເປັນໄປໄດ້, ນັ້ນແມ່ນ, ຫນ່ວຍງານຕົ້ນຕໍຂອງ Kubernetes (ນີ້ພວກເຮົາຫມາຍຄວາມວ່າຄ່າເລີ່ມຕົ້ນ kube-scheduler) ຄວນຈະບໍ່ປ່ຽນແປງ. ພວກເຮົາບໍ່ຕ້ອງການແກ້ໄຂບັນຫາຢູ່ໃນສະຖານທີ່ຫນຶ່ງແລະສ້າງມັນຢູ່ໃນບ່ອນອື່ນ. ດັ່ງນັ້ນ, ພວກເຮົາມາຮອດສອງທາງເລືອກໃນການແກ້ໄຂບັນຫາ, ເຊິ່ງໄດ້ຖືກປະກາດໃນບົດແນະນໍາ - ການສ້າງຕາຕະລາງເພີ່ມເຕີມຫຼືການຂຽນຂອງທ່ານເອງ. ຄວາມຕ້ອງການຕົ້ນຕໍສໍາລັບການກໍານົດເວລາວຽກງານ cron ແມ່ນການແຈກຢາຍການໂຫຼດເທົ່າທຽມກັນໃນທົ່ວສາມໂຫນດ. ຄວາມຕ້ອງການນີ້ສາມາດພໍໃຈໄດ້ໂດຍນະໂຍບາຍ kube-scheduler ທີ່ມີຢູ່ແລ້ວ, ດັ່ງນັ້ນເພື່ອແກ້ໄຂບັນຫາຂອງພວກເຮົາບໍ່ມີຈຸດໃດໃນການຂຽນຕາຕະລາງຂອງທ່ານເອງ.

ຄໍາແນະນໍາສໍາລັບການສ້າງແລະການຕິດຕັ້ງ kube-scheduler ເພີ່ມເຕີມແມ່ນໄດ້ອະທິບາຍໄວ້ໃນ ເອກະສານ. ຢ່າງໃດກໍຕາມ, ມັນເບິ່ງຄືວ່າພວກເຮົາວ່າຫນ່ວຍງານ Deployment ບໍ່ພຽງພໍທີ່ຈະຮັບປະກັນຄວາມທົນທານຕໍ່ຄວາມຜິດພາດໃນການດໍາເນີນງານຂອງການບໍລິການທີ່ສໍາຄັນເຊັ່ນ kube-scheduler, ດັ່ງນັ້ນພວກເຮົາຈຶ່ງຕັດສິນໃຈທີ່ຈະໃຊ້ kube-scheduler ໃຫມ່ເປັນ Static Pod, ເຊິ່ງຈະຖືກຕິດຕາມໂດຍກົງ. ໂດຍ Kubelet. ດັ່ງນັ້ນ, ພວກເຮົາມີຄວາມຕ້ອງການດັ່ງຕໍ່ໄປນີ້ສໍາລັບ kube-scheduler ໃຫມ່:

1. ບໍລິການຕ້ອງຖືກນຳໃຊ້ເປັນ Static Pod ຢູ່ໃນກຸ່ມແມ່ບົດທັງໝົດ
2. ຄວາມທົນທານຕໍ່ຄວາມຜິດຈະຕ້ອງຖືກສະໜອງໃຫ້ ໃນກໍລະນີທີ່ຝອດທີ່ໃຊ້ຢູ່ກັບ kube-scheduler ບໍ່ສາມາດໃຊ້ໄດ້
3. ບູລິມະສິດຕົ້ນຕໍໃນເວລາວາງແຜນຄວນຈະເປັນຈໍານວນຂອງຊັບພະຍາກອນທີ່ມີຢູ່ໃນ node (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

ໂດຍຫຍໍ້ກ່ຽວກັບການປ່ຽນແປງຕົ້ນຕໍ:

1. ປ່ຽນຊື່ຂອງຝັກ ແລະບັນຈຸເປັນ kube-scheduler-cron
2. ກໍານົດການນໍາໃຊ້ພອດ 10151 ແລະ 10159 ເປັນທາງເລືອກທີ່ຖືກກໍານົດ hostNetwork: true ແລະພວກເຮົາບໍ່ສາມາດໃຊ້ພອດດຽວກັນກັບຄ່າເລີ່ມຕົ້ນ kube-scheduler (10251 ແລະ 10259)
3. ການນໍາໃຊ້ຕົວກໍານົດການ --config, ພວກເຮົາກໍານົດໄຟລ໌ການຕັ້ງຄ່າທີ່ການບໍລິການຄວນຈະເລີ່ມຕົ້ນ
4. ການຕິດຕັ້ງໄຟລ໌ການຕັ້ງຄ່າ (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-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"

ໂດຍຫຍໍ້ກ່ຽວກັບການປ່ຽນແປງຕົ້ນຕໍ:

1. ພວກເຮົາຕັ້ງ ScheduleName ເປັນຊື່ການບໍລິການ kube-scheduler-cron ຂອງພວກເຮົາ.
2. ໃນພາລາມິເຕີ lockObjectName ທ່ານຍັງຈໍາເປັນຕ້ອງໄດ້ກໍານົດຊື່ຂອງການບໍລິການຂອງພວກເຮົາແລະໃຫ້ແນ່ໃຈວ່າພາລາມິເຕີ leaderElect ຕັ້ງເປັນ true (ຖ້າທ່ານມີ master node ດຽວ, ທ່ານສາມາດຕັ້ງມັນເປັນ false).
3. ລະບຸເສັ້ນທາງໄປຫາໄຟລ໌ທີ່ມີລາຍລະອຽດຂອງນະໂຍບາຍການກໍານົດເວລາໃນພາລາມິເຕີ algorithmSource.

ມັນເປັນມູນຄ່າການພິຈາລະນາຢ່າງໃກ້ຊິດຢູ່ໃນຈຸດທີສອງ, ບ່ອນທີ່ພວກເຮົາແກ້ໄຂຕົວກໍານົດການສໍາລັບກະແຈ leaderElection. ເພື່ອຮັບປະກັນຄວາມທົນທານຕໍ່ຄວາມຜິດພາດ, ພວກເຮົາໄດ້ເປີດໃຊ້ງານ (leaderElect) ຂະ​ບວນ​ການ​ຂອງ​ການ​ຄັດ​ເລືອກ​ຜູ້​ນໍາ (ແມ່​ບົດ​) ລະ​ຫວ່າງ​ຝັກ​ຂອງ​ພວກ​ເຮົາ kube-scheduler ໂດຍ​ນໍາ​ໃຊ້​ຈຸດ​ສຸດ​ທ້າຍ​ດຽວ​ສໍາ​ລັບ​ເຂົາ​ເຈົ້າ (resourceLock) ຊື່ kube-scheduler-cron (lockObjectName) ໃນ namespace ລະ​ບົບ kube (lockObjectNamespace). О том как в Kubernetes обеспечивается высокая доступность основных компонентов (в том числе kube-scheduler) можно ознакомиться в ບົດຄວາມ.

• ໄຟລ໌ນະໂຍບາຍການກຳນົດເວລາ (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 ທໍາອິດລວບລວມບັນຊີລາຍຊື່ຂອງ nodes ທີ່ pod ສາມາດກໍານົດໄດ້ຕາມນະໂຍບາຍ GeneralPredicates (ເຊິ່ງປະກອບມີຊຸດຂອງ PodFitsResources, PodFitsHostPorts, HostName, ແລະ MatchNodeSelector policy). ແລະຫຼັງຈາກນັ້ນແຕ່ລະ node ໄດ້ຖືກປະເມີນໂດຍສອດຄ່ອງກັບຊຸດຂອງນະໂຍບາຍໃນ array ບູລິມະສິດ. ​ເພື່ອ​ປະຕິບັດ​ເງື່ອນ​ໄຂ​ຂອງ​ວຽກ​ງານ​ຂອງ​ພວກ​ເຮົາ, ພວກ​ຂ້າພະ​ເຈົ້າ​ຖື​ວ່າ​ບັນດາ​ນະ​ໂຍບາຍ​ດັ່ງກ່າວ​ຈະ​ເປັນ​ການ​ແກ້​ໄຂ​ທີ່​ດີ​ທີ່​ສຸດ. ຂ້າ​ພະ​ເຈົ້າ​ຂໍ​ເຕືອນ​ທ່ານ​ວ່າ​ຊຸດ​ນະ​ໂຍ​ບາຍ​ທີ່​ມີ​ຄໍາ​ອະ​ທິ​ບາຍ​ລະ​ອຽດ​ຂອງ​ພວກ​ເຂົາ​ແມ່ນ​ມີ​ຢູ່​ໃນ ເອກະສານ. ເພື່ອບັນລຸວຽກງານຂອງທ່ານ, ທ່ານພຽງແຕ່ສາມາດປ່ຽນຊຸດນະໂຍບາຍທີ່ໃຊ້ແລະກໍານົດນ້ໍາຫນັກທີ່ເຫມາະສົມກັບພວກເຂົາ.

ໃຫ້ໂທຫາ manifest ຂອງ kube-scheduler ໃຫມ່, ທີ່ພວກເຮົາສ້າງໃນຕອນຕົ້ນຂອງບົດ, kube-scheduler-custom.yaml ແລະວາງມັນຢູ່ໃນເສັ້ນທາງຕໍ່ໄປນີ້ /etc/kubernetes/manifests ໃນສາມແມ່ບົດ. ຖ້າທຸກສິ່ງທຸກຢ່າງຖືກເຮັດຢ່າງຖືກຕ້ອງ, Kubelet ຈະເປີດຕົວ pod ໃນແຕ່ລະ node, ແລະໃນບັນທຶກຂອງ 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:{}]'

ໃນປັດຈຸບັນທັງຫມົດທີ່ຍັງເຫຼືອແມ່ນເພື່ອຊີ້ໃຫ້ເຫັນໃນ spec ຂອງ CronJob ຂອງພວກເຮົາວ່າທຸກຄໍາຮ້ອງຂໍສໍາລັບການກໍານົດເວລາຝັກຂອງມັນຄວນຈະຖືກດໍາເນີນການໂດຍ kube-scheduler ໃຫມ່ຂອງພວກເຮົາ:

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

ສະຫລຸບ

ໃນທີ່ສຸດ, ພວກເຮົາໄດ້ຮັບຕົວກໍານົດເວລາ kube ເພີ່ມເຕີມທີ່ມີຊຸດນະໂຍບາຍການກໍານົດເວລາທີ່ເປັນເອກະລັກ, ວຽກງານທີ່ຖືກຕິດຕາມໂດຍກົງໂດຍ kubelet. ນອກຈາກນັ້ນ, ພວກເຮົາໄດ້ຈັດຕັ້ງການເລືອກຕັ້ງຜູ້ນໍາໃຫມ່ລະຫວ່າງຝັກຂອງ kube-scheduler ຂອງພວກເຮົາໃນກໍລະນີທີ່ຜູ້ນໍາເກົ່າບໍ່ສາມາດໃຊ້ໄດ້ຍ້ອນເຫດຜົນບາງຢ່າງ.

ຄໍາຮ້ອງສະຫມັກແລະການບໍລິການປົກກະຕິຍັງສືບຕໍ່ຖືກກໍານົດໂດຍຜ່ານ kube-scheduler ເລີ່ມຕົ້ນ, ແລະວຽກງານ cron ທັງຫມົດໄດ້ຖືກໂອນໄປໃຫມ່ຢ່າງສົມບູນ. ການໂຫຼດທີ່ສ້າງຂຶ້ນໂດຍວຽກງານ cron ໃນປັດຈຸບັນໄດ້ຖືກແຈກຢາຍຢ່າງເທົ່າທຽມກັນໃນທົ່ວທຸກ nodes. ພິຈາລະນາວ່າວຽກງານ cron ສ່ວນໃຫຍ່ຖືກປະຕິບັດຢູ່ໃນຂໍ້ດຽວກັນກັບຄໍາຮ້ອງສະຫມັກຕົ້ນຕໍຂອງໂຄງການ, ນີ້ໄດ້ຫຼຸດລົງຢ່າງຫຼວງຫຼາຍຄວາມສ່ຽງຂອງການເຄື່ອນຍ້າຍຝັກເນື່ອງຈາກການຂາດຊັບພະຍາກອນ. ຫຼັງຈາກການແນະນໍາ kube-scheduler ເພີ່ມເຕີມ, ບັນຫາກ່ຽວກັບການກໍານົດເວລາທີ່ບໍ່ສະເຫມີກັນຂອງວຽກງານ cron ຈະບໍ່ເກີດຂຶ້ນ.

ອ່ານບົດຄວາມອື່ນໆໃນ blog ຂອງພວກເຮົາ:

• ການຈັດການການຈະລາຈອນໃນກຸ່ມ Kubernetes ດ້ວຍ Calico
• ເຂົ້າໃຈຕົວເລືອກນະໂຍບາຍເຄືອຂ່າຍກັບ Calico
• ເມື່ອ Linux conntrack ບໍ່ແມ່ນເພື່ອນຂອງເຈົ້າອີກຕໍ່ໄປ
• 4 ຕົວຢ່າງຂອງການໂອນ iota
• ການອັບເກຣດກຸ່ມ Kubernetes ໂດຍບໍ່ມີການຢຸດເຮັດວຽກ
• ການນຳໃຊ້ສູນການຢຸດເຮັດວຽກ ແລະຖານຂໍ້ມູນ
• Kubernetes: ເປັນຫຍັງມັນຈຶ່ງສຳຄັນຫຼາຍໃນການຕັ້ງຄ່າການຈັດການຊັບພະຍາກອນຂອງລະບົບ?

ແຫຼ່ງຂໍ້ມູນ: www.habr.com