കുബെർനെറ്റസിന്റെ മികച്ച സമ്പ്രദായങ്ങൾ. ഉറവിട അഭ്യർത്ഥനകളും പരിധികളും സജ്ജീകരിക്കുന്നു

കുബെർനെറ്റസിന്റെ മികച്ച സമ്പ്രദായങ്ങൾ. ചെറിയ പാത്രങ്ങൾ ഉണ്ടാക്കുന്നു
കുബെർനെറ്റസിന്റെ മികച്ച സമ്പ്രദായങ്ങൾ. നെയിംസ്പേസ് ഉള്ള കുബർനെറ്റുകളുടെ ഓർഗനൈസേഷൻ
കുബെർനെറ്റസിന്റെ മികച്ച സമ്പ്രദായങ്ങൾ. റെഡിനെസ്, ലൈവ്‌നെസ് ടെസ്റ്റുകൾ ഉപയോഗിച്ച് കുബർനെറ്റസ് ലൈവ്‌നെസ് സാധൂകരിക്കുന്നു

ഓരോ Kubernetes റിസോഴ്സിനും, നിങ്ങൾക്ക് രണ്ട് തരത്തിലുള്ള ആവശ്യകതകൾ ക്രമീകരിക്കാൻ കഴിയും - അഭ്യർത്ഥനകളും പരിധികളും. ഒരു കണ്ടെയ്‌നറോ പോഡോ പ്രവർത്തിപ്പിക്കുന്നതിന് ആവശ്യമായ സൗജന്യ നോഡ് ഉറവിടങ്ങളുടെ ലഭ്യതയ്ക്കുള്ള ഏറ്റവും കുറഞ്ഞ ആവശ്യകതകൾ ആദ്യത്തേത് വിവരിക്കുന്നു, രണ്ടാമത്തേത് കണ്ടെയ്‌നറിന് ലഭ്യമായ ഉറവിടങ്ങളെ കർശനമായി പരിമിതപ്പെടുത്തുന്നു.

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

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

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

ഒരു പോഡിലെ ഓരോ കണ്ടെയ്‌നറിനും അതിന്റേതായ ചോദ്യങ്ങളും പരിധികളും സജ്ജീകരിക്കാൻ കഴിയും, ഇതെല്ലാം അഡിറ്റീവാണ്. പ്രോസസ്സർ ഉറവിടങ്ങൾ മില്ലികോറുകളിൽ നിർവചിച്ചിരിക്കുന്നു. നിങ്ങളുടെ കണ്ടെയ്‌നറിന് പ്രവർത്തിക്കാൻ രണ്ട് ഫുൾ കോറുകൾ ആവശ്യമുണ്ടെങ്കിൽ, നിങ്ങൾ മൂല്യം 2000 മീറ്ററായി സജ്ജമാക്കുക. കണ്ടെയ്നറിന് കാമ്പിന്റെ 1/4 ന്റെ ശക്തി മാത്രമേ ആവശ്യമുള്ളൂവെങ്കിൽ, മൂല്യം 250 മീ. ഏറ്റവും വലിയ നോഡിന്റെ കോറുകളുടെ എണ്ണത്തേക്കാൾ വലിയ ഒരു CPU റിസോഴ്സ് മൂല്യം നിങ്ങൾ അസൈൻ ചെയ്യുകയാണെങ്കിൽ, നിങ്ങളുടെ പോഡ് ആരംഭിക്കാൻ ഷെഡ്യൂൾ ചെയ്യപ്പെടില്ല. നിങ്ങൾക്ക് നാല് കോറുകൾ ആവശ്യമുള്ള ഒരു പോഡ് ഉണ്ടെങ്കിൽ സമാനമായ ഒരു സാഹചര്യം സംഭവിക്കും, കൂടാതെ കുബർനെറ്റസ് ക്ലസ്റ്ററിൽ രണ്ട് പ്രധാന വെർച്വൽ മെഷീനുകൾ മാത്രമേ അടങ്ങിയിട്ടുള്ളൂ.

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

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

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

നിങ്ങളുടെ നോഡുകൾക്ക് നൽകാൻ കഴിയുന്ന ഉറവിടങ്ങളെ കവിയുന്ന അഭ്യർത്ഥനകൾ നിങ്ങൾക്ക് കോൺഫിഗർ ചെയ്യാൻ കഴിയില്ല എന്നത് ഓർത്തിരിക്കേണ്ടത് പ്രധാനമാണ്. GKE വെർച്വൽ മെഷീനുകൾക്കായുള്ള പങ്കിട്ട റിസോഴ്‌സ് സ്പെസിഫിക്കേഷനുകൾ ഈ വീഡിയോയ്ക്ക് താഴെയുള്ള ലിങ്കുകളിൽ കാണാം.

അനുയോജ്യമായ ഒരു ലോകത്ത്, വർക്ക്ഫ്ലോകൾ സുഗമമായി പ്രവർത്തിക്കുന്നതിന് കണ്ടെയ്‌നറിന്റെ സ്ഥിരസ്ഥിതി ക്രമീകരണങ്ങൾ മതിയാകും. എന്നാൽ യഥാർത്ഥ ലോകം അങ്ങനെയല്ല, വിഭവങ്ങളുടെ ഉപയോഗം കോൺഫിഗർ ചെയ്യാൻ ആളുകൾക്ക് എളുപ്പത്തിൽ മറക്കാൻ കഴിയും, അല്ലെങ്കിൽ അടിസ്ഥാന സൗകര്യങ്ങളുടെ യഥാർത്ഥ കഴിവുകൾ കവിയുന്ന അഭ്യർത്ഥനകളും നിയന്ത്രണങ്ങളും ഹാക്കർമാർ സജ്ജമാക്കും. അത്തരം സാഹചര്യങ്ങൾ ഉണ്ടാകുന്നത് തടയാൻ, നിങ്ങൾക്ക് ResourceQuota, LimitRange റിസോഴ്സ് ക്വാട്ടകൾ കോൺഫിഗർ ചെയ്യാം.

ഒരു നെയിംസ്പേസ് സൃഷ്ടിച്ചുകഴിഞ്ഞാൽ, ക്വാട്ടകൾ ഉപയോഗിച്ച് അത് ബ്ലോക്ക് ചെയ്യാവുന്നതാണ്. ഉദാഹരണത്തിന്, നിങ്ങൾക്ക് പ്രോഡ്, ഡെവ് നെയിംസ്‌പേസുകൾ ഉണ്ടെങ്കിൽ, പ്രൊഡക്ഷൻ ക്വാട്ടകളൊന്നുമില്ല, വളരെ കർശനമായ വികസന ക്വാട്ടകളും ഇല്ല എന്നതാണ് പാറ്റേൺ. ട്രാഫിക്കിൽ കുത്തനെ കുതിച്ചുയരുന്ന സാഹചര്യത്തിൽ, ലഭ്യമായ മുഴുവൻ ഉറവിടവും ഏറ്റെടുക്കാൻ ഇത് പ്രോഡിനെ അനുവദിക്കുന്നു, dev- നെ പൂർണ്ണമായും തടയുന്നു.

റിസോഴ്സ് ക്വാട്ട ഇതുപോലെയായിരിക്കാം. ഈ ഉദാഹരണത്തിൽ 4 വിഭാഗങ്ങളുണ്ട് - ഇവയാണ് കോഡിന്റെ 4 താഴെ വരികൾ.

അവ ഓരോന്നും നോക്കാം. Requests.cpu എന്നത് നെയിംസ്‌പെയ്‌സിലെ എല്ലാ കണ്ടെയ്‌നറുകളിൽ നിന്നും വരാവുന്ന പരമാവധി സംയോജിത സിപിയു അഭ്യർത്ഥനകളാണ്. ഈ ഉദാഹരണത്തിൽ, നിങ്ങൾക്ക് 50 മി അഭ്യർത്ഥനകളുള്ള 10 കണ്ടെയ്നറുകൾ, 100 മി അഭ്യർത്ഥനകളുള്ള അഞ്ച് കണ്ടെയ്നറുകൾ അല്ലെങ്കിൽ 500 മി അഭ്യർത്ഥനകളുള്ള ഒരു കണ്ടെയ്നർ എന്നിവ ഉണ്ടായിരിക്കാം. നൽകിയിരിക്കുന്ന നെയിംസ്‌പെയ്‌സിന്റെ മൊത്തം requests.cpu 500 മീറ്ററിൽ കുറവാണെങ്കിൽ, എല്ലാം ശരിയാകും.

മെമ്മറി അഭ്യർത്ഥിച്ച requests.memory എന്നത് നെയിംസ്‌പെയ്‌സിലെ എല്ലാ കണ്ടെയ്‌നറുകൾക്കും ഉണ്ടായിരിക്കാവുന്ന സംയോജിത മെമ്മറി അഭ്യർത്ഥനകളുടെ പരമാവധി അളവാണ്. മുമ്പത്തെ കാര്യത്തിലെന്നപോലെ, നെയിംസ്‌പെയ്‌സിൽ അഭ്യർത്ഥിച്ച മെമ്മറിയുടെ ആകെ അളവ് 50 മെബിബൈറ്റിൽ കുറവാണെങ്കിൽ, നിങ്ങൾക്ക് 2 20 mib കണ്ടെയ്‌നറുകൾ, അഞ്ച് 100 mib കണ്ടെയ്‌നറുകൾ അല്ലെങ്കിൽ ഒരു 100 mib കണ്ടെയ്‌നർ എന്നിവ ഉണ്ടായിരിക്കാം.

Limits.cpu എന്നത് നെയിംസ്‌പെയ്‌സിലെ എല്ലാ കണ്ടെയ്‌നറുകൾക്കും ഉപയോഗിക്കാനാകുന്ന സിപിയു പവറിന്റെ പരമാവധി സംയോജിത അളവാണ്. ഇത് പ്രൊസസർ പവർ അഭ്യർത്ഥനകളുടെ പരിധിയായി നമുക്ക് കണക്കാക്കാം.

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

പരിധി പരിധി ഇനിപ്പറയുന്നവ ചെയ്യാവുന്ന നിയന്ത്രണങ്ങൾ നൽകുന്നു:

• നെയിംസ്‌പെയ്‌സിലെ ഓരോ മൊഡ്യൂളിനും കണ്ടെയ്‌നറിനും കമ്പ്യൂട്ടിംഗ് ഉറവിടങ്ങളുടെ ഏറ്റവും കുറഞ്ഞതും കൂടിയതുമായ ഉപയോഗം ഉറപ്പാക്കുക;
• നെയിംസ്‌പെയ്‌സിലെ ഓരോ PersistentVolumeClaim-നും വേണ്ടിയുള്ള ഏറ്റവും കുറഞ്ഞതും കൂടിയതുമായ സ്റ്റാറേജ് അഭ്യർത്ഥന സംഭരണ ​​അഭ്യർത്ഥനകൾ നടപ്പിലാക്കുക;
• ഒരു നെയിംസ്പേസിൽ ഒരു റിസോഴ്സിനായുള്ള അഭ്യർത്ഥനയും ഒരു പരിധിയും തമ്മിലുള്ള ബന്ധം നടപ്പിലാക്കുക;
• നെയിംസ്‌പേസിൽ ഉറവിടങ്ങൾ കണക്കാക്കുന്നതിനുള്ള ഡിഫോൾട്ട് അഭ്യർത്ഥനകൾ/പരിധികൾ സജ്ജീകരിക്കുകയും റൺടൈമിൽ അവ യാന്ത്രികമായി കണ്ടെയ്‌നറുകളിലേക്ക് കുത്തിവയ്ക്കുകയും ചെയ്യുക.

ഇതുവഴി നിങ്ങളുടെ നെയിംസ്‌പെയ്‌സിൽ ഒരു പരിധി ശ്രേണി സൃഷ്‌ടിക്കാനാകും. ഒരു ക്വാട്ടയിൽ നിന്ന് വ്യത്യസ്തമായി, മുഴുവൻ നെയിംസ്‌പെയ്‌സിനും ബാധകമാണ്, വ്യക്തിഗത കണ്ടെയ്‌നറുകൾക്കായി പരിധി ശ്രേണി ഉപയോഗിക്കുന്നു. നെയിംസ്‌പെയ്‌സിനുള്ളിൽ വളരെ ചെറിയതോ അല്ലെങ്കിൽ ഭീമാകാരമായതോ ആയ കണ്ടെയ്‌നറുകൾ സൃഷ്‌ടിക്കുന്നതിൽ നിന്ന് ഇത് ഉപയോക്താക്കളെ തടയും. ലിമിറ്റ് റേഞ്ച് ഇതുപോലെയായിരിക്കാം.

മുമ്പത്തെ കാര്യത്തിലെന്നപോലെ, ഇവിടെയും 4 വിഭാഗങ്ങൾ വേർതിരിച്ചറിയാൻ കഴിയും. നമുക്ക് ഓരോന്നും നോക്കാം.
ഡിഫോൾട്ട് വിഭാഗം പോഡിലെ കണ്ടെയ്‌നറിനായി സ്ഥിരസ്ഥിതി പരിധികൾ സജ്ജമാക്കുന്നു. നിങ്ങൾ ഈ മൂല്യങ്ങൾ അങ്ങേയറ്റത്തെ ശ്രേണിയിലേക്ക് സജ്ജമാക്കുകയാണെങ്കിൽ, ഈ മൂല്യങ്ങൾ വ്യക്തമായി സജ്ജീകരിച്ചിട്ടില്ലാത്ത ഏത് കണ്ടെയ്‌നറുകളും സ്ഥിരസ്ഥിതി മൂല്യങ്ങൾ പിന്തുടരും.

ഡിഫോൾട്ട് അഭ്യർത്ഥന വിഭാഗം defaultRequest പോഡിലെ കണ്ടെയ്‌നറിനായുള്ള ഡിഫോൾട്ട് അഭ്യർത്ഥനകൾ കോൺഫിഗർ ചെയ്യുന്നു. വീണ്ടും, നിങ്ങൾ ഈ മൂല്യങ്ങൾ അങ്ങേയറ്റത്തെ ശ്രേണിയിലേക്ക് സജ്ജമാക്കുകയാണെങ്കിൽ, ഈ ഓപ്‌ഷനുകൾ വ്യക്തമായി സജ്ജീകരിക്കാത്ത ഏത് കണ്ടെയ്‌നറുകളും ഈ മൂല്യങ്ങളിലേക്ക് സ്ഥിരസ്ഥിതിയാകും.

പോഡിലെ ഒരു കണ്ടെയ്‌നറിന് സജ്ജമാക്കാൻ കഴിയുന്ന പരമാവധി പരിധികൾ പരമാവധി വിഭാഗം വ്യക്തമാക്കുന്നു. ഡിഫോൾട്ട് വിഭാഗത്തിലെയും കണ്ടെയ്നർ പരിധികളിലെയും മൂല്യങ്ങൾ ഈ പരിധിക്ക് മുകളിൽ സജ്ജീകരിക്കാൻ കഴിയില്ല. മൂല്യം പരമാവധി ആയി സജ്ജീകരിക്കുകയും സ്ഥിരസ്ഥിതി വിഭാഗമൊന്നുമില്ലെങ്കിൽ, പരമാവധി മൂല്യം സ്ഥിര മൂല്യമായി മാറുകയും ചെയ്യുന്നത് ശ്രദ്ധിക്കേണ്ടതാണ്.

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

വീണ്ടും, ഈ മൂല്യം സജ്ജീകരിച്ചിട്ടുണ്ടെങ്കിൽ, ഡിഫോൾട്ട് അല്ല, ഏറ്റവും കുറഞ്ഞ മൂല്യം ഡിഫോൾട്ട് പ്രോംപ്റ്റായി മാറുന്നു എന്നത് ശ്രദ്ധിക്കേണ്ടതാണ്.

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

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

നിങ്ങൾക്ക് പിന്നീട് നോഡ് കപ്പാസിറ്റി തീർന്നാൽ, നിങ്ങളുടെ പണം ലാഭിക്കാൻ ഓട്ടോസ്‌കേലിംഗ് നോഡുകളുടെ എണ്ണം കുറയ്ക്കും. അതുകൊണ്ടാണ് അഭ്യർത്ഥനകളെ അടിസ്ഥാനമാക്കി കുബർനെറ്റസ് പോഡുകൾ ഷെഡ്യൂൾ ചെയ്യുന്നത്. എന്നിരുന്നാലും, പരിധി അഭ്യർത്ഥനകളേക്കാൾ കൂടുതലായിരിക്കാം, ചില സന്ദർഭങ്ങളിൽ നോഡ് യഥാർത്ഥത്തിൽ ഉറവിടങ്ങൾ തീർന്നേക്കാം. ഈ അവസ്ഥയെ നമ്മൾ ഓവർകമ്മിറ്റ്മെന്റ് സ്റ്റേറ്റ് എന്ന് വിളിക്കുന്നു.

ഞാൻ പറഞ്ഞതുപോലെ, സിപിയുവിലേക്ക് വരുമ്പോൾ, കുബർനെറ്റസ് പോഡുകൾ പരിമിതപ്പെടുത്താൻ തുടങ്ങും. ഓരോ പോഡിനും അത് ആവശ്യപ്പെടുന്നത്രയും ലഭിക്കും, എന്നാൽ അത് പരിധിയിൽ എത്തിയില്ലെങ്കിൽ, ത്രോട്ടിലിംഗ് പ്രയോഗിക്കാൻ തുടങ്ങും.

മെമ്മറി റിസോഴ്സുകളുടെ കാര്യം വരുമ്പോൾ, നിങ്ങൾ സിസ്റ്റം ഉറവിടങ്ങൾ സ്വതന്ത്രമാക്കുന്നത് വരെ ഏതൊക്കെ പോഡുകൾ ഇല്ലാതാക്കണമെന്നും അല്ലെങ്കിൽ മുഴുവൻ സിസ്റ്റവും തകരാറിലാകുന്നത് വരെ ഏതൊക്കെ പോഡുകൾ സൂക്ഷിക്കണമെന്നും തീരുമാനങ്ങൾ എടുക്കാൻ കുബെർനെറ്റസ് നിർബന്ധിതനാകുന്നു.

നിങ്ങൾക്ക് ഒരു മെഷീൻ മെമ്മറി തീർന്നിരിക്കുന്ന ഒരു സാഹചര്യം നമുക്ക് സങ്കൽപ്പിക്കാം - കുബർനെറ്റസ് അത് എങ്ങനെ കൈകാര്യം ചെയ്യും?

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

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

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

കുബെർനെറ്റസിന്റെ മികച്ച സമ്പ്രദായങ്ങൾ. ശരിയായ ഷട്ട്ഡൗൺ അവസാനിപ്പിക്കുക

ചില പരസ്യങ്ങൾ 🙂

ഞങ്ങളോടൊപ്പം താമസിച്ചതിന് നന്ദി. ഞങ്ങളുടെ ലേഖനങ്ങൾ നിങ്ങൾക്ക് ഇഷ്ടമാണോ? കൂടുതൽ രസകരമായ ഉള്ളടക്കം കാണാൻ ആഗ്രഹിക്കുന്നുണ്ടോ? ഒരു ഓർഡർ നൽകി അല്ലെങ്കിൽ സുഹൃത്തുക്കൾക്ക് ശുപാർശ ചെയ്തുകൊണ്ട് ഞങ്ങളെ പിന്തുണയ്ക്കുക, $4.99 മുതൽ ഡെവലപ്പർമാർക്കുള്ള ക്ലൗഡ് VPS, എൻട്രി ലെവൽ സെർവറുകളുടെ ഒരു അദ്വിതീയ അനലോഗ്, നിങ്ങൾക്കായി ഞങ്ങൾ കണ്ടുപിടിച്ചതാണ്: VPS (KVM) E5-2697 v3 (6 കോറുകൾ) 10GB DDR4 480GB SSD 1Gbps-നെക്കുറിച്ചുള്ള മുഴുവൻ സത്യവും $19 മുതൽ അല്ലെങ്കിൽ എങ്ങനെ ഒരു സെർവർ പങ്കിടാം? (RAID1, RAID10 എന്നിവയ്‌ക്കൊപ്പം 24 കോറുകൾ വരെയും 40GB DDR4 വരെയും ലഭ്യമാണ്).

ആംസ്റ്റർഡാമിലെ Equinix Tier IV ഡാറ്റാ സെന്ററിൽ Dell R730xd 2 മടങ്ങ് വിലക്കുറവാണോ? ഇവിടെ മാത്രം 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV $199 മുതൽ നെതർലാൻഡിൽ! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 മുതൽ! കുറിച്ച് വായിക്കുക ഇൻഫ്രാസ്ട്രക്ചർ കോർപ്പറേഷൻ എങ്ങനെ നിർമ്മിക്കാം. ഒരു പൈസയ്ക്ക് 730 യൂറോ വിലയുള്ള Dell R5xd E2650-4 v9000 സെർവറുകൾ ഉപയോഗിക്കുന്ന ക്ലാസ്?

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