Kubernetes Pod VPN vs എഗ്രെസ് ഗേറ്റ്വേ: ടണൽ ആർക്കുള്ളത്?
Pod അതിന്റേതായ നെറ്റ്വർക്ക് നെയിംസ്പേസ് ആണ്, അതിനാൽ യഥാർത്ഥ തിരഞ്ഞെടുപ്പ് ഏത് പാളി ടണൽ സ്വന്തമാക്കുന്നു എന്നതാണ്: ഓരോ വർക്ക്ലോഡിനും ഐഡന്റിറ്റി അല്ലെങ്കിൽ ഒരു പങ്കിട്ട ഉറവിടത്തോടുകൂടിയ CNI-നിർദ്ദേശിത എഗ്രെസ്.
നിങ്ങൾ vpn-gateway എന്ന Pod വിന്യസിക്കുന്നു, ഒരു ടെസ്റ്റ് ക്ലയന്റിനെ അതിന്റെ വിലാസത്തിലേക്ക് ചൂണ്ടിക്കാണിക്കുന്നു, പാക്കറ്റുകൾ അപ്രത്യക്ഷമാകുന്നത് കാണുന്നു. മാനിഫെസ്റ്റിൽ ഒന്നും തെറ്റല്ല, kubelet-ന് പരാതിയുമില്ല. കാരണം കോൺഫിഗറേഷനല്ല, ഘടനാപരമാണ്: Kubernetes ഓരോ Pod-നും അതിന്റേതായ നെറ്റ്വർക്ക് നെയിംസ്പേസ് നൽകുന്നു, അതിനാൽ ഒരു പേരോ ലേബലോ പങ്കിട്ട API നെയിംസ്പേസോ പാക്കറ്റുകൾ എവിടേക്ക് പോകുന്നു എന്നതിൽ ഒന്നും മാറ്റുന്നില്ല. അതിനാൽ VPN ട്രാഫിക് ക്ലസ്റ്ററിൽ നിന്ന് എങ്ങനെ പുറത്തുപോകുന്നു എന്നത് സ്വന്തം അവകാശത്തെക്കുറിച്ചുള്ള ചോദ്യത്തിൽ നിന്നാണ് തുടങ്ങുന്നത്, കണ്ടെയ്നർ ഇമേജുകളിൽ നിന്നല്ല.
രണ്ട് സംവിധാനങ്ങൾ മിക്ക യഥാർത്ഥ വിന്യാസങ്ങളെയും ഉൾക്കൊള്ളുന്നു, അവ പരസ്പരം മാറ്റാവുന്നതല്ല. ഒന്ന് ടണൽ വർക്ക്ലോഡിന്റെ സ്വന്തം നെറ്റ്വർക്ക് നെയിംസ്പേസിനുള്ളിൽ ഇടുന്നു. മറ്റൊന്ന് CNI-യോട് തിരഞ്ഞെടുത്ത ട്രാഫിക് നിയുക്ത ഗേറ്റ്വേ നോഡിലൂടെ കടത്തിവിടാൻ ആവശ്യപ്പെടുന്നു. അവ വ്യത്യസ്തമായി പരാജയപ്പെടുന്നു, വ്യത്യസ്തമായി സ്കെയിൽ ചെയ്യുന്നു, വ്യത്യസ്ത ടീമുകൾക്ക് ഉത്തരം നൽകുന്നു, അതിനാൽ കണ്ടെയ്നർ ചോദ്യം സാധാരണയായി ഒരിക്കലും തീരാത്ത തർക്കങ്ങൾ സൃഷ്ടിക്കുന്നു.
Pod-ന്റെ അതിർത്തി ഒരു നെയിംസ്പേസാണ്, ജംപ് ഹോസ്റ്റല്ല
Linux നെറ്റ്വർക്ക് നെയിംസ്പേസ് അതിന്റെ ഇന്റർഫേസുകൾ, വിലാസങ്ങൾ, റൂട്ടുകൾ, ഫയർവാൾ നിയമങ്ങൾ എന്നിവ സ്വന്തമാക്കുന്നു, ഓരോ Pod-നും ഒന്ന് ലഭിക്കുന്നു. ആ Pod-നുള്ളിലെ കണ്ടെയ്നറുകൾ അതിൽ ചേരുന്നു, അതുകൊണ്ടാണ് ഒരു സഹായ കണ്ടെയ്നറിന് ആപ്ലിക്കേഷൻ പിന്നീട് പിന്തുടരുന്ന റൂട്ടുകൾ വീണ്ടും എഴുതാൻ കഴിയുന്നത്. അയൽ Pod-ന് സമാനമായി കാണപ്പെടുന്നതും എന്നാൽ പൂർണ്ണമായും വേറിട്ടതുമായ സ്റ്റാക്ക് ഉണ്ട്. ഗേറ്റ്വേ Pod-ന് പാരമ്പര്യമായി ലഭിക്കാൻ പങ്കിട്ട പട്ടികയില്ല, ഒരു നെയിംസ്പേസിൽ നിന്ന് മറ്റൊന്നിലേക്ക് ട്രാഫിക്കിന്റെ സൂചിത കൈമാറ്റവുമില്ല.
അതുകൊണ്ടാണ് ഗേറ്റ്വേ-Pod മാതൃക ശരിക്കും പ്രവർത്തിക്കുന്നത്, മുകളിൽ നിന്ന് എന്തെങ്കിലും യഥാർത്ഥത്തിൽ അതിന് പാക്കറ്റുകൾ അയയ്ക്കുമ്പോൾ മാത്രം: ഒരു Service, നോഡിലെ സ്റ്റാറ്റിക് റൂട്ട്, അല്ലെങ്കിൽ CNI-യിലെ സ്റ്റിയറിംഗ് നയം. വെറും വിലാസം ഒന്നിനെയും ആകർഷിക്കുന്നില്ല.
ഓരോ Pod-നുമുള്ള ടണൽ എന്ത് നൽകുന്നു, എന്ത് ചെലവാക്കുന്നു
വർക്ക്ലോഡിന്റെ നെയിംസ്പേസിൽ പ്രവർത്തിക്കുന്ന ടണൽ ആ വർക്ക്ലോഡിന് അതിന്റേതായ ക്ലയന്റ് ഐഡന്റിറ്റി നൽകുന്നു, സെഷൻ അനുവദിക്കുന്നതിനോ കണക്കാക്കുന്നതിനോ മുമ്പ് നിരവധി റിമോട്ട് ആക്സസ് സേവനങ്ങൾ അത് ആവശ്യപ്പെടുന്നു. കേടുപാടിന്റെ പരിധിയും പ്രാദേശികമായി തുടരുന്നു: തകർന്ന ടണൽ എല്ലാം ഉപയോഗിക്കുന്ന പങ്കിട്ട പാതയ്ക്ക് പകരം ഒരു Deployment നിർത്തലാക്കുന്നു. അത് എങ്ങനെ പ്രവർത്തിക്കുന്നു എന്നത് നടപ്പാക്കലിനെ ആശ്രയിച്ചിരിക്കുന്നു, ഇവിടെയാണ് ആളുകൾ തെറ്റായി ഊഹിക്കുന്നത്.
കേവലം കെർണൽ അവസ്ഥ മാത്രം ആവശ്യമുള്ള സെറ്റപ്പ് ഒരു init കണ്ടെയ്നറിൽ പൂർത്തിയായി പുറത്തുപോകാം. Pod-ന്റെ മുഴുവൻ ആയുസ്സിലും ജീവനോടെ ഇരിക്കേണ്ട യൂസർസ്പേസ് ഡീമണിന് Kubernetes 1.29-ൽ നേറ്റീവ് സൈഡ്കാർ ആയി അവതരിപ്പിച്ച പുനരാരംഭിക്കാവുന്ന init കണ്ടെയ്നർ രൂപം ആവശ്യമാണ്, ആ വ്യത്യാസം രുചിയിൽ നിന്നല്ല, ടണലിന്റെ നടപ്പാക്കലിൽ നിന്നാണ് വരുന്നത്. ഈ മാതൃകയുടെ ചെലവ് തനിപ്പകർപ്പാണ്: ഓരോ റെപ്ലിക്കയും പ്രാമാണീകരിക്കുന്നു, സ്വന്തം ടണൽ വിലാസം സ്വീകരിക്കുന്നു, ഒരു റിമോട്ട് സെഷൻ സ്ലോട്ട് ഉപയോഗിക്കുന്നു, അതിനാൽ ഓട്ടോസ്കെയിലിംഗ് സംഭവം ലിങ്കിന്റെ മറുവശത്ത് ഒരു ശേഷി സംഭവമായി മാറുന്നു. ഒരു ക്രെഡൻഷ്യൽ എല്ലാ റെപ്ലിക്കകളിലേക്കും പകർത്തുന്നത് ആ ചെലവ് നീക്കുന്നില്ല, അത് ഓഡിറ്റ് ട്രെയിൽ നീക്കുന്നു. അനുമതികളും അതേ പരിശോധന അർഹിക്കുന്നു, കാരണം സ്വന്തം നെയിംസ്പേസിൽ NET_ADMIN ആഗ്രഹിക്കുന്ന ടണലിന് privileged: true ഉദാഹരണത്തിന്റെ മുഴുവൻ ഹോസ്റ്റിന്റെ അധികാരം പാരമ്പര്യമായി സ്വീകരിക്കാൻ കാരണമില്ല.
CNI എഗ്രെസ് സ്വന്തമാക്കുമ്പോൾ
CNI അതിനെ പിന്തുണയ്ക്കുന്നുവെങ്കിൽ, ഒരു എഗ്രെസ് ഗേറ്റ്വേ വർക്ക്ലോഡും ലക്ഷ്യശ്രേണിയും അനുസരിച്ച് ട്രാഫിക് തിരഞ്ഞെടുത്ത്, പിന്നീട് ഒരു പ്രവചനീയ സ്രോതസ്സ് വിലാസത്തിൻ കീഴിൽ തിരഞ്ഞെടുത്ത നോഡുകളിലൂടെ അയയ്ക്കുന്നു. Cilium-ന്റെ പതിപ്പാണ് സാധാരണ റഫറൻസ്, അതിന്റെ ഡോക്യുമെന്റേഷൻ വ്യക്തമായി പറയുന്നത് ഈ സവിശേഷതയ്ക്ക് പ്രത്യേക Cilium കോൺഫിഗറേഷനും ശരിയായ ഇന്റർഫേസുകളും വിലാസങ്ങളും ഉള്ള ഗേറ്റ്വേ നോഡുകളും ആവശ്യമാണ് എന്നാണ്. Pod സൃഷ്ടിച്ചതിന് ശേഷമുള്ള ഒരു പ്രാരംഭ കാലയളവും ഇത് സൂചിപ്പിക്കുന്നു, അപ്പോൾ സ്റ്റിയറിംഗ് ഇനിയും നടപ്പാക്കിയിട്ടില്ല, അത് അടിക്കുറിപ്പല്ല, ഡിസൈൻ ഇൻപുട്ടാണ്.
ആ കാലതാമസം നിങ്ങളുടെ സ്വന്തം വാഗ്ദാനത്തിനെതിരെ വായിക്കുക. മറ്റൊരു വഴിയിലൂടെ ഒരു ട്രാഫിക്കും പുറത്തുപോകരുത് എന്നതാണ് നിയമമെങ്കിൽ, ഇടവേളയിൽ അയയ്ക്കുന്ന പുതിയ Pod അത് ഇതിനകം ലംഘിച്ചിട്ടുണ്ട്, അതിനാൽ സ്റ്റാർട്ടപ്പ് ക്രമത്തിന് സ്വന്തം ഉത്തരം വേണം: നയം പ്രാബല്യത്തിൽ വരുന്നതുവരെ ആപ്ലിക്കേഷൻ പിടിച്ചുവയ്ക്കുക, അല്ലെങ്കിൽ ആ വിൻഡോ സ്വീകരിച്ച് രേഖപ്പെടുത്തുക.
അവകാശവാദം ഇടുങ്ങിയതായി സൂക്ഷിക്കുക. ഒരു എഗ്രെസ് ഗേറ്റ്വേ ഒരു പാത തിരഞ്ഞെടുത്ത് വിവർത്തനം ചെയ്യുന്നു. അത് ഒരു VPN അവസാനിപ്പിക്കുന്നില്ല, അതിന് പിന്നിൽ പിന്തുണയ്ക്കുന്ന ഒരു കണക്ഷൻ ഇല്ലാതെ ക്ലസ്റ്ററിനെ നിങ്ങളുടെ റിമോട്ട് നെറ്റ്വർക്കിന്റെ ക്ലയന്റാക്കുന്നുമില്ല.
| Question | Per-Pod tunnel | CNI egress gateway |
|---|---|---|
| Who holds the client identity | Each workload | The gateway, shared |
| What scaling changes | Enrollment and sessions per replica | Throughput and capacity per node |
| What the remote side sees | Distinct addresses | One translated source |
| Failure scope | One Deployment | Every workload behind the gateway |
വിവർത്തനം റിമോട്ട് വശം കാണുന്നത് നിശബ്ദമായി മാറ്റുന്നു
ഗേറ്റ്വേ സ്രോതസ്സ് വീണ്ടും എഴുതിയാൽ ഓരോ Pod-ന്റെയും വിലാസങ്ങൾ ഇല്ലാതാകുന്നു, അതിനാൽ ഐഡന്റിറ്റിയെ അടിസ്ഥാനമാക്കിയുള്ള അനുവദനീയ ലിസ്റ്റ് ഒരു പങ്കിട്ട വിലാസത്തെ അടിസ്ഥാനമാക്കിയുള്ള ലിസ്റ്റായി മാറുന്നു. ഇത് ഒരു വിനിമയമാണ്, വീഴ്ചയല്ല: പരിപാലിക്കാൻ കുറച്ച് നിയമങ്ങൾ, എന്തെങ്കിലും മോശമായി പെരുമാറുമ്പോൾ പരുക്കൻ ആരോപണം.
ആപ്ലിക്കേഷൻ തലത്തിലുള്ള പ്രാമാണീകരണവും അഭ്യർത്ഥന ലോഗിംഗും നെറ്റ്വർക്ക് ഇനി റിപ്പോർട്ട് ചെയ്യാത്തത് വഹിക്കണം. ഗേറ്റ്വേയുടെ ശേഷിയും മാറ്റിസ്ഥാപിക്കലും പങ്കിട്ട അടിസ്ഥാന സൗകര്യമായി കാണുക, കാരണം ഒരു നോഡിന്റെ റീബൂട്ട് ഇപ്പോൾ അതിന് പിന്നിലുള്ള എല്ലാ വർക്ക്ലോഡുകളെയും തടസ്സപ്പെടുത്തുന്നു, മടക്കപ്പാത നേരത്തെ പരിശോധിക്കുക: വിവർത്തനം ചെയ്ത വിലാസത്തിൽ എങ്ങനെ എത്താമെന്ന് റിമോട്ട് അറ്റം അറിയണം, സാധാരണയായി മാനിഫെസ്റ്റല്ല, ഒരു മനുഷ്യൻ സ്വന്തമാക്കേണ്ട ഒരു റൂട്ട് അല്ലെങ്കിൽ NAT വഴി. വിലാസ പ്ലാനിംഗും ഇവിടെയുണ്ട്, കാരണം ഓവർലാപ്പ് ചെയ്യുന്ന ക്ലസ്റ്റർ, റിമോട്ട് ശ്രേണികൾ രണ്ട് മാതൃകകളെയും തകർക്കുന്നു, IPv6 സ്വീകരിക്കുന്നത് വൈരുദ്ധ്യമുള്ള ഒരു പ്ലാനിന് ന്യായീകരണമല്ല.
സ്വന്തം അവകാശത്താൽ തീരുമാനിക്കുക, പിന്നീട് വാഗ്ദാനം ചെയ്ത പരാജയം പരീക്ഷിക്കുക
റിമോട്ട് സേവനം വ്യക്തിഗത വർക്ക്ലോഡുകളെ പ്രാമാണീകരിക്കുമ്പോൾ, കുറച്ച് Deployment-കൾക്ക് മാത്രം ലിങ്ക് ആവശ്യമുള്ളപ്പോൾ, പരാജയം പ്രാദേശികമായി തുടരേണ്ടപ്പോൾ ഓരോ Pod-നുമുള്ള ടണൽ തിരഞ്ഞെടുക്കുക. ഒരു നെറ്റ്വർക്ക് ടീം ഇതിനകം പാത സ്വന്തമാക്കുമ്പോൾ, നിരവധി വർക്ക്ലോഡുകൾ ഒരു ലക്ഷ്യം പങ്കിടുമ്പോൾ, സ്ഥിരമായ സ്രോതസ്സ് വിലാസം മുഴുവൻ അഭ്യാസത്തിന്റെ ലക്ഷ്യമാകുമ്പോൾ ഗേറ്റ്വേ തിരഞ്ഞെടുക്കുക.
ഏതായാലും, സ്ഥിരമായ അവസ്ഥയല്ല, നിങ്ങൾ വിറ്റ സ്വഭാവം പരിശോധിക്കുക. ഒരു Pod സൃഷ്ടിക്കുക, അതിനെ ഉടൻ അയയ്ക്കാൻ അനുവദിക്കുക, ടണലിൽ നിന്ന് ഒന്നും രക്ഷപ്പെടുന്നില്ല എന്നതായിരുന്നു വാഗ്ദാനമെങ്കിൽ ആദ്യ സെക്കൻഡുകൾ നിരീക്ഷിക്കുക. അഞ്ച് റെപ്ലിക്കകളിലേക്ക് സ്കെയിൽ ചെയ്യുക, വാഗ്ദാനം ഓരോ വർക്ക്ലോഡിനുമുള്ള ഐഡന്റിറ്റി ആയിരുന്നുവെങ്കിൽ റിമോട്ട് അറ്റം റിപ്പോർട്ട് ചെയ്യുന്ന സെഷനുകൾ എണ്ണുക. ഈ രണ്ട് പരിശോധനകൾ മാനിഫെസ്റ്റ് അവലോകനത്തേക്കാൾ വളരെ വേഗം സംവിധാനത്തിന്റെ പരിധികൾ വെളിപ്പെടുത്തുന്നു, അടുത്ത സംഭവം ഏത് ടീമിന്റേതാണെന്ന് അവ പറയുന്നു.