Text size
പരീക്ഷിച്ചറിഞ്ഞത്6 മിനിറ്റ് വായന

അഭ്യർത്ഥനകളും പരിമിതികളും: എല്ലാവരും തെറ്റായി മനസ്സിലാക്കുന്ന ക്രമീകരണങ്ങൾ

എന്തിനാണ് നിങ്ങളുടെ പാഡ് കൊല്ലപ്പെട്ടത്, എന്തുകൊണ്ടാണ് അത് വേഗത കുറഞ്ഞത്, സിപിയു പരിധി നല്ല ആശയമാണോ എന്ന്.

Requests and limits: the settings everyone gets wrong
AI ഉപയോഗിച്ച് സൃഷ്ടിച്ച ചിത്രീകരണം

ഏറ്റവും കൂടുതൽ ആശയക്കുഴപ്പം ഉണ്ടാക്കുന്ന ഒരു കുബർനെറ്റസ് ക്രമീകരണം തിരഞ്ഞെടുക്കേണ്ടിവന്നാൽ അത് റിസോഴ്സ് അഭ്യർത്ഥനകളും പരിമിതികളും ആയിരിക്കും. അവ ലളിതമായി കാണപ്പെടുന്നു: ഒരു YAML ഫയലിലെ ചില സംഖ്യകൾ. പക്ഷെ അവയാണ് നിങ്ങളുടെ ബേസ് എവിടെയാണെന്ന് തീരുമാനിക്കുന്നത്, എത്ര വേഗതയേറിയതാണെന്ന്, അത് കൊല്ലപ്പെടുമോ എന്ന്, നിങ്ങളുടെ ക്ലസ്റ്ററിന് എത്ര ചിലവാകും.

നമുക്ക് അവ ശരിക്കും ചെയ്യുന്നതെന്താണെന്ന് നോക്കാം.

ആവശ്യങ്ങളും പരിമിതികളും എന്താണ് അർത്ഥമാക്കുന്നത്

resources:
  requests:
    cpu: 250m
    memory: 256Mi
  limits:
    cpu: "1"
    memory: 512Mi

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

പരിമിതികൾ ഈ കപ്പലിന് ഉപയോഗിക്കാൻ അനുവാദമുള്ള പരമാവധി അളവാണ്.

പ്രധാനമായ ഒരു കാര്യം: സിപിയുവും മെമ്മറിയും പരിധി വരെ എത്തുമ്പോൾ തികച്ചും വ്യത്യസ്തമായി പെരുമാറുന്നു.

ഒരു പരിധി വരെ എത്തുമ്പോൾ യഥാർത്ഥത്തിൽ സംഭവിക്കുന്നത്

സിപിയു കംപ്രസ്സബിൾ ആണ്. ഒരു കണ്ടെയ്നര് അതിന്റെ പരിധിയേക്കാൾ കൂടുതൽ സിപിയു ഉപയോഗിക്കാന് ശ്രമിച്ചാൽ, അത് ലഭിക്കും കുത്തിവയ്ക്കുക. അത് തകരുകയില്ല, അത് വേഗത കുറയ്ക്കും. ഓരോ സമയ സ്ലൈസിനും ഒരു നിശ്ചിത സമയത്തേക്ക് മാത്രമേ ഇത് പ്രവർത്തിക്കാവൂ. ഇത് പലപ്പോഴും ഉയർന്ന ശരാശരി സിപിയു ഉപയോഗമില്ലാതെ, നിഗൂഢമായ ലേറ്റൻസി സ്പൈക്കുകളായി കാണപ്പെടുന്നു.

മെമ്മറി കംപ്രസ്സു ചെയ്യാവുന്നതല്ല. ഒരു കണ്ടെയ്നര് അതിന്റെ പരിധിയേക്കാൾ കൂടുതൽ മെമ്മറി ഉപയോഗിക്കുന്നുവെങ്കില് , കേർണല് അത് കൊല്ലുന്നു. അത് പ്രശസ്തമായ കൊലപാതകം നില. ഈ പാഡ് പുനരാരംഭിക്കും, അത് തുടരുകയാണെങ്കിൽ, CrashLoopBackOff.

kubectl describe pod shop-api-7d9f
# Last State: Terminated
#   Reason:   OOMKilled
#   Exit Code: 137

പുറന്തള്ളൽ കൂടി ഉണ്ട്. ഒരു നോഡ് മൊത്തത്തിൽ മെമ്മറി തീർന്നാൽ കുബെലെറ്റ് പാഡുകൾ പുറന്തള്ളുന്നു. ആവശ്യങ്ങൾക്കപ്പുറം ഉപയോഗിക്കുന്നവയിൽ നിന്ന് തുടങ്ങുന്നു.

ക്യു.എസ്. ക്ലാസുകൾ, ലളിതമായി

കുബർനെറ്റസ് ഓരോ പാഡിനെയും അതിന്റെ ആവശ്യങ്ങളും പരിമിതികളും അടിസ്ഥാനമാക്കി മൂന്ന് സേവന ഗുണനിലവാര ക്ലാസുകളിലൊന്നിലേക്ക് മാറ്റുന്നുഃ

  • ഉറപ്പു നല് കുന്നു: ഓരോ കണ്ടെയ്നറിലും സിപിയു, മെമ്മറി എന്നിവയുടെ തുല്യ പരിധി ആവശ്യപ്പെടുന്നു. അവസാനമായി പുറത്താക്കപ്പെട്ടത്.
  • പൊട്ടിത്തെറിക്കാവുന്ന: അപേക്ഷകൾ നിശ്ചയിച്ചിട്ടുണ്ടെങ്കിലും പരിധിക്ക് താഴെയാണ് (അല്ലെങ്കിൽ ചിലത് മാത്രം നിശ്ചയിച്ചിട്ടുള്ളതാണ്). ഏറ്റവും സാധാരണമായ ക്ലാസ്.
  • മികച്ച പരിശ്രമം: യാതൊരു അഭ്യർത്ഥനയും പരിമിതിയും ഇല്ല. നോഡ് സമ്മർദ്ദത്തിലായാല് ആദ്യം പുറത്താക്കപ്പെടും.

പ്രധാനപ്പെട്ട സേവനങ്ങള് ക്ക്, ബെസ്റ്റ് എഫോർട്ട് ഒഴിവാക്കുക. നിർണായക വർക്ക് ലോഡുകൾക്ക്, കുറഞ്ഞത് മെമ്മറിക്ക് ഉറപ്പുള്ളവയെങ്കിലും പരിഗണിക്കുക.

നിങ്ങളുടെ കോപ്പ എവിടെയാണെന്ന് തീരുമാനിക്കുന്നത് അഭ്യർത്ഥനകളാണ്. അതിര് അത് എങ്ങനെ മരിക്കുന്നു എന്ന് തീരുമാനിക്കും.

സി. പി. യു പരിമിതികൾ ചർച്ച

ഇവിടെയാണ് എൻജിനീയർമാർ തർക്കിക്കുന്നത്. സിപിയു പരിധി നിശ്ചയിക്കണോ?

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

സിപിയു പരിമിതികളുടെ കേസ്: പ്രവചിക്കാവുന്നതാണു്. ഒന്നിലധികം വാടകക്കാരെ ഉള്ള ക്ലസ്റ്ററുകളിൽ, അല്ലെങ്കിൽ ഒരു ശബ്ദമുള്ള വർക്ക് ലോഡ് എല്ലാം പിടിച്ചെടുക്കുന്നത് തടയേണ്ടിവരുമ്പോൾ, പരിമിതികൾ കടുത്ത അതിരുകൾ നൽകുന്നു. ചില റൺ ടൈമുകളും ലൈസൻസിംഗ് മോഡലുകളും അവയെ ആശ്രയിച്ചിരിക്കുന്നു.

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

ശരിയായ സംഖ്യകൾ കണ്ടെത്തുക

ഊഹിക്കലാണ് മിക്ക ടീമുകളും തുടങ്ങുന്നത്, അത് സാധാരണയായി രണ്ട് ദിശകളിലും തെറ്റാണ്: ചില ബോട്ടുകൾ പട്ടിണി കിടക്കുന്നു, മറ്റുള്ളവർ ഒരിക്കലും ഉപയോഗിക്കാത്ത വിഭവങ്ങൾ റിസർവ് ചെയ്യുന്നു (അതിനു നിങ്ങൾ പണം നൽകുന്നു).

മികച്ച സമീപനങ്ങൾ:

  • യഥാർത്ഥ ഉപയോഗം നോക്കൂ. പ്രൊമെഥ്യൂസ് അല്ലെങ്കിൽ നിങ്ങളുടെ നിരീക്ഷണ ഉപകരണത്തില് കുറഞ്ഞത് ഒരാഴ്ചയോളം. സാധാരണ ആരംഭ പോയിന്റ്ഃ സാധാരണ ഉപയോഗത്തിനടുത്തുള്ള അഭ്യർത്ഥനകൾ (ഉദാഹരണത്തിന് 90 ാം ശതമാനത്തിൽ), പീക്കിന് മുകളിലുള്ള ചില ഹെഡ്റൂം ഉള്ള മെമ്മറി പരിധി.
  • ശുപാർശ മോഡിൽ VPA നിങ്ങള് ക്ക് വേണ്ടി നിർദ്ദേശങ്ങള് കണക്കുകൂട്ടുന്നു.
  • ഗോൾഡ് ലോക്ക് (ഫെയർവിൻഡിൽ നിന്നും) ശുപാർശ മോഡിൽ വിപിഎ പ്രവർത്തിപ്പിക്കുകയും ഡാഷ്ബോർഡിൽ നാമമേഖലയുടെ ഫലങ്ങൾ കാണിക്കുകയും ചെയ്യുന്നു.
  • സ്ത്രോസ്ഫിംഗിനായി പരിശോധിക്കുക കൂടെ container_cpu_cfs_throttled_periods_total മെട്രിക് കുറഞ്ഞ ശരാശരി ഉപയോഗത്തോടെയുള്ള ഉയർന്ന സ്ത്രോട്ടിലിംഗ് സിപിയു പരിധി വളരെ കടുപ്പമുള്ളതിന്റെ സൂചനയാണ്.
  • ഭാഷാ റൺടൈംസ് പ്രധാനമാണ്. ജാവ, നോഡ്. ജെ. എസ്, ഗോ എന്നിവയ്ക്ക് ഓരോന്നിനും കണ്ടെയ്നർ മെമ്മറിയുമായും സിപിയു പരിമിതികളുമായും സ്വന്തം ബന്ധമുണ്ട്. നിങ്ങളുടെ റൺടൈം അതിന്റെ പരിമിതികൾ അറിയുന്നുണ്ടെന്ന് ഉറപ്പുവരുത്തുക (ആധുനിക ജെവിഎം കൺടെയിൻററുകളുടെ പരിമിതികളെ സ്വപ്രേരിതമായി തിരിച്ചറിയുന്നു, ഉദാഹരണത്തിന്).

മുഴുവൻ ക്ലസ്റ്ററിനും സംരക്ഷണ കവറുകൾ

ഏതെങ്കിലും ക്രമീകരണങ്ങളില്ലാത്ത പാഡുകൾ അകത്തേക്ക് കടക്കുന്നത് തടയാൻ:

  • പരിധി പരിധി ഓരോ നാമമേഖലയ്ക്കും സ്ഥിരസ്ഥിതി അഭ്യർത്ഥനകളും പരിമിതികളും സജ്ജമാക്കുന്നു.
  • വിഭവ ക്വാട്ട ഒരു നാമമേഖലയ്ക്ക് ആവശ്യപ്പെടാവുന്ന മൊത്തം പരിധി നിശ്ചയിക്കുന്നു.
  • നയ ഉപകരണങ്ങള് കെയ്വർനോ എല്ലാ പാഡുകളിലും അഭ്യർത്ഥനകൾ ആവശ്യപ്പെടാം.

അതുകൊണ്ട് ഇന്ന് നീ എന്തു ചെയ്യണം?

നിങ്ങളുടെ ഏത് വർക്ക് ലോഡുകളിലാണ് അഭ്യർത്ഥനകളില്ലെന്ന് പരിശോധിക്കുക. ആദ്യം അവയെ ശരിയാക്കൂ. പിന്നെ OOMKills, സ്ത്രോട്ടിംഗ് അളവുകൾ എന്നിവ നോക്കൂ, ഊഹക്കച്ചവടത്തിനു പകരം യഥാർത്ഥ ഡാറ്റയെ അടിസ്ഥാനമാക്കി ക്രമീകരിക്കുക.

എന്റെ അഭിപ്രായം: സത്യസന്ധമായി അഭ്യർത്ഥനകൾ സജ്ജമാക്കുക, മെമ്മറി പരിമിതികളെ ആദരവോടെ കൈകാര്യം ചെയ്യുക, നിങ്ങളുടെ സ്വന്തം സിപിയു കുറയ്ക്കുന്നതിന് മുമ്പ് രണ്ടുതവണ ചിന്തിക്കുക.

ഡെസ്ലി