ProHoster > blog > Utawala > Urekebishaji mzuri wa uelekezaji wa MetalLB katika hali ya L2

Urekebishaji mzuri wa uelekezaji wa MetalLB katika hali ya L2

Urekebishaji mzuri wa uelekezaji wa MetalLB katika hali ya L2
Si muda mrefu uliopita nilikabiliwa na kazi isiyo ya kawaida sana ya kusanidi njia ya MetalLB. Kila kitu kitakuwa sawa, kwa sababu ... Kawaida MetalLB haihitaji hatua zozote za ziada, lakini kwa upande wetu tunayo nguzo kubwa yenye usanidi rahisi sana wa mtandao.

Katika makala haya nitakuambia jinsi ya kusanidi uelekezaji kulingana na chanzo na sera kwa mtandao wa nje wa nguzo yako.

Sitaingia kwa undani juu ya kusakinisha na kusanidi MetalLB, kwani nadhani tayari una uzoefu fulani. Ninapendekeza kwenda moja kwa moja kwa uhakika, ambayo ni kuanzisha njia. Kwa hivyo tuna kesi nne:

Kesi ya 1: Wakati hakuna usanidi unahitajika

Hebu tuangalie kesi rahisi.

Urekebishaji mzuri wa uelekezaji wa MetalLB katika hali ya L2

Usanidi wa ziada wa uelekezaji hauhitajiki wakati anwani zilizotolewa na MetalLB ziko katika mtandao mdogo sawa na anwani za nodi zako.

Kwa mfano, una subnet 192.168.1.0/24, ina kipanga njia 192.168.1.1, na nodi zako hupokea anwani: 192.168.1.10-30, basi kwa MetalLB unaweza kurekebisha masafa 192.168.1.100-120 na uhakikishe kuwa watafanya kazi bila usanidi wowote wa ziada.

Kwanini hivyo? Kwa sababu nodi zako tayari zina njia zilizosanidiwa:

# 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

Na anwani kutoka kwa safu sawa zitazitumia tena bila vitendo vyovyote vya ziada.

Kesi ya 2: Wakati ubinafsishaji wa ziada unahitajika

Urekebishaji mzuri wa uelekezaji wa MetalLB katika hali ya L2

Unapaswa kusanidi njia za ziada wakati wowote nodi zako hazina anwani ya IP iliyosanidiwa au njia ya kwenda kwa subnet ambayo MetalLB inatoa anwani.

Nitaelezea kwa undani zaidi. Wakati wowote MetalLB inapotoa anwani, inaweza kulinganishwa na mgawo rahisi kama:

ip addr add 10.9.8.7/32 dev lo

Makini na:

  • a) Anwani imepewa kiambishi awali /32 yaani, njia haitaongezwa kiotomatiki kwa subnet yake (ni anwani tu)
  • b) Anwani imeambatishwa kwa kiolesura chochote cha nodi (kwa mfano loopback). Ni muhimu kutaja hapa vipengele vya mtandao wa mtandao wa Linux. Haijalishi ni kiolesura gani unachoongeza anwani, kernel itachakata maombi ya arp kila wakati na kutuma majibu ya arp kwa yoyote kati yao, tabia hii inachukuliwa kuwa sawa na, zaidi ya hayo, inatumika sana katika mazingira yenye nguvu kama Kubernetes.

Tabia hii inaweza kubinafsishwa, kwa mfano kwa kuwezesha arp kali:

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

Katika hali hii, majibu ya arp yatatumwa tu ikiwa kiolesura kina anwani maalum ya IP. Mpangilio huu unahitajika ikiwa unapanga kutumia MetalLB na proksi yako ya kube inafanya kazi katika hali ya IPVS.

Walakini, MetalLB haitumii kernel kuchakata maombi ya arp, lakini inajifanya yenyewe katika nafasi ya mtumiaji, kwa hivyo chaguo hili halitaathiri utendakazi wa MetalLB.

Wacha turudi kwenye kazi yetu. Ikiwa njia ya anwani zilizotolewa haipo kwenye nodi zako, ongeza mapema kwa nodi zote:

ip route add 10.9.8.0/24 dev eth1

Kesi ya 3: Unapohitaji uelekezaji wa msingi wa chanzo

Utahitaji kusanidi uelekezaji kulingana na chanzo unapopokea pakiti kupitia lango tofauti, si lile lililosanidiwa kwa chaguo-msingi, kwa hivyo pakiti za majibu zinapaswa pia kupitia lango sawa.

Kwa mfano, una subnet sawa 192.168.1.0/24 iliyojitolea kwa nodi zako, lakini unataka kutoa anwani za nje kwa kutumia MetalLB. Hebu tuchukulie una anwani nyingi kutoka kwa subnet 1.2.3.0/24 ziko katika VLAN 100 na unataka kuzitumia kufikia huduma za Kubernetes nje.

Urekebishaji mzuri wa uelekezaji wa MetalLB katika hali ya L2

Wakati wa kuwasiliana 1.2.3.4 utakuwa ukifanya maombi kutoka kwa subnet tofauti na 1.2.3.0/24 na kusubiri jibu. Nodi ambayo kwa sasa ni bwana wa anwani iliyotolewa na MetalLB 1.2.3.4, itapokea pakiti kutoka kwa router 1.2.3.1, lakini jibu kwa ajili yake lazima lazima kwenda njia sawa, kupitia 1.2.3.1.

Kwa kuwa nodi yetu tayari ina lango chaguo-msingi lililosanidiwa 192.168.1.1, basi kwa chaguo-msingi jibu litaenda kwake, na sio 1.2.3.1, kupitia ambayo tulipokea kifurushi.

Jinsi ya kukabiliana na hali hii?

Katika kesi hii, unahitaji kuandaa nodes zako zote kwa njia ambayo wako tayari kutumikia anwani za nje bila usanidi wa ziada. Hiyo ni, kwa mfano hapo juu, unahitaji kuunda kiolesura cha VLAN kwenye nodi mapema:

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

Na kisha ongeza njia:

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

Tafadhali kumbuka kuwa tunaongeza njia kwenye jedwali tofauti la uelekezaji 100 itakuwa na njia mbili tu zinazohitajika kutuma pakiti ya majibu kupitia lango 1.2.3.1, iko nyuma ya kiolesura eth0.100.

Sasa tunahitaji kuongeza sheria rahisi:

ip rule add from 1.2.3.0/24 lookup 100

ambayo inasema wazi: ikiwa anwani ya chanzo cha pakiti iko ndani 1.2.3.0/24, basi unahitaji kutumia meza ya uelekezaji 100. Ndani yake tayari tumeeleza njia itakayompeleka 1.2.3.1

Kesi ya 4: Unapohitaji uelekezaji unaotegemea sera

Topolojia ya mtandao ni sawa na katika mfano uliopita, lakini hebu tuseme unataka kuwa na uwezo wa kufikia anwani za nje. 1.2.3.0/24 kutoka kwa maganda yako:

Urekebishaji mzuri wa uelekezaji wa MetalLB katika hali ya L2

Upekee ni kwamba wakati wa kupata anwani yoyote ndani 1.2.3.0/24, pakiti ya majibu hugonga nodi na ina anwani ya chanzo katika safu 1.2.3.0/24 itatumwa kwa utii eth0.100, lakini tunataka Kubernetes ielekeze kwenye ganda letu la kwanza, ambalo lilitoa ombi asili.

Kutatua tatizo hili kuligeuka kuwa ngumu, lakini ikawa shukrani inayowezekana kwa uelekezaji wa sera:

Kwa ufahamu bora wa mchakato, hapa kuna mchoro wa netfilter block:
Urekebishaji mzuri wa uelekezaji wa MetalLB katika hali ya L2

Kwanza, kama katika mfano uliopita, wacha tuunde jedwali la ziada la uelekezaji:

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

Sasa hebu tuongeze sheria chache kwa 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

Sheria hizi zitaashiria miunganisho inayoingia kwenye kiolesura eth0.100, kuashiria pakiti zote na lebo 0x100, majibu ndani ya muunganisho sawa pia yatawekewa lebo sawa.

Sasa tunaweza kuongeza sheria ya uelekezaji:

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

Hiyo ni, pakiti zote zilizo na anwani ya chanzo 1.2.3.0/24 na tag 0x100 lazima ipitishwe kwa kutumia meza 100.

Kwa hivyo, pakiti zingine zilizopokelewa kwenye kiolesura kingine si chini ya sheria hii, ambayo itawawezesha kupitishwa kwa kutumia zana za kawaida za Kubernetes.

Kuna jambo moja zaidi, katika Linux kuna kinachojulikana kama kichungi cha njia ya nyuma, ambayo inaharibu jambo zima; hufanya ukaguzi rahisi: kwa pakiti zote zinazoingia, inabadilisha anwani ya chanzo ya pakiti na anwani ya mtumaji na kuangalia ikiwa. pakiti inaweza kuondoka kupitia kiolesura kilekile ambacho kilipokelewa, ikiwa sivyo, itaichuja.

Shida ni kwamba kwa upande wetu haitafanya kazi kwa usahihi, lakini tunaweza kuizima:

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

Tafadhali kumbuka kuwa amri ya kwanza inadhibiti tabia ya kimataifa ya rp_filter; ikiwa haijazimwa, amri ya pili haitakuwa na athari. Walakini, violesura vilivyosalia vitasalia na rp_filter kuwezeshwa.

Ili kutopunguza kabisa utendakazi wa kichujio, tunaweza kutumia rp_filter utekelezaji kwa netfilter. Kutumia rpfilter kama moduli ya iptables, unaweza kusanidi sheria zinazobadilika kabisa, kwa mfano:

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

wezesha rp_filter kwenye kiolesura eth0.100 kwa anwani zote isipokuwa 1.2.3.0/24.

Chanzo: mapenzi.com

Kuongeza maoni