1.14-ന് ശേഷം GKE പോഡുകൾക്ക് VPN ആക്സസ് നഷ്ടമായി: ഉറവിടം ശരിയാക്കാനുള്ള രണ്ട് വഴികൾ

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

രണ്ട് സാധുവായ ഉത്തരങ്ങളുണ്ട്, അവ വെവ്വേറെ സ്ഥലങ്ങളിലേക്ക് നയിക്കുന്നു. ConfigMap തിരുത്തുന്നതിന് മുമ്പ് ഉറവിട കരാർ തിരഞ്ഞെടുക്കുക.

ഇൻസ്റ്റാൾ ചെയ്യുന്നത് നിർത്തിയ ഡിഫോൾട്ട് നിയമം

പഴയ GKE പതിപ്പുകൾ masquerade നിയമം ഇൻസ്റ്റാൾ ചെയ്തിരുന്നു, അത് ലക്ഷ്യം 10.0.0.0/8-ന് പുറത്തായിരിക്കുമ്പോൾ പോഡ് ഉറവിടങ്ങളെ നോഡ് വിലാസം കൊണ്ട് മാറ്റിസ്ഥാപിച്ചിരുന്നു. ആ പരിധിക്കുള്ളിലെ VPN ഗേറ്റ്വേ പോഡ് വിലാസം കണ്ടു, അതിൽനിന്ന് അകലെയുള്ളതെല്ലാം നോഡിൽനിന്ന് വന്നതുപോലെ തോന്നി. പിയർമാർ നോഡ് വിലാസങ്ങൾക്ക് ചുറ്റും അനുമതി പട്ടികകളും തിരിച്ചുള്ള റൂട്ടുകളും നിർമ്മിച്ചു, കാരണം അവർ നിരീക്ഷിച്ചത് അതാണ്.

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

ചത്ത ഘടകം എന്ന അർത്ഥത്തിൽ ഒന്നും തകർന്നിട്ടില്ല. ഏത് ഉറവിടമാണ് നിയമാനുസൃതം എന്നതിൽ ഇരു ഭാഗവും യോജിക്കുന്നില്ല എന്നു മാത്രം.

പിയർ കാണേണ്ട ഉറവിടം തിരഞ്ഞെടുക്കുക

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

നോഡ് വിലാസങ്ങൾ നിലനിർത്തുന്നതാണ് കുറഞ്ഞ ചെലവുള്ള കരാർ. ആ ലക്ഷ്യത്തിന് masquerade വീണ്ടും ഓണാക്കുക, പിയർ ഇതിനകം വിശ്വസിക്കുന്ന വിലാസം കാണുന്നത് തുടരും.

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

മൂന്നാമത്തെ ഓപ്ഷൻ സാധാരണയായി തെറ്റാണ്: എല്ലാം masquerade ചെയ്ത് ട്രാഫിക് ആരോപിക്കാനുള്ള കഴിവ് നഷ്ടപ്പെടുത്തുന്നത്. പിയറിന് നോഡ് വിലാസങ്ങളല്ലാതെ മറ്റൊന്നും റൂട്ട് ചെയ്യാൻ കഴിയില്ലെങ്കിൽ മാത്രം ഇത് ഒഴിവാക്കുക.

nonMasqueradeCIDRs യഥാർത്ഥ പരിധികളിലേക്ക് നയിക്കുക

GKE kube-system-ൽ ip-masq-agent പ്രവർത്തിപ്പിക്കുന്നു, അതിന്റെ ConfigMap masquerade ഒഴിവാക്കുന്ന ലക്ഷ്യങ്ങൾ പട്ടികപ്പെടുത്തുന്നു. ടണലിലേക്കുള്ള പോഡ് ഉറവിടങ്ങൾ സംരക്ഷിക്കാൻ പോഡ് പരിധി, നോഡ് സബ്നെറ്റ്, പ്രാദേശിക പ്രിഫിക്സ് എന്നിവയെല്ലാം ആ പട്ടികയിൽ വരുന്നു.

മാതൃകാ മൂല്യങ്ങൾ നിങ്ങളുടെ സ്വന്തം ക്ലസ്റ്ററിലെ പരിധികൾ കൊണ്ട് മാറ്റുക. ആവശ്യത്തിലധികം പട്ടിക വിശാലമാക്കരുത്, കാരണം ഓരോ അധിക എൻട്രിയും മറ്റൊരു ലക്ഷ്യം കാണുന്നത് മാറ്റുന്നു. താഴെയുള്ള മൂന്ന് എൻട്രികൾ പോഡ് നെറ്റ്വർക്ക്, നോഡ് സബ്നെറ്റ്, ടണലിന് പിന്നിലെ പ്രിഫിക്സ് എന്നിവയെ പ്രതിനിധീകരിക്കുന്നു:

nonMasqueradeCIDRs:
  - 10.12.0.0/14
  - 10.100.0.0/16
  - 172.16.0.0/12
masqLinkLocal: false
resyncInterval: 60s

0.0.0.0/0 എന്ന എൻട്രി എല്ലാ ലക്ഷ്യങ്ങൾക്കും masquerade പ്രവർത്തനരഹിതമാക്കുന്നു, ഇത് ബന്ധമില്ലാത്ത വർക്ലോഡുകൾ പുറം സേവനങ്ങൾക്ക് എങ്ങനെ കാണപ്പെടുന്നു എന്നത് മാറ്റുന്നു, അപൂർവമായി മാത്രമേ ഉദ്ദേശിക്കപ്പെടുന്നുള്ളൂ. ഏജന്റ് resyncInterval-ൽ അതിന്റെ കോൺഫിഗറേഷൻ വീണ്ടും വായിക്കുന്നു, അതിനാൽ പുനരാരംഭിക്കേണ്ടതില്ല. ഏജന്റ് പോഡ് പ്രവർത്തിക്കുന്നുണ്ടെന്ന് പരിശോധിച്ച്, അതിനുള്ളിൽ മൗണ്ട് ചെയ്ത ഫയൽ തുറക്കുക. ആ ഫയൽ വായിക്കുന്നതാണ് മാറ്റം എത്തിയെന്ന് തെളിയിക്കുന്നത്.

മറുപടി പാതയാണ് മറ്റേ പകുതി

masquerade അഭ്യർത്ഥനയുടെ ഉറവിടം മാറ്റുന്നു, മറ്റൊന്നുമല്ല. പിയറിന് ഏത് ഉറവിടം ലഭിച്ചാലും അതിലേക്ക് തിരികെ ഒരു റൂട്ട് ഇപ്പോഴും വേണം, ക്ലസ്റ്ററിന് പിയറിലേക്ക് ഒരു റൂട്ടും ഇപ്പോഴും വേണം.

VPN ഗേറ്റ്വേയിലെ ക്യാപ്ചർ രണ്ട് പരാജയങ്ങളെ വേഗം വേർതിരിക്കുന്നു. പോഡ് വിലാസങ്ങളുമായി എത്തി ഒരിക്കലും മറുപടി ലഭിക്കാത്ത പാക്കറ്റുകൾ എന്നാൽ പിയറിന് പോഡ് പ്രിഫിക്സിന് റൂട്ട് ഇല്ല. ഗേറ്റ്വേയിൽ പ്രത്യക്ഷപ്പെട്ട് ക്ലസ്റ്ററിൽ എത്താത്ത മറുപടി എന്നാൽ പ്രാദേശിക റൂട്ട് കാണുന്നില്ല. ഏതായാലും കരാർ ടിക്കറ്റിൽ എഴുതുക: പിയർ ഏത് ഉറവിടം കാണുന്നു, ഏത് പ്രിഫിക്സിലേക്ക് തിരികെ റൂട്ട് ചെയ്യുന്നു.

ഓരോ അപ്ഗ്രേഡിന് ശേഷവും വീണ്ടും പരിശോധിക്കുക

masquerade-ന്റെ ഡിഫോൾട്ട് സ്വഭാവം ഇതിനകം ഒരിക്കൽ മാറിയിട്ടുണ്ട്, നോഡ് പൂൾ മാറ്റിസ്ഥാപിക്കുന്നത് ക്ലസ്റ്റർ നെറ്റ്വർക്കിംഗ് പുനഃസജ്ജമാക്കിയേക്കാം. ഉറവിട കരാറിനെ ഊഹിക്കാനുള്ളതല്ല, പരിശോധിക്കാനുള്ളതായി കണക്കാക്കുക.

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