కొంతకాలం క్రితం నేను 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 మోడ్‌లో రన్ అవుతుంటే ఈ సెట్టింగ్ అవసరం.

అయినప్పటికీ, MetalLB arp అభ్యర్థనలను ప్రాసెస్ చేయడానికి కెర్నల్‌ను ఉపయోగించదు, కానీ అది వినియోగదారు-స్పేస్‌లో చేస్తుంది, కాబట్టి ఈ ఎంపిక 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లో ఉంది మరియు మీరు బాహ్యంగా 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.

అందువల్ల, మరొక ఇంటర్‌ఫేస్‌లో స్వీకరించబడిన ఇతర ప్యాకెట్‌లు ఈ నియమానికి లోబడి ఉండవు, ఇది వాటిని ప్రామాణిక కుబెర్నెట్స్ సాధనాలను ఉపయోగించి రూట్ చేయడానికి అనుమతిస్తుంది.

ఇంకొక విషయం ఉంది, Linux లో రివర్స్ పాత్ ఫిల్టర్ అని పిలవబడుతుంది, ఇది మొత్తం పాడు చేస్తుంది; ఇది సాధారణ తనిఖీని చేస్తుంది: అన్ని ఇన్‌కమింగ్ ప్యాకెట్‌ల కోసం, ఇది పంపినవారి చిరునామాతో ప్యాకెట్ యొక్క మూల చిరునామాను మారుస్తుంది మరియు తనిఖీ చేస్తుంది ప్యాకెట్ స్వీకరించిన అదే ఇంటర్‌ఫేస్ ద్వారా వదిలివేయవచ్చు, కాకపోతే, అది దాన్ని ఫిల్టర్ చేస్తుంది.

సమస్య ఏమిటంటే, మా విషయంలో ఇది సరిగ్గా పనిచేయదు, కానీ మేము దానిని నిలిపివేయవచ్చు:

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 అమలును ఉపయోగించవచ్చు. rpfilterని iptables మాడ్యూల్‌గా ఉపయోగించి, మీరు చాలా సరళమైన నియమాలను కాన్ఫిగర్ చేయవచ్చు, ఉదాహరణకు:

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