GKE പോഡുകൾക്ക് VPN വഴി ഓൺ-പ്രെം ഹോസ്റ്റുകളിൽ എത്താൻ കഴിയാത്തതിന്റെ കാരണം

നോഡിൽ നിന്ന് പിംഗ് പ്രവർത്തിക്കുന്നു, പോഡിൽ നിന്ന് പരാജയപ്പെടുന്നു, ഓൺ-പ്രെമിൽ ഒന്നും എത്തുന്നില്ല. ടണലും റൂട്ടും കുഴപ്പമില്ല; വയറിലെ സ്രോതസ്സ് വിലാസമല്ല. ഈ രണ്ട് സാഹചര്യങ്ങളുടെ വ്യത്യാസം, ക്ലസ്റ്റർ വിടുമ്പോൾ പാക്കറ്റ് താൻ എന്താണെന്ന് അവകാശപ്പെടുന്നു എന്നതാണ്, ഇതിനെക്കുറിച്ച് GKE-യ്ക്ക് അഭിപ്രായമുണ്ട്. സംവിധാനം masquerade ഒഴിവുകളുടെ പട്ടികയാണ്, അത് വായിക്കാൻ ഒരു കമാൻഡ് മതി.

എന്തെങ്കിലും മാറ്റുന്നതിന് മുൻപ് പ്രാബല്യത്തിലുള്ള പട്ടിക വായിക്കുക

ഓരോ ലക്ഷ്യ ശ്രേണിക്കും പോഡ് ട്രാഫിക് പുറത്തുപോകുമ്പോൾ നോഡ് വിലാസത്തിലേക്ക് മാറ്റിയെഴുതണോ എന്ന് തീരുമാനിക്കുന്ന ഒരു ഏജന്റ് GKE നൽകുന്നു. അതിന്റെ സ്ഥാപിത കോൺഫിഗറേഷൻ മൂന്ന് RFC1918 ബ്ലോക്കുകളെ, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, ഒഴിവാക്കപ്പെട്ട ലക്ഷ്യങ്ങളായി പേരിടുന്നു. അതിനാൽ പോഡിൽ നിന്ന് പ്രാദേശിക 10.x ഹോസ്റ്റിലേക്ക് അയക്കുന്നതെല്ലാം പോഡിന്റെ സ്വന്തം വിലാസം ഇപ്പോഴും ചേർത്തുനിർത്തിയാണ് നോഡ് വിടുന്നത്. നോഡിന്റെ സ്വന്തം ട്രാഫിക് മാറ്റിയെഴുതുന്നില്ല, അതുകൊണ്ടുതന്നെ അതിന്റെ പിംഗ് പ്രവർത്തിക്കുന്നു.

ഉദ്ദേശിച്ച കോൺഫിഗറേഷനും ഇൻസ്റ്റാൾ ചെയ്ത നിയമങ്ങളും വായിക്കുക, അവ യോജിച്ചില്ലെന്നിരിക്കാം. kubectl -n kube-system get configmap ip-masq-agent -o yaml ഏജന്റിനോട് എന്ത് പറഞ്ഞു എന്ന് കാണിക്കുന്നു, kubectl -n kube-system get pods -l k8s-app=ip-masq-agent അത് പ്രയോഗിക്കാൻ എന്തെങ്കിലും ഓടുന്നുണ്ടോ എന്ന് കാണിക്കുന്നു. നോഡിൽ iptables-save | grep -i masq കേർണലിൽ യഥാർത്ഥത്തിൽ ഉള്ള നിയമങ്ങൾ കാണിക്കുന്നു. ConfigMap ഒന്ന് പറയുകയും നിയമങ്ങൾ മറ്റൊന്ന് പറയുകയും ചെയ്താൽ, സംശയിക്കേണ്ടത് നെറ്റ്വർക്കത്തെയല്ല, ഏജന്റിനെയാണ്.

ക്യാപ്ചർ ഉപയോഗിച്ച് സ്രോതസ്സ് വിലാസം സ്ഥിരീകരിക്കുക

പട്ടിക മാറ്റുന്നതിന് മുൻപ് ഒരു ക്യാപ്ചർ എടുക്കുക. ഒരു ലക്ഷ്യത്തിൽ മാത്രം ഫിൽട്ടർ ചെയ്താൽ ഔട്ട്പുട്ട് വായിക്കാവുന്നതായിരിക്കും: tcpdump -ni any host 10.20.30.40.

അതിനെ എതിർവശം റിപ്പോർട്ട് ചെയ്യുന്നതുമായി താരതമ്യം ചെയ്യുക. ഓൺ-പ്രെമിൽ പോഡിന്റെ വിലാസം കാണിച്ച് മറുപടിയില്ലാത്ത ക്യാപ്ചർ വൃത്തം അടയ്ക്കുന്നു: ടണലിന്റെ യാതൊരു തകരാറുമില്ലാതെ ഒഴിവുപട്ടിക അസമത്വം വിശദീകരിക്കുന്നു. ഒരു സ്രോതസ്സ് വിലാസത്തിന്റെ രണ്ട് നിരീക്ഷണങ്ങൾ CNI-യെക്കുറിച്ചുള്ള ഊഹം നിർത്താൻ മതി.

ഒഴിവ് പോഡ് CIDR-ലേക്ക് ചുരുക്കുക

പിന്തുണയ്ക്കുന്ന പരിഹാരം ഒഴിവ് നീക്കം ചെയ്യുന്നതിനുപകരം ചുരുക്കുന്നു: പോഡ് CIDR ഒഴിവായി നിലനിർത്തി 10.x സ്ഥലത്തിന്റെ ബാക്കി ഒഴിവാക്കുക. ആ പട്ടിക ഏജന്റിന്റെ ConfigMap-ൽ nonMasqueradeCIDRs-ന് കീഴിൽ കിടക്കുന്നു, അത് മാറ്റുന്നത് ഒരു തിരുത്തലും തുടർന്ന് ഒരു റോൾഔട്ടുമാണ്. വിശാലമായ എൻട്രി ക്ലസ്റ്ററിന്റെ യഥാർത്ഥ പോഡ് ശ്രേണി കൊണ്ട് മാറ്റുക, ക്ലസ്റ്ററിനുള്ളിലെ ട്രാഫിക്കിന് ഇപ്പോഴും ആവശ്യമെങ്കിൽ മറ്റ് സ്വകാര്യ ബ്ലോക്കുകൾ നിലനിർത്തുക, കാരണമില്ലെങ്കിൽ resyncInterval അതേപടി വിടുക. പ്രയോഗിക്കുക, ഏജന്റ് പോഡുകൾ പുനരാരംഭിച്ചതും കേർണൽ നിയമങ്ങൾ മാറിയതും സ്ഥിരീകരിക്കുക.

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

പല നോഡ് പൂളുകളുള്ള ക്ലസ്റ്ററിൽ, ബാധിക്കപ്പെട്ട പോഡുകൾ യഥാർത്ഥത്തിൽ ഓടുന്ന നോഡുകളിൽ ഏജന്റ് ഷെഡ്യൂൾ ചെയ്തിട്ടുണ്ടോ എന്ന് പരിശോധിക്കുക. DaemonSet ഇല്ലാത്ത പൂൾ അതിന്റെ പഴയ നിയമങ്ങൾ നിലനിർത്തുന്നു, ConfigMap-ൽ അത് കാണിക്കുന്ന ഒന്നുമുണ്ടാവില്ല.

ബദലും അതിന്റെ ചെലവും

മറ്റൊരു ഓപ്ഷൻ പോഡ് വിലാസങ്ങൾ അസ്പൃശ്യമായി നിർത്തി പാതയെ അവയെക്കുറിച്ച് പഠിപ്പിക്കുന്നു. പോഡ് CIDR Cloud VPN ട്രാഫിക് സെലക്ടറുകളിലേക്ക് പോകുന്നു, മറുപടികൾക്ക് എങ്ങോട്ട് പോകണമെന്ന് അറിയാൻ പ്രാദേശിക വശത്തിന് അതിന് ഒരു തിരിച്ചുപോക്ക് റൂട്ട് വേണം. ഇത് ചില സുരക്ഷാ മാതൃകകൾ ആഗ്രഹിക്കുന്ന പോഡ് ഐഡന്റിറ്റി സംരക്ഷിക്കുന്നു, കൂടാതെ എതിർവശം സ്വീകരിക്കേണ്ട റൂട്ടിംഗ്, ഫയർവാൾ പരിധികൾ രണ്ടും വിശാലമാക്കുന്നു.

വ്യാപാരം വായനക്ഷമതയും പരിധിയും തമ്മിലാണ്. വിവർത്തനം പ്രാദേശിക വശത്തിന് ഓരോ നോഡിനും ഒരു വിലാസം കാണിക്കുന്നു, അത് അനുമതി പട്ടികയിൽ ചേർക്കാൻ എളുപ്പവും ഏത് പോഡ് എന്ത് അയച്ചു എന്നത് മറയ്ക്കുന്നതുമാണ്. വിവർത്തനമില്ലെങ്കിൽ പോഡ് വിലാസം അറ്റം മുതൽ അറ്റം വരെ നിലനിൽക്കുന്നു, അത് ആരോപണത്തിന് നല്ലതും പുതിയ ശ്രേണി പഠിക്കേണ്ട പാതയിലെ ഓരോ ഉപകരണത്തിനും മോശവുമാണ്. രണ്ട് ഓപ്ഷനുകളും Docker അല്ലെങ്കിൽ CNI കുറ്റമല്ല; രണ്ടും പ്രവർത്തന ബിൽ ഉള്ള റൂട്ടിംഗ് തീരുമാനങ്ങളാണ്. നിങ്ങളുടെ ടീമിന് അടയ്ക്കാൻ കഴിയുന്ന ബിൽ ഉള്ളത് തിരഞ്ഞെടുത്ത് എന്തുകൊണ്ടെന്ന് എഴുതുക.

പരിശോധിച്ച് പിൻവലിക്കുക

അതേ ക്യാപ്ചർ വീണ്ടും ഓടിക്കുക. നിങ്ങളുടെ തിരുത്തലിന് ശേഷവും നോഡ് തലത്തിലുള്ള ക്യാപ്ചർ പോഡ് വിലാസം അച്ചടിക്കുന്നെങ്കിൽ, ConfigMap എന്ത് പറഞ്ഞാലും നിയമങ്ങൾ ഒരിക്കലും മാറിയിട്ടില്ല എന്നാണ് അർത്ഥം. വയറാണ് വസ്തുത; ബാക്കിയെല്ലാം അനുമാനമാണ്.

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

പിൻവലിക്കൽ എന്നത് മുൻപത്തെ ConfigMap, അതേ രീതിയിൽ പ്രയോഗിച്ച്, ഏജന്റ് പുനരാരംഭിച്ചു എന്നതിന്റെയും നിയമങ്ങൾ മാറി എന്നതിന്റെയും അതേ സ്ഥിരീകരണത്തോടെയാണ്. മാറ്റരേഖയിൽ ഒരു അറിയപ്പെടുന്ന അഭ്യർത്ഥനയുടെ മുൻപും ശേഷവുമുള്ള സ്രോതസ്സ് വിലാസം സൂക്ഷിക്കുക, കാരണം ആ ഒരു വരി മാത്രമാണ് മാറ്റം നിങ്ങൾ പറഞ്ഞത് ചെയ്തു എന്ന് തെളിയിക്കുന്നത്. GKE IP masquerade ഏജന്റ് ഗൈഡ് സ്ഥിരസ്ഥിതികളും ConfigMap ഫീൽഡുകളും രേഖപ്പെടുത്തുന്നു. റോൾഔട്ടിന് ശേഷം സ്രോതസ്സ് വിലാസം മാറിയിട്ടില്ലെങ്കിൽ, ആ നോഡിൽ ഏജന്റ് ഓടുന്നില്ല, എത്ര YAML തിരുത്തിയാലും അത് ശരിയാകില്ല.