ഷെഡ്യൂളിംഗ് നിയമങ്ങളുടെ ഒരു ഇഷ്‌ടാനുസൃത സെറ്റ് ഉപയോഗിച്ച് ഒരു അധിക ക്യൂബ്-ഷെഡ്യൂളർ സൃഷ്‌ടിക്കുന്നു

കുബെർനെറ്റസിൻ്റെ ഒരു അവിഭാജ്യ ഘടകമാണ് ക്യൂബ്-ഷെഡ്യൂളർ, ഇത് നിർദ്ദിഷ്ട നയങ്ങൾക്ക് അനുസൃതമായി നോഡുകളിലുടനീളം പോഡുകൾ ഷെഡ്യൂൾ ചെയ്യുന്നതിന് ഉത്തരവാദിയാണ്. മിക്കപ്പോഴും, ഒരു കുബർനെറ്റസ് ക്ലസ്റ്ററിൻ്റെ പ്രവർത്തന സമയത്ത്, പോഡുകൾ ഷെഡ്യൂൾ ചെയ്യാൻ ഏത് പോളിസികളാണ് ഉപയോഗിക്കുന്നതെന്ന് ഞങ്ങൾ ചിന്തിക്കേണ്ടതില്ല, കാരണം ഡിഫോൾട്ട് ക്യൂബ്-ഷെഡ്യൂളറിൻ്റെ പോളിസികളുടെ സെറ്റ് മിക്ക ദൈനംദിന ജോലികൾക്കും അനുയോജ്യമാണ്. എന്നിരുന്നാലും, പോഡുകൾ അനുവദിക്കുന്ന പ്രക്രിയ നന്നായി ക്രമീകരിക്കേണ്ടത് പ്രധാനമായ സാഹചര്യങ്ങളുണ്ട്, കൂടാതെ ഈ ചുമതല നിർവഹിക്കുന്നതിന് രണ്ട് വഴികളുണ്ട്:

1. ഒരു ഇഷ്‌ടാനുസൃത നിയമങ്ങളുള്ള ഒരു ക്യൂബ്-ഷെഡ്യൂളർ സൃഷ്‌ടിക്കുക
2. നിങ്ങളുടെ സ്വന്തം ഷെഡ്യൂളർ എഴുതി API സെർവർ അഭ്യർത്ഥനകൾക്കൊപ്പം പ്രവർത്തിക്കാൻ പഠിപ്പിക്കുക

ഈ ലേഖനത്തിൽ, ഞങ്ങളുടെ പ്രോജക്റ്റുകളിലൊന്നിൽ ചൂളകളുടെ അസമമായ ഷെഡ്യൂളിൻ്റെ പ്രശ്നം പരിഹരിക്കുന്നതിനുള്ള ആദ്യ പോയിൻ്റ് നടപ്പിലാക്കുന്നത് ഞാൻ വിവരിക്കും.

ക്യൂബ് ഷെഡ്യൂളർ എങ്ങനെ പ്രവർത്തിക്കുന്നു എന്നതിനെക്കുറിച്ചുള്ള ഒരു ഹ്രസ്വ ആമുഖം

പോഡുകൾ നേരിട്ട് ഷെഡ്യൂൾ ചെയ്യുന്നതിന് ക്യൂബ്-ഷെഡ്യൂളർ ഉത്തരവാദിയല്ല എന്ന വസ്തുത പ്രത്യേകം ശ്രദ്ധിക്കേണ്ടതാണ് - പോഡ് സ്ഥാപിക്കേണ്ട നോഡ് നിർണ്ണയിക്കുന്നതിനുള്ള ഉത്തരവാദിത്തം മാത്രമാണ് ഇതിന്. മറ്റൊരു വിധത്തിൽ പറഞ്ഞാൽ, ക്യൂബ്-ഷെഡ്യൂളറുടെ പ്രവർത്തനത്തിൻ്റെ ഫലം നോഡിൻ്റെ പേരാണ്, അത് ഷെഡ്യൂളിംഗ് അഭ്യർത്ഥനയ്ക്കായി API സെർവറിലേക്ക് മടങ്ങുന്നു, അവിടെയാണ് അതിൻ്റെ ജോലി അവസാനിക്കുന്നത്.

ആദ്യം, kube-scheduler, പ്രെഡിക്കേറ്റ് പോളിസികൾക്ക് അനുസൃതമായി പോഡ് ഷെഡ്യൂൾ ചെയ്യാൻ കഴിയുന്ന നോഡുകളുടെ ഒരു ലിസ്റ്റ് കംപൈൽ ചെയ്യുന്നു. അടുത്തതായി, ഈ ലിസ്റ്റിൽ നിന്നുള്ള ഓരോ നോഡിനും മുൻഗണനാ നയങ്ങൾക്ക് അനുസൃതമായി നിശ്ചിത എണ്ണം പോയിൻ്റുകൾ ലഭിക്കും. ഫലമായി, പരമാവധി എണ്ണം പോയിൻ്റുകളുള്ള നോഡ് തിരഞ്ഞെടുത്തു. ഒരേ പരമാവധി സ്കോർ ഉള്ള നോഡുകൾ ഉണ്ടെങ്കിൽ, ക്രമരഹിതമായ ഒന്ന് തിരഞ്ഞെടുക്കപ്പെടും. പ്രവചനങ്ങൾ (ഫിൽട്ടറിംഗ്), മുൻഗണനകൾ (സ്കോറിംഗ്) നയങ്ങളുടെ ഒരു ലിസ്റ്റും വിവരണവും ഇതിൽ കാണാം പ്രമാണീകരണം.

പ്രശ്നമുള്ള ശരീരത്തിൻ്റെ വിവരണം

Nixys-ൽ നിരവധി വ്യത്യസ്ത Kubernetes ക്ലസ്റ്ററുകൾ പരിപാലിക്കപ്പെടുന്നുണ്ടെങ്കിലും, ഞങ്ങളുടെ പ്രോജക്‌റ്റുകളിലൊന്നിന് ധാരാളം പീരിയോഡിക് ടാസ്‌ക്കുകൾ (~100 CronJob എൻ്റിറ്റികൾ) പ്രവർത്തിപ്പിക്കേണ്ടി വന്നപ്പോൾ, അടുത്തിടെയാണ് പോഡുകൾ ഷെഡ്യൂൾ ചെയ്യുന്ന പ്രശ്നം ഞങ്ങൾ ആദ്യം നേരിട്ടത്. പ്രശ്‌നത്തിൻ്റെ വിവരണം കഴിയുന്നത്ര ലളിതമാക്കാൻ, ഞങ്ങൾ ഒരു മൈക്രോസർവീസ് ഉദാഹരണമായി എടുക്കും, അതിനുള്ളിൽ മിനിറ്റിൽ ഒരിക്കൽ ഒരു ക്രോൺ ടാസ്‌ക് സമാരംഭിക്കുകയും സിപിയുവിൽ കുറച്ച് ലോഡ് സൃഷ്ടിക്കുകയും ചെയ്യുന്നു. ക്രോൺ ടാസ്‌ക് പ്രവർത്തിപ്പിക്കുന്നതിന്, തികച്ചും സമാനമായ സ്വഭാവസവിശേഷതകളുള്ള മൂന്ന് നോഡുകൾ അനുവദിച്ചു (ഓരോന്നിലും 24 vCPU-കൾ).

അതേസമയം, ഇൻപുട്ട് ഡാറ്റയുടെ അളവ് നിരന്തരം മാറിക്കൊണ്ടിരിക്കുന്നതിനാൽ, ക്രോൺജോബ് എക്സിക്യൂട്ട് ചെയ്യാൻ എത്ര സമയമെടുക്കുമെന്ന് കൃത്യമായി പറയാൻ കഴിയില്ല. ശരാശരി, ക്യൂബ്-ഷെഡ്യൂളറിൻ്റെ സാധാരണ പ്രവർത്തന സമയത്ത്, ഓരോ നോഡും 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), ചില മുൻഗണനകൾക്കായി മാത്രം നേടിയ പോയിൻ്റുകൾ പ്രതിഫലിക്കുന്നു. ലോഗുകളുടെ മുകളിലെ ഉദ്ധരണിയിൽ, ലോഗുകളിൽ പ്രതിഫലിക്കുന്ന എല്ലാ മുൻഗണനകൾക്കും നോഡുകൾ സാധാരണയിലും പ്രശ്‌ന ഷെഡ്യൂളിംഗിലും ഒരേ എണ്ണം പോയിൻ്റുകൾ സ്‌കോർ ചെയ്യുന്നതായി നിങ്ങൾക്ക് കാണാൻ കഴിയും, എന്നാൽ പ്രശ്‌ന ആസൂത്രണത്തിൻ്റെ കാര്യത്തിൽ അന്തിമ ഫലം വ്യത്യസ്തമാണ്. അതിനാൽ, ചില മുൻഗണനകൾക്കായി, സ്‌കോറിംഗ് "തിരശ്ശീലയ്ക്ക് പിന്നിൽ" സംഭവിക്കുന്നുവെന്ന് നമുക്ക് നിഗമനം ചെയ്യാം, കൂടാതെ നോഡിന് ഏത് മുൻഗണനയ്ക്കാണ് പോയിൻ്റുകൾ ലഭിച്ചില്ലെന്ന് മനസിലാക്കാൻ ഞങ്ങൾക്ക് മാർഗമില്ല. ഈ പ്രശ്നം ഞങ്ങൾ വിശദമായി വിവരിച്ചു ഇഷ്യൂ ഗിത്തബിലെ കുബർനെറ്റസ് ശേഖരം. എഴുതുന്ന സമയത്ത്, Kubernetes v1.15,1.16, 1.17, XNUMX അപ്‌ഡേറ്റുകളിൽ ലോഗിംഗ് പിന്തുണ ചേർക്കുമെന്ന് ഡവലപ്പർമാരിൽ നിന്ന് ഒരു പ്രതികരണം ലഭിച്ചു.
2. ഏത് നിർദ്ദിഷ്ട നയങ്ങളിലാണ് kube-scheduler നിലവിൽ പ്രവർത്തിക്കുന്നതെന്ന് മനസിലാക്കാൻ എളുപ്പവഴിയില്ല. അതെ, ഇൻ പ്രമാണീകരണം ഈ ലിസ്‌റ്റ് ലിസ്‌റ്റ് ചെയ്‌തിട്ടുണ്ട്, എന്നാൽ ഓരോ മുൻഗണന നയങ്ങൾക്കും ഏതൊക്കെ നിർദിഷ്ട തൂക്കങ്ങളാണ് നൽകിയിരിക്കുന്നത് എന്നതിനെക്കുറിച്ചുള്ള വിവരങ്ങൾ ഇതിൽ അടങ്ങിയിട്ടില്ല. ഡിഫോൾട്ട് ക്യൂബ്-ഷെഡ്യൂളറിൻ്റെ ഭാരങ്ങൾ കാണാനോ നയങ്ങൾ എഡിറ്റ് ചെയ്യാനോ മാത്രമേ നിങ്ങൾക്ക് കഴിയൂ സോഴ്സ് കോഡുകൾ.

ഇമേജ് ലോക്കാലിറ്റി പ്രയോറിറ്റി പോളിസി അനുസരിച്ച് ഒരു നോഡിന് പോയിൻ്റുകൾ ലഭിച്ചിട്ടില്ലെന്ന് ഒരിക്കൽ രേഖപ്പെടുത്താൻ ഞങ്ങൾക്ക് കഴിഞ്ഞു എന്നത് ശ്രദ്ധിക്കേണ്ടതാണ്, ആപ്ലിക്കേഷൻ പ്രവർത്തിപ്പിക്കുന്നതിന് ആവശ്യമായ ഇമേജ് ഇതിനകം ഉണ്ടെങ്കിൽ ഒരു നോഡിന് അവാർഡ് നൽകുന്നു. അതായത്, ആപ്ലിക്കേഷൻ്റെ ഒരു പുതിയ പതിപ്പ് പുറത്തിറക്കിയ സമയത്ത്, ക്രോൺ ടാസ്‌ക് രണ്ട് നോഡുകളിൽ പ്രവർത്തിക്കാൻ കഴിഞ്ഞു, ഡോക്കർ രജിസ്ട്രിയിൽ നിന്ന് ഒരു പുതിയ ചിത്രം അവയിലേക്ക് ഡൗൺലോഡ് ചെയ്തു, അങ്ങനെ രണ്ട് നോഡുകൾക്ക് മൂന്നാമത്തേതിനെ അപേക്ഷിച്ച് ഉയർന്ന അന്തിമ സ്കോർ ലഭിച്ചു. .

ഞാൻ മുകളിൽ എഴുതിയത് പോലെ, ലോഗുകളിൽ ImageLocality Priority നയത്തിൻ്റെ മൂല്യനിർണ്ണയത്തെക്കുറിച്ചുള്ള വിവരങ്ങൾ ഞങ്ങൾ കാണുന്നില്ല, അതിനാൽ ഞങ്ങളുടെ അനുമാനം പരിശോധിക്കുന്നതിനായി, ആപ്ലിക്കേഷൻ്റെ പുതിയ പതിപ്പ് ഉള്ള ചിത്രം ഞങ്ങൾ മൂന്നാം നോഡിലേക്ക് ഇട്ടു, അതിനുശേഷം ഷെഡ്യൂളിംഗ് ശരിയായി പ്രവർത്തിച്ചു. . ImageLocalityPriority നയം കാരണം, ഷെഡ്യൂളിംഗ് പ്രശ്നം വളരെ അപൂർവമായി മാത്രമേ നിരീക്ഷിക്കപ്പെട്ടിട്ടുള്ളൂ; മിക്കപ്പോഴും ഇത് മറ്റെന്തെങ്കിലും ബന്ധപ്പെട്ടിരിക്കുന്നു. ഡിഫോൾട്ട് ക്യൂബ്-ഷെഡ്യൂളറിൻ്റെ മുൻഗണനകളുടെ പട്ടികയിലെ ഓരോ പോളിസികളും പൂർണ്ണമായി ഡീബഗ് ചെയ്യാൻ ഞങ്ങൾക്ക് കഴിയാത്തതിനാൽ, പോഡ് ഷെഡ്യൂളിംഗ് പോളിസികളുടെ ഫ്ലെക്സിബിൾ മാനേജ്‌മെൻ്റ് ഞങ്ങൾക്ക് ആവശ്യമായിരുന്നു.

പ്രശ്ന പ്രസ്താവന

പ്രശ്നത്തിനുള്ള പരിഹാരം കഴിയുന്നത്ര വ്യക്തമായിരിക്കണമെന്ന് ഞങ്ങൾ ആഗ്രഹിച്ചു, അതായത്, കുബർനെറ്റസിൻ്റെ പ്രധാന സ്ഥാപനങ്ങൾ (ഇവിടെ ഞങ്ങൾ അർത്ഥമാക്കുന്നത് ഡിഫോൾട്ട് ക്യൂബ്-ഷെഡ്യൂളർ) മാറ്റമില്ലാതെ തുടരണം. ഒരിടത്ത് പ്രശ്‌നം പരിഹരിച്ച് മറ്റൊരിടത്ത് പ്രശ്‌നം സൃഷ്ടിക്കാൻ ഞങ്ങൾ ആഗ്രഹിച്ചില്ല. അതിനാൽ, പ്രശ്നം പരിഹരിക്കുന്നതിനുള്ള രണ്ട് ഓപ്ഷനുകളിലേക്ക് ഞങ്ങൾ എത്തി, അത് ലേഖനത്തിൻ്റെ ആമുഖത്തിൽ പ്രഖ്യാപിച്ചു - ഒരു അധിക ഷെഡ്യൂളർ സൃഷ്ടിക്കുക അല്ലെങ്കിൽ നിങ്ങളുടേത് എഴുതുക. ക്രോൺ ടാസ്‌ക്കുകൾ ഷെഡ്യൂൾ ചെയ്യുന്നതിനുള്ള പ്രധാന ആവശ്യകത മൂന്ന് നോഡുകളിലുടനീളം ലോഡ് തുല്യമായി വിതരണം ചെയ്യുക എന്നതാണ്. നിലവിലുള്ള kube-ഷെഡ്യൂളർ നയങ്ങളാൽ ഈ ആവശ്യകത തൃപ്തിപ്പെടുത്താൻ കഴിയും, അതിനാൽ ഞങ്ങളുടെ പ്രശ്നം പരിഹരിക്കുന്നതിന് നിങ്ങളുടെ സ്വന്തം ഷെഡ്യൂളർ എഴുതുന്നതിൽ അർത്ഥമില്ല.

ഒരു അധിക ക്യൂബ് ഷെഡ്യൂളർ സൃഷ്ടിക്കുന്നതിനും വിന്യസിക്കുന്നതിനുമുള്ള നിർദ്ദേശങ്ങൾ വിവരിച്ചിരിക്കുന്നു പ്രമാണീകരണം. എന്നിരുന്നാലും, ക്യൂബ്-ഷെഡ്യൂളർ പോലുള്ള ഒരു നിർണായക സേവനത്തിൻ്റെ പ്രവർത്തനത്തിലെ പിഴവ് സഹിഷ്ണുത ഉറപ്പാക്കാൻ വിന്യാസ സ്ഥാപനം പര്യാപ്തമല്ലെന്ന് ഞങ്ങൾക്ക് തോന്നി, അതിനാൽ ഒരു പുതിയ ക്യൂബ്-ഷെഡ്യൂളറിനെ ഒരു സ്റ്റാറ്റിക് പോഡായി വിന്യസിക്കാൻ ഞങ്ങൾ തീരുമാനിച്ചു, അത് നേരിട്ട് നിരീക്ഷിക്കപ്പെടും. കുബെലെറ്റിൻ്റെ. അതിനാൽ, പുതിയ ക്യൂബ്-ഷെഡ്യൂളറിനായി ഞങ്ങൾക്ക് ഇനിപ്പറയുന്ന ആവശ്യകതകൾ ഉണ്ട്:

1. എല്ലാ ക്ലസ്റ്റർ മാസ്റ്ററുകളിലും ഈ സേവനം ഒരു സ്റ്റാറ്റിക് പോഡായി വിന്യസിച്ചിരിക്കണം
2. ക്യൂബ്-ഷെഡ്യൂളറുള്ള സജീവ പോഡ് ലഭ്യമല്ലെങ്കിൽ, തെറ്റ് സഹിഷ്ണുത നൽകണം
3. ആസൂത്രണം ചെയ്യുമ്പോൾ പ്രധാന മുൻഗണന നോഡിൽ ലഭ്യമായ ഉറവിടങ്ങളുടെ എണ്ണമായിരിക്കണം (LastRequestedPriority)

പരിഹാരം നടപ്പിലാക്കൽ

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. പോഡിൻ്റെയും കണ്ടെയ്‌നറിൻ്റെയും പേര് kube-scheduler-cron എന്നാക്കി മാറ്റി
2. ഓപ്ഷൻ നിർവചിച്ചിരിക്കുന്നതുപോലെ 10151, 10159 എന്നീ പോർട്ടുകളുടെ ഉപയോഗം വ്യക്തമാക്കി hostNetwork: true ഡിഫോൾട്ട് ക്യൂബ്-ഷെഡ്യൂളർ (10251, 10259) പോലെയുള്ള അതേ പോർട്ടുകൾ ഞങ്ങൾക്ക് ഉപയോഗിക്കാൻ കഴിയില്ല.
3. --config പാരാമീറ്റർ ഉപയോഗിച്ച്, സേവനം ആരംഭിക്കേണ്ട കോൺഫിഗറേഷൻ ഫയൽ ഞങ്ങൾ വ്യക്തമാക്കി.
4. കോൺഫിഗറേഷൻ ഫയലിൻ്റെ കോൺഫിഗർ ചെയ്‌ത മൗണ്ടിംഗ് (ഷെഡ്യൂളർ-കസ്റ്റം. കോൺഫ്), ഹോസ്റ്റിൽ നിന്നുള്ള പോളിസി ഫയലും (ഷെഡ്യൂളർ-കസ്റ്റം-പൊളിസി-config.json) ഷെഡ്യൂൾ ചെയ്യുന്നു

ഞങ്ങളുടെ kube-ഷെഡ്യൂളറിന് ഡിഫോൾട്ട് അവകാശങ്ങൾക്ക് സമാനമായ അവകാശങ്ങൾ ആവശ്യമാണെന്ന് മറക്കരുത്. അതിൻ്റെ ക്ലസ്റ്റർ റോൾ എഡിറ്റ് ചെയ്യുക:

kubectl edit clusterrole system:kube-scheduler

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

കോൺഫിഗറേഷൻ ഫയലിലും ഷെഡ്യൂളിംഗ് പോളിസി ഫയലിലും എന്താണ് അടങ്ങിയിരിക്കേണ്ടതെന്ന് ഇപ്പോൾ നമുക്ക് സംസാരിക്കാം:

• കോൺഫിഗറേഷൻ ഫയൽ (scheduler-custom.conf)
  ഡിഫോൾട്ട് kube-ഷെഡ്യൂളർ കോൺഫിഗറേഷൻ ലഭിക്കുന്നതിന്, നിങ്ങൾ പരാമീറ്റർ ഉപയോഗിക്കണം --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. ഞങ്ങളുടെ kube-scheduler-cron സേവനത്തിൻ്റെ പേരിലേക്ക് ഞങ്ങൾ ഷെഡ്യൂളർനെയിം സജ്ജമാക്കി.
2. പരാമീറ്ററിൽ lockObjectName നിങ്ങൾ ഞങ്ങളുടെ സേവനത്തിൻ്റെ പേരും സജ്ജീകരിക്കുകയും പരാമീറ്റർ ഉറപ്പാക്കുകയും വേണം leaderElect ശരി എന്ന് സജ്ജീകരിക്കുക (നിങ്ങൾക്ക് ഒരു മാസ്റ്റർ നോഡ് ഉണ്ടെങ്കിൽ, നിങ്ങൾക്കത് തെറ്റ് എന്ന് സജ്ജീകരിക്കാം).
3. പാരാമീറ്ററിലെ ഷെഡ്യൂളിംഗ് നയങ്ങളുടെ വിവരണത്തോടെ ഫയലിലേക്കുള്ള പാത വ്യക്തമാക്കി algorithmSource.

രണ്ടാമത്തെ പോയിൻ്റ് സൂക്ഷ്മമായി പരിശോധിക്കുന്നത് മൂല്യവത്താണ്, അവിടെ ഞങ്ങൾ കീയുടെ പാരാമീറ്ററുകൾ എഡിറ്റുചെയ്യുന്നു leaderElection. തെറ്റ് സഹിഷ്ണുത ഉറപ്പാക്കാൻ, ഞങ്ങൾ പ്രവർത്തനക്ഷമമാക്കി (leaderElect) ഞങ്ങളുടെ ക്യൂബ്-ഷെഡ്യൂളറുടെ പോഡുകൾക്കിടയിൽ ഒരു നേതാവിനെ (മാസ്റ്റർ) തിരഞ്ഞെടുക്കുന്ന പ്രക്രിയ അവയ്‌ക്കായി ഒരൊറ്റ എൻഡ്‌പോയിൻ്റ് ഉപയോഗിച്ച് (resourceLockkube-scheduler-cron എന്ന പേര്lockObjectNameക്യൂബ്-സിസ്റ്റം നെയിംസ്പേസിൽ (lockObjectNamespace). പ്രധാന ഘടകങ്ങളുടെ (ക്യൂബ്-ഷെഡ്യൂളർ ഉൾപ്പെടെ) ഉയർന്ന ലഭ്യത Kubernetes ഉറപ്പാക്കുന്നത് എങ്ങനെയെന്ന് കണ്ടെത്താനാകും ലേഖനം.

• പോളിസി ഫയൽ ഷെഡ്യൂൾ ചെയ്യുന്നു (ഷെഡ്യൂളർ-കസ്റ്റം-പൊളിസി-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 ആദ്യം GeneralPredicates പോളിസി (PodFitsResources, PodFitsHostPorts, HostName, MatchNodeSelector പോളിസികളുടെ ഒരു കൂട്ടം ഉൾപ്പെടുന്ന) അനുസരിച്ച് ഒരു പോഡ് ഷെഡ്യൂൾ ചെയ്യാൻ കഴിയുന്ന നോഡുകളുടെ ഒരു ലിസ്റ്റ് സമാഹരിക്കുന്നു. തുടർന്ന് മുൻഗണനാ ശ്രേണിയിലെ നയങ്ങളുടെ കൂട്ടത്തിന് അനുസൃതമായി ഓരോ നോഡും വിലയിരുത്തപ്പെടുന്നു. ഞങ്ങളുടെ ടാസ്ക്കിൻ്റെ വ്യവസ്ഥകൾ നിറവേറ്റുന്നതിന്, അത്തരം ഒരു കൂട്ടം നയങ്ങളാണ് ഏറ്റവും മികച്ച പരിഹാരമെന്ന് ഞങ്ങൾ കരുതി. വിശദമായ വിവരണങ്ങളുള്ള ഒരു കൂട്ടം നയങ്ങൾ ലഭ്യമാണെന്ന് ഞാൻ നിങ്ങളെ ഓർമ്മിപ്പിക്കട്ടെ പ്രമാണീകരണം. നിങ്ങളുടെ ടാസ്‌ക് പൂർത്തിയാക്കാൻ, നിങ്ങൾക്ക് ഉപയോഗിച്ച പോളിസികളുടെ സെറ്റ് മാറ്റുകയും അവയ്ക്ക് ഉചിതമായ തൂക്കങ്ങൾ നൽകുകയും ചെയ്യാം.

അധ്യായത്തിൻ്റെ തുടക്കത്തിൽ ഞങ്ങൾ സൃഷ്ടിച്ച പുതിയ kube-ഷെഡ്യൂളറിൻ്റെ മാനിഫെസ്റ്റിനെ, 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:{}]'

ഇപ്പോൾ അവശേഷിക്കുന്നത്, ഞങ്ങളുടെ CronJob-ൻ്റെ സ്പെസിഫിക്കേഷനിൽ അതിൻ്റെ പോഡുകൾ ഷെഡ്യൂൾ ചെയ്യുന്നതിനുള്ള എല്ലാ അഭ്യർത്ഥനകളും ഞങ്ങളുടെ പുതിയ kube-ഷെഡ്യൂളർ പ്രോസസ്സ് ചെയ്യണമെന്ന് സൂചിപ്പിക്കുക മാത്രമാണ്:

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

തീരുമാനം

ആത്യന്തികമായി, ക്യുബെലെറ്റ് നേരിട്ട് നിരീക്ഷിക്കുന്ന തനതായ ഷെഡ്യൂളിംഗ് നയങ്ങളുള്ള ഒരു അധിക ക്യൂബ്-ഷെഡ്യൂളർ ഞങ്ങൾക്ക് ലഭിച്ചു. കൂടാതെ, ചില കാരണങ്ങളാൽ പഴയ നേതാവ് ലഭ്യമല്ലാത്ത സാഹചര്യത്തിൽ, ഞങ്ങളുടെ കുബേ ഷെഡ്യൂളറുടെ പോഡുകൾക്കിടയിൽ ഞങ്ങൾ ഒരു പുതിയ നേതാവിൻ്റെ തിരഞ്ഞെടുപ്പ് സജ്ജീകരിച്ചിട്ടുണ്ട്.

സ്ഥിരമായ ക്യൂബ്-ഷെഡ്യൂളർ വഴി സ്ഥിരമായ ആപ്ലിക്കേഷനുകളും സേവനങ്ങളും ഷെഡ്യൂൾ ചെയ്യുന്നത് തുടരുന്നു, കൂടാതെ എല്ലാ ക്രോൺ ടാസ്‌ക്കുകളും പൂർണ്ണമായും പുതിയതിലേക്ക് മാറ്റുകയും ചെയ്‌തു. ക്രോൺ ടാസ്‌ക്കുകൾ സൃഷ്‌ടിച്ച ലോഡ് ഇപ്പോൾ എല്ലാ നോഡുകളിലും തുല്യമായി വിതരണം ചെയ്യപ്പെടുന്നു. പ്രോജക്റ്റിൻ്റെ പ്രധാന ആപ്ലിക്കേഷനുകളുടെ അതേ നോഡുകളിലാണ് മിക്ക ക്രോൺ ടാസ്ക്കുകളും നടപ്പിലാക്കുന്നത് എന്നത് കണക്കിലെടുക്കുമ്പോൾ, ഇത് വിഭവങ്ങളുടെ അഭാവം മൂലം പോഡുകൾ ചലിപ്പിക്കുന്നതിനുള്ള അപകടസാധ്യത ഗണ്യമായി കുറച്ചിരിക്കുന്നു. അധിക ക്യൂബ്-ഷെഡ്യൂളർ അവതരിപ്പിച്ച ശേഷം, ക്രോൺ ടാസ്‌ക്കുകളുടെ അസമമായ ഷെഡ്യൂളിംഗുമായി ബന്ധപ്പെട്ട പ്രശ്‌നങ്ങൾ മേലിൽ ഉയർന്നുവന്നില്ല.

ഞങ്ങളുടെ ബ്ലോഗിലെ മറ്റ് ലേഖനങ്ങളും വായിക്കുക:

• കാലിക്കോയ്‌ക്കൊപ്പം കുബർനെറ്റസ് ക്ലസ്റ്ററിലെ ട്രാഫിക് മാനേജ്‌മെൻ്റ്
• കാലിക്കോയുമായുള്ള നെറ്റ്‌വർക്ക് പോളിസി ഓപ്ഷനുകൾ മനസ്സിലാക്കുന്നു
• Linux contrack നിങ്ങളുടെ സുഹൃത്തല്ലെങ്കിൽ
• അയോട്ട കൈമാറ്റങ്ങളുടെ 4 ഉദാഹരണങ്ങൾ
• പ്രവർത്തനരഹിതമായ ഒരു കുബർനെറ്റസ് ക്ലസ്റ്റർ അപ്‌ഗ്രേഡുചെയ്യുന്നു
• സീറോ ഡൌൺടൈം വിന്യാസവും ഡാറ്റാബേസുകളും
• കുബെർനെറ്റസ്: സിസ്റ്റം റിസോഴ്‌സ് മാനേജ്‌മെന്റ് കോൺഫിഗർ ചെയ്യേണ്ടത് എന്തുകൊണ്ട്?

അവലംബം: www.habr.com