കുബർനെറ്റസിലെ ഓട്ടോസ്‌കേലിംഗും റിസോഴ്‌സ് മാനേജ്‌മെന്റും (അവലോകനവും വീഡിയോ റിപ്പോർട്ടും)

ഏപ്രിൽ 27 ന് സമ്മേളനത്തിൽ സമരം 2019, "DevOps" വിഭാഗത്തിന്റെ ഭാഗമായി, "Autoscaling and resource management in Kubernetes" എന്ന റിപ്പോർട്ട് നൽകി. നിങ്ങളുടെ ആപ്ലിക്കേഷനുകളുടെ ഉയർന്ന ലഭ്യത ഉറപ്പാക്കാനും മികച്ച പ്രകടനം ഉറപ്പാക്കാനും K8s എങ്ങനെ ഉപയോഗിക്കാം എന്നതിനെക്കുറിച്ച് ഇത് സംസാരിക്കുന്നു.

പാരമ്പര്യമനുസരിച്ച്, അവതരിപ്പിക്കുന്നതിൽ ഞങ്ങൾക്ക് സന്തോഷമുണ്ട് റിപ്പോർട്ടിന്റെ വീഡിയോ (44 മിനിറ്റ്, ലേഖനത്തേക്കാൾ കൂടുതൽ വിവരദായകമാണ്) കൂടാതെ വാചക രൂപത്തിലുള്ള പ്രധാന സംഗ്രഹവും. പോകൂ!

റിപ്പോർട്ടിന്റെ വിഷയം ഓരോ വാക്കും വിശകലനം ചെയ്ത് അവസാനം മുതൽ ആരംഭിക്കാം.

കുബേർനെറ്റ്

ഞങ്ങളുടെ ഹോസ്റ്റിൽ ഡോക്കർ കണ്ടെയ്‌നറുകൾ ഉണ്ടെന്ന് പറയാം. എന്തിനുവേണ്ടി? ലളിതവും മികച്ചതുമായ വിന്യാസം അനുവദിക്കുന്ന ആവർത്തനക്ഷമതയും ഒറ്റപ്പെടലും ഉറപ്പാക്കാൻ, CI/CD. കണ്ടെയ്‌നറുകളുള്ള ഇത്തരം നിരവധി വാഹനങ്ങൾ നമുക്കുണ്ട്.

ഈ കേസിൽ കുബെർനെറ്റസ് എന്താണ് നൽകുന്നത്?

1. ഞങ്ങൾ ഈ മെഷീനുകളെ കുറിച്ച് ചിന്തിക്കുന്നത് നിർത്തി "ക്ലൗഡ്" ഉപയോഗിച്ച് പ്രവർത്തിക്കാൻ തുടങ്ങുന്നു പാത്രങ്ങളുടെ കൂട്ടം അല്ലെങ്കിൽ പോഡ്സ് (പാത്രങ്ങളുടെ ഗ്രൂപ്പുകൾ).
2. മാത്രമല്ല, ഞങ്ങൾ വ്യക്തിഗത പോഡുകളെക്കുറിച്ച് ചിന്തിക്കുകപോലുമില്ല, പക്ഷേ കൂടുതൽ കൈകാര്യം ചെയ്യുകоവലിയ ഗ്രൂപ്പുകൾ. അത്തരം ഉയർന്ന തലത്തിലുള്ള പ്രാകൃതങ്ങൾ ഒരു നിശ്ചിത ജോലിഭാരം പ്രവർത്തിപ്പിക്കുന്നതിന് ഒരു ടെംപ്ലേറ്റ് ഉണ്ടെന്ന് പറയാൻ ഞങ്ങളെ അനുവദിക്കുക, അത് പ്രവർത്തിപ്പിക്കുന്നതിന് ആവശ്യമായ നിരവധി സന്ദർഭങ്ങൾ ഇവിടെയുണ്ട്. ഞങ്ങൾ പിന്നീട് ടെംപ്ലേറ്റ് മാറ്റുകയാണെങ്കിൽ, എല്ലാ സംഭവങ്ങളും മാറും.
3. സഹായത്തോടെ ഡിക്ലറേറ്റീവ് API നിർദ്ദിഷ്ട കമാൻഡുകളുടെ ഒരു ക്രമം നടപ്പിലാക്കുന്നതിനുപകരം, കുബർനെറ്റസ് സൃഷ്ടിച്ച "ലോകത്തിന്റെ ഘടന" (YAML-ൽ) ഞങ്ങൾ വിവരിക്കുന്നു. വീണ്ടും: വിവരണം മാറുമ്പോൾ, അതിന്റെ യഥാർത്ഥ പ്രദർശനവും മാറും.

റിസോഴ്സ് മാനേജ്മെന്റ്

സിപിയു

നമുക്ക് nginx, php-fpm, mysql എന്നിവ സെർവറിൽ പ്രവർത്തിപ്പിക്കാം. ഈ സേവനങ്ങൾക്ക് യഥാർത്ഥത്തിൽ കൂടുതൽ പ്രോസസ്സുകൾ പ്രവർത്തിക്കും, അവയിൽ ഓരോന്നിനും കമ്പ്യൂട്ടിംഗ് ഉറവിടങ്ങൾ ആവശ്യമാണ്:

(സ്ലൈഡിലെ അക്കങ്ങൾ "തത്തകൾ" ആണ്, കമ്പ്യൂട്ടിംഗ് പവറിന്റെ ഓരോ പ്രക്രിയയുടെയും അമൂർത്തമായ ആവശ്യകത)

ഇതിനൊപ്പം പ്രവർത്തിക്കുന്നത് എളുപ്പമാക്കുന്നതിന്, പ്രക്രിയകളെ ഗ്രൂപ്പുകളായി സംയോജിപ്പിക്കുന്നത് യുക്തിസഹമാണ് (ഉദാഹരണത്തിന്, എല്ലാ nginx പ്രക്രിയകളും ഒരു ഗ്രൂപ്പായി "nginx"). ഇത് ചെയ്യാനുള്ള ലളിതവും വ്യക്തവുമായ മാർഗ്ഗം ഓരോ ഗ്രൂപ്പും ഒരു കണ്ടെയ്നറിൽ ഇടുക എന്നതാണ്:

തുടരുന്നതിന്, ഒരു കണ്ടെയ്നർ എന്താണെന്ന് നിങ്ങൾ ഓർക്കേണ്ടതുണ്ട് (ലിനക്സിൽ). വളരെക്കാലം മുമ്പ് നടപ്പിലാക്കിയ കേർണലിലെ മൂന്ന് പ്രധാന സവിശേഷതകൾ കാരണം അവയുടെ രൂപം സാധ്യമാക്കി: കഴിവുകൾ, നാമസ്പെയ്സുകൾ и cgroups. മറ്റ് സാങ്കേതികവിദ്യകൾ (ഡോക്കർ പോലുള്ള സൗകര്യപ്രദമായ "ഷെല്ലുകൾ" ഉൾപ്പെടെ) കൂടുതൽ വികസനം സുഗമമാക്കി:

റിപ്പോർട്ടിന്റെ പശ്ചാത്തലത്തിൽ, ഞങ്ങൾക്ക് താൽപ്പര്യമുണ്ട് cgroups, കാരണം നിയന്ത്രണ ഗ്രൂപ്പുകൾ റിസോഴ്സ് മാനേജ്മെന്റ് നടപ്പിലാക്കുന്ന കണ്ടെയ്നറുകളുടെ (ഡോക്കർ, മുതലായവ) പ്രവർത്തനത്തിന്റെ ഭാഗമാണ്. ഞങ്ങൾ ആഗ്രഹിച്ചതുപോലെ ഗ്രൂപ്പുകളായി സംയോജിപ്പിച്ച പ്രക്രിയകൾ നിയന്ത്രണ ഗ്രൂപ്പുകളാണ്.

ഈ പ്രക്രിയകൾക്കായുള്ള സിപിയു ആവശ്യകതകളിലേക്കും ഇപ്പോൾ പ്രോസസ്സുകളുടെ ഗ്രൂപ്പുകളിലേക്കും മടങ്ങാം:

(എല്ലാ സംഖ്യകളും വിഭവങ്ങളുടെ ആവശ്യകതയുടെ അമൂർത്തമായ പ്രകടനമാണെന്ന് ഞാൻ ആവർത്തിക്കുന്നു)

അതേ സമയം, സിപിയുവിന് തന്നെ ഒരു നിശ്ചിത പരിമിതമായ വിഭവമുണ്ട് (ഉദാഹരണത്തിൽ ഇത് 1000 ആണ്), എല്ലാവർക്കും കുറവായിരിക്കാം (എല്ലാ ഗ്രൂപ്പുകളുടെയും ആവശ്യങ്ങളുടെ ആകെത്തുക 150+850+460=1460 ആണ്). ഈ കേസിൽ എന്ത് സംഭവിക്കും?

കേർണൽ ഉറവിടങ്ങൾ വിതരണം ചെയ്യാൻ തുടങ്ങുകയും അത് "ന്യായമായി" ചെയ്യുകയും ചെയ്യുന്നു, ഓരോ ഗ്രൂപ്പിനും ഒരേ അളവിലുള്ള വിഭവങ്ങൾ നൽകുന്നു. എന്നാൽ ആദ്യ സന്ദർഭത്തിൽ, അവയിൽ ആവശ്യത്തിലധികം (333>150) ഉണ്ട്, അതിനാൽ അധികമായത് (333-150=183) കരുതൽ ശേഖരത്തിൽ തുടരുന്നു, അത് മറ്റ് രണ്ട് കണ്ടെയ്നറുകൾക്കിടയിൽ തുല്യമായി വിതരണം ചെയ്യപ്പെടുന്നു:

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

രണ്ടാമത്തെ കണ്ടെയ്നറിലെ (php-fpm) വിഭവങ്ങളുടെ അഭാവത്തിന്റെ കാര്യം നോക്കാം. എല്ലാ കണ്ടെയ്നർ ഉറവിടങ്ങളും പ്രക്രിയകൾക്കിടയിൽ തുല്യമായി വിതരണം ചെയ്യപ്പെടുന്നു. തൽഫലമായി, മാസ്റ്റർ പ്രക്രിയ നന്നായി പ്രവർത്തിക്കുന്നു, പക്ഷേ എല്ലാ തൊഴിലാളികളും മന്ദഗതിയിലാക്കുന്നു, അവർക്ക് ആവശ്യമുള്ളതിന്റെ പകുതിയിൽ താഴെ മാത്രമേ ലഭിക്കുന്നുള്ളൂ:

ഇങ്ങനെയാണ് CFS ഷെഡ്യൂളർ പ്രവർത്തിക്കുന്നത്. കണ്ടെയ്‌നറുകളിലേക്ക് ഞങ്ങൾ നൽകുന്ന തൂക്കങ്ങളെ ഞങ്ങൾ കൂടുതൽ വിളിക്കും അഭ്യർത്ഥിക്കുന്നു. എന്തുകൊണ്ടാണ് ഇത് സംഭവിക്കുന്നത് - കൂടുതൽ കാണുക.

നമുക്ക് മറുവശത്ത് നിന്ന് മുഴുവൻ സാഹചര്യവും നോക്കാം. നിങ്ങൾക്കറിയാവുന്നതുപോലെ, എല്ലാ റോഡുകളും റോമിലേക്കും കമ്പ്യൂട്ടറിന്റെ കാര്യത്തിൽ സിപിയുവിലേക്കും നയിക്കുന്നു. ഒരു സിപിയു, നിരവധി ജോലികൾ - നിങ്ങൾക്ക് ഒരു ട്രാഫിക് ലൈറ്റ് ആവശ്യമാണ്. ഉറവിടങ്ങൾ കൈകാര്യം ചെയ്യുന്നതിനുള്ള ഏറ്റവും ലളിതമായ മാർഗ്ഗം "ട്രാഫിക് ലൈറ്റ്" ആണ്: അവർ ഒരു പ്രോസസ്സിന് സിപിയുവിലേക്ക് ഒരു നിശ്ചിത ആക്സസ് സമയം നൽകി, അടുത്തത് മുതലായവ.

ഈ സമീപനത്തെ ഹാർഡ് ക്വാട്ട എന്ന് വിളിക്കുന്നു (ഹാർഡ് പരിമിതപ്പെടുത്തൽ). നമുക്ക് അത് ലളിതമായി ഓർക്കാം പരിധികൾ. എന്നിരുന്നാലും, നിങ്ങൾ എല്ലാ കണ്ടെയ്‌നറുകൾക്കും പരിധികൾ വിതരണം ചെയ്യുകയാണെങ്കിൽ, ഒരു പ്രശ്‌നം ഉയർന്നുവരുന്നു: mysql റോഡിലൂടെ ഡ്രൈവ് ചെയ്യുകയായിരുന്നു, ഒരു ഘട്ടത്തിൽ അതിന്റെ CPU-ന്റെ ആവശ്യം അവസാനിച്ചു, എന്നാൽ മറ്റെല്ലാ പ്രക്രിയകളും CPU വരെ കാത്തിരിക്കാൻ നിർബന്ധിതരാകുന്നു. നിഷ്ക്രിയ.

നമുക്ക് ലിനക്സ് കേർണലിലേക്കും സിപിയുവുമായുള്ള അതിന്റെ ഇടപെടലിലേക്കും മടങ്ങാം - മൊത്തത്തിലുള്ള ചിത്രം ഇപ്രകാരമാണ്:

cgroup-ന് രണ്ട് ക്രമീകരണങ്ങളുണ്ട് - അടിസ്ഥാനപരമായി ഇവ രണ്ട് ലളിതമായ "ട്വിസ്റ്റുകൾ" ആണ്, അത് നിങ്ങളെ നിർണ്ണയിക്കാൻ അനുവദിക്കുന്നു:

1. കണ്ടെയ്നറിനുള്ള ഭാരം (അഭ്യർത്ഥനകൾ) ആണ് ഷെയറുകള്;
2. കണ്ടെയ്‌നർ ടാസ്‌ക്കുകളിൽ പ്രവർത്തിക്കുന്നതിനുള്ള മൊത്തം സിപിയു സമയത്തിന്റെ ശതമാനം (പരിധികൾ). ക്വാട്ട.

സിപിയു അളക്കുന്നത് എങ്ങനെ?

വ്യത്യസ്ത വഴികളുണ്ട്:

1. എന്ത് തത്ത കഷണം, ആർക്കും അറിയില്ല - നിങ്ങൾ ഓരോ തവണയും ചർച്ച ചെയ്യേണ്ടതുണ്ട്.
2. താൽപ്പര്യം വ്യക്തവും എന്നാൽ ആപേക്ഷികവുമാണ്: 50 കോറുകളും 4 കോറുകളും ഉള്ള ഒരു സെർവറിന്റെ 20% തികച്ചും വ്യത്യസ്തമായ കാര്യങ്ങളാണ്.
3. നിങ്ങൾക്ക് ഇതിനകം സൂചിപ്പിച്ചവ ഉപയോഗിക്കാം ഭാരം, ലിനക്സിന് അറിയാമെങ്കിലും അവ ആപേക്ഷികവുമാണ്.
4. കമ്പ്യൂട്ടിംഗ് ഉറവിടങ്ങൾ അളക്കുക എന്നതാണ് ഏറ്റവും അനുയോജ്യമായ ഓപ്ഷൻ സെക്കന്റുകൾ. ആ. തത്സമയ സെക്കന്റുകളുമായി താരതമ്യപ്പെടുത്തുമ്പോൾ പ്രോസസ്സർ സമയത്തിന്റെ സെക്കൻഡിൽ: 1 റിയൽ സെക്കൻഡിൽ 1 സെക്കൻഡ് പ്രോസസ്സർ സമയം നൽകി - ഇത് ഒരു മുഴുവൻ സിപിയു കോർ ആണ്.

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

3 സിപിയു കോറുകളുള്ള ഒരു സെർവറുള്ള ഒരു ലളിതമായ ഉദാഹരണം നോക്കാം, അവിടെ മൂന്ന് പോഡുകൾക്ക് ഭാരം (500, 1000, 1500) നൽകും, അത് അവയ്ക്ക് അനുവദിച്ചിരിക്കുന്ന കോറുകളുടെ അനുബന്ധ ഭാഗങ്ങളിലേക്ക് എളുപ്പത്തിൽ പരിവർത്തനം ചെയ്യപ്പെടും (0,5, 1, 1,5).

നിങ്ങൾ രണ്ടാമത്തെ സെർവർ എടുക്കുകയാണെങ്കിൽ, അവിടെ ഇരട്ടി കോറുകൾ (6) ഉണ്ടാകും, അതേ പോഡുകൾ അവിടെ സ്ഥാപിക്കുകയാണെങ്കിൽ, കോറുകളുടെ വിതരണം 2 (യഥാക്രമം 1, 2, 3, യഥാക്രമം) കൊണ്ട് ഗുണിച്ച് എളുപ്പത്തിൽ കണക്കാക്കാം. എന്നാൽ ഈ സെർവറിൽ നാലാമത്തെ പോഡ് ദൃശ്യമാകുമ്പോൾ ഒരു പ്രധാന നിമിഷം സംഭവിക്കുന്നു, അതിന്റെ ഭാരം, സൗകര്യാർത്ഥം, 3000 ആയിരിക്കും. ഇത് സിപിയു ഉറവിടങ്ങളുടെ ഒരു ഭാഗം (പകുതി കോറുകൾ) എടുത്തുകളയുന്നു, ശേഷിക്കുന്ന പോഡുകൾക്ക് അവ വീണ്ടും കണക്കാക്കുന്നു (പകുതി):

കുബർനെറ്റുകളും സിപിയു ഉറവിടങ്ങളും

കുബർനെറ്റസിൽ, സിപിയു ഉറവിടങ്ങൾ സാധാരണയായി അളക്കുന്നു മില്ലിയാഡ്രാക്സ്, അതായത്. അടിസ്ഥാന ഭാരമായി 0,001 കോറുകൾ എടുക്കുന്നു. (Linux/cgroups ടെർമിനോളജിയിലെ അതേ സംഗതിയെ CPU ഷെയർ എന്ന് വിളിക്കുന്നു, എന്നിരുന്നാലും, കൂടുതൽ കൃത്യമായി പറഞ്ഞാൽ, 1000 millicores = 1024 CPU ഷെയറുകൾ.) എല്ലാ പോഡുകളുടെയും ഭാരത്തിന്റെ ആകെത്തുകയ്ക്ക് CPU ഉറവിടങ്ങളേക്കാൾ കൂടുതൽ പോഡുകൾ സെർവറിൽ സ്ഥാപിക്കുന്നില്ലെന്ന് K8s ഉറപ്പാക്കുന്നു.

ഇത് എങ്ങനെ സംഭവിക്കുന്നു? നിങ്ങൾ ഒരു കുബർനെറ്റസ് ക്ലസ്റ്ററിലേക്ക് ഒരു സെർവർ ചേർക്കുമ്പോൾ, അതിന് എത്ര CPU കോറുകൾ ലഭ്യമാണെന്ന് റിപ്പോർട്ടുചെയ്യുന്നു. ഒരു പുതിയ പോഡ് സൃഷ്ടിക്കുമ്പോൾ, ഈ പോഡിന് എത്ര കോറുകൾ ആവശ്യമാണെന്ന് കുബർനെറ്റസ് ഷെഡ്യൂളർക്ക് അറിയാം. അങ്ങനെ, ആവശ്യത്തിന് കോറുകൾ ഉള്ള ഒരു സെർവറിലേക്ക് പോഡ് അസൈൻ ചെയ്യപ്പെടും.

എങ്കിൽ എന്ത് സംഭവിക്കും അല്ല അഭ്യർത്ഥന വ്യക്തമാക്കിയിട്ടുണ്ടോ (അതായത് പോഡിന് ആവശ്യമായ കോറുകളുടെ ഒരു നിശ്ചിത എണ്ണം ഇല്ല)? കുബെർനെറ്റസ് സാധാരണയായി വിഭവങ്ങൾ കണക്കാക്കുന്നത് എങ്ങനെയെന്ന് നമുക്ക് നോക്കാം.

ഒരു പോഡിനായി നിങ്ങൾക്ക് രണ്ട് അഭ്യർത്ഥനകളും (CFS ഷെഡ്യൂളർ) പരിധികളും (ട്രാഫിക് ലൈറ്റ് ഓർക്കുന്നുണ്ടോ?):

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

മെമ്മറി

മെമ്മറിയിൽ, സാഹചര്യം സമാനമാണ്, പക്ഷേ അല്പം വ്യത്യസ്തമാണ് - എല്ലാത്തിനുമുപരി, ഈ വിഭവങ്ങളുടെ സ്വഭാവം വ്യത്യസ്തമാണ്. പൊതുവേ, സാമ്യം ഇപ്രകാരമാണ്:

മെമ്മറിയിൽ അഭ്യർത്ഥനകൾ എങ്ങനെ നടപ്പിലാക്കുന്നുവെന്ന് നോക്കാം. പോഡുകളെ സെർവറിൽ ജീവിക്കാൻ അനുവദിക്കുക, മെമ്മറി ഉപഭോഗം മാറ്റുക, അവയിലൊന്ന് മെമ്മറി തീരുന്നതുവരെ വലുതാകുന്നതുവരെ. ഈ സാഹചര്യത്തിൽ, OOM കൊലയാളി പ്രത്യക്ഷപ്പെടുകയും ഏറ്റവും വലിയ പ്രക്രിയയെ കൊല്ലുകയും ചെയ്യുന്നു:

ഇത് എല്ലായ്പ്പോഴും ഞങ്ങൾക്ക് അനുയോജ്യമല്ല, അതിനാൽ ഏതൊക്കെ പ്രക്രിയകളാണ് നമുക്ക് പ്രധാനമെന്നും കൊല്ലപ്പെടരുതെന്നും നിയന്ത്രിക്കാൻ കഴിയും. ഇത് ചെയ്യുന്നതിന്, പരാമീറ്റർ ഉപയോഗിക്കുക oom_score_adj.

നമുക്ക് CPU-യുടെ QoS ക്ലാസുകളിലേക്ക് മടങ്ങാം, പോഡുകൾക്കുള്ള മെമ്മറി ഉപഭോഗ മുൻഗണനകൾ നിർണ്ണയിക്കുന്ന oom_score_adj മൂല്യങ്ങളുമായി ഒരു സാമ്യം വരയ്ക്കാം:

• ഒരു പോഡിന്റെ ഏറ്റവും കുറഞ്ഞ oom_score_adj മൂല്യം - -998 - ഇത്തരമൊരു പോഡ് അവസാനമായി കൊല്ലണം എന്നാണ്. ഗ്യാരണ്ടി.
• ഏറ്റവും ഉയർന്നത് - 1000 - ആണ് നല്ല ശ്രമം, അത്തരം കായ്കൾ ആദ്യം കൊല്ലപ്പെടുന്നു.
• ശേഷിക്കുന്ന മൂല്യങ്ങൾ കണക്കാക്കാൻ (പൊട്ടുന്ന) ഒരു സൂത്രവാക്യമുണ്ട്, അതിന്റെ സാരാംശം ഒരു പോഡ് കൂടുതൽ വിഭവങ്ങൾ ആവശ്യപ്പെട്ടാൽ അത് കൊല്ലപ്പെടാനുള്ള സാധ്യത കുറവാണ്.

രണ്ടാമത്തെ "ട്വിസ്റ്റ്" - ലിമിറ്റ്_ഇൻ_ബൈറ്റുകൾ - പരിധികൾക്കായി. ഇത് ഉപയോഗിച്ച്, എല്ലാം ലളിതമാണ്: ഇഷ്യൂ ചെയ്ത മെമ്മറിയുടെ പരമാവധി അളവ് ഞങ്ങൾ നിയോഗിക്കുന്നു, ഇവിടെ (സിപിയുവിൽ നിന്ന് വ്യത്യസ്തമായി) ഇത് എങ്ങനെ അളക്കാം (മെമ്മറി) എന്ന ചോദ്യമില്ല.

ആകെ

കുബർനെറ്റസിലെ ഓരോ പോഡും നൽകിയിരിക്കുന്നു requests и limits - സിപിയുവിനും മെമ്മറിക്കുമുള്ള രണ്ട് പരാമീറ്ററുകളും:

1. അഭ്യർത്ഥനകളെ അടിസ്ഥാനമാക്കി, സെർവറുകൾക്കിടയിൽ പോഡുകൾ വിതരണം ചെയ്യുന്ന കുബർനെറ്റസ് ഷെഡ്യൂളർ പ്രവർത്തിക്കുന്നു;
2. എല്ലാ പാരാമീറ്ററുകളുടെയും അടിസ്ഥാനത്തിൽ, പോഡിന്റെ QoS ക്ലാസ് നിർണ്ണയിക്കപ്പെടുന്നു;
3. CPU അഭ്യർത്ഥനകളെ അടിസ്ഥാനമാക്കിയാണ് ആപേക്ഷിക ഭാരം കണക്കാക്കുന്നത്;
4. CPU അഭ്യർത്ഥനകളെ അടിസ്ഥാനമാക്കി CFS ഷെഡ്യൂളർ ക്രമീകരിച്ചിരിക്കുന്നു;
5. മെമ്മറി അഭ്യർത്ഥനകളെ അടിസ്ഥാനമാക്കിയാണ് OOM കില്ലർ ക്രമീകരിച്ചിരിക്കുന്നത്;
6. CPU പരിധികളെ അടിസ്ഥാനമാക്കി ഒരു "ട്രാഫിക് ലൈറ്റ്" ക്രമീകരിച്ചിരിക്കുന്നു;
7. മെമ്മറി പരിധികളെ അടിസ്ഥാനമാക്കി, cgroup-നായി ഒരു പരിധി ക്രമീകരിച്ചിരിക്കുന്നു.

പൊതുവേ, റിസോഴ്‌സ് മാനേജ്‌മെന്റിന്റെ പ്രധാന ഭാഗം കുബെർനെറ്റസിൽ എങ്ങനെ സംഭവിക്കുന്നു എന്നതിനെക്കുറിച്ചുള്ള എല്ലാ ചോദ്യങ്ങൾക്കും ഈ ചിത്രം ഉത്തരം നൽകുന്നു.

ഓട്ടോസ്കെയിലിംഗ്

K8s ക്ലസ്റ്റർ-ഓട്ടോസ്കെയിലർ

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

ഇത് കുബർനെറ്റസ് ക്ലസ്റ്ററിന്റെ ഓട്ടോസ്കെയിലിംഗ് ആണ്, ഇത് മികച്ച രീതിയിൽ പ്രവർത്തിക്കുന്നു (ഞങ്ങളുടെ അനുഭവത്തിൽ). എന്നിരുന്നാലും, മറ്റിടങ്ങളിലെന്നപോലെ, ഇവിടെയും ചില സൂക്ഷ്മതകളുണ്ട് ...

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

വിന്യാസം ഉള്ള 3 സെർവറുകളുടെ ഒരു ക്ലസ്റ്റർ പരിഗണിക്കുക. ഇതിന് 6 പോഡുകൾ ഉണ്ട്: ഇപ്പോൾ ഓരോ സെർവറിനും 2 ഉണ്ട്. ചില കാരണങ്ങളാൽ ഞങ്ങൾ സെർവറുകളിൽ ഒന്ന് ഓഫ് ചെയ്യാൻ ആഗ്രഹിച്ചു. ഇത് ചെയ്യുന്നതിന്, ഞങ്ങൾ കമാൻഡ് ഉപയോഗിക്കും kubectl drain, ഏത്:

• ഈ സെർവറിലേക്ക് പുതിയ പോഡുകൾ അയയ്ക്കുന്നത് നിരോധിക്കും;
• സെർവറിൽ നിലവിലുള്ള പോഡുകൾ ഇല്ലാതാക്കും.

പോഡുകളുടെ എണ്ണം (6) നിലനിർത്തുന്നതിന് കുബെർനെറ്റസ് ഉത്തരവാദിയായതിനാൽ, അത് ലളിതമായി പുനഃസൃഷ്ടിക്കും പുതിയ പോഡുകൾ ഹോസ്റ്റുചെയ്യുന്നതിന് ലഭ്യമല്ലെന്ന് ഇതിനകം അടയാളപ്പെടുത്തിയതിനാൽ അവ മറ്റ് നോഡുകളിൽ, പക്ഷേ പ്രവർത്തനരഹിതമാക്കിയ ഒന്നിൽ അല്ല. ഇത് കുബർനെറ്റസിന്റെ അടിസ്ഥാന മെക്കാനിക്കാണ്.

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

മോംഗോഡിബി കഴിയുമായിരുന്നു ഒരു കോറം ആവശ്യമുള്ളതിനാൽ മരിക്കുക: മൂന്ന് ഇൻസ്റ്റാളേഷനുകളുടെ ഒരു ക്ലസ്റ്ററിന്, കുറഞ്ഞത് രണ്ടെണ്ണമെങ്കിലും പ്രവർത്തിക്കണം. എന്നിരുന്നാലും, ഇത് സംഭവിക്കുന്നില്ല - നന്ദി PodDisruptionBudget. ഈ പരാമീറ്റർ ആവശ്യമായ ഏറ്റവും കുറഞ്ഞ വർക്കിംഗ് പോഡുകളുടെ എണ്ണം നിർണ്ണയിക്കുന്നു. MongoDB പോഡുകളിലൊന്ന് ഇപ്പോൾ പ്രവർത്തിക്കുന്നില്ല എന്നറിയുന്നതും, PodDisruptionBudget MongoDB-യ്‌ക്കായി സജ്ജീകരിച്ചിരിക്കുന്നതും കാണുന്നതും minAvailable: 2, ഒരു പോഡ് ഇല്ലാതാക്കാൻ Kubernetes നിങ്ങളെ അനുവദിക്കില്ല.

ചുവടെയുള്ള വരി: ക്ലസ്റ്റർ റിലീസ് ചെയ്യുമ്പോൾ പോഡുകളുടെ ചലനം (വാസ്തവത്തിൽ, പുനഃസൃഷ്ടി) ശരിയായി പ്രവർത്തിക്കുന്നതിന്, PodDisruptionBudget കോൺഫിഗർ ചെയ്യേണ്ടത് ആവശ്യമാണ്.

തിരശ്ചീന സ്കെയിലിംഗ്

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

ഇന്ന് കുബെർനെറ്റസിൽ ഇത് സ്വമേധയാ ചെയ്യേണ്ടതില്ല: അളന്ന ലോഡ് സൂചകങ്ങളുടെ മൂല്യങ്ങളെ ആശ്രയിച്ച് പോഡുകളുടെ എണ്ണത്തിൽ ഒരു യാന്ത്രിക വർദ്ധനവ് / കുറവ് ക്രമീകരിച്ചിരിക്കുന്നു.

ഇവിടെയുള്ള പ്രധാന ചോദ്യങ്ങൾ ഇവയാണ്: കൃത്യമായി എന്താണ് അളക്കേണ്ടത് и എങ്ങനെ വ്യാഖ്യാനിക്കാം ലഭിച്ച മൂല്യങ്ങൾ (പോഡുകളുടെ എണ്ണം മാറ്റുന്നതിൽ തീരുമാനമെടുക്കുന്നതിന്). നിങ്ങൾക്ക് ധാരാളം അളക്കാൻ കഴിയും:

സാങ്കേതികമായി ഇത് എങ്ങനെ ചെയ്യാം - അളവുകൾ ശേഖരിക്കുക മുതലായവ. - ഞാൻ റിപ്പോർട്ടിൽ വിശദമായി സംസാരിച്ചു നിരീക്ഷണവും കുബർനെറ്റസും. ഒപ്റ്റിമൽ പാരാമീറ്ററുകൾ തിരഞ്ഞെടുക്കുന്നതിനുള്ള പ്രധാന ഉപദേശം പരീക്ഷണം!

ഉണ്ട് രീതി ഉപയോഗിക്കുക (ഉപയോഗ സാച്ചുറേഷനും പിശകുകളും), ഇതിന്റെ അർത്ഥം ഇപ്രകാരമാണ്. ഏത് അടിസ്ഥാനത്തിലാണ് സ്കെയിൽ ചെയ്യുന്നത് അർത്ഥമാക്കുന്നത്, ഉദാഹരണത്തിന്, php-fpm? തൊഴിലാളികൾ ഒഴിഞ്ഞുപോകുന്നുവെന്ന വസ്തുതയുടെ അടിസ്ഥാനത്തിൽ, ഇത് ഉപയോഗം. തൊഴിലാളികൾ തീർന്ന് പുതിയ കണക്ഷനുകൾ സ്വീകരിക്കുന്നില്ലെങ്കിൽ, ഇത് ഇതിനകം തന്നെ സാച്ചുറേഷൻ. ഈ രണ്ട് പരാമീറ്ററുകളും അളക്കണം, മൂല്യങ്ങളെ ആശ്രയിച്ച്, സ്കെയിലിംഗ് നടത്തണം.

പകരം ഒരു നിഗമനത്തിൽ എന്ന

റിപ്പോർട്ടിന് ഒരു തുടർച്ചയുണ്ട്: ലംബമായ സ്കെയിലിംഗിനെ കുറിച്ചും ശരിയായ ഉറവിടങ്ങൾ എങ്ങനെ തിരഞ്ഞെടുക്കാം എന്നതിനെ കുറിച്ചും. ഭാവിയിലെ വീഡിയോകളിൽ ഞാൻ ഇതിനെക്കുറിച്ച് സംസാരിക്കും ഞങ്ങളുടെ YouTube - നിങ്ങൾ നഷ്‌ടപ്പെടാതിരിക്കാൻ സബ്‌സ്‌ക്രൈബ് ചെയ്യുക!

വീഡിയോകളും സ്ലൈഡുകളും

പ്രകടനത്തിൽ നിന്നുള്ള വീഡിയോ (44 മിനിറ്റ്):

റിപ്പോർട്ടിന്റെ അവതരണം:

പി.എസ്

ഞങ്ങളുടെ ബ്ലോഗിലെ കുബർനെറ്റസിനെക്കുറിച്ചുള്ള മറ്റ് റിപ്പോർട്ടുകൾ:

• «കുബർനെറ്റുകളെ വിപുലീകരിക്കുകയും പൂരകമാക്കുകയും ചെയ്യുന്നു» (ആന്ദ്രേ പോളോവോവ്; ഏപ്രിൽ 8, 2019 സെന്റ് ഹൈലോഡിൽ++);
• «ഡാറ്റാബേസുകളും കുബർനെറ്റുകളും» (Dmitry Stolyarov; നവംബർ 8, 2018 ഹൈലോഡ്++ ൽ);
• «നിരീക്ഷണവും കുബർനെറ്റസും» (Dmitry Stolyarov; മെയ് 28, 2018 RootConf-ൽ);
• «കുബർനെറ്റസ്, GitLab എന്നിവയ്‌ക്കൊപ്പമുള്ള CI/CD മികച്ച രീതികൾ» (Dmitry Stolyarov; നവംബർ 7, 2017 ഹൈലോഡ്++ ൽ);
• «ചെറിയ പ്രോജക്ടുകളിൽ കുബർനെറ്റുകളുമായുള്ള ഞങ്ങളുടെ അനുഭവം» (Dmitry Stolyarov; ജൂൺ 6, 2017 RootConf-ൽ).

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