കുബർനെറ്റസിൽ ഒരു ആപ്ലിക്കേഷൻ വികസിപ്പിക്കുന്നതിനുള്ള ആവശ്യകതകൾ

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

ഈ പ്രഭാഷണം "കുബർനെറ്റസിലെ സ്ലർം നൈറ്റ് സ്കൂൾ" ഈവനിംഗ് സ്കൂളിന്റെ തുറന്ന സൈദ്ധാന്തിക പ്രഭാഷണങ്ങൾ നിങ്ങൾക്ക് കാണാൻ കഴിയും Youtube-ൽ, ഒരു പ്ലേലിസ്റ്റിലേക്ക് ഗ്രൂപ്പുചെയ്‌തു. വീഡിയോയെക്കാൾ വാചകം ഇഷ്ടപ്പെടുന്നവർക്കായി, ഞങ്ങൾ ഈ ലേഖനം തയ്യാറാക്കിയിട്ടുണ്ട്.

എന്റെ പേര് പവൽ സെലിവാനോവ്, നിലവിൽ ഞാൻ Mail.ru ക്ലൗഡ് സൊല്യൂഷനിലെ മുൻനിര DevOps എഞ്ചിനീയറാണ്, ഞങ്ങൾ മേഘങ്ങൾ നിർമ്മിക്കുന്നു, ഞങ്ങൾ മാനേജുമെന്റ് kubernetes ഉണ്ടാക്കുന്നു തുടങ്ങിയവ. എന്റെ ടാസ്ക്കുകളിൽ ഇപ്പോൾ വികസനത്തിനുള്ള സഹായം, ഈ മേഘങ്ങൾ റോൾ ഔട്ട് ചെയ്യുക, ഞങ്ങൾ എഴുതുന്ന ആപ്ലിക്കേഷനുകൾ പുറത്തിറക്കുക, ഞങ്ങളുടെ ഉപയോക്താക്കൾക്കായി ഞങ്ങൾ നൽകുന്ന ടൂളുകൾ നേരിട്ട് വികസിപ്പിക്കൽ എന്നിവ ഉൾപ്പെടുന്നു.

ഞാൻ DevOps ചെയ്യുന്നു, കഴിഞ്ഞ, മിക്കവാറും, മൂന്ന് വർഷമായി ഞാൻ കരുതുന്നു. പക്ഷേ, തത്വത്തിൽ, ഏകദേശം അഞ്ച് വർഷമായി DevOps ചെയ്യുന്നത് ഞാൻ ചെയ്യുന്നു. അതിനുമുമ്പ്, ഞാൻ കൂടുതലും അഡ്മിൻ കാര്യങ്ങളിൽ ഏർപ്പെട്ടിരുന്നു. ഞാൻ വളരെക്കാലം മുമ്പ് കുബെർനെറ്റിനൊപ്പം പ്രവർത്തിക്കാൻ തുടങ്ങി - ഞാൻ അതിൽ പ്രവർത്തിക്കാൻ തുടങ്ങിയിട്ട് ഏകദേശം നാല് വർഷം കഴിഞ്ഞിട്ടുണ്ടാകും.

പൊതുവേ, ഞാൻ കുബെർനെറ്റസ് പതിപ്പ് 1.3 ആയിരുന്നപ്പോൾ ആരംഭിച്ചു, ഒരുപക്ഷേ, ഒരുപക്ഷേ 1.2 - അത് ശൈശവാവസ്ഥയിൽ ആയിരിക്കുമ്പോൾ. ഇപ്പോൾ അത് ശൈശവാവസ്ഥയിലല്ല - കുബർനെറ്റസ് ചെയ്യാൻ ആഗ്രഹിക്കുന്ന എഞ്ചിനീയർമാർക്ക് വിപണിയിൽ വലിയ ഡിമാൻഡുണ്ടെന്ന് വ്യക്തമാണ്. മാത്രമല്ല കമ്പനികൾക്ക് ഇത്തരക്കാർക്ക് ആവശ്യക്കാർ ഏറെയാണ്. അതിനാൽ, വാസ്തവത്തിൽ, ഈ പ്രഭാഷണം പ്രത്യക്ഷപ്പെട്ടു.

ഞാൻ സംസാരിക്കുന്ന പദ്ധതിയെക്കുറിച്ച് നമ്മൾ സംസാരിക്കുകയാണെങ്കിൽ, അത് ഇതുപോലെ കാണപ്പെടുന്നു, ബ്രാക്കറ്റിൽ ഇത് എഴുതിയിരിക്കുന്നു (TL; DR) - “വളരെ നീളം; വായിക്കരുത്". ഇന്നത്തെ എന്റെ അവതരണം അനന്തമായ ലിസ്റ്റുകൾ ഉൾക്കൊള്ളുന്നതാണ്.

വാസ്തവത്തിൽ, അത്തരം അവതരണങ്ങൾ നിർമ്മിക്കുമ്പോൾ ഞാൻ തന്നെ ഇഷ്ടപ്പെടുന്നില്ല, എന്നാൽ ഇത് അത്തരമൊരു വിഷയമാണ്, ഞാൻ ഈ അവതരണം തയ്യാറാക്കുമ്പോൾ, ഈ വിവരങ്ങൾ എങ്ങനെ വ്യത്യസ്തമായി ഓർഗനൈസുചെയ്യാമെന്ന് ഞാൻ ശരിക്കും കണ്ടെത്തിയില്ല.

കാരണം, മൊത്തത്തിൽ, ഈ വിവരങ്ങൾ “ctrl+c, ctrl+v” ആണ്, മറ്റ് കാര്യങ്ങൾക്കൊപ്പം, DevOps വിഭാഗത്തിലെ ഞങ്ങളുടെ വിക്കിയിൽ നിന്നുള്ളതാണ്, ഡെവലപ്പർമാർക്കായി ഞങ്ങൾ എഴുതിയ ആവശ്യകതകൾ: “കൂട്ടുകാരേ, ഞങ്ങൾ നിങ്ങളുടെ ആപ്ലിക്കേഷൻ ലോഞ്ച് ചെയ്യാൻ കുബർനെറ്റസ്, ഇത് ഇതുപോലെ ആയിരിക്കണം.

അതുകൊണ്ടാണ് അവതരണം ഒരു വലിയ പട്ടികയായി മാറിയത്. ക്ഷമിക്കണം. പറ്റുമെങ്കിൽ ബോറടിക്കാതിരിക്കാൻ പരമാവധി പറയാൻ ശ്രമിക്കും.

നമ്മൾ ഇപ്പോൾ എന്താണ് കാണാൻ പോകുന്നത്:

• ഇവയാണ്, ഒന്നാമതായി, ലോഗുകൾ (അപ്ലിക്കേഷൻ ലോഗുകൾ?), കുബർനെറ്റസിൽ അവയുമായി എന്തുചെയ്യണം, അവയുമായി എന്തുചെയ്യണം, അവ എന്തായിരിക്കണം;
• Kubernetes-ലെ കോൺഫിഗറേഷനുകളുമായി എന്തുചെയ്യണം, Kubernetes-നായി ഒരു ആപ്ലിക്കേഷൻ കോൺഫിഗർ ചെയ്യുന്നതിനുള്ള ഏറ്റവും മികച്ചതും മോശവുമായ വഴികൾ എന്തൊക്കെയാണ്;
• പ്രവേശനക്ഷമത പരിശോധനകൾ പൊതുവായി എന്താണെന്നും അവ എങ്ങനെയായിരിക്കണം എന്നതിനെക്കുറിച്ചും നമുക്ക് സംസാരിക്കാം;
• ഗംഭീരമായ ഷട്ട്ഡൗൺ എന്താണെന്ന് നമുക്ക് സംസാരിക്കാം;
• നമുക്ക് വീണ്ടും വിഭവങ്ങളെ കുറിച്ച് സംസാരിക്കാം;
• ഡാറ്റ സംഭരണം എന്ന വിഷയത്തിൽ ഒരിക്കൽ കൂടി സ്പർശിക്കാം;
• ഈ നിഗൂഢമായ ക്ലൗഡ്-നേറ്റീവ് ആപ്ലിക്കേഷൻ എന്താണെന്ന് അവസാനം ഞാൻ നിങ്ങളോട് പറയും. Cloudnativeness, ഈ പദത്തിന്റെ വിശേഷണമായി.

രേഖകൾ

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

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

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

നമ്മൾ Kubernetes നെക്കുറിച്ച് സംസാരിക്കുകയാണെങ്കിൽ, ഒരു ഡോക്കർ കണ്ടെയ്‌നറിൽ നിന്ന് എവിടെയെങ്കിലും ലോഗുകൾ എഴുതാനുള്ള ശരിയായ സ്ഥലം അവ ആപ്ലിക്കേഷനിൽ നിന്ന് Stdout/Stderr എന്ന് വിളിക്കപ്പെടുന്നവയിലേക്ക് എഴുതുക എന്നതാണ്, അതായത്, ഓപ്പറേറ്റിംഗ് സിസ്റ്റത്തിന്റെ സ്റ്റാൻഡേർഡ് ഔട്ട്‌പുട്ട് സ്ട്രീമുകൾ, സാധാരണ പിശക് ഔട്ട്പുട്ട്. ഡോക്കറിലും പ്രത്യേകിച്ചും കുബർനെറ്റിസിലും ലോഗുകൾ തത്ത്വത്തിൽ സ്ഥാപിക്കുന്നതിനുള്ള ഏറ്റവും ശരിയായതും ലളിതവും യുക്തിസഹവുമായ മാർഗമാണിത്. കാരണം നിങ്ങളുടെ ആപ്ലിക്കേഷൻ Stdout/Stderr-ലേക്ക് ലോഗുകൾ എഴുതുകയാണെങ്കിൽ, ഈ ലോഗുകൾ എന്തുചെയ്യണമെന്ന് തീരുമാനിക്കേണ്ടത് ഡോക്കറും കുബർനെറ്റസ് ആഡ്-ഓണും ആണ്. ഡോക്കർ ഡിഫോൾട്ടായി അതിന്റെ പ്രത്യേക ഫയലുകൾ JSON ഫോർമാറ്റിൽ നിർമ്മിക്കും.

ഇവിടെ ചോദ്യം ഉയർന്നുവരുന്നു, ഈ ലോഗുകൾ ഉപയോഗിച്ച് നിങ്ങൾ അടുത്തതായി എന്തുചെയ്യും? ഏറ്റവും എളുപ്പമുള്ള മാർഗം വ്യക്തമാണ്, ഞങ്ങൾക്ക് ചെയ്യാനുള്ള കഴിവുണ്ട് kubectl logs ഈ "പോഡുകളുടെ" ഈ ലോഗുകൾ നോക്കുക. പക്ഷേ, ഒരുപക്ഷേ, ഇത് വളരെ നല്ല ഓപ്ഷനല്ല - ലോഗുകൾ ഉപയോഗിച്ച് മറ്റെന്തെങ്കിലും ചെയ്യേണ്ടതുണ്ട്.

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

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

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

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

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

അടുത്ത പോയിന്റ്, ഇവിടെ ഞാൻ ഇതിനെക്കുറിച്ച് വീണ്ടും സംസാരിക്കാൻ ആഗ്രഹിക്കുന്നു - ഞങ്ങൾ ലോഗുകളുടെ വിഷയത്തിൽ സ്പർശിക്കുന്നതിനാൽ, അവയുമായി പ്രവർത്തിക്കുന്നത് സൗകര്യപ്രദമാക്കുന്നതിന് ലോഗുകൾ എങ്ങനെ കാണപ്പെടണം എന്നതിനെക്കുറിച്ച് സംസാരിക്കുന്നത് നന്നായിരിക്കും. ഞാൻ പറഞ്ഞതുപോലെ, വിഷയം കുബർനെറ്റുമായി നേരിട്ട് ബന്ധപ്പെട്ടതല്ല, പക്ഷേ ഇത് DevOps എന്ന വിഷയവുമായി വളരെ നന്നായി ബന്ധപ്പെട്ടിരിക്കുന്നു. ഈ രണ്ട് വ്യത്യസ്ത വകുപ്പുകൾ തമ്മിലുള്ള വികസന സംസ്കാരവും സൗഹൃദവും എന്ന വിഷയത്തിൽ - ദേവ്, ഓപ്‌സ്, അങ്ങനെ എല്ലാവർക്കും സൗകര്യപ്രദമാണ്.

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

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

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

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

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

കോൺഫിഗറേഷൻ

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

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

ഈ കാര്യം - ഞങ്ങൾ ഇത് മുമ്പ് ഉപയോഗിച്ചു, കണ്ടെയ്‌നറുകളുടെ വരവോടെ ഇത് പ്രത്യേകിച്ചും ജനപ്രിയമായി - ഇതിനെ ENV (പരിസ്ഥിതി) വേരിയബിളുകൾ എന്ന് വിളിക്കുന്നു, അതായത്, നിങ്ങളുടെ ഓപ്പറേറ്റിംഗ് സിസ്റ്റത്തിലുള്ള പരിസ്ഥിതി വേരിയബിളുകൾ. നിങ്ങളുടെ ആപ്ലിക്കേഷൻ കോൺഫിഗർ ചെയ്യുന്നതിനുള്ള ഏറ്റവും അനുയോജ്യമായ മാർഗ്ഗമാണിത്, കാരണം നിങ്ങൾക്ക് JAVA, Python, Go, Perl, God forbid എന്നിവയിൽ ആപ്ലിക്കേഷനുകൾ ഉണ്ടെങ്കിൽ അവയ്‌ക്കെല്ലാം ഡാറ്റാബേസ് ഹോസ്റ്റ്, ഡാറ്റാബേസ് ഉപയോക്താവ്, ഡാറ്റാബേസ് പാസ്‌വേഡ് വേരിയബിളുകൾ എന്നിവ വായിക്കാൻ കഴിയും, അത് അനുയോജ്യമാണ്. നിങ്ങൾക്ക് നാല് വ്യത്യസ്ത ഭാഷകളിലുള്ള ആപ്ലിക്കേഷനുകൾ ഡാറ്റാബേസ് പ്ലാനിൽ അതേ രീതിയിൽ ക്രമീകരിച്ചിട്ടുണ്ട്. കൂടുതൽ വ്യത്യസ്ത കോൺഫിഗറുകളൊന്നുമില്ല.

ENV വേരിയബിളുകൾ ഉപയോഗിച്ച് എല്ലാം ക്രമീകരിക്കാൻ കഴിയും. ഞങ്ങൾ കുബെർനെറ്റസിനെ കുറിച്ച് പറയുമ്പോൾ, വിന്യാസത്തിനുള്ളിൽ തന്നെ ENV വേരിയബിളുകൾ പ്രഖ്യാപിക്കാൻ ഒരു മികച്ച മാർഗമുണ്ട്. അതനുസരിച്ച്, ഞങ്ങൾ രഹസ്യ ഡാറ്റയെക്കുറിച്ചാണ് സംസാരിക്കുന്നതെങ്കിൽ, ഞങ്ങൾക്ക് ഉടൻ തന്നെ ENV വേരിയബിളുകളിൽ നിന്നുള്ള രഹസ്യ ഡാറ്റ (ഡാറ്റാബേസുകളിലേക്കുള്ള പാസ്‌വേഡുകൾ മുതലായവ) ഒരു രഹസ്യത്തിലേക്ക് തള്ളാനും ഒരു രഹസ്യ ക്ലസ്റ്റർ സൃഷ്ടിക്കാനും ഞങ്ങൾ നേരിട്ട് പ്രഖ്യാപിക്കുന്നില്ലെന്ന് വിന്യാസത്തിലെ ENV വിവരണത്തിൽ സൂചിപ്പിക്കാനും കഴിയും. ഈ വേരിയബിളിന്റെ മൂല്യവും ഈ ഡാറ്റാബേസ് പാസ്‌വേഡ് വേരിയബിളിന്റെ മൂല്യവും രഹസ്യത്തിൽ നിന്ന് വായിക്കും. ഇതാണ് സ്റ്റാൻഡേർഡ് കുബർനെറ്റസ് പെരുമാറ്റം. നിങ്ങളുടെ ആപ്ലിക്കേഷനുകൾ കോൺഫിഗർ ചെയ്യുന്നതിനുള്ള ഏറ്റവും അനുയോജ്യമായ ഓപ്ഷനാണിത്. കോഡ് തലത്തിൽ, ഇത് വീണ്ടും ഡെവലപ്പർമാർക്ക് ബാധകമാണ്. നിങ്ങൾ DevOps ആണെങ്കിൽ, നിങ്ങൾക്ക് ഇങ്ങനെ ചോദിക്കാം: “സുഹൃത്തുക്കളേ, പരിസ്ഥിതി വേരിയബിളുകൾ വായിക്കാൻ നിങ്ങളുടെ ആപ്ലിക്കേഷനെ പഠിപ്പിക്കൂ. ഞങ്ങൾ എല്ലാവരും സന്തുഷ്ടരായിരിക്കും. ”

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

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

കോൺഫിഗറേഷനുകൾ നിങ്ങൾ വിചാരിക്കുന്നതല്ല എന്നതാണ് ഒരേയൊരു ചോദ്യം. Config.pi എന്നത് ഉപയോഗിക്കാൻ സൗകര്യപ്രദമായ ഒരു കോൺഫിഗറല്ല. അല്ലെങ്കിൽ നിങ്ങളുടെ സ്വന്തം ഫോർമാറ്റിലുള്ള ചില കോൺഫിഗറേഷനുകൾ, പകരം സമ്മാനിച്ചവ - ഇതും ഞാൻ ഉദ്ദേശിച്ച കോൺഫിഗറല്ല.

ഞാൻ സംസാരിക്കുന്നത് സ്വീകാര്യമായ ഫോർമാറ്റിലുള്ള കോൺഫിഗറേഷനെക്കുറിച്ചാണ്, അതായത്, ഏറ്റവും ജനപ്രിയമായ മാനദണ്ഡം .yaml സ്റ്റാൻഡേർഡ് ആണ്. ഇത് എങ്ങനെ വായിക്കണമെന്ന് വ്യക്തമാണ്, ഇത് മനുഷ്യർക്ക് വായിക്കാൻ കഴിയുന്നതാണ്, ആപ്ലിക്കേഷനിൽ നിന്ന് എങ്ങനെ വായിക്കണമെന്ന് വ്യക്തമാണ്.

അതനുസരിച്ച്, YAML-ന് പുറമേ, നിങ്ങൾക്ക് JSON ഉപയോഗിക്കാനും കഴിയും, അവിടെ നിന്ന് ആപ്ലിക്കേഷൻ കോൺഫിഗറേഷൻ വായിക്കുന്ന കാര്യത്തിൽ YAML പോലെ തന്നെ പാഴ്‌സിംഗ് സൗകര്യപ്രദമാണ്. ആളുകൾക്ക് വായിക്കാൻ ഇത് കൂടുതൽ അസൗകര്യമാണ്. നിങ്ങൾക്ക് ഫോർമാറ്റ് പരീക്ഷിക്കാം. മാനുഷിക വീക്ഷണകോണിൽ നിന്ന് ഇത് വായിക്കുന്നത് വളരെ സൗകര്യപ്രദമാണ്, എന്നാൽ ഇത് സ്വയമേവ പ്രോസസ്സ് ചെയ്യുന്നത് അസൗകര്യമായേക്കാം, നിങ്ങൾ എപ്പോഴെങ്കിലും നിങ്ങളുടെ സ്വന്തം കോൺഫിഗറേഷനുകൾ സൃഷ്ടിക്കാൻ ആഗ്രഹിക്കുന്നുവെങ്കിൽ, ini ഫോർമാറ്റ് സൃഷ്ടിക്കാൻ ഇതിനകം തന്നെ അസൗകര്യമുണ്ടാകാം.

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

നിങ്ങൾക്ക് ഒരു കോൺഫിഗ്മാപ്പ് ഉണ്ടെങ്കിൽ, നിങ്ങളുടെ ആപ്ലിക്കേഷനെ നന്നായി പഠിപ്പിക്കാൻ കഴിയും, ഉദാഹരണത്തിന്, കോൺഫിഗറേഷൻ മൌണ്ട് ചെയ്തിരിക്കുന്ന ഫയലിലെ മാറ്റങ്ങൾ സ്വയമേവ ട്രാക്ക് ചെയ്യാനും കോൺഫിഗറേഷനുകൾ മാറുമ്പോൾ നിങ്ങളുടെ ആപ്ലിക്കേഷൻ സ്വയമേവ റീലോഡ് ചെയ്യാനും കഴിയും. ഇത് പൊതുവെ അനുയോജ്യമായ ഒരു ഓപ്ഷനായിരിക്കും.

വീണ്ടും, ഞാൻ ഇതിനെക്കുറിച്ച് ഇതിനകം സംസാരിച്ചു - രഹസ്യ വിവരങ്ങൾ കോൺഫിഗ്മാപ്പിൽ ഇല്ല, രഹസ്യ വിവരങ്ങൾ വേരിയബിളുകളിലില്ല, രഹസ്യ വിവരങ്ങൾ രഹസ്യങ്ങളിലില്ല. അവിടെ നിന്ന്, ഈ രഹസ്യ വിവരങ്ങൾ നയതന്ത്രവുമായി ബന്ധിപ്പിക്കുക. സാധാരണയായി ഞങ്ങൾ Kubernetes ഒബ്‌ജക്‌റ്റുകൾ, വിന്യാസങ്ങൾ, കോൺഫിഗ്‌മാപ്പുകൾ, സേവനങ്ങൾ എന്നിവയുടെ എല്ലാ വിവരണങ്ങളും git-ൽ സംഭരിക്കുന്നു. അതനുസരിച്ച്, ഡാറ്റാബേസിലേക്ക് പാസ്‌വേഡ് git-ൽ ഇടുന്നത്, അത് നിങ്ങളുടെ ജിറ്റ് ആണെങ്കിലും, നിങ്ങൾക്ക് കമ്പനിയിൽ ഉള്ളത് ഒരു മോശം ആശയമാണ്. കാരണം, ചുരുങ്ങിയത്, git എല്ലാം ഓർക്കുന്നു, അവിടെ നിന്ന് പാസ്‌വേഡുകൾ നീക്കംചെയ്യുന്നത് അത്ര എളുപ്പമല്ല.

ആരോഗ്യ പരിശോധന

അടുത്ത പോയിന്റ് ഇതാണ് ആരോഗ്യ പരിശോധന. പൊതുവേ, നിങ്ങളുടെ ആപ്ലിക്കേഷൻ പ്രവർത്തിക്കുന്നുണ്ടോയെന്ന് പരിശോധിക്കുന്നതാണ് ആരോഗ്യ പരിശോധന. അതേ സമയം, ഞങ്ങൾ മിക്കപ്പോഴും ചില വെബ് ആപ്ലിക്കേഷനുകളെക്കുറിച്ചാണ് സംസാരിക്കുന്നത്, അതിനനുസരിച്ച്, ആരോഗ്യ പരിശോധനയുടെ വീക്ഷണകോണിൽ നിന്ന് (ഇവിടെയും കൂടുതലും വിവർത്തനം ചെയ്യാതിരിക്കുന്നതാണ് നല്ലത്) ഇത് അവർ പ്രോസസ്സ് ചെയ്യുന്ന ചില പ്രത്യേക URL ആയിരിക്കും. ഒരു സ്റ്റാൻഡേർഡ്, അവർ സാധാരണയായി ചെയ്യുന്നു /health.

ഈ URL ആക്‌സസ് ചെയ്യുമ്പോൾ, അതനുസരിച്ച്, ഞങ്ങളുടെ ആപ്ലിക്കേഷൻ ഒന്നുകിൽ "അതെ, ശരി, എനിക്ക് എല്ലാം ശരിയാണ്, 200" അല്ലെങ്കിൽ "ഇല്ല, എനിക്ക് എല്ലാം ശരിയല്ല, ഏകദേശം 500" എന്ന് പറയുന്നു. അതനുസരിച്ച്, ഞങ്ങളുടെ ആപ്ലിക്കേഷൻ http അല്ല, ഒരു വെബ് ആപ്ലിക്കേഷനല്ലെങ്കിൽ, ഞങ്ങൾ ഇപ്പോൾ സംസാരിക്കുന്നത് ഏതെങ്കിലും തരത്തിലുള്ള ഡെമണിനെക്കുറിച്ചാണ്, ആരോഗ്യ പരിശോധനകൾ എങ്ങനെ നടത്താമെന്ന് നമുക്ക് കണ്ടെത്താനാകും. അതായത്, അത് ആവശ്യമില്ല, ആപ്ലിക്കേഷൻ http ഇല്ലെങ്കിൽ, ആരോഗ്യ പരിശോധന കൂടാതെ എല്ലാം പ്രവർത്തിക്കുന്നു, ഇത് ഒരു തരത്തിലും ചെയ്യാൻ കഴിയില്ല. നിങ്ങൾക്ക് ഫയലിലെ ചില വിവരങ്ങൾ ആനുകാലികമായി അപ്ഡേറ്റ് ചെയ്യാൻ കഴിയും, നിങ്ങളുടെ ഡെമണിനായി നിങ്ങൾക്ക് ചില പ്രത്യേക കമാൻഡുകൾ കൊണ്ടുവരാൻ കഴിയും. daemon status, അത് "അതെ, എല്ലാം ശരിയാണ്, ഡെമൺ പ്രവർത്തിക്കുന്നു, അത് ജീവനോടെയുണ്ട്" എന്ന് പറയും.

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

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

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

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

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

അതായത്, നിങ്ങളുടെ അപേക്ഷ, ഒരു അഭ്യർത്ഥന വരുമ്പോൾ /health, അത് പ്രതികരിക്കുക മാത്രമല്ല, “200, ശരി”, അത് ആദ്യം പോകുന്നു, ഉദാഹരണത്തിന്, ഡാറ്റാബേസിലേക്ക്, അതിലേക്ക് കണക്റ്റുചെയ്യാൻ ശ്രമിക്കുന്നു, അവിടെ വളരെ അടിസ്ഥാനപരമായ എന്തെങ്കിലും ചെയ്യുന്നു, ഒന്ന് തിരഞ്ഞെടുക്കുക പോലെ, അതിൽ ഒരു കണക്ഷൻ ഉണ്ടോ എന്ന് പരിശോധിക്കുക. ഡാറ്റാബേസ്, നിങ്ങൾക്ക് ഡാറ്റാബേസ് അന്വേഷിക്കാം. ഇതെല്ലാം വിജയകരമാണെങ്കിൽ, ഉത്തരം "200, ശരി" ​​എന്നാണ്. ഇത് വിജയിച്ചില്ലെങ്കിൽ, ഒരു പിശക് ഉണ്ടെന്ന് പറയുന്നു, ഡാറ്റാബേസ് ലഭ്യമല്ല.

അതിനാൽ, ഇക്കാര്യത്തിൽ, ഞാൻ വീണ്ടും റെഡിനസ്/ലൈവ്‌നെസ് ടെസ്റ്റുകളിലേക്ക് മടങ്ങുന്നു - എന്തുകൊണ്ടാണ് നിങ്ങൾക്ക് ഒരു റെഡിനെസ് ടെസ്റ്റ് ആവശ്യമായി വരുന്നത്, പക്ഷേ ഒരു ലൈവ്‌നെസ് ടെസ്റ്റ് ചോദ്യം ചെയ്യപ്പെടുന്നു. കാരണം നിങ്ങൾ ആരോഗ്യ പരിശോധനകൾ ഞാൻ ഇപ്പോൾ പറഞ്ഞതുപോലെ കൃത്യമായി വിവരിച്ചാൽ, അത് ഉദാഹരണ ഭാഗത്ത് ലഭ്യമല്ലെന്ന് മാറും.в или со всех instanceഒരു ഡാറ്റാബേസിൽ, ഉദാഹരണത്തിന്. നിങ്ങൾ ഒരു റെഡിനെസ് ടെസ്റ്റ് പ്രഖ്യാപിച്ചപ്പോൾ, ഞങ്ങളുടെ ആരോഗ്യ പരിശോധനകൾ പരാജയപ്പെടാൻ തുടങ്ങി, അതനുസരിച്ച് ഡാറ്റാബേസ് ആക്‌സസ് ചെയ്യാൻ കഴിയാത്ത എല്ലാ ആപ്ലിക്കേഷനുകളും അവ സന്തുലിതമാക്കുന്നതിൽ നിന്ന് ഓഫാക്കി, വാസ്തവത്തിൽ അവഗണിച്ച അവസ്ഥയിൽ "ഹാംഗ്" ചെയ്യുകയും അവയുടെ ഡാറ്റാബേസുകൾക്കായി കാത്തിരിക്കുകയും ചെയ്യുന്നു. ജോലി.

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

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

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

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

കാരണം ജീവനുള്ള പരിശോധന, വലിയതോതിൽ, നമ്മൾ "കുടുങ്ങിക്കിടക്കുമ്പോഴാണ്". അനന്തമായ ലൂപ്പ് ആരംഭിച്ചു അല്ലെങ്കിൽ മറ്റെന്തെങ്കിലും - കൂടുതൽ അഭ്യർത്ഥനകളൊന്നും പ്രോസസ്സ് ചെയ്യുന്നില്ല. അതിനാൽ, അവയെ വേർതിരിക്കുന്നതിൽ പോലും അർത്ഥമുണ്ട് - അവയിൽ വ്യത്യസ്ത യുക്തികൾ നടപ്പിലാക്കുക.

നിങ്ങൾക്ക് ഒരു പരിശോധന നടത്തുമ്പോൾ, ആരോഗ്യ പരിശോധനകൾ നടത്തുമ്പോൾ എന്താണ് ഉത്തരം നൽകേണ്ടത് എന്നതിനെക്കുറിച്ച്. ഇത് ശരിക്കും ഒരു വേദനയാണ്. ഇത് പരിചയമുള്ളവർ ഒരുപക്ഷേ ചിരിക്കും - എന്നാൽ ഗൗരവമായി, 200% കേസുകളിലും “XNUMX” എന്ന് ഉത്തരം നൽകുന്ന സേവനങ്ങൾ ഞാൻ എന്റെ ജീവിതത്തിൽ കണ്ടിട്ടുണ്ട്. അതായത്, ആരാണ് വിജയിച്ചത്. എന്നാൽ അതേ സമയം പ്രതികരണത്തിന്റെ ശരീരത്തിൽ അവർ "അത്തരം ഒരു പിശക്" എഴുതുന്നു.

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

ചില ആളുകൾ ഇത് തമാശയായി കാണാതിരിക്കാനും മറ്റുള്ളവർ ഇത് വളരെ വേദനാജനകമാണെന്ന് കണ്ടെത്താനും, ഒരു ലളിതമായ നിയമം പാലിക്കുന്നത് ഇപ്പോഴും മൂല്യവത്താണ്. ആരോഗ്യ പരിശോധനകളിലും തത്വത്തിൽ വെബ് ആപ്ലിക്കേഷനുകളിൽ പ്രവർത്തിക്കുമ്പോഴും.

എല്ലാം ശരിയാണെങ്കിൽ, ഇരുന്നൂറാമത്തെ ഉത്തരം ഉപയോഗിച്ച് പ്രതികരിക്കുക. തത്വത്തിൽ, ഏത് ഇരുനൂറാമത്തെ ഉത്തരവും നിങ്ങൾക്ക് അനുയോജ്യമാകും. നിങ്ങൾ റാഗ്സി നന്നായി വായിക്കുകയും ചില പ്രതികരണ സ്റ്റാറ്റസുകൾ മറ്റുള്ളവയിൽ നിന്ന് വ്യത്യസ്തമാണെന്ന് അറിയുകയും ചെയ്യുന്നുവെങ്കിൽ, ഉചിതമായവ ഉപയോഗിച്ച് ഉത്തരം നൽകുക: 204, 5, 10, 15, എന്തായാലും. ഇത് വളരെ നല്ലതല്ലെങ്കിൽ, "രണ്ട് പൂജ്യം പൂജ്യം" മാത്രം. എല്ലാം മോശമാവുകയും ആരോഗ്യ പരിശോധന പ്രതികരിക്കാതിരിക്കുകയും ചെയ്താൽ, ഏതെങ്കിലും അഞ്ഞൂറിൽ നിന്ന് ഉത്തരം നൽകുക. വീണ്ടും, എങ്ങനെ പ്രതികരിക്കണമെന്ന് നിങ്ങൾ മനസ്സിലാക്കുന്നുവെങ്കിൽ, വ്യത്യസ്ത പ്രതികരണ നിലകൾ പരസ്പരം എങ്ങനെ വ്യത്യാസപ്പെട്ടിരിക്കുന്നു. നിങ്ങൾക്ക് മനസ്സിലാകുന്നില്ലെങ്കിൽ, എന്തെങ്കിലും തെറ്റ് സംഭവിച്ചാൽ ആരോഗ്യ പരിശോധനകളോട് പ്രതികരിക്കാനുള്ള നിങ്ങളുടെ ഓപ്ഷനാണ് 502.

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

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

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

അടുത്തതായി, ആപ്ലിക്കേഷനുകൾ സമാരംഭിക്കുമ്പോൾ ഞങ്ങൾക്ക് വേദനാജനകമായ ഒരു പ്രശ്നമുണ്ട്.

വാസ്തവത്തിൽ, ഇത് കുബെർനെറ്റുകൾക്ക് വലിയതോതിൽ ബാധകമല്ല; ചിലതരം ബഹുജന വികസനത്തിന്റെയും പ്രത്യേകിച്ച് DevOps-ന്റെയും സംസ്കാരം കുബർനെറ്റുകളുടെ അതേ സമയത്താണ് വ്യാപിക്കാൻ തുടങ്ങിയത്. അതിനാൽ, മൊത്തത്തിൽ, കുബർനെറ്റസ് ഇല്ലാതെ നിങ്ങളുടെ ആപ്ലിക്കേഷൻ മനോഹരമായി ഷട്ട്ഡൗൺ ചെയ്യേണ്ടതുണ്ടെന്ന് ഇത് മാറുന്നു. കുബർനെറ്റസിന് മുമ്പ് തന്നെ ആളുകൾ ഇത് ചെയ്തു, എന്നാൽ കുബർനെറ്റസിന്റെ വരവോടെ ഞങ്ങൾ ഇതിനെ കുറിച്ച് കൂട്ടമായി സംസാരിച്ചു തുടങ്ങി.

ഗംഭീരമായ ഷട്ട്ഡൗൺ

പൊതുവേ, എന്താണ് ഗ്രേസ്ഫുൾ ഷട്ട്ഡൗൺ, എന്തുകൊണ്ട് അത് ആവശ്യമാണ്? ചില കാരണങ്ങളാൽ നിങ്ങളുടെ ആപ്ലിക്കേഷൻ തകരാറിലാകുമ്പോൾ, നിങ്ങൾ ചെയ്യേണ്ടത് ഇതാണ് app stop - അല്ലെങ്കിൽ നിങ്ങൾക്ക് ഓപ്പറേറ്റിംഗ് സിസ്റ്റത്തിൽ നിന്ന് ഒരു സിഗ്നൽ ലഭിക്കുന്നു, നിങ്ങളുടെ ആപ്ലിക്കേഷൻ അത് മനസിലാക്കുകയും അതിനെക്കുറിച്ച് എന്തെങ്കിലും ചെയ്യുകയും വേണം. നിങ്ങളുടെ അപേക്ഷയ്ക്ക് ഒരു SIGTERM ലഭിക്കുകയും "SIGTERM, നമുക്ക് നിൽക്കാം, പ്രവർത്തിക്കാം, ഒന്നും ചെയ്യാതിരിക്കുകയും ചെയ്യും" എന്നതു പോലെയുള്ളതാണ് ഏറ്റവും മോശം സാഹചര്യം. ഇത് തികച്ചും മോശമായ ഓപ്ഷനാണ്.

നിങ്ങളുടെ അപേക്ഷയ്ക്ക് ഒരു SIGTERM ലഭിക്കുകയും "അവർ സെഗ്‌ടേം എന്ന് പറയുകയും ചെയ്യുമ്പോൾ, ഞങ്ങൾ അവസാനിക്കുകയാണ്, ഞാൻ കണ്ടില്ല, ഉപയോക്തൃ അഭ്യർത്ഥനകളൊന്നും എനിക്കറിയില്ല, എങ്ങനെയുള്ളതാണെന്ന് എനിക്കറിയില്ല." ഞാൻ ഇപ്പോൾ പ്രവർത്തിക്കുന്ന അഭ്യർത്ഥനകൾ, അവർ പറഞ്ഞു SIGTERM, അതിനർത്ഥം ഞങ്ങൾ അവസാനിപ്പിക്കുകയാണ് " ഇതും ഒരു മോശം ഓപ്ഷനാണ്.

ഏത് ഓപ്ഷനാണ് നല്ലത്? പ്രവർത്തനങ്ങളുടെ പൂർത്തീകരണം കണക്കിലെടുക്കുക എന്നതാണ് ആദ്യ പോയിന്റ്. നിങ്ങളുടെ സെർവറിന് ഒരു SIGTERM ലഭിക്കുകയാണെങ്കിൽ അത് എന്താണ് ചെയ്യുന്നതെന്ന് ഇപ്പോഴും കണക്കിലെടുക്കുന്നതാണ് ഒരു നല്ല ഓപ്ഷൻ.

SIGTERM ഒരു സോഫ്റ്റ് ഷട്ട്ഡൗൺ ആണ്, ഇത് പ്രത്യേകം രൂപകൽപ്പന ചെയ്‌തതാണ്, ഇത് കോഡ് തലത്തിൽ തടസ്സപ്പെടുത്താൻ കഴിയും, ഇത് പ്രോസസ്സ് ചെയ്യാൻ കഴിയും, ഇപ്പോൾ പറയൂ, കാത്തിരിക്കൂ, ഞങ്ങൾ ആദ്യം ഉള്ള ജോലി പൂർത്തിയാക്കും, തുടർന്ന് ഞങ്ങൾ പുറത്തുകടക്കും.

ഒരു കുബർനെറ്റസ് വീക്ഷണകോണിൽ നിന്ന്, ഇത് ഇങ്ങനെയാണ് കാണപ്പെടുന്നത്. Kubernetes ക്ലസ്റ്ററിൽ പ്രവർത്തിക്കുന്ന ഒരു പോഡിനോട്, "ദയവായി നിർത്തൂ, പോകൂ" എന്ന് പറയുമ്പോൾ അല്ലെങ്കിൽ ഞങ്ങൾ പുനരാരംഭിക്കുമ്പോൾ അല്ലെങ്കിൽ Kubernetes പോഡുകൾ പുനഃസൃഷ്ടിക്കുമ്പോൾ ഒരു അപ്‌ഡേറ്റ് സംഭവിക്കുമ്പോൾ, Kubernetes പോഡിലേക്ക് അതേ SIGTERM സന്ദേശം അയയ്ക്കുന്നു, കാത്തിരിക്കുന്നു കുറച്ച് സമയം, കൂടാതെ , അവൻ കാത്തിരിക്കുന്ന സമയമാണിത്, അതും കോൺഫിഗർ ചെയ്തിട്ടുണ്ട്, ഡിപ്ലോമകളിൽ അത്തരമൊരു പ്രത്യേക പാരാമീറ്റർ ഉണ്ട്, അതിനെ ഗ്രേസ്ഫുൾ ഷട്ട്ഡൗൺ ടൈംഔട്ട് എന്ന് വിളിക്കുന്നു. നിങ്ങൾ മനസ്സിലാക്കുന്നതുപോലെ, അതിനെ വെറുതെയല്ല വിളിക്കുന്നത്, ഞങ്ങൾ ഇപ്പോൾ അതിനെക്കുറിച്ച് സംസാരിക്കുന്നത് വെറുതെയല്ല.

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

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

നിങ്ങളുടെ ആപ്ലിക്കേഷൻ അവസാനിക്കുമ്പോൾ, ഉചിതമായ ചില എക്സിറ്റ് കോഡ് നൽകണം. അതായത്, നിങ്ങളുടെ അപേക്ഷ അടയ്‌ക്കാനും നിർത്താനും ആവശ്യപ്പെടുകയും അത് സാധാരണ രീതിയിൽ നിർത്താൻ കഴിയുകയും ചെയ്‌താൽ, നിങ്ങൾ ഏതെങ്കിലും തരത്തിലുള്ള എക്‌സിറ്റ് കോഡ് 1,5,255 മുതലായവ തിരികെ നൽകേണ്ടതില്ല. സീറോ കോഡ് അല്ലാത്ത എന്തും, കുറഞ്ഞത് ലിനക്സ് സിസ്റ്റങ്ങളിലെങ്കിലും, എനിക്ക് ഇത് ഉറപ്പാണ്, അത് വിജയകരമല്ലെന്ന് കണക്കാക്കപ്പെടുന്നു. അതായത്, ഈ കേസിൽ നിങ്ങളുടെ അപേക്ഷ ഒരു പിശകോടെ അവസാനിച്ചതായി കണക്കാക്കുന്നു. അതനുസരിച്ച്, സൗഹാർദ്ദപരമായ രീതിയിൽ, നിങ്ങളുടെ അപേക്ഷ ഒരു പിശക് കൂടാതെ പൂർത്തിയാക്കിയാൽ, നിങ്ങൾ ഔട്ട്പുട്ടിൽ 0 എന്ന് പറയുന്നു. ചില കാരണങ്ങളാൽ നിങ്ങളുടെ ആപ്ലിക്കേഷൻ പരാജയപ്പെടുകയാണെങ്കിൽ, നിങ്ങൾ ഔട്ട്പുട്ടിൽ നോൺ-0 എന്ന് പറയുന്നു. നിങ്ങൾക്ക് ഈ വിവരങ്ങളുമായി പ്രവർത്തിക്കാൻ കഴിയും.

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

ചില സാധാരണ ചാറ്റുകളുടെ ഡെവലപ്പർമാർക്ക് അത് അറിയാത്തപ്പോൾ, വെബ്‌സോക്കറ്റ് തകരാൻ സാധ്യതയുണ്ട്. അവർക്കായി, പ്രോക്സിയിൽ എന്തെങ്കിലും സംഭവിക്കുമ്പോൾ, ഞങ്ങൾ കോൺഫിഗറേഷൻ മാറ്റുന്നു, അത് വീണ്ടും ലോഡുചെയ്യുന്നു. സ്വാഭാവികമായും, ഈ കേസിൽ എല്ലാ ദീർഘകാല സെഷനുകളും കീറിപ്പറിഞ്ഞിരിക്കുന്നു. ഡെവലപ്പർമാർ ഞങ്ങളുടെ അടുത്തേക്ക് ഓടിവന്ന് പറഞ്ഞു: "കുട്ടികളേ, നിങ്ങൾ എന്താണ് ചെയ്യുന്നത്, ഞങ്ങളുടെ എല്ലാ ക്ലയന്റുകളുടെയും ചാറ്റ് തകർന്നു!" ഞങ്ങൾ അവരോട് പറയുന്നു: “നിങ്ങൾ എന്താണ് ചെയ്യുന്നത്? നിങ്ങളുടെ ഉപഭോക്താക്കൾക്ക് വീണ്ടും കണക്റ്റ് ചെയ്യാൻ കഴിയുന്നില്ലേ? അവർ പറയുന്നു: "ഇല്ല, സെഷനുകൾ കീറാതിരിക്കാൻ ഞങ്ങൾക്ക് ആവശ്യമാണ്." ചുരുക്കത്തിൽ, ഇത് യഥാർത്ഥത്തിൽ അസംബന്ധമാണ്. ക്ലയന്റ് വശം കണക്കിലെടുക്കേണ്ടതുണ്ട്. പ്രത്യേകിച്ചും, ഞാൻ പറയുന്നതുപോലെ, വെബ്‌സോക്കറ്റുകൾ പോലെയുള്ള ദീർഘകാല സെഷനുകൾ ഉപയോഗിച്ച്, അത് തകർക്കാൻ കഴിയും, കൂടാതെ ഉപയോക്താവിന്റെ ശ്രദ്ധയിൽപ്പെടാതെ, നിങ്ങൾക്ക് അത്തരം സെഷനുകൾ വീണ്ടും ഇൻസ്റ്റാൾ ചെയ്യാൻ കഴിയണം. പിന്നെ എല്ലാം തികഞ്ഞതാണ്.

വിഭവങ്ങൾ

യഥാർത്ഥത്തിൽ, ഇവിടെ ഞാൻ നിങ്ങളോട് ഒരു നേരായ കഥ പറയാം. യഥാർത്ഥ ജീവിതത്തിൽ നിന്ന് വീണ്ടും. വിഭവങ്ങളെ കുറിച്ച് ഞാൻ കേട്ടിട്ടുള്ളതിൽ വച്ച് ഏറ്റവും അസുഖകരമായ കാര്യം.

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

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

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

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

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

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

ഡാറ്റ സംഭരണം

ഞങ്ങളുടെ അടുത്ത പോയിന്റ് ഡാറ്റ സംഭരണത്തെക്കുറിച്ചാണ്. അവരുമായി എന്തുചെയ്യണം, പൊതുവേ, കുബർനെറ്റസിലെ സ്ഥിരോത്സാഹത്തോടെ എന്തുചെയ്യണം?

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

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

ഞങ്ങളുടെ ആപ്ലിക്കേഷൻ സംഭരിക്കാൻ ആഗ്രഹിക്കുന്ന ഡാറ്റ, ഉപയോക്താക്കൾ അപ്‌ലോഡ് ചെയ്യുന്ന ചില ചിത്രങ്ങൾ, ഞങ്ങളുടെ ആപ്ലിക്കേഷൻ അതിന്റെ പ്രവർത്തന സമയത്ത് സൃഷ്ടിക്കുന്ന ചില കാര്യങ്ങൾ, ഉദാഹരണത്തിന്, സ്റ്റാർട്ടപ്പിൽ ഞങ്ങൾ എന്തുചെയ്യണം? കുബർനെറ്റസിൽ അവരുമായി എന്തുചെയ്യണം?

പൊതുവേ, ആദർശപരമായി, അതെ, തീർച്ചയായും, കുബെർനെറ്റസ് വളരെ നന്നായി രൂപകൽപ്പന ചെയ്തിട്ടുള്ളതാണ് കൂടാതെ പൊതുവെ സ്‌റ്റേറ്റ്‌ലെസ് ആപ്ലിക്കേഷനുകൾക്കായി വിഭാവനം ചെയ്തതാണ്. അതായത്, വിവരങ്ങൾ സംഭരിക്കാത്ത ആപ്ലിക്കേഷനുകൾക്ക്. ഇത് അനുയോജ്യമാണ്.

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

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

സെഫിൽ ഞങ്ങൾക്ക് ഒരു കോഴ്‌സ് ഉണ്ടായിരിക്കും, നിങ്ങൾക്ക് കഴിയും പ്രോഗ്രാമിനെക്കുറിച്ച് സ്വയം പരിചയപ്പെടുകയും ഒരു അപേക്ഷ സമർപ്പിക്കുകയും ചെയ്യുക.

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

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

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

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

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

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

Cloudnativeness

അവസാന ഉപവിഷയം എന്താണ് ക്ലൗഡ്നേറ്റീവ്. എന്തുകൊണ്ട് അത് ആവശ്യമാണ്? Cloudnativeness തുടങ്ങിയവ.

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

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

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

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

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

എന്നാൽ എന്റെ അനുഭവത്തിൽ നിന്ന്, വീണ്ടും, ഞാൻ കണ്ടിട്ടുള്ളതിൽ വച്ച് ഏറ്റവും മികച്ച കാര്യമാണിത്. ദിവസത്തിന്റെ സമയത്തെ അടിസ്ഥാനമാക്കി ക്ലൗഡ്നേറ്റീവ് ക്ലസ്റ്റർ സ്കെയിൽ ചെയ്യുമ്പോൾ. ബാക്ക് ഓഫീസിലെ ആളുകൾ ഉപയോഗിച്ചിരുന്ന ഒരു ബാക്കെൻഡ് സേവനമായിരുന്നു അത്. അതായത്, അവർ രാവിലെ 9 മണിക്ക് ജോലിക്ക് വരുന്നു, സിസ്റ്റത്തിലേക്ക് ലോഗിൻ ചെയ്യാൻ തുടങ്ങുന്നു, അതനുസരിച്ച്, എല്ലാം പ്രവർത്തിക്കുന്ന ക്ലൗഡ്നേറ്റീവ് ക്ലസ്റ്റർ വീർക്കാൻ തുടങ്ങുന്നു, പുതിയ പോഡുകൾ സമാരംഭിക്കുന്നു, അങ്ങനെ ജോലിക്ക് വരുന്ന എല്ലാവർക്കും ആപ്ലിക്കേഷനുമായി പ്രവർത്തിക്കാൻ കഴിയും. അവർ രാത്രി 8-നോ 6-നോ ജോലിയിൽ നിന്ന് പോകുമ്പോൾ, ആരും ഇപ്പോൾ ആപ്ലിക്കേഷൻ ഉപയോഗിക്കുന്നില്ലെന്ന് കുബർനെറ്റസ് ക്ലസ്റ്ററുകൾ ശ്രദ്ധിക്കുകയും ചുരുങ്ങാൻ തുടങ്ങുകയും ചെയ്യുന്നു. 30 ശതമാനം വരെ സമ്പാദ്യം ഉറപ്പാണ്. അക്കാലത്ത് ഇത് ആമസോണിൽ പ്രവർത്തിച്ചു; അക്കാലത്ത് റഷ്യയിൽ ഇത് നന്നായി ചെയ്യാൻ കഴിയുന്ന ആരും ഉണ്ടായിരുന്നില്ല.

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

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

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

ഈ പ്രശ്നങ്ങളെല്ലാം കൂടുതൽ വിശദമായി ഇവിടെ ചർച്ചചെയ്യുന്നു കുബർനെറ്റസ് വീഡിയോ കോഴ്സുകൾ: ജൂനിയർ, ബേസിക്, മെഗാ. ലിങ്ക് പിന്തുടരുന്നതിലൂടെ നിങ്ങൾക്ക് പ്രോഗ്രാമും വ്യവസ്ഥകളും പരിചയപ്പെടാം. ഒരു ദിവസം 1-2 മണിക്കൂർ വീട്ടിൽ നിന്നോ ജോലിയിൽ നിന്നോ പഠിച്ച് നിങ്ങൾക്ക് കുബർനെറ്റസ് പഠിക്കാൻ കഴിയും എന്നതാണ് സൗകര്യപ്രദമായ കാര്യം.

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