🥇 वेळापत्रक नियमांच्या सानुकूल संचासह अतिरिक्त कुबे-शेड्यूलर तयार करणे

कुबे-शेड्युलर हा कुबर्नेट्सचा एक अविभाज्य घटक आहे, जो निर्दिष्ट धोरणांनुसार नोड्समध्ये शेड्यूल करण्यासाठी जबाबदार आहे. बर्‍याचदा, कुबर्नेट्स क्लस्टरच्या ऑपरेशन दरम्यान, आम्हाला पॉड शेड्यूल करण्यासाठी कोणती पॉलिसी वापरली जाते याचा विचार करण्याची गरज नाही, कारण डीफॉल्ट क्युब-शेड्युलरच्या धोरणांचा संच बहुतेक दैनंदिन कामांसाठी योग्य असतो. तथापि, अशी परिस्थिती असते जेव्हा आमच्यासाठी शेंगा वाटप करण्याच्या प्रक्रियेस बारकाईने ट्यून करणे महत्त्वाचे असते आणि हे कार्य पूर्ण करण्याचे दोन मार्ग आहेत:

नियमांच्या सानुकूल संचासह क्यूबे-शेड्यूलर तयार करा
तुमचा स्वतःचा शेड्युलर लिहा आणि API सर्व्हर विनंत्यांसह कार्य करण्यास शिकवा

या लेखात, मी आमच्या प्रकल्पांपैकी एकावर चूलांच्या असमान शेड्यूलिंगच्या समस्येचे निराकरण करण्यासाठी पहिल्या बिंदूच्या अंमलबजावणीचे वर्णन करेन.

कुबे-शेड्युलर कसे कार्य करते याचा थोडक्यात परिचय

हे विशेषतः लक्षात घेण्यासारखे आहे की कुबे-शेड्यूलर थेट शेड्यूलिंग शेड्यूलसाठी जबाबदार नाही - तो केवळ पॉड कोणत्या नोडवर ठेवायचा हे ठरवण्यासाठी जबाबदार आहे. दुस-या शब्दात, क्यूबे-शेड्यूलरच्या कार्याचा परिणाम म्हणजे नोडचे नाव, जे शेड्यूलिंग विनंतीसाठी एपीआय सर्व्हरकडे परत येते आणि तिथेच त्याचे काम संपते.

प्रथम, क्यूबे-शेड्यूलर नोड्सची एक सूची संकलित करतो ज्यावर पॉड शेड्यूल केले जाऊ शकते प्रेडिकेट्स धोरणांनुसार. पुढे, या सूचीतील प्रत्येक नोडला प्राधान्यक्रम धोरणांनुसार ठराविक गुण प्राप्त होतात. परिणामी, जास्तीत जास्त गुणांसह नोड निवडला जातो. समान कमाल स्कोअर असलेले नोड्स असल्यास, यादृच्छिक एक निवडला जातो. अंदाज (फिल्टरिंग) आणि प्राधान्यक्रम (स्कोअरिंग) धोरणांची यादी आणि वर्णन यामध्ये आढळू शकते दस्तऐवजीकरण.

समस्या शरीराचे वर्णन

Nixys येथे मोठ्या संख्येने विविध Kubernetes क्लस्टर्सची देखभाल केली जात असूनही, आम्हाला पहिल्यांदा शेड्यूलिंग पॉड्सची समस्या अगदी अलीकडेच आली, जेव्हा आमच्या प्रकल्पांपैकी एकाला मोठ्या प्रमाणात नियतकालिक कार्ये (~100 CronJob संस्था) चालवायची होती. समस्येचे वर्णन शक्य तितके सोपे करण्यासाठी, आम्ही एक मायक्रोसर्व्हिसचे उदाहरण घेऊ, ज्यामध्ये CPU वर काही भार निर्माण करून मिनिटातून एकदा क्रॉन कार्य सुरू केले जाते. क्रॉन कार्य चालविण्यासाठी, पूर्णपणे समान वैशिष्ट्यांसह तीन नोड्स वाटप केले गेले (प्रत्येक वर 24 vCPU).

त्याच वेळी, इनपुट डेटाची मात्रा सतत बदलत असल्याने क्रोनजॉब कार्यान्वित होण्यासाठी किती वेळ लागेल हे अचूकपणे सांगणे अशक्य आहे. सरासरी, क्यूबे-शेड्युलरच्या सामान्य ऑपरेशन दरम्यान, प्रत्येक नोड 3-4 जॉब इंस्टन्स चालवते, जे प्रत्येक नोडच्या CPU वर ~20-30% लोड तयार करतात:

समस्या ही आहे की कधीकधी क्रॉन टास्क पॉड्स तीन नोड्सपैकी एकावर शेड्यूल करणे थांबवतात. म्हणजेच, काही वेळेस, एका नोड्ससाठी एकही पॉड नियोजित केलेला नव्हता, तर इतर दोन नोड्सवर टास्कच्या 6-8 प्रती चालू होत्या, ज्यामुळे CPU लोडच्या ~40-60% तयार होते:

समस्या पूर्णपणे यादृच्छिक वारंवारतेसह पुनरावृत्ती होते आणि कोडची नवीन आवृत्ती आणल्याच्या क्षणाशी अधूनमधून सहसंबंधित होते.

क्यूब-शेड्युलर लॉगिंग पातळी 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 धोरणामुळे शेड्युलिंगची समस्या अगदी क्वचितच आढळून आली होती; अधिक वेळा ती दुसर्‍या कशाशी तरी संबंधित होती. डीफॉल्ट क्यूब-शेड्युलरच्या प्राधान्यक्रमांच्या यादीतील प्रत्येक पॉलिसी आम्ही पूर्णपणे डीबग करू शकलो नाही या वस्तुस्थितीमुळे, आम्हाला पॉड शेड्युलिंग पॉलिसींच्या लवचिक व्यवस्थापनाची आवश्यकता होती.

समस्येची निर्मिती

आम्हाला समस्येचे निराकरण शक्य तितके विशिष्ट असावे असे वाटत होते, म्हणजे, कुबर्नेट्सचे मुख्य घटक (येथे आमचा अर्थ डीफॉल्ट क्युब-शेड्यूलर) अपरिवर्तित असावा. आम्हाला समस्या एका ठिकाणी सोडवायची नव्हती आणि ती दुसऱ्या ठिकाणी निर्माण करायची होती. अशा प्रकारे, आम्ही समस्येचे निराकरण करण्यासाठी दोन पर्यायांवर आलो, जे लेखाच्या प्रस्तावनेत घोषित केले गेले होते - अतिरिक्त शेड्यूलर तयार करणे किंवा स्वतःचे लेखन. क्रॉन टास्क शेड्यूल करण्यासाठी मुख्य आवश्यकता म्हणजे लोड तीन नोड्समध्ये समान रीतीने वितरित करणे. ही आवश्यकता विद्यमान क्यूबे-शेड्यूलर धोरणांद्वारे पूर्ण केली जाऊ शकते, म्हणून आमच्या समस्येचे निराकरण करण्यासाठी, स्वतःचे शेड्यूलर लिहिण्यात काही अर्थ नाही.

अतिरिक्त क्यूब-शेड्युलर तयार करण्यासाठी आणि तैनात करण्याच्या सूचनांमध्ये वर्णन केले आहे दस्तऐवजीकरण. तथापि, आम्हाला असे वाटले की क्यूबे-शेड्यूलर सारख्या गंभीर सेवेच्या ऑपरेशनमध्ये दोष सहिष्णुता सुनिश्चित करण्यासाठी उपयोजन संस्था पुरेशी नाही, म्हणून आम्ही एक नवीन क्यूबे-शेड्यूलर स्थिर पॉड म्हणून तैनात करण्याचा निर्णय घेतला, ज्याचे थेट निरीक्षण केले जाईल. कुबेलेट द्वारे. अशा प्रकारे, नवीन क्यूबे-शेड्युलरसाठी आमच्याकडे खालील आवश्यकता आहेत:

सेवा सर्व क्लस्टर मास्टर्सवर स्थिर पॉड म्हणून तैनात करणे आवश्यक आहे
क्यूबे-शेड्यूलरसह सक्रिय पॉड अनुपलब्ध असल्यास फॉल्ट टॉलरन्स प्रदान करणे आवश्यक आहे
नियोजन करताना मुख्य प्राधान्य नोडवर उपलब्ध संसाधनांची संख्या असावी (LeastRequestedPriority)

अंमलबजावणी उपाय

हे लगेच लक्षात घेण्यासारखे आहे की आम्ही Kubernetes 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) चे कॉन्फिगर केलेले माउंटिंग

आमच्या kube-शेड्युलरला डीफॉल्ट प्रमाणेच अधिकारांची आवश्यकता असेल हे विसरू नका. त्याची क्लस्टर भूमिका संपादित करा:

kubectl edit clusterrole system:kube-scheduler

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

आता कॉन्फिगरेशन फाइल आणि शेड्युलिंग पॉलिसी फाइलमध्ये काय समाविष्ट असावे याबद्दल बोलूया:

कॉन्फिगरेशन फाइल (scheduler-custom.conf)
डीफॉल्ट क्यूब-शेड्यूलर कॉन्फिगरेशन प्राप्त करण्यासाठी, तुम्ही पॅरामीटर वापरणे आवश्यक आहे --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) कुबे-सिस्टम नेमस्पेसमध्ये (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-शेड्यूलर प्रथम नोड्सची सूची संकलित करतो ज्यात पॉड शेड्यूल केला जाऊ शकतो जनरल प्रेडिकेट्स धोरणानुसार (ज्यात PodFitsResources, PodFitsHostPorts, HostName आणि MatchNodeSelector धोरणांचा संच समाविष्ट आहे). आणि नंतर प्रत्येक नोडचे मूल्यमापन प्राधान्यक्रमांच्या धोरणांच्या संचानुसार केले जाते. आमच्या कार्याच्या अटींची पूर्तता करण्यासाठी, आम्ही असा विचार केला की धोरणांचा संच हा सर्वोत्तम उपाय असेल. मी तुम्हाला आठवण करून देतो की त्यांच्या तपशीलवार वर्णनांसह धोरणांचा संच उपलब्ध आहे दस्तऐवजीकरण. तुमचे कार्य पूर्ण करण्यासाठी, तुम्ही फक्त वापरलेल्या धोरणांचा संच बदलू शकता आणि त्यांना योग्य वजन नियुक्त करू शकता.

चला नवीन kube-scheduler च्या मॅनिफेस्टला कॉल करूया, जो आपण धड्याच्या सुरुवातीला तयार केला आहे, kube-scheduler-custom.yaml आणि त्याला खालील पथ /etc/kubernetes/manifests मध्ये तीन मास्टर नोड्सवर ठेवा. सर्वकाही योग्यरित्या केले असल्यास, कुबेलेट प्रत्येक नोडवर एक पॉड लाँच करेल आणि आमच्या नवीन 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:{}]'

आता फक्त आमच्या क्रोनजॉबच्या वैशिष्ट्यामध्ये सूचित करणे बाकी आहे की त्याच्या पॉड्स शेड्यूल करण्याच्या सर्व विनंत्या आमच्या नवीन kube-शेड्युलरद्वारे प्रक्रिया केल्या पाहिजेत:

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

निष्कर्ष

शेवटी, आम्हाला शेड्युलिंग पॉलिसीच्या अनन्य संचासह एक अतिरिक्त क्यूबे-शेड्यूलर मिळाला, ज्याच्या कामाचे थेट कुबेलेटद्वारे निरीक्षण केले जाते. याव्यतिरिक्त, जुना नेता काही कारणास्तव अनुपलब्ध झाल्यास आम्ही आमच्या कुबे-शेड्युलरच्या शेंगांच्या दरम्यान नवीन नेत्याची निवड केली आहे.

डीफॉल्ट क्यूब-शेड्यूलरद्वारे नियमित अनुप्रयोग आणि सेवा शेड्यूल केल्या जातात आणि सर्व क्रॉन कार्ये पूर्णपणे नवीनकडे हस्तांतरित केली गेली आहेत. क्रॉन टास्कद्वारे तयार केलेला लोड आता सर्व नोड्समध्ये समान रीतीने वितरीत केला जातो. प्रकल्पाच्या मुख्य अनुप्रयोगांप्रमाणेच बहुतेक क्रॉन कार्ये त्याच नोड्सवर चालविली जातात हे लक्षात घेता, यामुळे संसाधनांच्या कमतरतेमुळे पॉड हलविण्याचा धोका लक्षणीयरीत्या कमी झाला आहे. अतिरिक्त क्यूबे-शेड्यूलर सादर केल्यानंतर, क्रॉन कार्यांच्या असमान शेड्यूलिंगसह समस्या उद्भवल्या नाहीत.

आमच्या ब्लॉगवरील इतर लेख देखील वाचा:

स्त्रोत: www.habr.com

शेड्युलिंग नियमांच्या सानुकूल संचासह अतिरिक्त क्यूबे-शेड्यूलर तयार करणे