കുബർനെറ്റസിൽ നിങ്ങളുടെ ആദ്യ ആപ്ലിക്കേഷൻ വിന്യസിക്കുമ്പോൾ അഞ്ച് തെറ്റുകൾ

ആരിസ്-ഡ്രീമറിന്റെ പരാജയം

ആപ്ലിക്കേഷൻ കുബെർനെറ്റസിലേക്ക് മൈഗ്രേറ്റ് ചെയ്താൽ മതിയെന്നും (ഹെൽം ഉപയോഗിച്ചോ അല്ലെങ്കിൽ മാനുവലായോ) അവർ സന്തുഷ്ടരായിരിക്കുമെന്നും പലരും വിശ്വസിക്കുന്നു. എന്നാൽ അത് അത്ര ലളിതമല്ല.

ടീം Mail.ru ക്ലൗഡ് സൊല്യൂഷനുകൾ DevOps എഞ്ചിനീയർ ജൂലിയൻ ഗിണ്ടിയുടെ ഒരു ലേഖനം പരിഭാഷപ്പെടുത്തി. മൈഗ്രേഷൻ പ്രക്രിയയിൽ തന്റെ കമ്പനി നേരിട്ട അപകടങ്ങൾ അദ്ദേഹം പങ്കുവെക്കുന്നു, അതുവഴി നിങ്ങൾ അതേ റാക്കിൽ കാലുകുത്തരുത്.

ഘട്ടം ഒന്ന്: പോഡ് അഭ്യർത്ഥനകളും പരിധികളും സജ്ജീകരിക്കുക

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

പോഡ് അഭ്യർത്ഥനകൾ - പോഡ് ഒപ്റ്റിമൽ ആയി സ്ഥാപിക്കാൻ ഷെഡ്യൂളർ ഉപയോഗിക്കുന്ന പ്രധാന മൂല്യമാണിത്.

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

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

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

പോഡ് പരിധികൾ - ഇത് പോഡിന്റെ വ്യക്തമായ പരിധിയാണ്. കണ്ടെയ്‌നറിന് ക്ലസ്റ്റർ അനുവദിക്കുന്ന പരമാവധി വിഭവങ്ങളെ ഇത് പ്രതിനിധീകരിക്കുന്നു.

വീണ്ടും, നിന്ന് ഔദ്യോഗിക ഡോക്യുമെന്റേഷൻ: ഒരു കണ്ടെയ്‌നറിന് 4 GiB മെമ്മറി പരിധി സജ്ജീകരിച്ചിട്ടുണ്ടെങ്കിൽ, kubelet (ഒപ്പം കണ്ടെയ്‌നർ റൺടൈമും) അത് നടപ്പിലാക്കും. നിർദ്ദിഷ്‌ട വിഭവ പരിധിയേക്കാൾ കൂടുതൽ ഉപയോഗിക്കാൻ കണ്ടെയ്‌നറിനെ റൺടൈം അനുവദിക്കുന്നില്ല. ഉദാഹരണത്തിന്, ഒരു കണ്ടെയ്‌നറിലെ ഒരു പ്രോസസ്സ് അനുവദനീയമായ മെമ്മറിയിൽ കൂടുതൽ ഉപയോഗിക്കാൻ ശ്രമിക്കുമ്പോൾ, സിസ്റ്റം കേർണൽ "ഓഫ് ഓഫ് മെമ്മറി" (OOM) പിശക് ഉപയോഗിച്ച് പ്രക്രിയ അവസാനിപ്പിക്കുന്നു.

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

സിസ്റ്റത്തിലെ മറ്റ് പ്രക്രിയകളിൽ ഇടപെടാതെ, ഒരു പ്രക്രിയയുടെ ജീവിതചക്രത്തിൽ ഒരു പോഡിന്റെ റിസോഴ്സ് ആവശ്യകതകൾ മാറണമെന്ന് ഞങ്ങൾ ആഗ്രഹിക്കുന്നു-അതാണ് പരിധികൾ നിശ്ചയിക്കുന്നതിന്റെ ലക്ഷ്യം.

നിർഭാഗ്യവശാൽ, എന്ത് മൂല്യങ്ങൾ സജ്ജീകരിക്കണമെന്ന് എനിക്ക് പ്രത്യേക നിർദ്ദേശങ്ങൾ നൽകാൻ കഴിയില്ല, പക്ഷേ ഞങ്ങൾ ഇനിപ്പറയുന്ന നിയമങ്ങൾ പാലിക്കുന്നു:

1. ഒരു ലോഡ് ടെസ്റ്റിംഗ് ടൂൾ ഉപയോഗിച്ച്, ഞങ്ങൾ ട്രാഫിക്കിന്റെ അടിസ്ഥാന തലം അനുകരിക്കുകയും പോഡ് റിസോഴ്സുകളുടെ ഉപയോഗം നിരീക്ഷിക്കുകയും ചെയ്യുന്നു (മെമ്മറിയും പ്രോസസറും).
2. ഞങ്ങൾ പോഡ് അഭ്യർത്ഥനകൾ ഏകപക്ഷീയമായി കുറഞ്ഞ മൂല്യത്തിലേക്ക് സജ്ജമാക്കി (അഭ്യർത്ഥനകളുടെ മൂല്യത്തിന്റെ ഏകദേശം 5 മടങ്ങ് റിസോഴ്‌സ് പരിധിയിൽ) നിരീക്ഷിക്കുക. അഭ്യർത്ഥനകൾ വളരെ കുറവായിരിക്കുമ്പോൾ, പ്രക്രിയ ആരംഭിക്കാൻ കഴിയില്ല, ഇത് പലപ്പോഴും നിഗൂഢമായ Go റൺടൈം പിശകുകൾക്ക് കാരണമാകുന്നു.

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

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

ഘട്ടം രണ്ട്: ലൈവ്‌നെസ്, റെഡിനസ് ടെസ്റ്റുകൾ സജ്ജീകരിക്കുക

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

സജീവത കണ്ടെയ്നർ പ്രവർത്തിക്കുന്നുണ്ടോ എന്ന് കാണിക്കുന്നു. ഇത് പരാജയപ്പെടുകയാണെങ്കിൽ, കുബെലെറ്റ് കണ്ടെയ്നറിനെ കൊല്ലുകയും അതിനായി ഒരു പുനരാരംഭിക്കൽ നയം പ്രവർത്തനക്ഷമമാക്കുകയും ചെയ്യും. കണ്ടെയ്‌നറിൽ ലൈവ്‌നെസ് പ്രോബ് സജ്ജീകരിച്ചിട്ടില്ലെങ്കിൽ, സ്ഥിരസ്ഥിതി വിജയമായിരിക്കും - ഇതാണ് അതിൽ പറയുന്നത് കുബെർനെറ്റസ് ഡോക്യുമെന്റേഷൻ.

ലൈവ്‌നെസ് പ്രോബുകൾ വിലകുറഞ്ഞതായിരിക്കണം, അതിനർത്ഥം അവ ധാരാളം വിഭവങ്ങൾ ഉപയോഗിക്കരുതെന്നാണ്, കാരണം അവ പതിവായി പ്രവർത്തിക്കുകയും ആപ്ലിക്കേഷൻ പ്രവർത്തിക്കുന്നുവെന്ന് കുബർനെറ്റുകളെ അറിയിക്കുകയും വേണം.

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

ഞങ്ങളുടെ കമ്പനിയിൽ, ഡാറ്റ (ഉദാഹരണത്തിന്, ഒരു റിമോട്ട് ഡാറ്റാബേസിൽ നിന്നോ കാഷെയിൽ നിന്നോ) പൂർണ്ണമായി ആക്‌സസ് ചെയ്യാനാകുന്നില്ലെങ്കിൽപ്പോലും, ലൈവ്‌നെസ് ടെസ്റ്റുകൾ ആപ്ലിക്കേഷന്റെ പ്രധാന ഘടകങ്ങൾ പരിശോധിക്കുന്നു.

200-ന്റെ പ്രതികരണ കോഡ് നൽകുന്ന ഒരു "ആരോഗ്യം" എൻഡ്‌പോയിന്റ് ഉപയോഗിച്ച് ഞങ്ങൾ ആപ്പുകൾ കോൺഫിഗർ ചെയ്‌തു. ഇത് പ്രോസസ്സ് പ്രവർത്തിക്കുന്നുവെന്നും അഭ്യർത്ഥനകൾ പ്രോസസ്സ് ചെയ്യാൻ പ്രാപ്‌തമാണെന്നും (എന്നാൽ ഇതുവരെ ട്രാഫിക്കില്ല) എന്നതിന്റെ സൂചനയാണിത്.

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

അഭ്യർത്ഥനകൾ സ്വീകരിക്കാൻ ആപ്ലിക്കേഷൻ തയ്യാറാണെന്ന് സൂചിപ്പിക്കുന്ന രീതിയിൽ ബാക്കെൻഡിലേക്ക് അയയ്‌ക്കേണ്ടതിനാൽ റെഡിനെസ് പ്രോബുകൾ കൂടുതൽ ഉറവിടങ്ങൾ ഉപയോഗിക്കുന്നു.

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

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

SELECT small_item FROM table LIMIT 1

Kubernetes-ൽ ഈ രണ്ട് മൂല്യങ്ങളും എങ്ങനെ ക്രമീകരിക്കാം എന്നതിന്റെ ഒരു ഉദാഹരണം ഇതാ:

livenessProbe: 
 httpGet:   
   path: /api/liveness    
   port: http 
readinessProbe:  
 httpGet:    
   path: /api/readiness    
   port: http  periodSeconds: 2

നിങ്ങൾക്ക് ചില അധിക കോൺഫിഗറേഷൻ ഓപ്ഷനുകൾ ചേർക്കാൻ കഴിയും:

• initialDelaySeconds - കണ്ടെയ്‌നറിന്റെ വിക്ഷേപണത്തിനും സാമ്പിളുകളുടെ ആരംഭത്തിനും ഇടയിൽ എത്ര സെക്കൻഡ് കടന്നുപോകും.
• periodSeconds - സാമ്പിൾ റണ്ണുകൾക്കിടയിലുള്ള കാത്തിരിപ്പ് ഇടവേള.
• timeoutSeconds - യൂണിറ്റ് അടിയന്തിരമായി കണക്കാക്കുന്ന സെക്കൻഡുകളുടെ എണ്ണം. പതിവ് സമയപരിധി.
• failureThreshold - ഒരു റീസ്റ്റാർട്ട് സിഗ്നൽ പോഡിലേക്ക് അയയ്ക്കുന്നതിന് മുമ്പുള്ള ടെസ്റ്റ് പരാജയങ്ങളുടെ എണ്ണം.
• successThreshold - പോഡ് തയ്യാറായ അവസ്ഥയിലേക്ക് പോകുന്നതിന് മുമ്പുള്ള വിജയകരമായ പ്രോബുകളുടെ എണ്ണം (ഒരു പരാജയത്തിന് ശേഷം, പോഡ് ആരംഭിക്കുമ്പോഴോ വീണ്ടെടുക്കുമ്പോഴോ).

ഘട്ടം മൂന്ന്: പോഡിനായി ഡിഫോൾട്ട് നെറ്റ്‌വർക്ക് നയങ്ങൾ സജ്ജീകരിക്കുക

കുബർനെറ്റസിന് ഒരു "ഫ്ലാറ്റ്" നെറ്റ്‌വർക്ക് ടോപ്പോഗ്രാഫി ഉണ്ട്; സ്ഥിരസ്ഥിതിയായി, എല്ലാ പോഡുകളും പരസ്പരം നേരിട്ട് ആശയവിനിമയം നടത്തുന്നു. ചില സന്ദർഭങ്ങളിൽ ഇത് അഭികാമ്യമല്ല.

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

ഉദാഹരണത്തിന്, ഒരു നിർദ്ദിഷ്‌ട നെയിംസ്‌പെയ്‌സിനായി എല്ലാ ഇൻകമിംഗ് ട്രാഫിക്കും നിഷേധിക്കുന്ന ഒരു ലളിതമായ നയം ചുവടെയുണ്ട്:

---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:  
 name: default-deny-ingress
spec:  
 podSelector: {}  
 policyTypes:  
   - Ingress

ഈ കോൺഫിഗറേഷന്റെ ദൃശ്യവൽക്കരണം:

(https://miro.medium.com/max/875/1*-eiVw43azgzYzyN1th7cZg.gif)
കൂടുതൽ വിശദാംശങ്ങൾ ഇവിടെ.

ഘട്ടം നാല്: ഹുക്കുകളും init കണ്ടെയ്‌നറുകളും ഉപയോഗിച്ച് ഇഷ്ടാനുസൃത പെരുമാറ്റം

ഞങ്ങളുടെ പ്രധാന ലക്ഷ്യങ്ങളിലൊന്ന്, ഡവലപ്പർമാർക്ക് പ്രവർത്തനരഹിതമായ സമയമില്ലാതെ കുബർനെറ്റസിന് വിന്യാസം നൽകുക എന്നതായിരുന്നു. ഇത് ബുദ്ധിമുട്ടാണ്, കാരണം ആപ്ലിക്കേഷനുകൾ ഷട്ട്ഡൗൺ ചെയ്യുന്നതിനും അവ ഉപയോഗിച്ച വിഭവങ്ങൾ സ്വതന്ത്രമാക്കുന്നതിനും നിരവധി ഓപ്ഷനുകൾ ഉണ്ട്.

പ്രത്യേക ബുദ്ധിമുട്ടുകൾ ഉയർന്നു നിക്കിക്സ്. ഈ പോഡുകൾ തുടർച്ചയായി വിന്യസിച്ചപ്പോൾ, വിജയകരമായി പൂർത്തിയാക്കുന്നതിന് മുമ്പ് സജീവമായ കണക്ഷനുകൾ ഉപേക്ഷിച്ചതായി ഞങ്ങൾ ശ്രദ്ധിച്ചു.

ഓൺലൈനിൽ വിപുലമായ ഗവേഷണത്തിന് ശേഷം, പോഡ് അവസാനിപ്പിക്കുന്നതിന് മുമ്പ് Nginx കണക്ഷനുകൾ സ്വയം തീർന്നുപോകുന്നതുവരെ കുബെർനെറ്റസ് കാത്തിരിക്കുന്നില്ല. ഒരു പ്രീ-സ്റ്റോപ്പ് ഹുക്ക് ഉപയോഗിച്ച്, ഞങ്ങൾ ഇനിപ്പറയുന്ന പ്രവർത്തനം നടപ്പിലാക്കുകയും പ്രവർത്തനരഹിതമായ സമയം പൂർണ്ണമായും ഒഴിവാക്കുകയും ചെയ്തു:

lifecycle: 
 preStop:
   exec:
     command: ["/usr/local/bin/nginx-killer.sh"]

പക്ഷേ nginx-killer.sh:

#!/bin/bash
sleep 3
PID=$(cat /run/nginx.pid)
nginx -s quit
while [ -d /proc/$PID ]; do
   echo "Waiting while shutting down nginx..."
   sleep 10
done

നിർദ്ദിഷ്‌ട ആപ്ലിക്കേഷനുകളുടെ ആരംഭം കൈകാര്യം ചെയ്യാൻ init കണ്ടെയ്‌നറുകളുടെ ഉപയോഗമാണ് വളരെ ഉപയോഗപ്രദമായ മറ്റൊരു മാതൃക. ആപ്ലിക്കേഷൻ ആരംഭിക്കുന്നതിന് മുമ്പ് റൺ ചെയ്യേണ്ട റിസോഴ്സ്-ഇന്റൻസീവ് ഡാറ്റാബേസ് മൈഗ്രേഷൻ പ്രക്രിയ നിങ്ങൾക്കുണ്ടെങ്കിൽ ഇത് പ്രത്യേകിച്ചും ഉപയോഗപ്രദമാണ്. പ്രധാന ആപ്ലിക്കേഷനായി അത്തരമൊരു പരിധി സജ്ജീകരിക്കാതെ തന്നെ നിങ്ങൾക്ക് ഈ പ്രക്രിയയ്ക്കായി ഉയർന്ന ഉറവിട പരിധി വ്യക്തമാക്കാനും കഴിയും.

പ്രധാന മൊഡ്യൂളിലേക്ക് ആ ക്രെഡൻഷ്യലുകൾ നൽകുന്ന ഒരു init കണ്ടെയ്‌നറിൽ രഹസ്യങ്ങൾ ആക്‌സസ് ചെയ്യുക എന്നതാണ് മറ്റൊരു പൊതു സ്കീം, ഇത് പ്രധാന ആപ്ലിക്കേഷൻ മൊഡ്യൂളിൽ നിന്നുള്ള രഹസ്യങ്ങളിലേക്കുള്ള അനധികൃത ആക്‌സസ് തടയുന്നു.

പതിവുപോലെ, ഡോക്യുമെന്റേഷനിൽ നിന്ന് ഉദ്ധരിക്കുക: Init കണ്ടെയ്‌നറുകൾ സുരക്ഷിതമായി ഇഷ്‌ടാനുസൃത കോഡോ യൂട്ടിലിറ്റികളോ പ്രവർത്തിപ്പിക്കുന്നു, അത് ആപ്ലിക്കേഷൻ കണ്ടെയ്‌നർ ചിത്രത്തിന്റെ സുരക്ഷ കുറയ്ക്കും. അനാവശ്യ ടൂളുകൾ വെവ്വേറെ സൂക്ഷിക്കുന്നതിലൂടെ, നിങ്ങൾ ആപ്ലിക്കേഷൻ കണ്ടെയ്നർ ഇമേജിന്റെ ആക്രമണ ഉപരിതലം പരിമിതപ്പെടുത്തുന്നു.

ഘട്ടം അഞ്ച്: കേർണൽ കോൺഫിഗർ ചെയ്യുന്നു

അവസാനമായി, കൂടുതൽ വിപുലമായ സാങ്കേതികതയെക്കുറിച്ച് സംസാരിക്കാം.

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

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

initContainers:
  - name: sysctl
     image: alpine:3.10
     securityContext:
         privileged: true
      command: ['sh', '-c', "sysctl -w net.core.somaxconn=32768"]

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

ഉപസംഹാരമായി

കുബെർനെറ്റസ് ഒരു റെഡിമെയ്ഡ് സൊല്യൂഷൻ പോലെ തോന്നുമെങ്കിലും, നിങ്ങളുടെ ആപ്ലിക്കേഷനുകൾ സുഗമമായി പ്രവർത്തിക്കാൻ നിങ്ങൾ എടുക്കേണ്ട ചില പ്രധാന ഘട്ടങ്ങളുണ്ട്.

നിങ്ങളുടെ കുബർനെറ്റസ് മൈഗ്രേഷനിലുടനീളം, "ലോഡ് ടെസ്റ്റിംഗ് സൈക്കിൾ" പിന്തുടരേണ്ടത് പ്രധാനമാണ്: ആപ്ലിക്കേഷൻ ലോഞ്ച് ചെയ്യുക, ലോഡ് ടെസ്റ്റ് ചെയ്യുക, മെട്രിക്‌സും സ്കെയിലിംഗ് സ്വഭാവവും നിരീക്ഷിക്കുക, ആ ഡാറ്റയെ അടിസ്ഥാനമാക്കി കോൺഫിഗറേഷൻ ക്രമീകരിക്കുക, തുടർന്ന് സൈക്കിൾ വീണ്ടും ആവർത്തിക്കുക.

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

എപ്പോഴും ഈ ചോദ്യങ്ങൾ സ്വയം ചോദിക്കുക:

1. ആപ്ലിക്കേഷനുകൾ എത്ര ഉറവിടങ്ങൾ ഉപയോഗിക്കുന്നു, ഈ വോളിയം എങ്ങനെ മാറും?
2. യഥാർത്ഥ സ്കെയിലിംഗ് ആവശ്യകതകൾ എന്തൊക്കെയാണ്? ആപ്പ് ശരാശരി എത്ര ട്രാഫിക് കൈകാര്യം ചെയ്യും? പീക്ക് ട്രാഫിക്കിന്റെ കാര്യമോ?
3. എത്ര തവണ സേവനം തിരശ്ചീനമായി സ്കെയിൽ ചെയ്യേണ്ടതുണ്ട്? ട്രാഫിക് സ്വീകരിക്കാൻ എത്ര വേഗത്തിൽ പുതിയ പോഡുകൾ ഓൺലൈനിൽ കൊണ്ടുവരണം?
4. പോഡ്‌സ് എത്ര കൃത്യമായി ഷട്ട് ഡൗൺ ചെയ്യും? ഇത് ഒട്ടും ആവശ്യമാണോ? പ്രവർത്തനരഹിതമാക്കാതെ വിന്യാസം സാധ്യമാണോ?
5. നിങ്ങൾക്ക് എങ്ങനെ സുരക്ഷാ അപകടസാധ്യതകൾ കുറയ്ക്കാനും ഏതെങ്കിലും വിട്ടുവീഴ്ച ചെയ്ത പോഡുകളിൽ നിന്നുള്ള കേടുപാടുകൾ പരിമിതപ്പെടുത്താനും കഴിയും? ഏതെങ്കിലും സേവനങ്ങൾക്ക് അവയ്ക്ക് ആവശ്യമില്ലാത്ത അനുമതികളോ ആക്‌സസുകളോ ഉണ്ടോ?

ഒരു ക്ലസ്റ്ററിൽ ആയിരക്കണക്കിന് സേവനങ്ങൾ വിന്യസിക്കുന്നതിനുള്ള മികച്ച സമ്പ്രദായങ്ങൾ പ്രയോജനപ്പെടുത്താൻ നിങ്ങളെ അനുവദിക്കുന്ന അവിശ്വസനീയമായ ഒരു പ്ലാറ്റ്ഫോം Kubernetes നൽകുന്നു. എന്നിരുന്നാലും, ഓരോ ആപ്ലിക്കേഷനും വ്യത്യസ്തമാണ്. ചില സമയങ്ങളിൽ നടപ്പിലാക്കുന്നതിന് കുറച്ചുകൂടി അധ്വാനം ആവശ്യമാണ്.

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

മറ്റെന്താണ് വായിക്കേണ്ടത്:

1. ഉൽപ്പാദന പരിതസ്ഥിതിയിൽ കണ്ടെയ്‌നറുകളും കുബർനെറ്റുകളും പ്രവർത്തിപ്പിക്കുന്നതിനുള്ള മികച്ച രീതികളും മികച്ച രീതികളും.
2. 90+ കുബർനെറ്റുകൾക്കുള്ള ഉപയോഗപ്രദമായ ഉപകരണങ്ങൾ: വിന്യാസം, മാനേജ്മെന്റ്, നിരീക്ഷണം, സുരക്ഷ എന്നിവയും അതിലേറെയും.
3. ടെലിഗ്രാമിലെ ഞങ്ങളുടെ ചാനൽ കുബെർനെറ്റസിന് ചുറ്റും.

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