കുബർനെറ്റസ് ക്ലസ്റ്റർ ഉറവിടങ്ങൾ നിരീക്ഷിക്കുന്നു

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

നേട്ടങ്ങളെക്കുറിച്ച് ഞാൻ നിങ്ങളോട് പറയും കുബെ കഴുകൻ, എന്നാൽ ബഹളത്തിന് കാരണമായത് എന്താണെന്നും ഉയർന്ന നിലവാരമുള്ള നിരീക്ഷണം ആവശ്യമായി വന്നത് എന്തുകൊണ്ടാണെന്നും ഞാൻ ആദ്യം വിശദീകരിക്കും.

4-50 നോഡുകളുടെ നിരവധി ക്ലസ്റ്ററുകൾ ഞാൻ കൈകാര്യം ചെയ്തു. ഓരോ ക്ലസ്റ്ററിലും 200 മൈക്രോ സർവീസുകളും ആപ്ലിക്കേഷനുകളും വരെ അടങ്ങിയിരിക്കുന്നു. നിലവിലുള്ള ഹാർഡ്‌വെയറിന്റെ മികച്ച ഉപയോഗത്തിനായി, മിക്ക വിന്യാസങ്ങളും ബർസ്റ്റബിൾ റാമും സിപിയു ഉറവിടങ്ങളും ഉപയോഗിച്ച് കോൺഫിഗർ ചെയ്‌തു. ഈ രീതിയിൽ, ആവശ്യമെങ്കിൽ പോഡുകൾക്ക് ലഭ്യമായ ഉറവിടങ്ങൾ എടുക്കാം, അതേ സമയം ഈ നോഡിലെ മറ്റ് ആപ്ലിക്കേഷനുകളിൽ ഇടപെടരുത്. ശരി, അത് മികച്ചതല്ലേ?

ക്ലസ്റ്റർ താരതമ്യേന കുറച്ച് സിപിയു (8%), റാമും (40%) ഉപയോഗിച്ചെങ്കിലും, നോഡിൽ ലഭ്യമായതിനേക്കാൾ കൂടുതൽ മെമ്മറി അനുവദിക്കാൻ ശ്രമിക്കുമ്പോൾ പോഡുകൾ മുൻകൂട്ടി ഉപയോഗിക്കുന്നതിൽ ഞങ്ങൾക്ക് നിരന്തരം പ്രശ്നങ്ങൾ ഉണ്ടായിരുന്നു. കുബർനെറ്റസ് റിസോഴ്‌സുകൾ നിരീക്ഷിക്കാൻ ഞങ്ങൾക്ക് ഒരു ഡാഷ്‌ബോർഡ് മാത്രമേ ഉണ്ടായിരുന്നുള്ളൂ. ഇതുപോലെ:

cAdvisor മെട്രിക്‌സ് മാത്രമുള്ള ഗ്രാഫാന ഡാഷ്‌ബോർഡ്

അത്തരമൊരു പാനൽ ഉപയോഗിച്ച്, ധാരാളം മെമ്മറിയും സിപിയുവും കഴിക്കുന്ന നോഡുകൾ കാണുന്നത് ഒരു പ്രശ്നമല്ല. കാരണം എന്താണെന്ന് കണ്ടെത്തുന്നതാണ് പ്രശ്നം. കായ്കൾ നിലനിറുത്തുന്നതിന്, തീർച്ചയായും എല്ലാ കായ്കളിലും ഗ്യാരണ്ടീഡ് റിസോഴ്‌സുകൾ സജ്ജീകരിക്കാം (പരിധിക്ക് തുല്യമായ വിഭവങ്ങൾ അഭ്യർത്ഥിക്കുന്നു). എന്നാൽ ഇത് ഹാർഡ്‌വെയറിന്റെ ഏറ്റവും മികച്ച ഉപയോഗമല്ല. ക്ലസ്റ്ററിന് നൂറുകണക്കിന് ജിഗാബൈറ്റ് മെമ്മറി ഉണ്ടായിരുന്നു, ചില നോഡുകൾ പട്ടിണിയിലായിരുന്നു, മറ്റുള്ളവയ്ക്ക് 4-10 ജിബി കരുതൽ ശേഖരം ഉണ്ടായിരുന്നു.

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

ഏറ്റവും സൗജന്യ ഉറവിടങ്ങളുള്ളതും അഭ്യർത്ഥന വ്യവസ്ഥകൾ പാലിക്കുന്നതുമായ നോഡ് പോഡിനായി തിരഞ്ഞെടുത്തു. നോഡുകളിലെ അഭ്യർത്ഥിച്ച ഉറവിടങ്ങൾ യഥാർത്ഥ ഉപയോഗവുമായി പൊരുത്തപ്പെടുന്നില്ലെന്ന് ഞങ്ങൾ കണ്ടെത്തി, ഇവിടെയാണ് ക്യൂബ് ഈഗിളും അതിന്റെ റിസോഴ്‌സ് മോണിറ്ററിംഗ് കഴിവുകളും രക്ഷാപ്രവർത്തനത്തിലേക്ക് വന്നത്.

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

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

കുബെ ഈഗിൾ ഡാഷ്‌ബോർഡ്

വിഭവങ്ങളുമായി ബന്ധപ്പെട്ട നിരവധി പ്രശ്നങ്ങൾ പരിഹരിക്കാനും ഉപകരണങ്ങൾ സംരക്ഷിക്കാനും ഞങ്ങൾക്ക് കഴിഞ്ഞു:

1. മൈക്രോ സർവീസുകൾക്ക് എത്ര വിഭവങ്ങൾ ആവശ്യമാണെന്ന് ചില ഡെവലപ്പർമാർക്ക് അറിയില്ല (അല്ലെങ്കിൽ വെറുതെ വിഷമിച്ചില്ല). ഉറവിടങ്ങൾക്കായുള്ള തെറ്റായ അഭ്യർത്ഥനകൾ കണ്ടെത്താൻ ഞങ്ങൾക്ക് ഒരു മാർഗവുമില്ല - ഇതിനായി ഞങ്ങൾ ഉപഭോഗവും അഭ്യർത്ഥനകളും പരിധികളും അറിയേണ്ടതുണ്ട്. ഇപ്പോൾ അവർ പ്രോമിത്യൂസ് മെട്രിക്‌സ് കാണുകയും യഥാർത്ഥ ഉപയോഗം നിരീക്ഷിക്കുകയും അഭ്യർത്ഥനകളും പരിധികളും ക്രമീകരിക്കുകയും ചെയ്യുന്നു.
2. JVM ആപ്ലിക്കേഷനുകൾ കൈകാര്യം ചെയ്യാൻ കഴിയുന്നത്ര റാം എടുക്കുന്നു. 75% ത്തിൽ കൂടുതൽ ഉപയോഗിക്കുമ്പോൾ മാത്രമേ ഗാർബേജ് കളക്ടർ മെമ്മറി റിലീസ് ചെയ്യുകയുള്ളൂ. മിക്ക സേവനങ്ങൾക്കും പൊട്ടിത്തെറിക്കാവുന്ന മെമ്മറി ഉള്ളതിനാൽ, അത് എല്ലായ്പ്പോഴും ജെവിഎം കൈവശപ്പെടുത്തിയിരുന്നു. അതിനാൽ, ഈ ജാവ സേവനങ്ങളെല്ലാം പ്രതീക്ഷിച്ചതിലും കൂടുതൽ റാം കഴിക്കുന്നു.
3. ചില ആപ്ലിക്കേഷനുകൾ വളരെയധികം മെമ്മറി അഭ്യർത്ഥിച്ചു, കൂടാതെ Kubernetes ഷെഡ്യൂളർ ഈ നോഡുകൾ മറ്റ് ആപ്ലിക്കേഷനുകൾക്ക് നൽകിയില്ല, വാസ്തവത്തിൽ അവ മറ്റ് നോഡുകളേക്കാൾ സ്വതന്ത്രമാണെങ്കിലും. ഒരു ഡെവലപ്പർ അബദ്ധത്തിൽ അഭ്യർത്ഥനയിൽ ഒരു അധിക അക്കം ചേർക്കുകയും ഒരു വലിയ റാം പിടിച്ചെടുക്കുകയും ചെയ്തു: 20-ന് പകരം 2 GB. ആരും ശ്രദ്ധിച്ചില്ല. അപ്ലിക്കേഷന് 3 പകർപ്പുകൾ ഉണ്ടായിരുന്നു, അതിനാൽ 3 നോഡുകളെ ബാധിച്ചു.
4. ഞങ്ങൾ റിസോഴ്‌സ് പരിധികൾ അവതരിപ്പിച്ചു, ശരിയായ അഭ്യർത്ഥനകളുള്ള പോഡുകൾ പുനഃക്രമീകരിച്ചു, കൂടാതെ എല്ലാ നോഡുകളിലുടനീളം ഹാർഡ്‌വെയർ ഉപയോഗത്തിന്റെ അനുയോജ്യമായ ബാലൻസ് ലഭിച്ചു. ഒന്നുരണ്ട് നോഡുകൾ മൊത്തത്തിൽ അടയ്ക്കാമായിരുന്നു. തുടർന്ന് ഞങ്ങൾ തെറ്റായ മെഷീനുകൾ ഉള്ളതായി കണ്ടു (സിപിയു ഓറിയന്റഡ്, മെമ്മറി ഓറിയന്റഡ് അല്ല). ഞങ്ങൾ തരം മാറ്റുകയും നിരവധി നോഡുകൾ ഇല്ലാതാക്കുകയും ചെയ്തു.

ഫലങ്ങൾ

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

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