കുബർനെറ്റസിലെ സിപിയു പരിധികളും ആക്രമണാത്മക ത്രോട്ടിലിംഗും

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

നിങ്ങൾക്ക് എപ്പോഴെങ്കിലും ഒരു ആപ്ലിക്കേഷൻ കുടുങ്ങിയിട്ടുണ്ടോ, ആരോഗ്യ പരിശോധനകളോട് പ്രതികരിക്കുന്നത് നിർത്തുക, എന്തുകൊണ്ടെന്ന് കണ്ടെത്താനാകുന്നില്ലേ? സാധ്യമായ ഒരു വിശദീകരണം CPU റിസോഴ്സ് ക്വാട്ട പരിധികളുമായി ബന്ധപ്പെട്ടതാണ്. ഈ ലേഖനത്തിൽ നമ്മൾ സംസാരിക്കുന്നത് ഇതാണ്.

അച്ചു ഡി.ആർ.:
നിങ്ങൾ ഒരു CFS ക്വാട്ട ബഗ് ഉള്ള Linux കേർണലിൻ്റെ ഒരു പതിപ്പാണ് ഉപയോഗിക്കുന്നതെങ്കിൽ, Kubernetes-ൽ CPU പരിധികൾ പ്രവർത്തനരഹിതമാക്കാൻ ഞങ്ങൾ ശക്തമായി ശുപാർശ ചെയ്യുന്നു (അല്ലെങ്കിൽ Kubelet-ൽ CFS ക്വാട്ടകൾ പ്രവർത്തനരഹിതമാക്കുക). കാമ്പിൽ ലഭ്യമാണ് ഗുരുതരമായ ഒപ്പം നന്നായി അറിയപ്പെടുന്നു അമിതമായ ത്രോട്ടിലിംഗിലേക്കും കാലതാമസത്തിലേക്കും നയിക്കുന്ന ഒരു ബഗ്.

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

ലേഖനത്തിന്റെ സംഗ്രഹം:

• കണ്ടെയ്‌നറുകളെക്കുറിച്ചും കുബർനെറ്റുകളെക്കുറിച്ചും കുറച്ച് വാക്കുകൾ;
• സിപിയു അഭ്യർത്ഥനകളും പരിധികളും എങ്ങനെ നടപ്പിലാക്കുന്നു;
• മൾട്ടി-കോർ പരിതസ്ഥിതിയിൽ സിപിയു പരിധി എങ്ങനെ പ്രവർത്തിക്കുന്നു;
• സിപിയു ത്രോട്ടിലിംഗ് എങ്ങനെ ട്രാക്ക് ചെയ്യാം;
• പ്രശ്ന പരിഹാരവും സൂക്ഷ്മതകളും.

കണ്ടെയ്‌നറുകളെക്കുറിച്ചും കുബർനെറ്റുകളെക്കുറിച്ചും കുറച്ച് വാക്കുകൾ

അടിസ്ഥാന സൗകര്യ ലോകത്തെ ആധുനിക നിലവാരമാണ് കുബർനെറ്റസ്. കണ്ടെയ്നർ ഓർക്കസ്ട്രേഷനാണ് ഇതിൻ്റെ പ്രധാന ജോലി.

കണ്ടെയ്നറുകൾ

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

കണ്ടെയ്നറുകൾ എല്ലാം മാറ്റി. ഇപ്പോൾ പുരാവസ്തു ഒരു കണ്ടെയ്നർ ചിത്രമാണ്. പ്രോഗ്രാം മാത്രമല്ല, ഒരു പൂർണ്ണമായ എക്സിക്യൂഷൻ എൻവയോൺമെൻ്റ് (Java/Python/...), കൂടാതെ ആവശ്യമായ ഫയലുകൾ/പാക്കേജുകൾ എന്നിവയും ഉൾക്കൊള്ളുന്ന ഒരു തരം എക്സ്റ്റെൻഡഡ് എക്സിക്യൂട്ടബിൾ ഫയലായി ഇത് പ്രതിനിധീകരിക്കാം, മുൻകൂട്ടി ഇൻസ്റ്റാൾ ചെയ്തതും തയ്യാറാണ്. ഓടുക. അധിക ഘട്ടങ്ങളൊന്നും കൂടാതെ വ്യത്യസ്ത സെർവറുകളിൽ കണ്ടെയ്‌നറുകൾ വിന്യസിക്കാനും പ്രവർത്തിപ്പിക്കാനും കഴിയും.

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

കുബേർനെറ്റ്

നേരത്തെ പറഞ്ഞതുപോലെ, കുബർനെറ്റസ് ഒരു കണ്ടെയ്നർ ഓർക്കസ്ട്രേറ്ററാണ്. ഇത് ഇതുപോലെ പ്രവർത്തിക്കുന്നു: നിങ്ങൾ അതിന് ഒരു കൂട്ടം മെഷീനുകൾ നൽകുക, തുടർന്ന് പറയുക: "ഹേയ്, കുബർനെറ്റസ്, 2 പ്രോസസറുകളും 3 ജിബി മെമ്മറിയും ഉള്ള എൻ്റെ കണ്ടെയ്‌നറിൻ്റെ പത്ത് സന്ദർഭങ്ങൾ നമുക്ക് സമാരംഭിക്കാം, അവ പ്രവർത്തിപ്പിച്ച് നിലനിർത്തുക!" ബാക്കി കാര്യങ്ങൾ കുബർനെറ്റസ് ഏറ്റെടുക്കും. ഇത് സൌജന്യ ശേഷി കണ്ടെത്തുകയും, കണ്ടെയ്നറുകൾ ലോഞ്ച് ചെയ്യുകയും ആവശ്യമെങ്കിൽ അവ പുനരാരംഭിക്കുകയും, പതിപ്പുകൾ മാറ്റുമ്പോൾ ഒരു അപ്ഡേറ്റ് പുറത്തിറക്കുകയും ചെയ്യും. അടിസ്ഥാനപരമായി, ഹാർഡ്‌വെയർ ഘടകത്തെ അമൂർത്തമാക്കാനും ആപ്ലിക്കേഷനുകൾ വിന്യസിക്കാനും പ്രവർത്തിപ്പിക്കാനും അനുയോജ്യമായ വൈവിധ്യമാർന്ന സിസ്റ്റങ്ങൾ നിർമ്മിക്കാനും Kubernetes നിങ്ങളെ അനുവദിക്കുന്നു.

സാധാരണക്കാരൻ്റെ വീക്ഷണകോണിൽ നിന്നുള്ള കുബർനെറ്റസ്

കുബർനെറ്റസിലെ അഭ്യർത്ഥനകളും പരിധികളും എന്തൊക്കെയാണ്

ശരി, ഞങ്ങൾ കണ്ടെയ്‌നറുകളും കുബർനെറ്റുകളും കവർ ചെയ്‌തു. ഒരേ മെഷീനിൽ ഒന്നിലധികം കണ്ടെയ്‌നറുകൾക്ക് താമസിക്കാൻ കഴിയുമെന്നും ഞങ്ങൾക്കറിയാം.

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

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

കുബർനെറ്റസിൽ അഭ്യർത്ഥനകളും പരിധികളും എങ്ങനെയാണ് നടപ്പിലാക്കുന്നത്

സിപിയു പരിധികൾ നടപ്പിലാക്കുന്നതിനായി കേർണലിൽ നിർമ്മിച്ചിരിക്കുന്ന ത്രോട്ടിംഗ് സംവിധാനം (ക്ലോക്ക് സൈക്കിളുകൾ ഒഴിവാക്കൽ) കുബെർനെറ്റസ് ഉപയോഗിക്കുന്നു. ഒരു ആപ്ലിക്കേഷൻ പരിധി കവിയുന്നുവെങ്കിൽ, ത്രോട്ടിലിംഗ് പ്രവർത്തനക്ഷമമാക്കും (അതായത്, ഇതിന് കുറച്ച് സിപിയു സൈക്കിളുകൾ മാത്രമേ ലഭിക്കൂ). മെമ്മറിയ്ക്കുള്ള അഭ്യർത്ഥനകളും പരിധികളും വ്യത്യസ്തമായി ക്രമീകരിച്ചിരിക്കുന്നു, അതിനാൽ അവ കണ്ടെത്തുന്നത് എളുപ്പമാണ്. ഇത് ചെയ്യുന്നതിന്, പോഡിൻ്റെ അവസാന പുനരാരംഭ നില പരിശോധിക്കുക: അത് "OOMKilled" ആണോ എന്ന്. CPU ത്രോട്ടിലിംഗ് അത്ര ലളിതമല്ല, കാരണം K8s മെട്രിക്കുകൾ ഉപയോഗത്തിലൂടെ മാത്രമേ ലഭ്യമാക്കൂ, cgroups വഴിയല്ല.

സിപിയു അഭ്യർത്ഥന

സിപിയു അഭ്യർത്ഥന എങ്ങനെയാണ് നടപ്പിലാക്കുന്നത്

ലാളിത്യത്തിനായി, ഉദാഹരണമായി 4-കോർ സിപിയു ഉള്ള ഒരു മെഷീൻ ഉപയോഗിക്കുന്ന പ്രക്രിയ നോക്കാം.

വിഭവങ്ങളുടെ (മെമ്മറിയും പ്രോസസറും) അലോക്കേഷൻ നിയന്ത്രിക്കാൻ K8s ഒരു കൺട്രോൾ ഗ്രൂപ്പ് മെക്കാനിസം (cgroups) ഉപയോഗിക്കുന്നു. അതിന് ഒരു ശ്രേണിപരമായ മാതൃക ലഭ്യമാണ്: കുട്ടി രക്ഷാകർതൃ ഗ്രൂപ്പിൻ്റെ പരിധികൾ അവകാശമാക്കുന്നു. വിതരണ വിശദാംശങ്ങൾ ഒരു വെർച്വൽ ഫയൽ സിസ്റ്റത്തിൽ സംഭരിച്ചിരിക്കുന്നു (/sys/fs/cgroup). ഒരു പ്രോസസറിൻ്റെ കാര്യത്തിൽ ഇതാണ് /sys/fs/cgroup/cpu,cpuacct/*.

K8s ഫയൽ ഉപയോഗിക്കുന്നു cpu.share പ്രോസസ്സർ ഉറവിടങ്ങൾ അനുവദിക്കുന്നതിന്. ഞങ്ങളുടെ കാര്യത്തിൽ, റൂട്ട് cgroup-ന് 4096 CPU ഉറവിടങ്ങൾ ലഭിക്കുന്നു - ലഭ്യമായ പ്രോസസർ ശക്തിയുടെ 100% (1 കോർ = 1024; ഇതൊരു നിശ്ചിത മൂല്യമാണ്). രജിസ്റ്റർ ചെയ്തിട്ടുള്ള പിൻഗാമികളുടെ ഓഹരികൾ അനുസരിച്ച് റൂട്ട് ഗ്രൂപ്പ് ആനുപാതികമായി വിഭവങ്ങൾ വിതരണം ചെയ്യുന്നു cpu.share, അവർ അവരുടെ പിൻഗാമികളോടും അങ്ങനെ തന്നെ ചെയ്യുന്നു. ഒരു സാധാരണ കുബർനെറ്റസ് നോഡിൽ, റൂട്ട് സി ഗ്രൂപ്പിന് മൂന്ന് കുട്ടികളുണ്ട്: system.slice, user.slice и kubepods. ആദ്യത്തെ രണ്ട് ഉപഗ്രൂപ്പുകളും കെ8-കൾക്ക് പുറത്തുള്ള നിർണായക സിസ്റ്റം ലോഡുകളും ഉപയോക്തൃ പ്രോഗ്രാമുകളും തമ്മിലുള്ള ഉറവിടങ്ങൾ വിതരണം ചെയ്യാൻ ഉപയോഗിക്കുന്നു. അവസാനത്തേത് - kubepods - പോഡുകൾക്കിടയിൽ വിഭവങ്ങൾ വിതരണം ചെയ്യുന്നതിനായി കുബർനെറ്റസ് സൃഷ്ടിച്ചത്.

ഒന്നാമത്തെയും രണ്ടാമത്തെയും ഉപഗ്രൂപ്പുകൾക്ക് ഓരോന്നും ലഭിച്ചതായി മുകളിലുള്ള ഡയഗ്രം കാണിക്കുന്നു 1024 ഷെയറുകൾ, kuberpod ഉപഗ്രൂപ്പ് അനുവദിച്ചു 4096 ഓഹരികൾ ഇത് എങ്ങനെ സാധ്യമാകും: എല്ലാത്തിനുമുപരി, റൂട്ട് ഗ്രൂപ്പിന് മാത്രമേ ആക്സസ് ഉള്ളൂ 4096 ഓഹരികൾ, അവളുടെ പിൻഗാമികളുടെ ഓഹരികളുടെ ആകെത്തുക ഈ സംഖ്യയെ കവിയുന്നു (6144)? മൂല്യം യുക്തിസഹമായി അർത്ഥമാക്കുന്നു, അതിനാൽ ലിനക്സ് ഷെഡ്യൂളർ (സിഎഫ്എസ്) സിപിയു ഉറവിടങ്ങൾ ആനുപാതികമായി അനുവദിക്കുന്നതിന് ഇത് ഉപയോഗിക്കുന്നു. ഞങ്ങളുടെ കാര്യത്തിൽ, ആദ്യത്തെ രണ്ട് ഗ്രൂപ്പുകൾ സ്വീകരിക്കുന്നു 680 യഥാർത്ഥ ഓഹരികൾ (16,6-ൽ 4096%), ശേഷിക്കുന്നത് kubepod-ന് ലഭിക്കുന്നു 2736 ഓഹരികൾ പ്രവർത്തനരഹിതമായ സാഹചര്യത്തിൽ, ആദ്യ രണ്ട് ഗ്രൂപ്പുകൾ അനുവദിച്ച വിഭവങ്ങൾ ഉപയോഗിക്കില്ല.

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

ഈ സംവിധാനം പ്രോസസർ പവറിൻ്റെ ന്യായമായ വിതരണം ഉറപ്പാക്കുകയും മറ്റുള്ളവരിൽ നിന്നുള്ള വിഭവങ്ങൾ ആരും "മോഷ്‌ടിക്കുന്നത്" എന്ന് ഉറപ്പാക്കുകയും ചെയ്യുന്നു.

സിപിയു പരിധി

കെ 8 കളിലെ പരിധികളുടെയും അഭ്യർത്ഥനകളുടെയും കോൺഫിഗറേഷനുകൾ സമാനമായി കാണപ്പെടുന്നുണ്ടെങ്കിലും, അവ നടപ്പിലാക്കുന്നത് തികച്ചും വ്യത്യസ്തമാണ്: ഇത് ഏറ്റവും തെറ്റിദ്ധരിപ്പിക്കുന്നത് ഏറ്റവും കുറവ് രേഖപ്പെടുത്തപ്പെട്ട ഭാഗവും.

K8s ഇടപഴകുന്നു CFS ക്വാട്ട മെക്കാനിസം പരിധികൾ നടപ്പിലാക്കാൻ. അവയുടെ ക്രമീകരണങ്ങൾ ഫയലുകളിൽ വ്യക്തമാക്കിയിട്ടുണ്ട് cfs_period_us и cfs_quota_us cgroup ഡയറക്ടറിയിൽ (ഫയലും അവിടെ സ്ഥിതിചെയ്യുന്നു cpu.share).

വ്യത്യസ്തമായി cpu.share, ക്വാട്ട അടിസ്ഥാനമാക്കിയുള്ളതാണ് സമയ കാലയളവ്, ലഭ്യമായ പ്രൊസസർ ശക്തിയിലല്ല. cfs_period_us കാലഘട്ടത്തിൻ്റെ ദൈർഘ്യം (യുഗം) വ്യക്തമാക്കുന്നു - ഇത് എല്ലായ്പ്പോഴും 100000 μs (100 ms) ആണ്. K8s-ൽ ഈ മൂല്യം മാറ്റാനുള്ള ഒരു ഓപ്ഷൻ ഉണ്ട്, എന്നാൽ ഇത് ഇപ്പോൾ ആൽഫയിൽ മാത്രമേ ലഭ്യമാകൂ. ഉപയോഗിച്ച ക്വാട്ടകൾ പുനരാരംഭിക്കാൻ ഷെഡ്യൂളർ യുഗം ഉപയോഗിക്കുന്നു. രണ്ടാമത്തെ ഫയൽ cfs_quota_us, ഓരോ യുഗത്തിലും ലഭ്യമായ സമയം (ക്വോട്ട) വ്യക്തമാക്കുന്നു. ഇത് മൈക്രോസെക്കൻഡിലും വ്യക്തമാക്കിയിട്ടുണ്ടെന്ന കാര്യം ശ്രദ്ധിക്കുക. ക്വാട്ട യുഗദൈർഘ്യം കവിഞ്ഞേക്കാം; മറ്റൊരു വിധത്തിൽ പറഞ്ഞാൽ, ഇത് 100 ms-ൽ കൂടുതലായിരിക്കാം.

16-കോർ മെഷീനുകളിലെ രണ്ട് സാഹചര്യങ്ങൾ നോക്കാം (ഓമിയോയിൽ നമുക്കുള്ള ഏറ്റവും സാധാരണമായ കമ്പ്യൂട്ടർ തരം):

സാഹചര്യം 1: 2 ത്രെഡുകളും 200 എംഎസ് പരിധിയും. ത്രോട്ടിലിംഗ് ഇല്ല

സാഹചര്യം 2: 10 ത്രെഡുകളും 200 എംഎസ് പരിധിയും. 20 ms കഴിഞ്ഞ് ത്രോട്ടിലിംഗ് ആരംഭിക്കുന്നു, മറ്റൊരു 80 ms കഴിഞ്ഞ് പ്രോസസ്സർ ഉറവിടങ്ങളിലേക്കുള്ള ആക്സസ് പുനരാരംഭിക്കുന്നു

നിങ്ങൾ സിപിയു പരിധി സജ്ജീകരിച്ചുവെന്ന് പറയാം 2 കേർണലുകൾ; Kubernetes ഈ മൂല്യം 200 ms ആയി വിവർത്തനം ചെയ്യും. ഇതിനർത്ഥം കണ്ടെയ്‌നറിന് ത്രോട്ടിലിംഗ് കൂടാതെ പരമാവധി 200ms CPU സമയം ഉപയോഗിക്കാനാകും.

ഇവിടെയാണ് വിനോദം ആരംഭിക്കുന്നത്. മുകളിൽ സൂചിപ്പിച്ചതുപോലെ, ലഭ്യമായ ക്വാട്ട 200 എംഎസ് ആണ്. നിങ്ങൾ സമാന്തരമായി പ്രവർത്തിക്കുകയാണെങ്കിൽ പത്ത് 12-കോർ മെഷീനിലെ ത്രെഡുകൾ (രംഗം 2-ൻ്റെ ചിത്രീകരണം കാണുക), മറ്റെല്ലാ പോഡുകളും നിഷ്‌ക്രിയമായിരിക്കുമ്പോൾ, ക്വാട്ട വെറും 20 ms-ൽ തീർന്നുപോകും (10 * 20 ms = 200 ms മുതൽ), ഈ പോഡിൻ്റെ എല്ലാ ത്രെഡുകളും തൂങ്ങിക്കിടക്കും. » (ത്രോട്ടിൽ) അടുത്ത 80 എം.എസ്. ഇതിനകം സൂചിപ്പിച്ചത് ഷെഡ്യൂളർ ബഗ്, അമിതമായ ത്രോട്ടിലിംഗ് സംഭവിക്കുന്നതിനാൽ കണ്ടെയ്‌നറിന് നിലവിലുള്ള ക്വാട്ട നിറവേറ്റാൻ പോലും കഴിയില്ല.

കായ്കളിലെ ത്രോട്ടിലിംഗ് എങ്ങനെ വിലയിരുത്താം?

പോഡിലേക്ക് ലോഗിൻ ചെയ്ത് എക്സിക്യൂട്ട് ചെയ്യുക cat /sys/fs/cgroup/cpu/cpu.stat.

• nr_periods - ഷെഡ്യൂളർ കാലയളവുകളുടെ ആകെ എണ്ണം;
• nr_throttled - കോമ്പോസിഷനിലെ ത്രോട്ടിൽ ചെയ്ത കാലഘട്ടങ്ങളുടെ എണ്ണം nr_periods;
• throttled_time - നാനോ സെക്കൻഡിൽ ക്യുമുലേറ്റീവ് ത്രോട്ടിൽഡ് സമയം.

ശരിക്കും എന്താണ് നടക്കുന്നത്?

തൽഫലമായി, എല്ലാ ആപ്ലിക്കേഷനുകളിലും ഞങ്ങൾക്ക് ഉയർന്ന ത്രോട്ടിംഗ് ലഭിക്കുന്നു. ചിലപ്പോൾ അവൻ അകത്തുണ്ട് ഒന്നര തവണ കണക്കാക്കിയതിനേക്കാൾ ശക്തമാണ്!

ഇത് വിവിധ പിശകുകളിലേക്ക് നയിക്കുന്നു - റെഡിനസ് ചെക്ക് പരാജയങ്ങൾ, കണ്ടെയ്നർ ഫ്രീസുകൾ, നെറ്റ്‌വർക്ക് കണക്ഷൻ ബ്രേക്കുകൾ, സേവന കോളുകൾക്കുള്ളിലെ സമയപരിധി. ഇത് ആത്യന്തികമായി ലേറ്റൻസി വർദ്ധിപ്പിക്കുന്നതിനും ഉയർന്ന പിശക് നിരക്കുകൾക്കും കാരണമാകുന്നു.

തീരുമാനവും അനന്തരഫലങ്ങളും

ഇവിടെ എല്ലാം ലളിതമാണ്. ഞങ്ങൾ CPU പരിധികൾ ഉപേക്ഷിച്ച്, ബഗ് പരിഹരിച്ച ഏറ്റവും പുതിയ പതിപ്പിലേക്ക് ക്ലസ്റ്ററുകളിലെ OS കേർണൽ അപ്ഡേറ്റ് ചെയ്യാൻ തുടങ്ങി. ഞങ്ങളുടെ സേവനങ്ങളിലെ പിശകുകളുടെ എണ്ണം (HTTP 5xx) ഉടൻ തന്നെ ഗണ്യമായി കുറഞ്ഞു:

HTTP 5xx പിശകുകൾ

ഒരു സുപ്രധാന സേവനത്തിന് HTTP 5xx പിശകുകൾ

പ്രതികരണ സമയം p95

ഗുരുതരമായ സേവന അഭ്യർത്ഥന ലേറ്റൻസി, 95-ാം ശതമാനം

പ്രവർത്തന ചിലവ്

ചെലവഴിച്ച ഉദാഹരണ മണിക്കൂറുകളുടെ എണ്ണം

മീൻപിടിത്തം എന്താണ്?

ലേഖനത്തിൻ്റെ തുടക്കത്തിൽ പറഞ്ഞതുപോലെ:

ഒരു സാമുദായിക അപ്പാർട്ട്മെൻ്റുമായി ഒരു സാമ്യം വരയ്ക്കാം... കുബർനെറ്റസ് ഒരു റിയൽറ്ററായി പ്രവർത്തിക്കുന്നു. എന്നാൽ പരസ്പരം കലഹങ്ങളിൽ നിന്ന് കുടിയാന്മാരെ എങ്ങനെ നിലനിർത്താം? അവരിൽ ഒരാൾ, പകുതി ദിവസം ബാത്ത്റൂം കടം വാങ്ങാൻ തീരുമാനിച്ചാലോ?

ഇതാ ക്യാച്ച്. ഒരു അശ്രദ്ധമായ കണ്ടെയ്‌നറിന് ഒരു മെഷീനിൽ ലഭ്യമായ എല്ലാ സിപിയു വിഭവങ്ങളും തിന്നുതീർക്കാൻ കഴിയും. നിങ്ങൾക്ക് ഒരു സ്മാർട്ട് ആപ്ലിക്കേഷൻ സ്റ്റാക്ക് ഉണ്ടെങ്കിൽ (ഉദാഹരണത്തിന്, JVM, Go, Node VM ശരിയായി ക്രമീകരിച്ചിരിക്കുന്നു), ഇത് ഒരു പ്രശ്നമല്ല: നിങ്ങൾക്ക് അത്തരം സാഹചര്യങ്ങളിൽ വളരെക്കാലം പ്രവർത്തിക്കാൻ കഴിയും. എന്നാൽ ആപ്ലിക്കേഷനുകൾ മോശമായി ഒപ്റ്റിമൈസ് ചെയ്തതോ ഒപ്റ്റിമൈസ് ചെയ്തിട്ടില്ലെങ്കിലോ (FROM java:latest), സ്ഥിതി നിയന്ത്രണാതീതമായേക്കാം. ഒമിയോയിൽ ഞങ്ങൾക്ക് പ്രധാന ഭാഷാ സ്റ്റാക്കിനായി മതിയായ സ്ഥിരസ്ഥിതി ക്രമീകരണങ്ങളുള്ള ഓട്ടോമേറ്റഡ് ബേസ് ഡോക്കർഫയലുകൾ ഉണ്ട്, അതിനാൽ ഈ പ്രശ്നം നിലവിലില്ല.

അളവുകൾ നിരീക്ഷിക്കാൻ ഞങ്ങൾ ശുപാർശ ചെയ്യുന്നു ഉപയോഗിക്കുക (ഉപയോഗം, സാച്ചുറേഷൻ, പിശകുകൾ), API കാലതാമസങ്ങളും പിശക് നിരക്കുകളും. ഫലങ്ങൾ പ്രതീക്ഷകൾ നിറവേറ്റുന്നുവെന്ന് ഉറപ്പാക്കുക.

റെഫറൻസുകൾ

ഇതാണ് ഞങ്ങളുടെ കഥ. എന്താണ് സംഭവിക്കുന്നതെന്ന് മനസിലാക്കാൻ ഇനിപ്പറയുന്ന മെറ്റീരിയലുകൾ വളരെയധികം സഹായിച്ചു:

• kernel.org → CFS ഷെഡ്യൂളർ;
• kernel.org → CFS ബാൻഡ്‌വിഡ്ത്ത് നിയന്ത്രണം;
• Linux കണ്ടെയ്‌നർ ഷെഡ്യൂളിംഗ് മനസ്സിലാക്കുന്നു;
• Linux കണ്ടെയ്‌നറുകളെ കുറിച്ച് നിങ്ങൾ അറിയേണ്ടതെല്ലാം, ഭാഗം I: Linux Control Groups and Process Isolation;
• കുബർനെറ്റസ് പരാജയ കഥകൾ - "സിപിയു ത്രോട്ടിലിംഗ്" തിരയുക.

കുബർനെറ്റസ് ബഗ് റിപ്പോർട്ടുകൾ:

• #51135: ഗ്യാരണ്ടീഡ് പോഡുകൾക്ക് CPU പരിധികൾ സജ്ജീകരിക്കുന്നത് ഒഴിവാക്കുക;
• #67577: CFS ക്വാട്ടകൾ അനാവശ്യമായ ത്രോട്ടിലിംഗിലേക്ക് നയിച്ചേക്കാം;
• അമിതമായ ആക്രമണാത്മക CFS.

നിങ്ങളുടെ പരിശീലനത്തിൽ സമാനമായ പ്രശ്നങ്ങൾ നേരിട്ടിട്ടുണ്ടോ അതോ കണ്ടെയ്നറൈസ്ഡ് പ്രൊഡക്ഷൻ പരിതസ്ഥിതികളിൽ ത്രോട്ടിലിംഗുമായി ബന്ധപ്പെട്ട അനുഭവം ഉണ്ടോ? അഭിപ്രായങ്ങളിൽ നിങ്ങളുടെ കഥ പങ്കിടുക!

വിവർത്തകനിൽ നിന്ന് പി.എസ്

ഞങ്ങളുടെ ബ്ലോഗിലും വായിക്കുക:

• «കുബർനെറ്റസിലെ ഓട്ടോസ്‌കേലിംഗും റിസോഴ്‌സ് മാനേജ്‌മെന്റും (അവലോകനവും വീഡിയോ റിപ്പോർട്ടും)";
• «കുബർനെറ്റസിൽ സിപിയു മാനേജർ എങ്ങനെ പ്രവർത്തിക്കുന്നു";
• «നിങ്ങൾ kubectl റൺ പ്രവർത്തിപ്പിക്കുമ്പോൾ Kubernetes-ൽ എന്താണ് സംഭവിക്കുന്നത്? ഭാഗം 2".

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