VPN സൈഡ്കാറിന് ഒരു സ്റ്റാർട്ട് നിയമവും ഒരു പരാജയ നിയമവും വേണം

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

ക്രമം ആദ്യ അഭ്യർത്ഥനയെ മാത്രം തടയുന്നു

Kubernetes പുനരാരംഭിക്കാവുന്ന init കണ്ടെയ്നറുകൾ കൊണ്ട് നിർമ്മിച്ച സൈഡ്കാർ ലൈഫ്സൈക്കിൾ പിന്തുണയ്ക്കുന്നു. ആ മാതൃകയിൽ സ്റ്റാർട്ടപ്പ് പ്രോബിന് ടണൽ തയ്യാറാണെന്ന് റിപ്പോർട്ട് ചെയ്യുന്നതുവരെ അടുത്ത ഇനിഷ്യലൈസേഷൻ ഘട്ടം പിടിച്ചുവയ്ക്കാം. ഇത് യഥാർത്ഥ മെച്ചമാണ്, എൻട്രിപോയിന്റ് സ്ക്രിപ്റ്റിൽ sleep ചേർക്കുന്നതിന് പകരം ഇത് ബോധപൂർവ്വം ഉപയോഗിക്കണം. ഗേറ്റ് അത് പരിശോധിക്കുന്ന വ്യവസ്ഥയോളം മാത്രമേ നല്ലതാകൂ.

ആ മാതൃകയ്ക്ക് പുറത്ത്, ക്രമത്തിന്റെ അർത്ഥശാസ്ത്രം നിങ്ങൾ ഉപയോഗിക്കുന്ന റൺടൈമിനോ ഡിപ്പൻഡൻസി സിസ്റ്റത്തിനോ സ്വന്തമാണ്, അവ ഒത്തുതീരണമെന്നില്ല. മറ്റൊരു പ്ലാറ്റ്ഫോമിൽ നിന്ന് പകർത്തിയ ഡിപ്ലോയ്മെന്റ് ടണലിനായി കാത്തിരിക്കുന്നതുപോലെ തോന്നാം, കാരണം ആപ്പ് യാദൃച്ഛികമായി പതുക്കെ ആരംഭിക്കുന്നു. അത് അതേ ഉറപ്പല്ല, ലോഡിൽ അത് പരാജയപ്പെടുന്നു.

ഗേറ്റ് എന്താണ് നിരീക്ഷിക്കുന്നതെന്ന് പറയുക: ഒരു പ്രോസസ്സ് ഉണ്ട്, ഒരു ഇന്റർഫേസ് ഉണ്ട്, ഒരു handshake പൂർത്തിയായി. ഇവയോരോന്നും “ഈ pod-ന് ആവശ്യമായ ലക്ഷ്യസ്ഥാനങ്ങളിലേക്കുള്ള ഡാറ്റ പാത പ്രവർത്തിക്കുന്നു” എന്നതിനേക്കാൾ ദുർബലമായ അവകാശവാദമാണ്.

ഡാറ്റ പാത അനുമാനിക്കുന്നതിന് പകരം നടപ്പാക്കുക

പ്രോബ് ഒരു നിമിഷത്തെ പരിശോധനയാണ്, firewall നിമിഷങ്ങൾക്കിടയിൽ ബാധകമാകുന്ന ഒരു സ്വഭാവമാണ്. ആപ്പ് ട്രാഫിക് ഒരിക്കലും ടണലിന് പുറത്ത് പോകരുതെന്നതാണ് ആവശ്യമെങ്കിൽ, അത് പങ്കിട്ട നെറ്റ്വർക്ക് നെയിംസ്പേസിൽ സ്വീകരിക്കുക-അല്ലെങ്കിൽ-ഉപേക്ഷിക്കുക നിയമമായി പ്രകടിപ്പിക്കണം. കണ്ടെയ്നർ ആരംഭ ക്രമത്തിന് ആ ആവശ്യം വഹിക്കാനാവില്ല. ഒരു നിയമത്തിന് മാത്രമേ കഴിയൂ.

ഒരു pod-ലെ കണ്ടെയ്നറുകൾ ആ നെയിംസ്പേസ് പങ്കിടുന്നു, അതിനാൽ നടപ്പാക്കൽ പോയിന്റ് നെയിംസ്പേസ് തന്നെയാണ്. നിങ്ങൾ എന്ത് എഴുതിയാലും, അത് ടണലിന്റെ സ്വന്തം പുറം കണക്ഷൻ ലഭ്യമായി വിടണം, കാരണം ആപ്പിനെ സംരക്ഷിക്കാൻ അത് തടയുന്നത് ആപ്പിന് ആവശ്യമായ പാത മുറിക്കുന്നു.

പരാജയ നയം വ്യക്തമായി തീരുമാനിക്കുക: ടണൽ ആരോഗ്യകരമല്ലാത്തപ്പോൾ ആപ്പ് ട്രാഫിക് പൂർണ്ണമായി നിർത്തണമോ, അതോ തുടർന്ന് സംരക്ഷിതമല്ലെന്ന് അടയാളപ്പെടുത്തണമോ? രണ്ടും ന്യായീകരിക്കാവുന്നതാണ്, ഒന്നും ഒരു പ്രത്യേക ക്രമത്തിൽ കണ്ടെയ്നറുകൾ ആരംഭിക്കുന്നതിലൂടെ ലഭിക്കുന്നതല്ല.

നിങ്ങൾ പരാമർശിക്കാത്ത ട്രാഫിക് പരിശോധിക്കുക

നിയന്ത്രിത ടണൽ പരാജയ സമയത്ത് ഒരു പുതിയ അഭ്യർത്ഥന എടുത്ത് അത് പുറത്ത് പോകുന്നുണ്ടോയെന്ന് നോക്കുക. തുടർന്ന് എക്സിറ്റ്-അഡ്രസ് പരിശോധന ഒരിക്കലും തൊടാത്ത പാതകൾക്കും പരിശോധന ആവർത്തിക്കുക: ക്ലസ്റ്ററിനുള്ളിലെ DNS റെസല്യൂഷൻ, IPv6 ലക്ഷ്യസ്ഥാനങ്ങൾ, പൊതു ഇന്റർനെറ്റിന് പകരം ക്ലസ്റ്റർ-ആന്തരിക വിലാസങ്ങളിലൂടെ എത്തുന്ന സേവനങ്ങൾ. ടണൽ മരിച്ചതിന് ശേഷവും നിശ്ശബ്ദമായി പ്രവർത്തിക്കുന്ന പാതകൾ ഇവയാണ്.

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

വെറും വൃത്തിയുള്ള തുടക്കത്തിന് ശേഷം മാത്രമല്ല, സൈഡ്കാർ റീസ്റ്റാർട്ടിന് ശേഷവും പരിശോധന ആവർത്തിക്കുക. പുനരാരംഭിച്ച ടണൽ കണ്ടെയ്നർ നെയിംസ്പേസിനെ റൂട്ടുകളും നയവുമായി ഇടനില അവസ്ഥയിൽ വിടാം.

ഡിപ്ലോയ്മെന്റ് റെക്കോർഡ് എഴുതുക

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

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

അവസാനമായി, ആപ്പ് പ്രവർത്തിക്കുമ്പോൾ വീണ്ടെടുക്കൽ പാത ഒരിക്കൽ പരിശോധിക്കുക. എഗ്രസ് പുനഃസ്ഥാപിക്കാൻ pod വീണ്ടും സൃഷ്ടിക്കേണ്ടതുണ്ടെന്ന് ആവശ്യപ്പെടുന്ന രൂപകൽപ്പന ഒരു തീരുമാനമാണ്, അത് നിങ്ങൾ കണ്ടെത്തിയതല്ല, നിങ്ങൾ എടുത്ത തീരുമാനമായിരിക്കണം.