Kube-scheduler යනු Kubernetes හි අනිවාර්ය අංගයකි, එය නිශ්චිත ප්‍රතිපත්තිවලට අනුකූලව නෝඩ් හරහා කරල් කාලසටහන්ගත කිරීම සඳහා වගකිව යුතුය. බොහෝ විට, Kubernetes පොකුරක් ක්රියාත්මක වන විට, පෙරනිමි kube-scheduler හි ප්‍රතිපත්ති මාලාව බොහෝ එදිනෙදා කාර්යයන් සඳහා සුදුසු බැවින්, කරල් උපලේඛනගත කිරීම සඳහා කුමන ප්‍රතිපත්ති භාවිතා කරන්නේ දැයි අපට සිතා බැලිය යුතු නැත. කෙසේ වෙතත්, කරල් වෙන් කිරීමේ ක්‍රියාවලිය මනාව සකස් කිරීම අපට වැදගත් වන අවස්ථා ඇති අතර, මෙම කාර්යය ඉටු කිරීමට ක්‍රම දෙකක් තිබේ:
- අභිරුචි නීති මාලාවක් සමඟ kube-scheduler එකක් සාදන්න
- ඔබේම උපලේඛකයක් ලියන්න සහ API සේවාදායක ඉල්ලීම් සමඟ වැඩ කිරීමට එය උගන්වන්න
මෙම ලිපියෙන්, අපගේ එක් ව්‍යාපෘතියක උදුන අසමාන ලෙස උපලේඛනගත කිරීමේ ගැටළුව විසඳීම සඳහා පළමු කරුණ ක්රියාත්මක කිරීම මම විස්තර කරමි.
kube-scheduler ක්‍රියා කරන ආකාරය පිළිබඳ කෙටි හැඳින්වීමක්
කරල් සෘජුවම උපලේඛනගත කිරීම සඳහා kube-scheduler වගකිව යුතු නොවන බව විශේෂයෙන් සඳහන් කිරීම වටී - එය වගකිව යුත්තේ කරල් තැබිය යුතු නෝඩය තීරණය කිරීම සඳහා පමණි. වෙනත් වචන වලින් කිවහොත්, kube-scheduler ගේ කාර්යයේ ප්‍රති result ලය වන්නේ නෝඩයේ නම වන අතර එය උපලේඛනගත ඉල්ලීමක් සඳහා API සේවාදායකයට නැවත පැමිණෙන අතර එහි කාර්යය අවසන් වන්නේ එතැනිනි.
පළමුව, kube-scheduler පුරෝකථන ප්‍රතිපත්තිවලට අනුකූලව පොඩ් කාලසටහන්ගත කළ හැකි නෝඩ් ලැයිස්තුවක් සම්පාදනය කරයි. ඊළඟට, මෙම ලැයිස්තුවෙන් සෑම නෝඩයකටම ප්‍රමුඛතා ප්‍රතිපත්තිවලට අනුකූලව නිශ්චිත ලකුණු සංඛ්යාවක් ලැබේ. එහි ප්රතිඵලයක් වශයෙන්, උපරිම ලකුණු සංඛ්යාවක් සහිත නෝඩය තෝරා ඇත. එකම උපරිම ලකුණු ඇති නෝඩ් තිබේ නම්, අහඹු එකක් තෝරා ගනු ලැබේ. පුරෝකථන (පෙරහන) සහ ප්‍රමුඛතා (ලකුණු කිරීම) ප්‍රතිපත්තිවල ලැයිස්තුවක් සහ විස්තරයක් සොයාගත හැකිය .
ගැටළු ශරීරය පිළිබඳ විස්තරය
Nixys හි විවිධ Kubernetes පොකුරු විශාල සංඛ්යාවක් පවත්වා ගෙන ගියද, අපි මුලින්ම කරල් කාලසටහන් කිරීමේ ගැටලුවට මුහුණ දුන්නේ මෑතකදී, අපගේ එක් ව්‍යාපෘතියකට ආවර්තිතා කාර්යයන් විශාල සංඛ්යාවක් (~100 CronJob ආයතන) ක්රියාත්මක කිරීමට අවශ්‍ය වූ විටය. ගැටලුවේ විස්තරය හැකිතාක් සරල කිරීම සඳහා, අපි උදාහරණයක් ලෙස එක් ක්ෂුද්‍ර සේවාවක් ගනිමු, එය තුළ මිනිත්තුවකට වරක් ක්‍රෝන් කාර්යයක් දියත් කර CPU මත යම් බරක් ඇති කරයි. ක්‍රෝන් කාර්යය ක්රියාත්මක කිරීම සඳහා, පරම සමාන ලක්ෂණ සහිත නෝඩ් තුනක් වෙන් කරන ලදී (එක් එක් vCPUs 24).
ඒ අතරම, ආදාන දත්ත පරිමාව නිරන්තරයෙන් වෙනස් වන බැවින්, ක්‍රොන්ජොබ් ක්රියාත්මක කිරීමට කොපමණ කාලයක් ගතවේද යන්න නිවැරදිව පැවසිය නොහැක. සාමාන්‍යයෙන්, kube-scheduler හි සාමාන්‍ය ක්‍රියාකාරිත්වය අතරතුර, සෑම node එකක්ම රැකියා අවස්ථා 3-4ක් ක්රියාත්මක කරයි, එමඟින් එක් එක් node එකෙහි CPU මත පැටවීමෙන් ~20-30% ක් නිර්මාණය වේ:
ගැටළුව වන්නේ සමහර විට ක්‍රෝන් ටාස්ක් පොඩ් නෝඩ් තුනෙන් එකක කාලසටහන් කිරීම නැවැත්වීමයි. එනම්, යම් අවස්ථාවක දී, එක් නෝඩ් එකක් සඳහා එක පොඩ් එකක්වත් සැලසුම් කර නොතිබූ අතර, අනෙක් නෝඩ් දෙකේ කාර්යයේ පිටපත් 6-8 ක් ක්රියාත්මක වෙමින්, CPU භාරයෙන් ~ 40-60% ක් නිර්මාණය කරයි:
ගැටලුව නිරපේක්ෂ අහඹු සංඛ්‍යාතයක් සමඟ නැවත නැවතත් සිදු වූ අතර කේතයේ නව අනුවාදයක් එළිදැක්වූ මොහොත සමඟ ඉඳහිට සහසම්බන්ධ වේ.
kube-scheduler logging level 10 level (-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එයින් එක් නෝඩ් එකක් අනෙක් ඒවාට වඩා අඩු අවසාන ලකුණු ලබා ගත් බව දැක ගත හැකි අතර, එබැවින් උපරිම ලකුණු ලබා ගත් නෝඩ් දෙක සඳහා පමණක් සැලසුම් කිරීම සිදු කරන ලදී. මේ අනුව, ගැටලුව හරියටම ඇත්තේ කරල් කාලසටහන්ගත කිරීම තුළ බව අපට නිසැකවම ඒත්තු ගියේය.
ගැටළුව විසඳීම සඳහා තවදුරටත් ඇල්ගොරිතම අපට පැහැදිලි විය - ලඝු-සටහන් විශ්ලේෂණය කරන්න, නෝඩයට ලකුණු නොලැබුනේ කුමන ප්‍රමුඛතාවයකින් දැයි තේරුම් ගන්න සහ අවශ්‍ය නම්, පෙරනිමි kube-scheduler හි ප්‍රතිපත්ති සකස් කරන්න. කෙසේ වෙතත්, මෙහිදී අපට සැලකිය යුතු දුෂ්කරතා දෙකකට මුහුණ දීමට සිදු වේ:
- උපරිම ලොග් කිරීමේ මට්ටමේදී (10), සමහර ප්‍රමුඛතා සඳහා පමණක් ලබාගත් ලකුණු පිළිබිඹු වේ. ලඝු-සටහන් හි ඉහත උද්ධෘතයේ, ලඝු-සටහන් හි පිළිබිඹු වන සියලුම ප්‍රමුඛතා සඳහා, සාමාන්‍ය සහ ගැටළු උපලේඛනගත කිරීමේදී නෝඩ් එකම ලකුණු සංඛ්යාවක් ලබා ගන්නා බව ඔබට දැක ගත හැකිය, නමුත් ගැටළු සැලසුම් කිරීමේදී අවසාන ප්‍රති result ලය වෙනස් වේ. මේ අනුව, සමහර ප්‍රමුඛතා සඳහා, ලකුණු කිරීම “තිරය පිටුපස” සිදු වන බව අපට නිගමනය කළ හැකි අතර, නෝඩයට ලකුණු නොලැබුනේ කුමන ප්‍රමුඛතාවය සඳහාද යන්න තේරුම් ගැනීමට අපට ක්‍රමයක් නොමැත. අපි මෙම ගැටළුව විස්තරාත්මකව විස්තර කළෙමු Github මත Kubernetes ගබඩාව. ලියන අවස්ථාව වන විට, Kubernetes v1.15,1.16, 1.17 සහ XNUMX යාවත්කාලීනයන් තුළ logging support එක් කරන බවට සංවර්ධකයින්ගෙන් ප්‍රතිචාරයක් ලැබිණි.
- kube-scheduler දැනට වැඩ කරන්නේ කුමන නිශ්චිත ප්‍රතිපත්ති මාලාවක් සමඟද යන්න තේරුම් ගැනීමට පහසු ක්‍රමයක් නොමැත. ඔව්, ඇතුලේ මෙම ලැයිස්තුව ලැයිස්තුගත කර ඇත, නමුත් එහි එක් එක් ප්‍රමුඛතා ප්‍රතිපත්ති සඳහා නිශ්චිත බර පවරන දේ පිළිබඳ තොරතුරු අඩංගු නොවේ. ඔබට පෙරනිමි kube-scheduler හි බර බැලීම හෝ ප්‍රතිපත්ති සංස්කරණය කිරීම පමණක් කළ හැක .
යෙදුම ක්රියාත්මක කිරීමට අවශ්‍ය රූපය දැනටමත් තිබේ නම් නෝඩයකට ප්‍රදානය කරන ImageLocalityPriority ප්‍රතිපත්තියට අනුව නෝඩයකට ලකුණු නොලැබුණු බව වාර්තා කිරීමට අපට හැකි වූ පසු සඳහන් කිරීම වටී. එනම්, යෙදුමේ නව අනුවාදයක් එළිදක්වන අවස්ථාවේදී, ක්‍රෝන් කාර්යය නෝඩ් දෙකක් මත ක්රියාත්මක වීමට සමත් වූ අතර, ඒවාට ඩොකර් රෙජිස්ට්‍රියෙන් නව රූපයක් බාගත කළ අතර එමඟින් නෝඩ් දෙකකට තුන්වන එකට සාපේක්ෂව ඉහළ අවසාන ලකුණු ලැබුණි. .
මා ඉහත ලියා ඇති පරිදි, ලඝු-සටහන් වල ImageLocalityPriority ප්‍රතිපත්තිය ඇගයීම පිළිබඳ තොරතුරු අපට නොපෙනේ, එබැවින් අපගේ උපකල්පනය පරීක්ෂා කිරීම සඳහා, අපි යෙදුමේ නව අනුවාදය සමඟ රූපය තෙවන නෝඩයට දැමූ අතර, පසුව උපලේඛනගත කිරීම නිවැරදිව ක්රියාත්මක විය. . නිශ්චිතවම ImageLocalityPriority ප්‍රතිපත්තිය නිසා උපලේඛනගත කිරීමේ ගැටලුව ඉතා කලාතුරකින් නිරීක්ෂණය විය; බොහෝ විට එය වෙනත් දෙයක් සමඟ සම්බන්ධ විය. පෙරනිමි kube-scheduler හි ප්‍රමුඛතා ලැයිස්තුවේ ඇති එක් එක් ප්‍රතිපත්ති සම්පූර්ණයෙන් දෝෂහරණය කිරීමට අපට නොහැකි වූ නිසා, අපට Pod scheduling ප්‍රතිපත්තිවල නම්‍යශීලී කළමනාකරණයක් අවශ්‍ය විය.
ගැටලුව ප්රකාශ කිරීම
අපට අවශ්‍ය වූයේ ගැටලුවට විසඳුම හැකිතාක් නිශ්චිතව, එනම්, Kubernetes හි ප්රධාන ආයතන (මෙහි අප අදහස් කරන්නේ පෙරනිමි kube-scheduler) නොවෙනස්ව පැවතිය යුතු බවයි. අපිට ඕන වුණේ එක තැනක තියෙන ප්‍රශ්නයක් විසඳලා තව තැනක ඒක නිර්මාණය කරන්න නෙවෙයි. මේ අනුව, අපි ගැටළුව විසඳීම සඳහා විකල්ප දෙකකට පැමිණියෙමු, ඒවා ලිපියේ හැඳින්වීමේදී නිවේදනය කරන ලදී - අතිරේක උපලේඛනයක් නිර්මාණය කිරීම හෝ ඔබේම ලිවීම. ක්‍රෝන් කාර්යයන් උපලේඛනගත කිරීමේ ප්රධාන අවශ්‍යතාවය වන්නේ නෝඩ් තුනක් හරහා බර ඒකාකාරව බෙදා හැරීමයි. පවතින kube-scheduler ප්‍රතිපත්ති මගින් මෙම අවශ්‍යතාවය තෘප්තිමත් කළ හැක, එබැවින් අපගේ ගැටලුව විසඳීම සඳහා ඔබේම උපලේඛකයක් ලිවීමේ තේරුමක් නැත.
අතිරේක kube-scheduler එකක් නිර්මාණය කිරීම සහ යෙදවීම සඳහා උපදෙස් විස්තර කර ඇත . කෙසේ වෙතත්, kube-scheduler වැනි තීරණාත්මක සේවාවක් ක්රියාත්මක කිරීමේදී දෝෂ ඉවසීම සහතික කිරීමට Deployment entity ප්‍රමාණවත් නොවන බව අපට පෙනුණි, එබැවින් අපි නව kube-scheduler එකක් Static Pod එකක් ලෙස යෙදවීමට තීරණය කළෙමු, එය සෘජුවම නිරීක්ෂණය කෙරේ. Kubelet විසිනි. මේ අනුව, නව kube-scheduler සඳහා අපට පහත අවශ්‍යතා තිබේ:
- සේවාව සියලුම පොකුරු ප්‍රධානීන් මත ස්ථිතික පොඩ් එකක් ලෙස යෙදවිය යුතුය
- kube-scheduler සමඟ සක්රිය පොඩ් එක නොමැති අවස්ථාවක දෝෂ ඉවසීම සැපයිය යුතුය
- සැලසුම් කිරීමේදී ප්රධාන ප්‍රමුඛතාවය විය යුත්තේ නෝඩයේ ඇති සම්පත් ගණනයි (LeastRequestedPriority)
ක්රියාත්මක කිරීමේ විසඳුම්
අපි Kubernetes v1.14.7 හි සියලු කටයුතු සිදු කරන බව වහාම සඳහන් කිරීම වටී, මන්ද මෙම ව්යාපෘතියේ භාවිතා කරන ලද අනුවාදය මෙයයි. අපගේ නව kube-scheduler සඳහා ප්‍රතිපත්ති ප්‍රකාශයක් ලිවීමෙන් ආරම්භ කරමු. අපි පෙරනිමි මැනිෆෙස්ටය (/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සහ අපට පෙරනිමි kube-scheduler (10251 සහ 10259) ලෙස එකම වරායන් භාවිතා කළ නොහැක. - --config පරාමිතිය භාවිතා කරමින්, අපි සේවාව ආරම්භ කළ යුතු වින්‍යාස ගොනුව සඳහන් කළෙමු.
- වින්‍යාසගත ගොනුව (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"ප්රධාන වෙනස්කම් ගැන කෙටියෙන්:
- අපි අපේ kube-scheduler-cron සේවාවේ නමට කාලසටහන් නම සකසමු.
- පරාමිතිය තුළ
lockObjectNameඔබ අපගේ සේවාවේ නම සැකසිය යුතු අතර පරාමිතිය බවට වග බලා ගන්නleaderElectසත්‍ය ලෙස සකසන්න (ඔබට එක් ප්රධාන නෝඩයක් තිබේ නම්, ඔබට එය අසත්‍ය ලෙස සැකසිය හැක). - පරාමිතියෙහි උපලේඛනගත කිරීමේ ප්‍රතිපත්ති පිළිබඳ විස්තරයක් සමඟ ගොනුව වෙත යන මාර්ගය සඳහන් කර ඇත
algorithmSource.
අපි යතුර සඳහා පරාමිතීන් සංස්කරණය කරන දෙවන කරුණ දෙස සමීපව බැලීම වටී leaderElection. වැරදි ඉවසීම සහතික කිරීම සඳහා, අපි සක්රිය කර ඇත (leaderElect(resourceLockkube-scheduler-cron ලෙස නම් කර ඇත (lockObjectName) kube-system namespace හි (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 ප්‍රථමයෙන් GeneralPredicates ප්‍රතිපත්තියට (PodFitsResources, PodFitsHostPorts, HostName, සහ MatchNodeSelector ප්‍රතිපත්ති මාලාව ඇතුළත්) අනුව පොඩ් එකක් කාලසටහන්ගත කළ හැකි නෝඩ් ලැයිස්තුවක් සම්පාදනය කරයි. ඉන්පසු සෑම නෝඩයක්ම ප්‍රමුඛතා අරාවේ ප්‍රතිපත්ති මාලාවට අනුකූලව ඇගයීමට ලක් කෙරේ. අපගේ කාර්යයේ කොන්දේසි සපුරාලීම සඳහා, එවැනි ප්‍රතිපත්ති මාලාවක් ප්‍රශස්ත විසඳුම වනු ඇතැයි අපි සැලකුවෙමු. ඒවායේ සවිස්තරාත්මක විස්තර සහිත ප්‍රතිපත්ති මාලාවක් ලබා ගත හැකි බව මම ඔබට මතක් කරමි . ඔබගේ කාර්යය ඉටු කිරීම සඳහා, ඔබට භාවිතා කරන ප්‍රතිපත්ති මාලාව සරලව වෙනස් කර ඒවාට සුදුසු බර පැවරිය හැක.
අපි පරිච්ඡේදයේ ආරම්භයේ දී අප විසින් නිර්මාණය කරන ලද නව kube-scheduler හි මැනිෆෙස්ට් එක, kube-scheduler-custom.yaml ලෙස හඳුන්වමු, එය පහත දැක්වෙන මාර්ගයෙහි /etc/kubernetes/manifests ප්රධාන නෝඩ් තුනක තබමු. සෑම දෙයක්ම නිවැරදිව සිදු කර ඇත්නම්, Kubelet විසින් එක් එක් නෝඩය මත පොඩ් එකක් දියත් කරනු ඇති අතර, අපගේ නව 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:{}]'දැන් ඉතිරිව ඇත්තේ අපගේ CronJob හි පිරිවිතරය තුළ එහි කරල් උපලේඛනගත කිරීම සඳහා වන සියලුම ඉල්ලීම් අපගේ නව kube-scheduler විසින් සැකසිය යුතු බව දැක්වීමයි:
...
jobTemplate:
spec:
template:
spec:
schedulerName: kube-scheduler-cron
...නිගමනය
අවසානයේදී, අපට සුවිශේෂී කාලසටහන්ගත කිරීමේ ප්‍රතිපත්ති මාලාවක් සහිත අතිරේක kube-කාලසටහන්ගත කරන්නෙකු ලැබුණි, එහි කාර්යය kubelet විසින් සෘජුවම නිරීක්ෂණය කරනු ලැබේ. ඊට අමතරව, කිසියම් හේතුවක් නිසා පැරණි නායකයා නොමැති වුවහොත් අපගේ kube-scheduler ගේ පොඩ්ඩෝ අතර නව නායකයෙකු තෝරා ගැනීම අපි පිහිටුවා ඇත.
නිත්‍ය යෙදුම් සහ සේවා පෙරනිමි kube-scheduler හරහා කාලසටහන්ගත කර ඇති අතර, සියලු ක්‍රෝන් කාර්යයන් සම්පූර්ණයෙන්ම නව එකට මාරු කර ඇත. ක්‍රෝන් කර්තව්‍යයන් මගින් සාදන ලද භාරය දැන් සියලුම නෝඩ් හරහා ඒකාකාරව බෙදා හරිනු ලැබේ. බොහෝ ක්‍රෝන් කාර්යයන් ව්යාපෘතියේ ප්රධාන යෙදුම් ලෙස එකම නෝඩ් මත ක්රියාත්මක වන බව සලකන විට, මෙය සම්පත් හිඟය හේතුවෙන් කරල් චලනය වීමේ අවදානම සැලකිය යුතු ලෙස අඩු කර ඇත. අතිරේක kube-scheduler හඳුන්වා දීමෙන් පසුව, ක්‍රෝන් කාර්යයන් අසමාන කාලසටහන්ගත කිරීම පිළිබඳ ගැටළු තවදුරටත් මතු නොවීය.
අපගේ බ්ලොග් අඩවියේ වෙනත් ලිපිද කියවන්න:
මූලාශ්රය: www.habr.com