ብጁ የመርሐግብር ደንቦች ስብስብ ያለው ተጨማሪ የኩቤ-መርሐግብር አዘጋጅ መፍጠር

ብጁ የመርሐግብር ደንቦች ስብስብ ያለው ተጨማሪ የኩቤ-መርሐግብር አዘጋጅ መፍጠር

Kube-scheduler የኩበርኔትስ ዋና አካል ነው፣ እሱም በተጠቀሱት ፖሊሲዎች መሰረት በኖዶች ውስጥ ያሉ ፖድዎችን መርሐግብር የማስያዝ ኃላፊነት አለበት። ብዙውን ጊዜ የኩበርኔትስ ክላስተር በሚሠራበት ጊዜ የነባሪ የኩቤ-መርሐግብር አዘጋጅ ፖሊሲዎች ስብስብ ለአብዛኛዎቹ የዕለት ተዕለት ተግባራት ተስማሚ ስለሆነ ፖድዎችን ለማቀድ የትኞቹ ፖሊሲዎች ጥቅም ላይ እንደሚውሉ ማሰብ የለብንም ። ነገር ግን፣ ፖድዎችን የመመደብ ሂደቱን ማስተካከል አስፈላጊ በሚሆንበት ጊዜ ሁኔታዎች አሉ፣ እና ይህን ተግባር ለማከናወን ሁለት መንገዶች አሉ።

  1. በብጁ የሕጎች ስብስብ የኩቤ-መርሐግብር አዘጋጅ ይፍጠሩ
  2. የራስዎን መርሐግብር ይጻፉ እና ከኤፒአይ አገልጋይ ጥያቄዎች ጋር እንዲሰራ ያስተምሩት።

በዚህ ጽሑፍ ውስጥ በአንዱ ፕሮጄክታችን ላይ የእቶን ምድጃዎችን ያልተስተካከለ የጊዜ ሰሌዳ ችግር ለመፍታት የመጀመሪያውን ነጥብ አፈፃፀም እገልጻለሁ ።

የኩቤ-መርሐግብር አዘጋጅ እንዴት እንደሚሰራ አጭር መግቢያ

በተለይም የኩቤ-መርሃግብር አዘጋጅ ፖድዎችን በቀጥታ ለማቀድ ሃላፊነት እንደሌለበት ልብ ሊባል የሚገባው ነው - እሱ የሚይዘው ፖድ የሚቀመጥበትን መስቀለኛ መንገድ ለመወሰን ብቻ ነው. በሌላ አነጋገር የ kube-scheduler ሥራ ውጤት የመስቀለኛ መንገድ ስም ነው, ይህም ለፕሮግራም ጥያቄ ወደ ኤፒአይ አገልጋይ ይመለሳል, እና እዚያ ላይ ስራው ያበቃል.

በመጀመሪያ, Kube-scheduler በፕሬዲኬትስ ፖሊሲዎች መሰረት ፖዱ ሊታቀድባቸው የሚችሉባቸውን የአንጓዎች ዝርዝር ያጠናቅራል. በመቀጠል፣ ከዚህ ዝርዝር ውስጥ ያለው እያንዳንዱ መስቀለኛ መንገድ ቅድሚያ በሚሰጣቸው መመሪያዎች መሠረት የተወሰኑ ነጥቦችን ይቀበላል። በውጤቱም, ከፍተኛው የነጥብ ብዛት ያለው መስቀለኛ መንገድ ተመርጧል. ተመሳሳይ ከፍተኛ ነጥብ ያላቸው አንጓዎች ካሉ፣ አንድ በዘፈቀደ ይመረጣል። የተሳቢዎች ዝርዝር እና መግለጫ (ማጣራት) እና ቅድሚያ የሚሰጣቸው (ነጥብ ማስቆጠር) ፖሊሲዎች በ ውስጥ ይገኛሉ ሰነድ.

የችግሩ አካል መግለጫ

በኒክሲስ ውስጥ በርካታ ቁጥር ያላቸው የተለያዩ የኩበርኔትስ ክላስተር ተጠብቀው ቢቆዩም፣ በመጀመሪያ የፖድ መርሐግብርን ችግር ያጋጠመን በቅርቡ ነው፣ ከፕሮጀክቶቻችን ውስጥ አንዱ ብዙ ወቅታዊ ተግባራትን (~ 100 CronJob አካላት) ማካሄድ ሲፈልግ ነበር። የችግሩን መግለጫ በተቻለ መጠን ለማቃለል አንድ ማይክሮ ሰርቪስ እንደ ምሳሌ እንወስዳለን ፣ በዚህ ውስጥ ክሮን ተግባር በደቂቃ አንድ ጊዜ ይጀምራል ፣ ይህም በሲፒዩ ላይ የተወሰነ ጭነት ይፈጥራል። የክሮን ስራውን ለማስኬድ ሶስት አንጓዎች ፍጹም ተመሳሳይ ባህሪያት ተመድበዋል (በእያንዳንዱ 24 vCPUs)።

በተመሳሳይ ጊዜ የግብአት ውሂብ መጠን በየጊዜው ስለሚለዋወጥ ክሮንጆብ ምን ያህል ጊዜ እንደሚፈጅ በትክክል መናገር አይቻልም። በአማካይ፣ በመደበኛ የኩቤ-መርሐግብር ሰጭ፣ እያንዳንዱ መስቀለኛ መንገድ ከ3-4 የሥራ አጋጣሚዎችን ያካሂዳል፣ ይህም በእያንዳንዱ መስቀለኛ መንገድ ሲፒዩ ላይ ያለውን ጭነት ~20-30% ይፈጥራል።

ብጁ የመርሐግብር ደንቦች ስብስብ ያለው ተጨማሪ የኩቤ-መርሐግብር አዘጋጅ መፍጠር

ችግሩ ራሱ አንዳንድ ጊዜ ክሮን ተግባር ፖድስ ከሶስት አንጓዎች በአንዱ ላይ መርሐግብር መያዙን ያቆማል። ማለትም ፣ በአንድ ወቅት ፣ ለአንዱ አንጓዎች አንድ ነጠላ ፖድ አልታቀደም ፣ በሌሎቹ ሁለት አንጓዎች ላይ 6-8 የተግባሩ ቅጂዎች እየሰሩ ነበር ፣ ይህም ~ 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. ኩቤ-መርሐግብር አስማሚ በአሁኑ ጊዜ ከየትኞቹ የፖሊሲዎች ስብስብ ጋር እንደሚሰራ ለመረዳት ቀላል መንገድ የለም። አዎ፣ ውስጥ ሰነድ ይህ ዝርዝር ተዘርዝሯል። ክብደቶቹን ማየት ወይም የነባሪውን የኩቤ መርሐግብር ተቆጣጣሪ ፖሊሲዎችን ማርትዕ የሚችሉት በ ውስጥ ብቻ ነው። የምንጭ ኮዶች.

አንድ ጊዜ አንድ መስቀለኛ መንገድ በ ImageLocaityPriority ፖሊሲ መሰረት ነጥቦችን እንዳልተቀበለ መመዝገብ ከቻልን በኋላ ማመልከቻውን ለማስኬድ አስፈላጊው ምስል ካለው ወደ መስቀለኛ መንገድ ይጠቁማል። ማለትም አዲስ የመተግበሪያው እትም በተለቀቀበት ወቅት የክሮን ስራው በሁለት አንጓዎች ላይ እንዲሰራ በማድረግ አዲስ ምስል ከዶክተር መዝገብ ቤት ወደ እነርሱ በማውረድ ሁለት አንጓዎች ከሦስተኛው አንፃር ከፍተኛ የመጨረሻ ውጤት አግኝተዋል ። .

ከላይ እንደጻፍኩት በምዝግብ ማስታወሻዎች ውስጥ ስለ ImageLocaityPriority ፖሊሲ ግምገማ መረጃን አይመለከትም, ስለዚህ የእኛን ግምት ለመፈተሽ, ምስሉን በአዲሱ የመተግበሪያው ስሪት ወደ ሶስተኛው መስቀለኛ መንገድ ጣልነው, ከዚያ በኋላ መርሐግብር በትክክል ይሠራል. . የመርሃግብር ችግር በጣም አልፎ አልፎ የሚታየው በImageLocalityPriority ፖሊሲ ምክንያት ነው፣ ብዙ ጊዜ ከሌላ ነገር ጋር ይያያዛል። በነባሪ የኩቤ መርሐግብር ሹም ቅድሚያ የሚሰጣቸውን ዝርዝር ውስጥ ያሉትን እያንዳንዱን ፖሊሲዎች ሙሉ በሙሉ ማረም ባለመቻላችን፣ የፖድ መርሐግብር ፖሊሲዎችን ተለዋዋጭ አስተዳደር ያስፈልገናል።

የችግሩ ቀመር

ለችግሩ መፍትሄው በተቻለ መጠን የተወሰነ እንዲሆን እንፈልጋለን ፣ ማለትም ፣ የኩበርኔትስ ዋና አካላት (እዚህ ማለት ነባሪውን የኩቤ-መርሐግብር አስማሚ ማለት ነው) ሳይለወጥ መቆየት አለበት። ችግርን በአንድ ቦታ መፍታት እና በሌላ መፍጠር አልፈለግንም። ስለዚህ, ችግሩን ለመፍታት ወደ ሁለት አማራጮች ደርሰናል, በአንቀጹ መግቢያ ላይ የታወጀው - ተጨማሪ የጊዜ ሰሌዳ መፍጠር ወይም የራስዎን መጻፍ. የ cron ስራዎችን ለማቀድ ዋናው መስፈርት ጭነቱን በሶስት አንጓዎች እኩል ማከፋፈል ነው. ይህ መስፈርት በነባር የኩቤ-መርሐግብር ፖሊሲዎች ሊሟላ ይችላል፣ስለዚህ ችግራችንን ለመፍታት የራስዎን መርሐግብር መፃፍ ምንም ፋይዳ የለውም።

ተጨማሪ የኩቤ-መርሃግብር ሰሪ ለመፍጠር እና ለማሰማራት መመሪያዎች በ ውስጥ ተብራርተዋል። ሰነድ. ነገር ግን እንደ ኩቤ-መርሐግብር ባለው ወሳኝ አገልግሎት ላይ የስህተቱ መቻቻልን ለማረጋገጥ የስምሪት አካል በቂ ስላልነበርን አዲስ የኩቤ መርሐግብር እንደ ስታቲክ ፖድ ለማሰማራት ወሰንን ይህም በቀጥታ ቁጥጥር ይደረግበታል። በኩቤሌት. ስለዚህ፣ ለአዲሱ የኩቤ መርሐግብር አዘጋጅ የሚከተሉትን መስፈርቶች አለን።

  1. አገልግሎቱ በሁሉም የክላስተር ጌቶች ላይ እንደ Static Pod መሰማራት አለበት።
  2. የኩቤ መርሐግብር አስማሚ ያለው ንቁ ፖድ የማይገኝ ከሆነ የስህተት መቻቻል መቅረብ አለበት።
  3. እቅድ በሚዘጋጅበት ጊዜ ዋናው ቅድሚያ የሚሰጠው በመስቀለኛ መንገድ ላይ የሚገኙ ሀብቶች ብዛት መሆን አለበት (ቢያንስ የሚጠየቅ ቅድሚያ)

የመፍትሄው ትግበራ

በ 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

ስለ ዋና ዋና ለውጦች በአጭሩ

  1. የፖድ እና መያዣውን ስም ወደ ኩቤ-መርሐግብር-ክሮን ለውጧል
  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ኩቤ-መርሐግብር-ክሮን (ስም)lockObjectName) በ kube-system namespace (lockObjectNamespace). Kubernetes እንዴት ዋና ዋና ክፍሎች (kube-schedulerን ጨምሮ) ከፍተኛ መገኘትን እንደሚያረጋግጥ በ ውስጥ ይገኛሉ። ጽሑፍ.

  • መርሐግብር ማስያዝ ፖሊሲ ፋይል (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-scheduler በመጀመሪያ አንድ ፖድ በጄኔራል ፕረዲዲስትስ ፖሊሲ (የPodFitsResources፣ PodFitsHostPorts፣ HostName እና MatchNodeSelector ፖሊሲዎች ስብስብን ጨምሮ) የሚታቀዱባቸውን ኖዶች ዝርዝር ያጠናቅራል። እና ከዚያ እያንዳንዱ መስቀለኛ መንገድ ቅድሚያ በሚሰጣቸው ድርድር ውስጥ በፖሊሲዎች ስብስብ መሠረት ይገመገማል። የተግባራችንን ሁኔታዎች ለማሟላት፣ እንደዚህ አይነት የፖሊሲዎች ስብስብ ጥሩ መፍትሄ እንደሚሆን ተመልክተናል። ከዝርዝር መግለጫዎቻቸው ጋር የፖሊሲዎች ስብስብ እንደሚገኝ ላስታውስህ ሰነድ. ተግባርዎን ለማከናወን በቀላሉ ጥቅም ላይ የሚውሉትን የፖሊሲዎች ስብስብ መቀየር እና ተገቢውን ክብደቶች መመደብ ይችላሉ።

በምዕራፉ መጀመሪያ ላይ የፈጠርነውን አዲሱን የኩቤ መርሐግብር አስመላሽ ኩቤ-መርሐግብር-custom.yaml ብለን እንጠራው እና በሚከተለው መንገድ /ወዘተ/kubernetes/በሦስት ማስተር ኖዶች ላይ ይገለጣል። ሁሉም ነገር በትክክል ከተሰራ ኩቤሌት በእያንዳንዱ መስቀለኛ መንገድ ላይ ፖድ ያስነሳል እና በአዲሱ የኩቤ መርሐግብር መዝገብ መዝገብ ውስጥ የመመሪያ ፋይላችን በተሳካ ሁኔታ መተግበሩን እናያለን፡

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 ዝርዝር ውስጥ ሁሉንም የእቃ ማቀፊያዎችን ለማቀድ የሚጠየቁ ጥያቄዎች በአዲሱ የኩቤ መርሐግብር መስተናገድ እንዳለባቸው ለማሳየት ነው።

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

መደምደሚያ

በመጨረሻም፣ ልዩ የሆነ የመርሃግብር አወጣጥ ፖሊሲ ያለው ተጨማሪ የኩቤ መርሐግብር አዘጋጅ አግኝተናል፣ ስራውም በቀጥታ በkubelet ቁጥጥር የሚደረግበት ነው። በተጨማሪም አሮጌው መሪ በሆነ ምክንያት የማይገኝ ከሆነ በእኛ የኩቤ መርሐግብር ሹም መካከል አዲስ መሪ ምርጫ አዘጋጅተናል።

መደበኛ አፕሊኬሽኖች እና አገልግሎቶች በነባሪ የኩቤ-መርሐግብር ሰጭ በኩል መርሐግብር መያዙን ይቀጥላሉ፣ እና ሁሉም የክሮን ተግባራት ሙሉ በሙሉ ወደ አዲሱ ተላልፈዋል። በ cron ተግባራት የተፈጠረው ጭነት አሁን በሁሉም አንጓዎች ላይ እኩል ተሰራጭቷል። አብዛኛዎቹ የክሮን ስራዎች ከፕሮጀክቱ ዋና ዋና አፕሊኬሽኖች ጋር ተመሳሳይ በሆነ መስቀለኛ መንገድ ላይ እንደሚተገበሩ ከግምት ውስጥ በማስገባት ይህ በሃብት እጦት ምክንያት ፖድዎችን የመንቀሳቀስ አደጋን በእጅጉ ቀንሷል. ተጨማሪውን የኩቤ-መርሐግብር አስተላላፊ ካስተዋወቀ በኋላ፣ የክሮን ሥራዎችን እኩል ባልሆነ መርሐግብር የማውጣት ችግሮች አልተነሱም።

በብሎጋችን ላይ ሌሎች ጽሑፎችን ያንብቡ፡-

ምንጭ: hab.com

አስተያየት ያክሉ