થોડા સમય પહેલા મને 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) સરનામું કોઈપણ નોડ ઈન્ટરફેસ સાથે જોડાયેલ છે (ઉદાહરણ તરીકે લૂપબેક). અહીં લિનક્સ નેટવર્ક સ્ટેકની વિશેષતાઓનો ઉલ્લેખ કરવો યોગ્ય છે. તમે કયા ઈન્ટરફેસમાં સરનામું ઉમેરો છો તે મહત્વનું નથી, કર્નલ હંમેશા એઆરપી વિનંતીઓ પર પ્રક્રિયા કરશે અને તેમાંથી કોઈપણને એઆરપી પ્રતિસાદો મોકલશે, આ વર્તણૂક યોગ્ય માનવામાં આવે છે અને વધુમાં, કુબરનેટ્સ જેવા ગતિશીલ વાતાવરણમાં વ્યાપકપણે ઉપયોગમાં લેવાય છે.

આ વર્તણૂકને કસ્ટમાઇઝ કરી શકાય છે, ઉદાહરણ તરીકે કડક એઆરપી સક્ષમ કરીને:

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 મોડમાં ચાલી રહી હોય તો આ સેટિંગ જરૂરી છે.

જો કે, મેટલએલબી એઆરપી વિનંતીઓ પર પ્રક્રિયા કરવા માટે કર્નલનો ઉપયોગ કરતું નથી, પરંતુ તે પોતે વપરાશકર્તા-જગ્યામાં કરે છે, તેથી આ વિકલ્પ મેટલએલબીની કામગીરીને અસર કરશે નહીં.

ચાલો આપણા કાર્ય પર પાછા આવીએ. જો જારી કરાયેલા સરનામાં માટેનો માર્ગ તમારા નોડ્સ પર અસ્તિત્વમાં નથી, તો તેને અગાઉથી તમામ નોડ્સમાં ઉમેરો:

ip route add 10.9.8.0/24 dev eth1

કેસ 3: જ્યારે તમને સ્ત્રોત-આધારિત રૂટીંગની જરૂર હોય

જ્યારે તમે એક અલગ ગેટવે દ્વારા પેકેટો પ્રાપ્ત કરો ત્યારે તમારે સ્ત્રોત-આધારિત રૂટીંગને ગોઠવવાની જરૂર પડશે, ડિફૉલ્ટ રૂપે રૂપરેખાંકિત નહીં, તેથી પ્રતિસાદ પેકેટો પણ સમાન ગેટવેમાંથી પસાર થવા જોઈએ.

ઉદાહરણ તરીકે, તમારી પાસે સમાન સબનેટ છે 192.168.1.0/24 તમારા નોડ્સને સમર્પિત છે, પરંતુ તમે MetalLB નો ઉપયોગ કરીને બાહ્ય સરનામાં જારી કરવા માંગો છો. ચાલો ધારીએ કે તમારી પાસે સબનેટમાંથી બહુવિધ સરનામાં છે 1.2.3.0/24 VLAN 100 માં સ્થિત છે અને તમે તેનો ઉપયોગ Kubernetes સેવાઓને બહારથી ઍક્સેસ કરવા માટે કરવા માંગો છો.

સંપર્ક કરતી વખતે 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, પરંતુ અમે ઈચ્છીએ છીએ કે Kubernetes તેને અમારા પ્રથમ પોડ પર રીડાયરેક્ટ કરે, જેણે મૂળ વિનંતી જનરેટ કરી.

આ સમસ્યાનું નિરાકરણ મુશ્કેલ બન્યું, પરંતુ નીતિ-આધારિત રૂટીંગને કારણે તે શક્ય બન્યું:

પ્રક્રિયાને વધુ સારી રીતે સમજવા માટે, અહીં નેટફિલ્ટર બ્લોક ડાયાગ્રામ છે:

પ્રથમ, અગાઉના ઉદાહરણની જેમ, ચાલો એક વધારાનું રૂટીંગ ટેબલ બનાવીએ:

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 સક્ષમ સાથે જ રહેશે.

ફિલ્ટરની કામગીરીને સંપૂર્ણપણે મર્યાદિત ન કરવા માટે, અમે નેટફિલ્ટર માટે 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