MetalLB-യ്‌ക്കായി റൂട്ടിംഗ് സജ്ജീകരിക്കുക എന്ന അസാധാരണമായ ഒരു ജോലി ഞാൻ വളരെക്കാലം മുമ്പ് അഭിമുഖീകരിച്ചു. എല്ലാം ശരിയാകും, കാരണം ... സാധാരണയായി MetalLB-ന് അധിക പ്രവർത്തനങ്ങളൊന്നും ആവശ്യമില്ല, എന്നാൽ ഞങ്ങളുടെ കാര്യത്തിൽ വളരെ ലളിതമായ ഒരു നെറ്റ്‌വർക്ക് കോൺഫിഗറേഷനുള്ള സാമാന്യം വലിയ ഒരു ക്ലസ്റ്റർ ഉണ്ട്.

നിങ്ങളുടെ ക്ലസ്റ്ററിന്റെ ബാഹ്യ നെറ്റ്‌വർക്കിനായി സോഴ്‌സ് അധിഷ്‌ഠിതവും പോളിസി അധിഷ്‌ഠിതവുമായ റൂട്ടിംഗ് എങ്ങനെ കോൺഫിഗർ ചെയ്യാമെന്ന് ഈ ലേഖനത്തിൽ ഞാൻ നിങ്ങളോട് പറയും.

MetalLB ഇൻസ്റ്റാൾ ചെയ്യുന്നതിനെക്കുറിച്ചും കോൺഫിഗർ ചെയ്യുന്നതിനെക്കുറിച്ചും ഞാൻ വിശദമായി പറയില്ല, കാരണം നിങ്ങൾക്ക് ഇതിനകം കുറച്ച് അനുഭവമുണ്ടെന്ന് ഞാൻ കരുതുന്നു. ഞാൻ നേരിട്ട് പോയിന്റിലേക്ക് പോകാൻ നിർദ്ദേശിക്കുന്നു, അതായത് റൂട്ടിംഗ് സജ്ജീകരിക്കുക. അതിനാൽ ഞങ്ങൾക്ക് നാല് കേസുകളുണ്ട്:

കേസ് 1: കോൺഫിഗറേഷൻ ആവശ്യമില്ലാത്തപ്പോൾ

നമുക്ക് ഒരു ലളിതമായ കേസ് നോക്കാം.

MetalLB നൽകുന്ന വിലാസങ്ങൾ നിങ്ങളുടെ നോഡുകളുടെ വിലാസങ്ങളുടെ അതേ സബ്നെറ്റിൽ ആയിരിക്കുമ്പോൾ അധിക റൂട്ടിംഗ് കോൺഫിഗറേഷൻ ആവശ്യമില്ല.

ഉദാഹരണത്തിന്, നിങ്ങൾക്ക് ഒരു സബ്നെറ്റ് ഉണ്ട് 192.168.1.0/24, ഇതിന് ഒരു റൂട്ടർ ഉണ്ട് 192.168.1.1, നിങ്ങളുടെ നോഡുകൾക്ക് വിലാസങ്ങൾ ലഭിക്കും: 192.168.1.10-30, തുടർന്ന് MetalLB-നായി നിങ്ങൾക്ക് ശ്രേണി ക്രമീകരിക്കാം 192.168.1.100-120 അധിക കോൺഫിഗറേഷൻ ഇല്ലാതെ അവ പ്രവർത്തിക്കുമെന്ന് ഉറപ്പാക്കുക.

എന്തുകൊണ്ടാണത്? കാരണം നിങ്ങളുടെ നോഡുകൾക്ക് ഇതിനകം ക്രമീകരിച്ച റൂട്ടുകൾ ഉണ്ട്:

# ip route
default via 192.168.1.1 dev eth0 onlink 
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.10

അതേ ശ്രേണിയിൽ നിന്നുള്ള വിലാസങ്ങൾ അധിക പ്രവർത്തനങ്ങളൊന്നുമില്ലാതെ അവ വീണ്ടും ഉപയോഗിക്കും.

കേസ് 2: അധിക ഇഷ്‌ടാനുസൃതമാക്കൽ ആവശ്യമുള്ളപ്പോൾ

നിങ്ങളുടെ നോഡുകൾക്ക് കോൺഫിഗർ ചെയ്‌ത IP വിലാസമോ MetalLB വിലാസങ്ങൾ നൽകുന്ന സബ്‌നെറ്റിലേക്കുള്ള റൂട്ടോ ഇല്ലാത്തപ്പോഴെല്ലാം നിങ്ങൾ അധിക റൂട്ടുകൾ കോൺഫിഗർ ചെയ്യണം.

ഞാൻ കുറച്ചുകൂടി വിശദമായി വിശദീകരിക്കാം. MetalLB ഒരു വിലാസം ഔട്ട്‌പുട്ട് ചെയ്യുമ്പോൾ, അതിനെ ഒരു ലളിതമായ അസൈൻമെന്റുമായി താരതമ്യം ചെയ്യാം:

ip addr add 10.9.8.7/32 dev lo

ശ്രദ്ധിക്കുക:

• a) വിലാസം ഒരു പ്രിഫിക്‌സ് ഉപയോഗിച്ചാണ് നൽകിയിരിക്കുന്നത് /32 അതായത്, സബ്നെറ്റിലേക്ക് ഒരു റൂട്ട് സ്വയമേവ ചേർക്കില്ല (ഇത് ഒരു വിലാസം മാത്രമാണ്)
• b) ഏതെങ്കിലും നോഡ് ഇന്റർഫേസിലേക്ക് വിലാസം ഘടിപ്പിച്ചിരിക്കുന്നു (ഉദാഹരണത്തിന് ലൂപ്പ്ബാക്ക്). ലിനക്സ് നെറ്റ്‌വർക്ക് സ്റ്റാക്കിന്റെ സവിശേഷതകൾ ഇവിടെ പരാമർശിക്കേണ്ടതാണ്. നിങ്ങൾ ഏത് ഇന്റർഫേസിലേക്ക് വിലാസം ചേർത്താലും, കേർണൽ എല്ലായ്‌പ്പോഴും arp അഭ്യർത്ഥനകൾ പ്രോസസ്സ് ചെയ്യുകയും അവയിലേതെങ്കിലും arp പ്രതികരണങ്ങൾ അയയ്‌ക്കുകയും ചെയ്യും, ഈ സ്വഭാവം ശരിയാണെന്ന് കണക്കാക്കപ്പെടുന്നു, മാത്രമല്ല, കുബർനെറ്റസ് പോലുള്ള ചലനാത്മക അന്തരീക്ഷത്തിൽ ഇത് വ്യാപകമായി ഉപയോഗിക്കപ്പെടുന്നു.

ഈ സ്വഭാവം ഇഷ്‌ടാനുസൃതമാക്കാവുന്നതാണ്, ഉദാഹരണത്തിന് കർശനമായ ആർപ് പ്രവർത്തനക്ഷമമാക്കുന്നതിലൂടെ:

echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce

ഈ സാഹചര്യത്തിൽ, ഇന്റർഫേസിൽ ഒരു നിർദ്ദിഷ്ട IP വിലാസം വ്യക്തമായി അടങ്ങിയിട്ടുണ്ടെങ്കിൽ മാത്രമേ arp പ്രതികരണങ്ങൾ അയയ്‌ക്കൂ. നിങ്ങൾ MetalLB ഉപയോഗിക്കാൻ ആഗ്രഹിക്കുന്നുവെങ്കിൽ ഈ ക്രമീകരണം ആവശ്യമാണ് കൂടാതെ നിങ്ങളുടെ kube-proxy IPVS മോഡിൽ പ്രവർത്തിക്കുന്നു.

എന്നിരുന്നാലും, arp അഭ്യർത്ഥനകൾ പ്രോസസ്സ് ചെയ്യുന്നതിന് MetalLB കേർണൽ ഉപയോഗിക്കുന്നില്ല, പക്ഷേ അത് ഉപയോക്തൃ-സ്പേസിൽ തന്നെ ചെയ്യുന്നു, അതിനാൽ ഈ ഓപ്ഷൻ MetalLB യുടെ പ്രവർത്തനത്തെ ബാധിക്കില്ല.

നമുക്ക് നമ്മുടെ ചുമതലയിലേക്ക് മടങ്ങാം. നൽകിയ വിലാസങ്ങൾക്കുള്ള റൂട്ട് നിങ്ങളുടെ നോഡുകളിൽ നിലവിലില്ലെങ്കിൽ, എല്ലാ നോഡുകളിലേക്കും അത് മുൻകൂട്ടി ചേർക്കുക:

ip route add 10.9.8.0/24 dev eth1

കേസ് 3: നിങ്ങൾക്ക് ഉറവിടം അടിസ്ഥാനമാക്കിയുള്ള റൂട്ടിംഗ് ആവശ്യമുള്ളപ്പോൾ

നിങ്ങൾക്ക് ഒരു പ്രത്യേക ഗേറ്റ്‌വേയിലൂടെ പാക്കറ്റുകൾ ലഭിക്കുമ്പോൾ ഉറവിട അധിഷ്‌ഠിത റൂട്ടിംഗ് കോൺഫിഗർ ചെയ്യേണ്ടതുണ്ട്, ഡിഫോൾട്ടായി കോൺഫിഗർ ചെയ്‌തതല്ല, അതിനാൽ പ്രതികരണ പാക്കറ്റുകളും അതേ ഗേറ്റ്‌വേയിലൂടെ കടന്നുപോകണം.

ഉദാഹരണത്തിന്, നിങ്ങൾക്ക് ഒരേ സബ്നെറ്റ് ഉണ്ട് 192.168.1.0/24 നിങ്ങളുടെ നോഡുകൾക്കായി സമർപ്പിച്ചിരിക്കുന്നു, എന്നാൽ MetalLB ഉപയോഗിച്ച് നിങ്ങൾക്ക് ബാഹ്യ വിലാസങ്ങൾ നൽകണം. നിങ്ങൾക്ക് ഒരു സബ്നെറ്റിൽ നിന്ന് ഒന്നിലധികം വിലാസങ്ങൾ ഉണ്ടെന്ന് കരുതുക 1.2.3.0/24 VLAN 100-ൽ സ്ഥിതിചെയ്യുന്നു, കൂടാതെ കുബർനെറ്റസ് സേവനങ്ങൾ ബാഹ്യമായി ആക്‌സസ് ചെയ്യാൻ നിങ്ങൾ അവ ഉപയോഗിക്കാൻ ആഗ്രഹിക്കുന്നു.

ബന്ധപ്പെടുമ്പോൾ 1.2.3.4 നിങ്ങൾ മറ്റൊരു സബ്‌നെറ്റിൽ നിന്ന് അഭ്യർത്ഥനകൾ നടത്തുന്നതാണ് 1.2.3.0/24 ഒരു ഉത്തരത്തിനായി കാത്തിരിക്കുക. നിലവിൽ MetalLB നൽകിയ വിലാസത്തിൻ്റെ പ്രധാന നോഡ് 1.2.3.4, റൂട്ടറിൽ നിന്ന് പാക്കറ്റ് ലഭിക്കും 1.2.3.1, എന്നാൽ അവനു വേണ്ടിയുള്ള ഉത്തരം അനിവാര്യമായും അതേ വഴിയിലൂടെ പോകണം 1.2.3.1.

ഞങ്ങളുടെ നോഡിന് ഇതിനകം ക്രമീകരിച്ച സ്ഥിരസ്ഥിതി ഗേറ്റ്‌വേ ഉള്ളതിനാൽ 192.168.1.1, അപ്പോൾ ഡിഫോൾട്ടായി പ്രതികരണം അവനിലേക്ക് പോകും, ​​അല്ല 1.2.3.1, അതിലൂടെ ഞങ്ങൾക്ക് പാക്കേജ് ലഭിച്ചു.

ഈ സാഹചര്യത്തെ എങ്ങനെ നേരിടാം?

ഈ സാഹചര്യത്തിൽ, നിങ്ങളുടെ എല്ലാ നോഡുകളും അധിക കോൺഫിഗറേഷൻ കൂടാതെ ബാഹ്യ വിലാസങ്ങൾ നൽകുന്നതിന് തയ്യാറാകുന്ന വിധത്തിൽ നിങ്ങൾ തയ്യാറാക്കേണ്ടതുണ്ട്. അതായത്, മുകളിലുള്ള ഉദാഹരണത്തിനായി, നിങ്ങൾ മുൻകൂട്ടി നോഡിൽ ഒരു VLAN ഇന്റർഫേസ് സൃഷ്ടിക്കേണ്ടതുണ്ട്:

ip link add link eth0 name eth0.100 type vlan id 100
ip link set eth0.100 up

തുടർന്ന് റൂട്ടുകൾ ചേർക്കുക:

ip route add 1.2.3.0/24 dev eth0.100 table 100
ip route add default via 1.2.3.1 table 100

ഒരു പ്രത്യേക റൂട്ടിംഗ് ടേബിളിലേക്ക് ഞങ്ങൾ റൂട്ടുകൾ ചേർക്കുന്നു എന്നത് ശ്രദ്ധിക്കുക 100 ഗേറ്റ്‌വേയിലൂടെ ഒരു പ്രതികരണ പാക്കറ്റ് അയയ്‌ക്കുന്നതിന് ആവശ്യമായ രണ്ട് റൂട്ടുകൾ മാത്രമേ ഇതിൽ അടങ്ങിയിരിക്കൂ 1.2.3.1, ഇന്റർഫേസിന് പിന്നിൽ സ്ഥിതിചെയ്യുന്നു eth0.100.

ഇപ്പോൾ ഞങ്ങൾ ഒരു ലളിതമായ നിയമം ചേർക്കേണ്ടതുണ്ട്:

ip rule add from 1.2.3.0/24 lookup 100

ഇത് വ്യക്തമായി പറയുന്നു: പാക്കറ്റിന്റെ ഉറവിട വിലാസം ഉള്ളതാണെങ്കിൽ 1.2.3.0/24, അപ്പോൾ നിങ്ങൾ റൂട്ടിംഗ് ടേബിൾ ഉപയോഗിക്കേണ്ടതുണ്ട് 100. അതിൽ അവനെ അയക്കുന്ന റൂട്ട് ഞങ്ങൾ ഇതിനകം വിവരിച്ചിട്ടുണ്ട് 1.2.3.1

കേസ് 4: നിങ്ങൾക്ക് പോളിസി അടിസ്ഥാനമാക്കിയുള്ള റൂട്ടിംഗ് ആവശ്യമുള്ളപ്പോൾ

നെറ്റ്‌വർക്ക് ടോപ്പോളജി മുമ്പത്തെ ഉദാഹരണത്തിലേതിന് സമാനമാണ്, എന്നാൽ ബാഹ്യ പൂൾ വിലാസങ്ങൾ ആക്‌സസ് ചെയ്യാൻ നിങ്ങൾ ആഗ്രഹിക്കുന്നുവെന്ന് പറയാം. 1.2.3.0/24 നിങ്ങളുടെ കായ്കളിൽ നിന്ന്:

ഏതെങ്കിലും വിലാസത്തിലേക്ക് പ്രവേശിക്കുമ്പോൾ എന്നതാണ് പ്രത്യേകത 1.2.3.0/24, പ്രതികരണ പാക്കറ്റ് നോഡിൽ എത്തുകയും ശ്രേണിയിൽ ഒരു ഉറവിട വിലാസം ഉണ്ടായിരിക്കുകയും ചെയ്യുന്നു 1.2.3.0/24 എന്നതിലേക്ക് അനുസരണയോടെ അയക്കും eth0.100, എന്നാൽ യഥാർത്ഥ അഭ്യർത്ഥന സൃഷ്ടിച്ച ഞങ്ങളുടെ ആദ്യ പോഡിലേക്ക് കുബർനെറ്റസ് ഇത് റീഡയറക്‌ട് ചെയ്യണമെന്ന് ഞങ്ങൾ ആഗ്രഹിക്കുന്നു.

ഈ പ്രശ്നം പരിഹരിക്കുന്നത് ബുദ്ധിമുട്ടാണ്, പക്ഷേ നയ-അടിസ്ഥാന റൂട്ടിംഗ് വഴി ഇത് സാധ്യമായി:

പ്രക്രിയയെ കുറിച്ച് കൂടുതൽ മനസ്സിലാക്കുന്നതിന്, ഇവിടെ ഒരു നെറ്റ്ഫിൽറ്റർ ബ്ലോക്ക് ഡയഗ്രം ഉണ്ട്:

ആദ്യം, മുമ്പത്തെ ഉദാഹരണത്തിലെന്നപോലെ, നമുക്ക് ഒരു അധിക റൂട്ടിംഗ് പട്ടിക ഉണ്ടാക്കാം:

ip route add 1.2.3.0/24 dev eth0.100 table 100
ip route add default via 1.2.3.1 table 100

ഇനി നമുക്ക് iptables-ലേക്ക് കുറച്ച് നിയമങ്ങൾ ചേർക്കാം:

iptables -t mangle -A PREROUTING -i eth0.100 -j CONNMARK --set-mark 0x100
iptables -t mangle -A PREROUTING  -j CONNMARK --restore-mark
iptables -t mangle -A PREROUTING -m mark ! --mark 0 -j RETURN
iptables -t mangle -A POSTROUTING -j CONNMARK --save-mark

ഈ നിയമങ്ങൾ ഇന്റർഫേസിലേക്കുള്ള ഇൻകമിംഗ് കണക്ഷനുകളെ അടയാളപ്പെടുത്തും eth0.100, എല്ലാ പാക്കറ്റുകളും ടാഗ് ഉപയോഗിച്ച് അടയാളപ്പെടുത്തുന്നു 0x100, ഒരേ കണക്ഷനിലുള്ള പ്രതികരണങ്ങളും അതേ ടാഗ് ഉപയോഗിച്ച് അടയാളപ്പെടുത്തും.

ഇപ്പോൾ നമുക്ക് ഒരു റൂട്ടിംഗ് നിയമം ചേർക്കാം:

ip rule add from 1.2.3.0/24 fwmark 0x100 lookup 100

അതായത്, ഒരു ഉറവിട വിലാസമുള്ള എല്ലാ പാക്കറ്റുകളും 1.2.3.0/24 ടാഗും 0x100 ഒരു ടേബിൾ ഉപയോഗിച്ച് റൂട്ട് ചെയ്യണം 100.

അതിനാൽ, മറ്റൊരു ഇന്റർഫേസിൽ ലഭിച്ച മറ്റ് പാക്കറ്റുകൾ ഈ നിയമത്തിന് വിധേയമല്ല, ഇത് സ്റ്റാൻഡേർഡ് കുബർനെറ്റസ് ടൂളുകൾ ഉപയോഗിച്ച് റൂട്ട് ചെയ്യാൻ അനുവദിക്കും.

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

ഞങ്ങളുടെ കാര്യത്തിൽ ഇത് ശരിയായി പ്രവർത്തിക്കില്ല എന്നതാണ് പ്രശ്നം, പക്ഷേ ഞങ്ങൾക്ക് ഇത് പ്രവർത്തനരഹിതമാക്കാം:

echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/eth0.100/rp_filter

ആദ്യത്തെ കമാൻഡ് rp_filter-ന്റെ ആഗോള സ്വഭാവത്തെ നിയന്ത്രിക്കുന്നുവെന്നത് ശ്രദ്ധിക്കുക; ഇത് പ്രവർത്തനരഹിതമാക്കിയിട്ടില്ലെങ്കിൽ, രണ്ടാമത്തെ കമാൻഡിന് ഫലമുണ്ടാകില്ല. എന്നിരുന്നാലും, ശേഷിക്കുന്ന ഇന്റർഫേസുകൾ rp_filter പ്രവർത്തനക്ഷമമാക്കി നിലനിൽക്കും.

ഫിൽട്ടറിന്റെ പ്രവർത്തനം പൂർണ്ണമായും പരിമിതപ്പെടുത്താതിരിക്കാൻ, നമുക്ക് netfilter-നായി rp_filter നടപ്പിലാക്കൽ ഉപയോഗിക്കാം. ഒരു iptables മൊഡ്യൂളായി rpfilter ഉപയോഗിച്ച്, നിങ്ങൾക്ക് തികച്ചും വഴക്കമുള്ള നിയമങ്ങൾ ക്രമീകരിക്കാൻ കഴിയും, ഉദാഹരണത്തിന്:

iptables -t raw -A PREROUTING -i eth0.100 -d 1.2.3.0/24 -j RETURN
iptables -t raw -A PREROUTING -i eth0.100 -m rpfilter --invert -j DROP

ഇന്റർഫേസിൽ rp_filter പ്രവർത്തനക്ഷമമാക്കുക eth0.100 ഒഴികെയുള്ള എല്ലാ വിലാസങ്ങൾക്കും 1.2.3.0/24.

അവലംബം: www.habr.com