Pod, നോഡ് അല്ലെങ്കിൽ ക്ലസ്റ്റർ: VPN sidecar യഥാർത്ഥത്തിൽ എന്താണ് വീണ്ടും റൂട്ട് ചെയ്യുന്നത്

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

പങ്കിട്ട namespace, പങ്കിട്ട പരിണാമങ്ങൾ

ഒരു Pod-ലെ രണ്ട് കണ്ടെയ്നറുകൾ loopback വഴി സംസാരിക്കുകയും ഒരേ ഇന്റർഫേസുകൾ കാണുകയും ചെയ്യുന്നു, അതുകൊണ്ടാണ് sidecar മാതൃക പൊതുവെ പ്രവർത്തിക്കുന്നത്: ആപ്പിന് ഒരു ടണൽ ഉണ്ടെന്ന് അറിയേണ്ടതില്ല, കാരണം അത് റിസോൾവ് ചെയ്യുന്ന റൂട്ട് അത് ഉപയോഗിക്കുന്ന namespace-ൽ ഇൻസ്റ്റാൾ ചെയ്തതാണ്. അതേ സവിശേഷത അർത്ഥമാക്കുന്നത് sidecar-ന്റെ തെറ്റുകൾ ആപ്പിന്റെ തെറ്റുകളാണ് എന്നാണ്. കൂടുതൽ പിടിക്കുന്ന ഒരു റൂട്ട്, അല്ലെങ്കിൽ ടണലിനുള്ളിലെ റിസോൾവറിലേക്ക് ചൂണ്ടുന്ന DNS മാറ്റം, ആ Pod-ലെ ഓരോ പ്രോസസ്സിനും ഉടൻ ബാധകമാകുന്നു. പങ്കിട്ട namespace-ൽ കണ്ടെയ്നർ അടിസ്ഥാനമാക്കിയ റൂട്ടിംഗ് ഇല്ല, അതിനാൽ sidecar-നെ ഒരു പ്രോസസ്സിലേക്ക് പരിമിതപ്പെടുത്താൻ കഴിയില്ല.

അവലോകന സമയത്ത് ഓർക്കേണ്ട സംവിധാനം ഇതാണ്: സ്വാധീനത്തിന്റെ ആരം Pod ആണ്, നോഡല്ല, ക്ലസ്റ്ററുമല്ല.

sidecar എത്താത്ത ഇടം

മറ്റ് Pod-കൾ അവയുടെ സ്വന്തം namespace-ഉം സ്വന്തം റൂട്ടിംഗും നിലനിർത്തുന്നു, അതിനാൽ അതേ egress ആവശ്യമുള്ള വർക്ക്ലോഡിന് അതേ sidecar അല്ലെങ്കിൽ പകരം നോഡ്-തല രൂപകൽപ്പന വേണം. നോഡിന്റെ ട്രാഫിക്കും Pod namespace-ന് പുറത്താണ്, ഹോസ്റ്റ് നെറ്റ്വർക്കുള്ള Pod-കൾ ഈ ഒറ്റപ്പെടുത്തലിൽ നിന്ന് മനഃപൂർവം പൂർണ്ണമായി ഒഴിവാകുന്നു. സൗകര്യപ്രദമായ എന്തിലേക്കെങ്കിലും എത്താൻ sidecar-നെ ഹോസ്റ്റ് നെറ്റ്വർക്കിംഗോടെ പ്രവർത്തിപ്പിച്ചാൽ, നിങ്ങൾ പരിധി ഒരു Pod-ൽ നിന്ന് മുഴുവൻ നോഡിലേക്ക് വിപുലീകരിച്ചു, അത് ഉറക്കെ പറയണം.

ക്ലസ്റ്റർ സേവനങ്ങളിലേക്കുള്ള ട്രാഫിക്കാണ് അടുത്ത സാധാരണ ആശ്ചര്യം. Pod-നുള്ളിലെ വിശാലമായ ഡിഫോൾട്ട് റൂട്ട് API സെർവറിനോ ClusterIP സേവനത്തിനോ ഉദ്ദേശിച്ച അഭ്യർത്ഥനകൾ പിടിച്ചെടുക്കാം, പിന്നീട് അവ ടണൽ തകർന്നതുപോലെ തോന്നുന്ന രീതിയിൽ പരാജയപ്പെടുന്നു.

റൂട്ട് പ്ലാൻ: Pod, സേവനം, നോഡ്, VPN ശ്രേണികൾ

നാല് ശ്രേണികൾ എഴുതി സൂക്ഷിക്കുക, എന്തെങ്കിലും വിന്യസിക്കുന്നതിന് മുൻപ് ഓവർലാപ്പ് പരിശോധിക്കുക: Pod CIDR, സേവന CIDR, നോഡ് വിലാസങ്ങൾ, VPN-ന് പിന്നിലെ ലക്ഷ്യസ്ഥാനങ്ങൾ. VPN-ന്റെ സ്വകാര്യ ശ്രേണികളും ക്ലസ്റ്ററിന്റെ സ്വന്തം ഇടവും തമ്മിലുള്ള ഓവർലാപ്പ് അപൂർവമല്ല, ഡിഫോൾട്ട് റൂട്ട് അതിന് തെറ്റായ പരിഹാരമാണ്. റൂട്ട് പ്ലാൻ മാനിഫെസ്റ്റിന്റെ അതേ റിപ്പോസിറ്ററിയിൽ വേണം, കാരണം അടുത്ത ക്ലസ്റ്റർ തികച്ചും വ്യത്യസ്തമായ Pod, സേവന ശ്രേണികൾ നൽകിയേക്കാം.

DNS പ്ലാനിന്റെ ഭാഗമാണ്, വേറിട്ട ആശങ്കയല്ല. റിസോൾവർ കോൺഫിഗറേഷൻ വീണ്ടും എഴുതുന്ന sidecar ക്ലസ്റ്ററിനുള്ളിലെ സേവന കണ്ടെത്തൽ തകർക്കാം, പുറത്തുള്ള അന്വേഷണങ്ങൾ തികച്ചും പ്രവർത്തിക്കുമ്പോൾ.

സ്റ്റാർട്ടും പരാജയവും വ്യക്തമായ അവസ്ഥകളാണ്

പ്രവർത്തിക്കുന്ന sidecar പ്രോസസ്സ് ഒരു egress നയമല്ല. ടണൽ തയ്യാറാകുന്നതിന് മുൻപ് ഏത് ട്രാഫിക്കിന് ഒഴുകാം, പിന്നീട് അത് മരിച്ചാൽ എന്ത് സംഭവിക്കും എന്നത് തീരുമാനിച്ച്, ആ തീരുമാനം നടപ്പാക്കുക: ആപ്പ് കണ്ടെയ്നറെ ഗേറ്റ് ചെയ്യുന്ന പ്രോബ്, ഡിഫോൾട്ടായി നിരസിക്കുന്ന നെറ്റ്വർക്ക് നയം, അല്ലെങ്കിൽ രണ്ടും. അവയിലൊന്നും ഇല്ലെങ്കിൽ ആപ്പ് ആരംഭിച്ച്, പേരുകൾ റിസോൾവ് ചെയ്ത്, ടണൽ ഇപ്പോഴും കണക്റ്റ് ചെയ്യുമ്പോൾ ട്രാഫിക്ക് നോഡിന്റെ സാധാരണ വഴിക്ക് പുറത്തേക്ക് അയക്കുന്നു.

ആ വിടവ് ആരോഗ്യകരമായ ക്ലസ്റ്ററിൽ ചെറുതും തകർന്നതിൽ സ്ഥിരവുമാണ്, ആക്രമണകാരിയോ ആകസ്മിക ഡാറ്റാ ചോർച്ചയോ ഇഷ്ടപ്പെടുന്ന സ്വഭാവം അതുതന്നെ.

ക്രമം ഒരു പരാജയ പരിശോധനയുമായി ചേർക്കുക. sidecar-നെ കൊല്ലുക, ആപ്പ് നിശബ്ദമായി പിന്നോട്ട് പോകുന്നതിന് പകരം അതിന്റെ ഉദ്ദേശിച്ച egress നഷ്ടപ്പെടുന്നുവെന്ന് സ്ഥിരീകരിക്കുക.

കഴിവുകൾ, നയങ്ങൾ, ആപ്പ് കണ്ടെയ്നറിൽ നിന്നുള്ള പരിശോധന

ഇന്റർഫേസുകൾ സൃഷ്ടിക്കാനും റൂട്ടുകൾ മാറ്റാനും ആവശ്യമായ കഴിവുകൾ നൽകുന്നത് പ്രത്യേകാവകാശ തീരുമാനമാണ്, ഒറ്റപ്പെട്ട Pod-ന് യോജിച്ച പ്രത്യേകാവകാശം നോഡ് സ്റ്റാക്കിൽ സ്വയമേവ യോജിക്കണമെന്നില്ല. ക്ലസ്റ്റർ പിന്തുണയ്ക്കുന്ന നെറ്റ്വർക്ക്, സുരക്ഷാ നയ സംവിധാനങ്ങൾ ഉപയോഗിക്കുക, ഓരോ CNI അല്ലെങ്കിൽ നയ നടപ്പാക്കലും VPN ഇന്റർഫേസിനെ ഒരേപോലെ കാണുമെന്ന് കരുതരുത്; വ്യത്യാസങ്ങൾ നിങ്ങൾക്ക് പ്രധാനമായ പരാജയ കേസുകളിൽ തന്നെ പ്രത്യക്ഷപ്പെടുന്നു.

യഥാർത്ഥ ആപ്പ് കണ്ടെയ്നറിൽ നിന്ന് പരീക്ഷിക്കുക, സ്വകാര്യ ലക്ഷ്യസ്ഥാനം, ക്ലസ്റ്റർ സേവനം, പൊതു ഇന്റർനെറ്റ് എന്നിവയിലേക്ക് പുതിയ അഭ്യർത്ഥനകളോടെ. sidecar-ൽ നിന്നുള്ള പരിശോധന ടണൽ പ്രവർത്തിക്കുന്നു എന്ന് തെളിയിക്കുന്നു, ആപ്പ് ആവശ്യമായത് എത്തുന്നു എന്നല്ല.

VPN കോൺഫിഗറേഷന് അരികിൽ ക്ലസ്റ്ററിന്റെ നെറ്റ്വർക്ക് അനുമാനങ്ങൾ രേഖപ്പെടുത്തുക. അപ്പോൾ വർക്ക്ലോഡ് മറ്റൊരു ക്ലസ്റ്ററിലേക്ക് മാറ്റുന്നത് നിശബ്ദമായി പ്രവർത്തനം നിർത്തുന്ന ഇമേജ് മാറ്റത്തിന് പകരം റൂട്ട് പ്ലാൻ പരിശോധിക്കുന്ന അഭ്യാസമാകുന്നു.