VPN-ൽ Docker Swarm: ടാസ്ക്കുകൾ പ്രവർത്തിക്കുന്നു, സേവന കോളുകൾ പരാജയപ്പെടുന്നു

രണ്ട് സൈറ്റുകളിലായി മൂന്ന് മാനേജർമാരും അഞ്ച് വർക്കർമാരും, ഒരു ടണലിലൂടെ ബന്ധിപ്പിച്ചിരിക്കുന്നു, docker service ls രണ്ട് വശങ്ങളിലും പ്രവർത്തിക്കുന്ന ടാസ്ക്കുകൾ കാണിക്കുന്നു, അതേസമയം സേവനങ്ങൾ തമ്മിലുള്ള കോളുകൾ സമയം കഴിയുന്നു. Swarm ലോഗുകളിൽ ഒന്നും തെറ്റായി തോന്നുന്നില്ല. ഈ സംയോജനം ഡാറ്റ പ്ലെയിൻ പ്രശ്നത്തിന്റെ അടയാളമാണ്: കൺട്രോൾ പ്ലെയിൻ നോഡുകളെ കണ്ടെത്തി, എൻകാപ്സുലേറ്റ് ചെയ്ത ഫ്രെയിമുകൾ യാത്ര പൂർത്തിയാക്കിയില്ല.

overlay-ക്ക് മുമ്പ് mesh ഉണ്ടായിരിക്കണം

Swarm-ന്റെ overlay എൻകാപ്സുലേറ്റ് ചെയ്ത ഫ്രെയിമുകൾ നോഡ് വിലാസങ്ങൾക്കിടയിൽ നേരിട്ട് തള്ളുന്നു, അതായത് ഓരോ നോഡിനും മറ്റേതൊരു നോഡും വിവർത്തനമില്ലാതെ എത്താവുന്ന ഒരു വിലാസം ടണൽ നൽകുന്ന ഇന്റർഫേസിൽ വേണം. ക്ലയന്റുകളെ പ്രസിദ്ധീകരിച്ച പോർട്ടിലേക്ക് മാത്രം കൊണ്ടുപോകുന്ന ടണൽ മതിയാകില്ല. അടിസ്ഥാന പാളി രണ്ട് ദിശകളിലും നോഡിൽ നിന്ന് നോഡിലേക്ക് റൂട്ട് ചെയ്യണം.

Swarm-നെ സ്പർശിക്കുന്നതിന് മുമ്പ് ഇത് പരീക്ഷിക്കുക. ഓരോ നോഡിൽ നിന്നും പങ്കാളിയുടെ ടണൽ വിലാസത്തിലേക്കുള്ള റൂട്ട് പരിശോധിച്ച്, ping ചെയ്ത്, പിന്നീട് കൺട്രോൾ പോർട്ട് പരീക്ഷിക്കുക. ping പ്രവർത്തിച്ച് പോർട്ട് പ്രവർത്തിക്കുന്നില്ലെങ്കിൽ, ടണൽ കുഴപ്പമില്ല, ഒരു ഫിൽട്ടർ വഴിയിൽ ഉണ്ട്.

ip -brief address
ip route get 10.20.0.12
ping -c3 10.20.0.12
nc -vz 10.20.0.12 2377

റൂട്ട് tun0 അല്ലെങ്കിൽ wg0-ന് പകരം ഭൗതിക ഇന്റർഫേസിലേക്ക് ചൂണ്ടുന്നുവെങ്കിൽ, overlay വിദൂര സൈറ്റിന് എത്താനാകാത്ത ഒരു വിലാസത്തിലേക്ക് എൻകാപ്സുലേറ്റ് ചെയ്യും, ലക്ഷണം പാക്കറ്റ് നഷ്ടം പോലെ തോന്നും.

ഓരോ നോഡും ഏത് വിലാസമാണ് പ്രഖ്യാപിക്കുന്നതെന്ന് പരിശോധിക്കുക

ഡീമൺ ഒരു വിലാസം പ്രഖ്യാപിക്കുന്നു, പങ്കാളികൾ അത് ഡാറ്റ പ്ലെയിനിന് ഉപയോഗിക്കുന്നു. പല നെറ്റ്വർക്കുകളുള്ള ഹോസ്റ്റിൽ ടണൽ മറ്റെന്തോ വഹിക്കുമ്പോൾ LAN അല്ലെങ്കിൽ പൊതു വിലാസം പ്രഖ്യാപിക്കാൻ എളുപ്പമാണ്. അനുമാനിക്കുന്നതിന് പകരം അത് പരിശോധിക്കുക, സ്ഥിരസ്ഥിതി തെറ്റാണെങ്കിൽ ചേരുമ്പോൾ --advertise-addr ഉപയോഗിച്ച് അത് പിൻ ചെയ്യുക. തനിക്ക് മാത്രം എത്താവുന്ന വിലാസം പ്രഖ്യാപിക്കുന്ന നോഡും swarm-ൽ ചേരും, പരാജയം പിന്നീട് സൈറ്റുകൾക്കിടയിൽ സംസാരിക്കാനാകാത്ത സേവനങ്ങളായി പ്രത്യക്ഷപ്പെടും.

പ്രഖ്യാപിച്ച വിലാസം പിന്നീട് മാറ്റുന്നത് കോൺഫിഗ് എഡിറ്റല്ല, കാരണം നോഡ് പുറത്തുപോയി വീണ്ടും ചേരണം.

ഓരോ നോഡിന്റെയും പ്രഖ്യാപിത വിലാസം നിങ്ങളുടെ കുറിപ്പുകളിൽ രേഖപ്പെടുത്തുക, കാരണം അത് മിക്ക അസമമായ പരാജയങ്ങളും വിശദീകരിക്കുന്നു.

Masquerade ആണ് സാധാരണ കുറ്റവാളി

നോഡുകൾക്കും ടണലിനും ഇടയിൽ ഒരു ഗേറ്റ്‌വേ ഇരിക്കുമ്പോൾ, ഭൗതിക ഇന്റർഫേസിൽ നിന്ന് പുറത്തുപോകുന്ന എല്ലാത്തിനും masquerade പ്രയോഗിക്കുകയെന്നതാണ് സാധാരണ തെറ്റ്. അത് overlay-ന്റെ ആന്തരിക വിലാസങ്ങളും വീണ്ടും എഴുതുന്നു, അതിനാൽ ഓരോ പങ്കാളിയും ഗേറ്റ്‌വേയിൽ നിന്ന് വരുന്നതായി തോന്നുന്നു, VXLAN പങ്കാളികൾ പരസ്പരം തിരിച്ചറിയുന്നത് നിർത്തുന്നു. ഫലം സാധാരണ ping പ്രവർത്തിക്കുമ്പോൾ നഷ്ടപ്പെട്ടതോ ഏകദിശയിലുള്ളതോ ആയ എൻകാപ്സുലേറ്റ് ചെയ്ത ട്രാഫിക്കാണ്.

overlay-ന്റെ പ്രിഫിക്സ് ഗേറ്റ്‌വേയിലൂടെ റൂട്ട് ചെയ്ത് വിവർത്തനം ചെയ്യാതെ വയ്ക്കുക. മറ്റൊരു പ്രിഫിക്സിന് വിവർത്തനം ശരിക്കും ആവശ്യമെങ്കിൽ, അത് അവിടെ മാത്രം പരിമിതപ്പെടുത്തുക, overlay ഉപയോഗിക്കുന്ന ശ്രേണിയിൽ ഒരിക്കലും അല്ല.

ip route add 172.16.0.0/22 via 10.20.0.1
iptables -t nat -I POSTROUTING -o tun0 -s 172.16.0.0/22 -j ACCEPT

നിയമങ്ങളുടെ ക്രമവും പാഠവും പരിശോധിക്കുക, കാരണം ചങ്ങലയിൽ നേരത്തെയുള്ള വിശാലമായ MASQUERADE പിന്നീടുള്ള ഇടുങ്ങിയ ഒഴിവാക്കലിനെ തോൽപ്പിക്കുന്നു.

VXLAN-ന് പാക്കറ്റിൽ ഇടം വേണം

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

docker network create --driver overlay --attachable --opt com.docker.network.driver.mtu=1400 swarm-overlay

ingress നെറ്റ്വർക്ക് സ്വയമേവ സൃഷ്ടിക്കപ്പെടുന്നു, അതിനാൽ അത് മാറ്റുകയെന്നാൽ സ്ഥലത്തുതന്നെ എഡിറ്റ് ചെയ്യുകയല്ല, നീക്കം ചെയ്ത് വീണ്ടും സൃഷ്ടിക്കുകയാണ്.

ടണലിന്റെ ഒരു വശം മാത്രം ശരിയാക്കിയാൽ, ചെറിയ MTU തന്നെയാണ് പ്രധാനം.

ലോഗുകളല്ല, ഡാറ്റ പ്ലെയിൻ നിരീക്ഷിക്കുക

ഇരു അറ്റങ്ങളിലും VXLAN പോർട്ട് ക്യാപ്ചർ ചെയ്യുക. ഒരു വശത്തുനിന്ന് പുറപ്പെട്ട് മറുവശത്ത് എത്തുന്ന ഫ്രെയിമുകൾ അടിസ്ഥാന പാളി കുഴപ്പമില്ലെന്നും പ്രശ്നം overlay-നുള്ളിലാണെന്നും അർഥം. പുറപ്പെട്ട് ഒരിക്കലും എത്താത്ത ഫ്രെയിമുകൾ റൂട്ട് അല്ലെങ്കിൽ ഫിൽട്ടർ എന്നർഥം. ഒട്ടും പുറപ്പെടാത്ത ഫ്രെയിമുകൾ ഉറവിട വിലാസം തെറ്റാണെന്നർഥം.

കുറച്ച് സെക്കൻഡുകൾക്ക് ശേഷം മാറുന്ന സേവന കണ്ടെത്തൽ പരാജയങ്ങൾ സാധാരണയായി പാക്കറ്റ് ബജറ്റിലേക്കോ അസ്ഥിരമായ വഴിയിലേക്കോ ആണ് വിരൽ ചൂണ്ടുന്നത്, raft ക്വാറത്തിലേക്കല്ല.

പ്രവർത്തിക്കുന്ന ഒരു സമയത്തിലെ ക്യാപ്ചർ സൂക്ഷിക്കുക, കാരണം അത് തകർന്നതുമായി താരതമ്യം ചെയ്യുന്നത് കോൺഫിഗ് വീണ്ടും വായിക്കുന്നതിനേക്കാൾ വേഗമാണ്.