Ekki er langt síðan ég stóð frammi fyrir mjög óvenjulegu verkefni að setja upp leið fyrir MetalLB. Allt væri í lagi, því... Venjulega þarf MetalLB engar viðbótaraðgerðir, en í okkar tilviki erum við með nokkuð stóran þyrping með mjög einfaldri netstillingu.

Í þessari grein mun ég segja þér hvernig á að stilla upprunatengda og stefnumiðaða leið fyrir ytra net klasans þíns.

Ég mun ekki fara í smáatriði um uppsetningu og stillingu MetalLB, þar sem ég geri ráð fyrir að þú hafir nú þegar reynslu. Ég legg til að farið sé beint að efninu, nefnilega að setja upp beina. Þannig að við höfum fjögur tilvik:

Tilvik 1: Þegar ekki er þörf á stillingum

Við skulum skoða einfalt mál.

Ekki er krafist frekari leiðarstillingar þegar vistföngin sem MetalLB gefur út eru í sama undirneti og heimilisföng hnútanna þinna.

Til dæmis ertu með undirnet 192.168.1.0/24, það er með router 192.168.1.1, og hnútarnir þínir fá heimilisföng: 192.168.1.10-30, þá fyrir MetalLB geturðu stillt svið 192.168.1.100-120 og vertu viss um að þau virki án frekari stillinga.

Afhverju er það? Vegna þess að hnútarnir þínir hafa þegar stilltar leiðir:

# 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

Og heimilisföng frá sama sviði munu endurnýta þau án frekari aðgerða.

Tilvik 2: Þegar þörf er á frekari aðlögun

Þú ættir að stilla viðbótarleiðir í hvert sinn sem hnútarnir þínir eru ekki með stillta IP tölu eða leið til undirnetsins sem MetalLB gefur út vistföng fyrir.

Ég skal útskýra það aðeins nánar. Alltaf þegar MetalLB gefur út heimilisfang er hægt að líkja því við einfalt verkefni eins og:

ip addr add 10.9.8.7/32 dev lo

Gefðu gaum að:

• a) Heimilisfanginu er úthlutað með forskeyti /32 það er, leið verður ekki sjálfkrafa bætt við undirnetið fyrir hana (það er bara heimilisfang)
• b) Heimilisfangið er tengt við hvaða hnútviðmót sem er (til dæmis loopback). Það er þess virði að nefna hér eiginleika Linux netstafla. Sama í hvaða viðmóti þú bætir heimilisfanginu við, kjarninn mun alltaf vinna úr arp beiðnir og senda arp svör við hverri þeirra, þessi hegðun er talin rétt og er þar að auki nokkuð mikið notuð í kraftmiklu umhverfi eins og Kubernetes.

Hægt er að aðlaga þessa hegðun, til dæmis með því að virkja strangt arp:

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

Í þessu tilviki verða arp svör aðeins send ef viðmótið inniheldur sérstaklega tiltekið IP tölu. Þessi stilling er nauðsynleg ef þú ætlar að nota MetalLB og kube-proxy þinn er í gangi í IPVS ham.

Hins vegar notar MetalLB ekki kjarnann til að vinna úr arp beiðnir, heldur gerir það sjálft í notendarými, þannig að þessi valkostur mun ekki hafa áhrif á rekstur MetalLB.

Snúum okkur aftur að verkefni okkar. Ef leiðin fyrir útgefin heimilisföng er ekki til á hnútunum þínum skaltu bæta henni fyrirfram við alla hnúta:

ip route add 10.9.8.0/24 dev eth1

Tilfelli 3: Þegar þú þarft upprunatengda leið

Þú þarft að stilla leið sem byggir á uppruna þegar þú færð pakka í gegnum sérstaka gátt, ekki þá sem sjálfgefið er stillt, þess vegna ættu svarpakkar einnig að fara í gegnum sömu gátt.

Til dæmis ertu með sama undirnet 192.168.1.0/24 tileinkað hnútunum þínum, en þú vilt gefa út ytri vistföng með MetalLB. Gerum ráð fyrir að þú sért með mörg heimilisföng frá undirneti 1.2.3.0/24 staðsett í VLAN 100 og þú vilt nota þau til að fá aðgang að Kubernetes þjónustu ytra.

Þegar haft er samband 1.2.3.4 þú munt gera beiðnir frá öðru undirneti en 1.2.3.0/24 og bíða eftir svari. Hnúturinn sem er nú meistari fyrir MetalLB heimilisfangið 1.2.3.4, mun fá pakkann frá beini 1.2.3.1, en svarið fyrir hann verður endilega að fara sömu leið, í gegnum 1.2.3.1.

Þar sem hnúturinn okkar er nú þegar með stillta sjálfgefna gátt 192.168.1.1, þá sjálfgefið mun svarið fara til hans, en ekki til 1.2.3.1, sem við fengum pakkann í gegnum.

Hvernig á að takast á við þetta ástand?

Í þessu tilviki þarftu að undirbúa alla hnúta þína á þann hátt að þeir séu tilbúnir til að þjóna ytri vistföngum án frekari stillingar. Það er, fyrir ofangreint dæmi, þú þarft að búa til VLAN tengi á hnútnum fyrirfram:

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

Og bættu síðan við leiðum:

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

Vinsamlegast athugaðu að við bætum leiðum við sérstaka leiðartöflu 100 það mun aðeins innihalda tvær leiðir sem nauðsynlegar eru til að senda svarpakka í gegnum gáttina 1.2.3.1, staðsett fyrir aftan viðmótið eth0.100.

Nú þurfum við að bæta við einfaldri reglu:

ip rule add from 1.2.3.0/24 lookup 100

sem segir beinlínis: ef upprunafang pakkans er í 1.2.3.0/24, þá þarftu að nota leiðartöfluna 100. Í henni höfum við þegar lýst leiðinni sem mun senda hann í gegnum 1.2.3.1

Tilfelli 4: Þegar þú þarft stefnumiðaða leið

Gróðurfræði netkerfisins er sú sama og í fyrra dæmi, en segjum að þú viljir líka fá aðgang að ytri laugarföngum 1.2.3.0/24 úr belgunum þínum:

Sérstaðan er sú að þegar þú nálgast hvaða heimilisfang sem er í 1.2.3.0/24, svarpakkinn lendir á hnútnum og hefur upprunavistfang á bilinu 1.2.3.0/24 verður hlýðni sendur til eth0.100, en við viljum að Kubernetes beini því í fyrsta hólfið okkar, sem bjó til upprunalegu beiðnina.

Það reyndist erfitt að leysa þetta vandamál, en það varð mögulegt þökk sé stefnumiðaðri leið:

Til að fá betri skilning á ferlinu er hér netfilter blokkarmynd:

Í fyrsta lagi, eins og í fyrra dæmi, skulum við búa til viðbótar leiðartöflu:

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

Nú skulum við bæta nokkrum reglum við 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

Þessar reglur munu merkja komandi tengingar við viðmótið eth0.100, merkir alla pakka með merkinu 0x100, svör innan sömu tengingar verða einnig merkt með sama merki.

Nú getum við bætt við leiðarreglu:

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

Það er að segja allir pakkar með upprunavistfangi 1.2.3.0/24 og merkja 0x100 verður að beina með töflu 100.

Þannig falla aðrir pakkar sem berast á annað viðmót ekki undir þessa reglu, sem gerir kleift að beina þeim með venjulegum Kubernetes verkfærum.

Það er eitt í viðbót, í Linux er svokölluð öfugslóðasía, sem spillir öllu, hún framkvæmir einfalda athugun: fyrir alla innkomna pakka breytir hún upprunastaðfangi pakkans með sendandafangi og athugar hvort pakkinn getur farið í gegnum sama viðmótið og hann var móttekinn á, ef ekki mun hann sía hann út.

Vandamálið er að í okkar tilviki mun það ekki virka rétt, en við getum slökkt á því:

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

Vinsamlegast athugaðu að fyrsta skipunin stjórnar alþjóðlegri hegðun rp_filter; ef hún er ekki óvirk, hefur önnur skipunin engin áhrif. Hins vegar verða viðmótin sem eftir eru áfram með rp_filter virkt.

Til þess að takmarka ekki alveg virkni síunnar getum við notað rp_filter útfærsluna fyrir netfilter. Með því að nota rpfilter sem iptables mát geturðu stillt nokkuð sveigjanlegar reglur, til dæmis:

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

virkjaðu rp_filter á viðmótinu eth0.100 fyrir öll heimilisföng nema 1.2.3.0/24.

Heimild: www.habr.com