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 කෝරමයට නොවේ.

වැඩ කරන කවුළුවක ග්‍රහණය තබා ගන්න, මන්ද එය කැඩුණු එක සමඟ සංසන්දනය කිරීම වින්‍යාසය නැවත කියවීමට වඩා වේගවත්ය.