સુનિશ્ચિત નિયમોના વૈવિધ્યપૂર્ણ સેટ સાથે વધારાના ક્યુબ-શેડ્યુલર બનાવવું

કુબે-શેડ્યુલર એ કુબરનેટ્સનું એક અભિન્ન ઘટક છે, જે નિર્દિષ્ટ નીતિઓ અનુસાર સમગ્ર નોડ્સમાં પોડ્સ શેડ્યૂલ કરવા માટે જવાબદાર છે. ઘણીવાર, કુબરનેટ્સ ક્લસ્ટરની કામગીરી દરમિયાન, આપણે પોડ્સ શેડ્યૂલ કરવા માટે કઈ નીતિઓનો ઉપયોગ કરવામાં આવે છે તે વિશે વિચારવાની જરૂર નથી, કારણ કે ડિફોલ્ટ ક્યુબ-શેડ્યૂલરની નીતિઓનો સમૂહ મોટાભાગના રોજિંદા કાર્યો માટે યોગ્ય છે. જો કે, એવી પરિસ્થિતિઓ છે જ્યારે અમારા માટે શીંગો ફાળવવાની પ્રક્રિયાને ફાઇન-ટ્યુન કરવી મહત્વપૂર્ણ છે, અને આ કાર્યને પૂર્ણ કરવાની બે રીતો છે:

1. નિયમોના કસ્ટમ સેટ સાથે ક્યૂબ-શેડ્યૂલર બનાવો
2. તમારું પોતાનું શેડ્યૂલર લખો અને તેને API સર્વર વિનંતીઓ સાથે કામ કરવાનું શીખવો

આ લેખમાં, હું અમારા પ્રોજેક્ટમાંના એક પર હર્થના અસમાન શેડ્યૂલની સમસ્યાને ઉકેલવા માટેના પ્રથમ મુદ્દાના અમલીકરણનું વર્ણન કરીશ.

કુબે-શેડ્યુલર કેવી રીતે કાર્ય કરે છે તેનો સંક્ષિપ્ત પરિચય

ખાસ કરીને એ હકીકતની નોંધ લેવી યોગ્ય છે કે કુબે-શેડ્યુલર પોડને સીધા શેડ્યૂલ કરવા માટે જવાબદાર નથી - તે ફક્ત તે નોડ નક્કી કરવા માટે જવાબદાર છે કે જેના પર પોડ મૂકવો. બીજા શબ્દોમાં કહીએ તો, ક્યુબે-શેડ્યુલરના કાર્યનું પરિણામ એ નોડનું નામ છે, જે તે શેડ્યુલિંગ વિનંતી માટે 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

જેમાંથી તે જોઈ શકાય છે કે એક નોડ્સે અન્ય કરતા ઓછા ફાઈનલ પોઈન્ટ્સ મેળવ્યા હતા, અને તેથી આયોજન ફક્ત બે નોડ્સ માટે જ હાથ ધરવામાં આવ્યું હતું જેણે મહત્તમ સ્કોર મેળવ્યો હતો. આમ, અમને ચોક્કસપણે ખાતરી થઈ કે સમસ્યા શીંગોના સમયપત્રકમાં ચોક્કસપણે રહેલી છે.

સમસ્યાને ઉકેલવા માટે આગળનું અલ્ગોરિધમ અમને સ્પષ્ટ હતું - લોગનું વિશ્લેષણ કરો, સમજો કે નોડે કઈ પ્રાધાન્યતાથી પોઈન્ટ બનાવ્યા નથી અને, જો જરૂરી હોય તો, ડિફોલ્ટ ક્યુબ-શેડ્યૂલરની નીતિઓને સમાયોજિત કરો. જો કે, અહીં આપણે બે નોંધપાત્ર મુશ્કેલીઓનો સામનો કરી રહ્યા છીએ:

1. મહત્તમ લોગીંગ સ્તર (10) પર, માત્ર કેટલીક પ્રાથમિકતાઓ માટે મેળવેલ પોઈન્ટ પ્રતિબિંબિત થાય છે. લોગના ઉપરોક્ત અવતરણમાં, તમે જોઈ શકો છો કે લોગમાં પ્રતિબિંબિત તમામ પ્રાથમિકતાઓ માટે, નોડ્સ સામાન્ય અને સમસ્યા શેડ્યુલિંગમાં સમાન સંખ્યામાં પોઈન્ટ મેળવે છે, પરંતુ સમસ્યાના આયોજનના કિસ્સામાં અંતિમ પરિણામ અલગ છે. આમ, અમે નિષ્કર્ષ પર આવી શકીએ છીએ કે કેટલીક પ્રાથમિકતાઓ માટે, સ્કોરિંગ "પડદા પાછળ" થાય છે, અને અમારી પાસે એ સમજવાનો કોઈ રસ્તો નથી કે કઈ પ્રાથમિકતા માટે નોડને પોઈન્ટ મળ્યા નથી. અમે આ સમસ્યાનું વિગતવાર વર્ણન કર્યું છે મુદ્દો Github પર Kubernetes ભંડાર. લખવાના સમયે, વિકાસકર્તાઓ તરફથી પ્રતિસાદ મળ્યો કે કુબરનેટ્સ v1.15,1.16, 1.17 અને XNUMX અપડેટ્સમાં લોગીંગ સપોર્ટ ઉમેરવામાં આવશે.
2. ક્યૂબ-શેડ્યુલર હાલમાં કયા ચોક્કસ નીતિઓ સાથે કામ કરે છે તે સમજવાનો કોઈ સરળ રસ્તો નથી. હા, માં દસ્તાવેજીકરણ આ સૂચિ સૂચિબદ્ધ છે, પરંતુ તેમાં દરેક પ્રાથમિકતા નીતિઓ માટે કયા ચોક્કસ વજન સોંપવામાં આવ્યા છે તે વિશેની માહિતી શામેલ નથી. તમે વજન જોઈ શકો છો અથવા ડિફૉલ્ટ ક્યુબ-શેડ્યૂલરની પૉલિસીમાં ફેરફાર કરી શકો છો સ્ત્રોત કોડ્સ.

એ નોંધવું યોગ્ય છે કે એકવાર અમે રેકોર્ડ કરી શક્યા કે નોડને ImageLocalityPriority નીતિ અનુસાર પોઈન્ટ મળ્યા નથી, જે નોડને પોઈન્ટ આપે છે જો તેની પાસે એપ્લિકેશન ચલાવવા માટે જરૂરી ઇમેજ હોય ​​તો. એટલે કે, એપ્લીકેશનનું નવું વર્ઝન રોલઆઉટ થયું તે સમયે, ક્રોન ટાસ્ક બે નોડ્સ પર ચાલવા માટે વ્યવસ્થાપિત હતું, ડોકર રજિસ્ટ્રીમાંથી તેમને એક નવી ઈમેજ ડાઉનલોડ કરવામાં આવી હતી, અને આમ બે નોડ્સને ત્રીજાની તુલનામાં ઉચ્ચ અંતિમ સ્કોર મળ્યો હતો. .

જેમ મેં ઉપર લખ્યું છે તેમ, લોગમાં અમને ImageLocalityPriority નીતિના મૂલ્યાંકન વિશેની માહિતી દેખાતી નથી, તેથી અમારી ધારણાને ચકાસવા માટે, અમે એપ્લિકેશનના નવા સંસ્કરણ સાથેની છબીને ત્રીજા નોડ પર ફેંકી દીધી છે, જે પછી શેડ્યુલિંગ યોગ્ય રીતે કાર્ય કરે છે. . તે ચોક્કસ રીતે ImageLocalityPriority નીતિને કારણે હતું કે શેડ્યૂલિંગ સમસ્યા ખૂબ જ ભાગ્યે જ જોવા મળી હતી; વધુ વખત તે કંઈક અન્ય સાથે સંકળાયેલી હતી. ડિફૉલ્ટ ક્યુબ-શેડ્યૂલરની પ્રાથમિકતાઓની સૂચિમાં અમે દરેક નીતિઓને સંપૂર્ણપણે ડિબગ કરી શક્યા ન હોવાને કારણે, અમને પોડ શેડ્યૂલિંગ નીતિઓના લવચીક સંચાલનની જરૂર હતી.

સમસ્યાની રચના

અમે ઇચ્છીએ છીએ કે સમસ્યાનો ઉકેલ શક્ય તેટલો ચોક્કસ હોવો જોઈએ, એટલે કે, કુબરનેટ્સની મુખ્ય સંસ્થાઓ (અહીં અમારો મતલબ ડિફોલ્ટ ક્યુબ-શેડ્યૂલર) યથાવત રહેવો જોઈએ. અમે સમસ્યાને એક જગ્યાએ હલ કરીને બીજી જગ્યાએ બનાવવા માંગતા ન હતા. આમ, અમે સમસ્યાને ઉકેલવા માટેના બે વિકલ્પો પર આવ્યા, જેની જાહેરાત લેખની પ્રસ્તાવનામાં કરવામાં આવી હતી - એક વધારાનું શેડ્યૂલર બનાવવું અથવા તમારું પોતાનું લખવું. ક્રોન કાર્યોને સુનિશ્ચિત કરવા માટેની મુખ્ય આવશ્યકતા એ છે કે ભારને ત્રણ ગાંઠોમાં સમાનરૂપે વિતરિત કરવો. આ જરૂરિયાત હાલની ક્યુબે-શેડ્યુલર નીતિઓ દ્વારા સંતોષી શકાય છે, તેથી અમારી સમસ્યાને ઉકેલવા માટે તમારા પોતાના શેડ્યૂલર લખવાનો કોઈ અર્થ નથી.

વધારાના ક્યુબ-શેડ્યુલર બનાવવા અને જમાવવા માટેની સૂચનાઓ વર્ણવેલ છે દસ્તાવેજીકરણ. જો કે, અમને એવું લાગતું હતું કે ડિપ્લોયમેન્ટ એન્ટિટી ક્યુબે-શેડ્યુલર જેવી જટિલ સેવાના સંચાલનમાં ખામી સહિષ્ણુતાને સુનિશ્ચિત કરવા માટે પૂરતી ન હતી, તેથી અમે એક નવા ક્યુબ-શેડ્યૂલરને સ્ટેટિક પોડ તરીકે જમાવવાનું નક્કી કર્યું, જેનું સીધું નિરીક્ષણ કરવામાં આવશે. કુબેલેટ દ્વારા. આમ, નવા ક્યૂબ-શેડ્યૂલર માટે અમારી પાસે નીચેની જરૂરિયાતો છે:

1. સેવાને તમામ ક્લસ્ટર માસ્ટર્સ પર સ્ટેટિક પોડ તરીકે જમાવવી આવશ્યક છે
2. ક્યુબે-શેડ્યુલર સાથે સક્રિય પોડ અનુપલબ્ધ હોય તેવા કિસ્સામાં ખામી સહિષ્ણુતા પ્રદાન કરવી આવશ્યક છે
3. આયોજન કરતી વખતે મુખ્ય અગ્રતા નોડ પર ઉપલબ્ધ સંસાધનોની સંખ્યા હોવી જોઈએ (LeastRequestedPriority)

અમલીકરણ ઉકેલો

તે તરત જ નોંધવું યોગ્ય છે કે અમે કુબરનેટ્સ v1.14.7 માં તમામ કાર્ય હાથ ધરીશું, કારણ કે આ તે સંસ્કરણ છે જેનો પ્રોજેક્ટમાં ઉપયોગ કરવામાં આવ્યો હતો. ચાલો આપણા નવા કુબે-શેડ્યુલર માટે મેનિફેસ્ટો લખીને શરૂઆત કરીએ. ચાલો મૂળભૂત મેનિફેસ્ટ (/etc/kubernetes/manifests/kube-scheduler.yaml) ને આધાર તરીકે લઈએ અને તેને નીચેના ફોર્મમાં લાવીએ:

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

મુખ્ય ફેરફારો વિશે સંક્ષિપ્તમાં:

1. પોડ અને કન્ટેનરનું નામ બદલીને kube-scheduler-cron કર્યું
2. પોર્ટ 10151 અને 10159 નો ઉપયોગ સ્પષ્ટ કર્યો કારણ કે વિકલ્પ વ્યાખ્યાયિત કરવામાં આવ્યો હતો hostNetwork: true અને અમે ડિફોલ્ટ ક્યુબ-શેડ્યુલર (10251 અને 10259) જેવા જ પોર્ટનો ઉપયોગ કરી શકતા નથી
3. --config પરિમાણનો ઉપયોગ કરીને, અમે રૂપરેખાંકન ફાઇલનો ઉલ્લેખ કર્યો છે જેની સાથે સેવા શરૂ થવી જોઈએ
4. હોસ્ટ તરફથી રૂપરેખાંકન ફાઇલ (scheduler-custom.conf) અને શેડ્યૂલિંગ પોલિસી ફાઇલ (scheduler-custom-policy-config.json) નું ગોઠવેલું માઉન્ટિંગ

ભૂલશો નહીં કે અમારા ક્યુબે-શેડ્યૂલરને ડિફોલ્ટના સમાન અધિકારોની જરૂર પડશે. તેની ક્લસ્ટર ભૂમિકા સંપાદિત કરો:

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"

મુખ્ય ફેરફારો વિશે સંક્ષિપ્તમાં:

1. અમે અમારી ક્યુબ-શેડ્યૂલર-ક્રોન સેવાના નામ પર શેડ્યૂલરનેમ સેટ કરીએ છીએ.
2. પરિમાણમાં lockObjectName તમારે અમારી સેવાનું નામ પણ સેટ કરવાની જરૂર છે અને ખાતરી કરો કે પરિમાણ leaderElect સાચું પર સેટ કરો (જો તમારી પાસે એક મુખ્ય નોડ હોય, તો તમે તેને ખોટા પર સેટ કરી શકો છો).
3. પરિમાણમાં શેડ્યૂલિંગ નીતિઓના વર્ણન સાથે ફાઇલનો પાથ સ્પષ્ટ કર્યો 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
}

આમ, ક્યુબ-શેડ્યુલર સૌપ્રથમ નોડ્સની સૂચિનું સંકલન કરે છે જેમાં સામાન્ય પ્રીડિકેટ્સ નીતિ (જેમાં PodFitsResources, PodFitsHostPorts, HostName અને MatchNodeSelector નીતિઓનો સમૂહ શામેલ છે) અનુસાર પોડ સુનિશ્ચિત કરી શકાય છે. અને પછી દરેક નોડનું મૂલ્યાંકન અગ્રતા એરેમાં નીતિઓના સેટ અનુસાર કરવામાં આવે છે. અમારા કાર્યની શરતોને પરિપૂર્ણ કરવા માટે, અમે વિચાર્યું કે આવી નીતિઓનો સમૂહ શ્રેષ્ઠ ઉકેલ હશે. હું તમને યાદ કરાવું કે તેમના વિગતવાર વર્ણનો સાથે નીતિઓનો સમૂહ આમાં ઉપલબ્ધ છે દસ્તાવેજીકરણ. તમારા કાર્યને પૂર્ણ કરવા માટે, તમે ઉપયોગમાં લેવાતી નીતિઓના સેટને બદલી શકો છો અને તેમને યોગ્ય વજન સોંપી શકો છો.

ચાલો નવા kube-scheduler ના મેનિફેસ્ટને કૉલ કરીએ, જે આપણે પ્રકરણની શરૂઆતમાં બનાવેલ છે, kube-scheduler-custom.yaml અને તેને નીચેના પાથ /etc/kubernetes/manifests માં ત્રણ મુખ્ય નોડ પર મૂકો. જો બધું યોગ્ય રીતે કરવામાં આવ્યું હોય, તો કુબેલેટ દરેક નોડ પર પોડ લોન્ચ કરશે, અને અમારા નવા ક્યુબ-શેડ્યૂલરના લોગમાં અમે માહિતી જોઈશું કે અમારી પોલિસી ફાઇલ સફળતાપૂર્વક લાગુ કરવામાં આવી હતી:

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:{}]'

હવે જે બાકી છે તે અમારા ક્રોનજોબના સ્પેકમાં સૂચવવાનું છે કે તેના પોડ્સ શેડ્યૂલ કરવા માટેની તમામ વિનંતીઓ અમારા નવા ક્યુબ-શેડ્યૂલર દ્વારા પ્રક્રિયા કરવી જોઈએ:

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

નિષ્કર્ષ

આખરે, અમને શેડ્યુલિંગ નીતિઓના અનન્ય સેટ સાથે વધારાના ક્યુબ-શેડ્યૂલર મળ્યા, જેનું કામ સીધું કુબેલેટ દ્વારા મોનિટર કરવામાં આવે છે. આ ઉપરાંત, જૂના નેતા કોઈ કારણસર અનુપલબ્ધ થાય તો અમે અમારા કુબે-શેડ્યુલરની શીંગો વચ્ચે નવા નેતાની ચૂંટણી ગોઠવી છે.

નિયમિત એપ્લિકેશનો અને સેવાઓ ડિફોલ્ટ ક્યુબ-શેડ્યુલર દ્વારા સુનિશ્ચિત કરવાનું ચાલુ રાખે છે, અને તમામ ક્રોન કાર્યો સંપૂર્ણપણે નવામાં સ્થાનાંતરિત કરવામાં આવ્યા છે. ક્રોન કાર્યો દ્વારા બનાવેલ લોડ હવે તમામ નોડ્સમાં સમાનરૂપે વિતરિત કરવામાં આવે છે. મોટા ભાગના ક્રોન કાર્યો પ્રોજેક્ટના મુખ્ય કાર્યક્રમો જેવા જ નોડ્સ પર ચલાવવામાં આવે છે તે ધ્યાનમાં લેતા, આનાથી સંસાધનોની અછતને કારણે પોડ્સ ખસેડવાનું જોખમ નોંધપાત્ર રીતે ઘટ્યું છે. વધારાના ક્યુબ-શેડ્યુલરની રજૂઆત કર્યા પછી, ક્રોન કાર્યોના અસમાન સમયપત્રક સાથે સમસ્યાઓ ઊભી થઈ નથી.

અમારા બ્લોગ પર અન્ય લેખો પણ વાંચો:

• કેલિકો સાથે કુબરનેટ્સ ક્લસ્ટરમાં ટ્રાફિક મેનેજમેન્ટ
• કેલિકો સાથે નેટવર્ક નીતિ વિકલ્પોને સમજવું
• જ્યારે Linux conntrack હવે તમારો મિત્ર નથી
• iota ટ્રાન્સફરના 4 ઉદાહરણો
• ડાઉનટાઇમ વિના કુબરનેટ્સ ક્લસ્ટરને અપગ્રેડ કરવું
• શૂન્ય ડાઉનટાઇમ જમાવટ અને ડેટાબેસેસ
• કુબરનેટ્સ: સિસ્ટમ રિસોર્સ મેનેજમેન્ટને ગોઠવવું શા માટે એટલું મહત્વપૂર્ણ છે?

સોર્સ: www.habr.com