Nedolgo nazaj sem se soočil z zelo nenavadno nalogo nastavitve usmerjanja za MetalLB. Vse bi bilo v redu, ker... Običajno MetalLB ne zahteva nobenih dodatnih dejanj, v našem primeru pa imamo precej veliko gručo z zelo preprosto konfiguracijo omrežja.

V tem članku vam bom povedal, kako konfigurirati usmerjanje na podlagi vira in pravilnika za zunanje omrežje vaše gruče.

Ne bom se spuščal v podrobnosti o namestitvi in ​​konfiguraciji MetalLB, saj predvidevam, da že imate nekaj izkušenj. Predlagam, da gremo naravnost k bistvu, in sicer nastavitvi usmerjanja. Torej imamo štiri primere:

Primer 1: Ko konfiguracija ni potrebna

Poglejmo preprost primer.

Dodatna konfiguracija usmerjanja ni potrebna, če so naslovi, ki jih izda MetalLB, v istem podomrežju kot naslovi vaših vozlišč.

Na primer, imate podomrežje 192.168.1.0/24, ima router 192.168.1.1in vaša vozlišča prejmejo naslove: 192.168.1.10-30, potem lahko za MetalLB prilagodite obseg 192.168.1.100-120 in se prepričajte, da bodo delovali brez dodatne konfiguracije.

Zakaj? Ker imajo vaša vozlišča že konfigurirane poti:

# 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

In naslovi iz istega obsega jih bodo znova uporabili brez dodatnih dejanj.

2. primer: ko je potrebna dodatna prilagoditev

Konfigurirajte dodatne poti, kadar vaša vozlišča nimajo konfiguriranega naslova IP ali poti do podomrežja, za katerega MetalLB izda naslove.

Bom razložil malo bolj podrobno. Kadarkoli MetalLB izda naslov, ga lahko primerjamo s preprosto dodelitvijo, kot je:

ip addr add 10.9.8.7/32 dev lo

Bodi pozoren na:

• a) Naslov je dodeljen s predpono /32 to pomeni, da pot zanjo ne bo samodejno dodana v podomrežje (to je samo naslov)
• b) Naslov je pritrjen na kateri koli vmesnik vozlišča (na primer povratna zanka). Tukaj je vredno omeniti značilnosti omrežnega sklada Linux. Ne glede na to, kateremu vmesniku dodate naslov, bo jedro vedno obdelalo zahteve arp in poslalo odgovore arp na katero koli od njih, to vedenje velja za pravilno in se poleg tega precej pogosto uporablja v tako dinamičnem okolju, kot je Kubernetes.

To vedenje je mogoče prilagoditi, na primer z omogočanjem strogega arp:

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

V tem primeru bodo odgovori arp poslani samo, če vmesnik izrecno vsebuje določen naslov IP. Ta nastavitev je potrebna, če nameravate uporabljati MetalLB in vaš kube-proxy deluje v načinu IPVS.

Vendar MetalLB ne uporablja jedra za obdelavo zahtev arp, ampak to počne sam v uporabniškem prostoru, tako da ta možnost ne bo vplivala na delovanje MetalLB.

Vrnimo se k naši nalogi. Če pot za izdane naslove ne obstaja na vaših vozliščih, jo vnaprej dodajte vsem vozliščem:

ip route add 10.9.8.0/24 dev eth1

Primer 3: Ko potrebujete usmerjanje na podlagi vira

Ko prejmete pakete prek ločenega prehoda, ne privzeto konfiguriranega, boste morali konfigurirati usmerjanje na podlagi vira, zato morajo tudi odzivni paketi iti skozi isti prehod.

Na primer, imate isto podomrežje 192.168.1.0/24 namenjen vašim vozliščem, vendar želite izdati zunanje naslove z uporabo MetalLB. Predpostavimo, da imate več naslovov iz podomrežja 1.2.3.0/24 ki se nahajajo v VLAN 100 in jih želite uporabiti za zunanji dostop do storitev Kubernetes.

Pri stiku 1.2.3.4 zahtevali boste iz drugega podomrežja 1.2.3.0/24 in počakajte na odgovor. Vozlišče, ki je trenutno glavno za naslov, ki ga je izdal MetalLB 1.2.3.4, bo prejel paket od usmerjevalnika 1.2.3.1, a mora odgovor zanj nujno iti po isti poti, skozi 1.2.3.1.

Ker ima naše vozlišče že konfiguriran privzeti prehod 192.168.1.1, potem bo odgovor privzeto šel njemu in ne 1.2.3.1, preko katerega smo prejeli paket.

Kako se spopasti s to situacijo?

V tem primeru morate vsa vaša vozlišča pripraviti tako, da bodo pripravljena služiti zunanjim naslovom brez dodatne konfiguracije. To pomeni, da morate za zgornji primer vnaprej ustvariti vmesnik VLAN na vozlišču:

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

In nato dodajte poti:

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

Upoštevajte, da dodamo poti v ločeno usmerjevalno tabelo 100 vseboval bo le dve poti, potrebni za pošiljanje odzivnega paketa skozi prehod 1.2.3.1, ki se nahaja za vmesnikom eth0.100.

Zdaj moramo dodati preprosto pravilo:

ip rule add from 1.2.3.0/24 lookup 100

ki izrecno pravi: če je izvorni naslov paketa v 1.2.3.0/24, potem morate uporabiti usmerjevalno tabelo 100. V njem smo že opisali pot, po kateri ga bomo poslali 1.2.3.1

Primer 4: Ko potrebujete usmerjanje na podlagi pravilnika

Topologija omrežja je enaka kot v prejšnjem primeru, vendar recimo, da želite imeti tudi možnost dostopa do naslovov zunanjega bazena 1.2.3.0/24 iz vaših podov:

Posebnost je, da pri dostopu do katerega koli naslova v 1.2.3.0/24, odzivni paket zadene vozlišče in ima izvorni naslov v območju 1.2.3.0/24 bo ubogljivo poslan eth0.100, vendar želimo, da ga Kubernetes preusmeri na naš prvi pod, ki je ustvaril prvotno zahtevo.

Reševanje tega problema se je izkazalo za težko, vendar je postalo mogoče zaradi usmerjanja na podlagi pravilnika:

Za boljše razumevanje postopka je tukaj blokovni diagram netfilterja:

Najprej, kot v prejšnjem primeru, ustvarimo dodatno usmerjevalno tabelo:

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

Zdaj pa dodamo nekaj pravil v 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

Ta pravila bodo označila dohodne povezave z vmesnikom eth0.100, ki označuje vse pakete z oznako 0x100, bodo tudi odgovori znotraj iste povezave označeni z isto oznako.

Zdaj lahko dodamo pravilo usmerjanja:

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

To so vsi paketi z izvornim naslovom 1.2.3.0/24 in oznako 0x100 je treba usmeriti s tabelo 100.

Tako drugi paketi, prejeti na drugem vmesniku, niso predmet tega pravila, kar bo omogočilo njihovo usmerjanje s standardnimi orodji Kubernetes.

Pa še ena stvar, v Linuxu obstaja tako imenovani filter povratne poti, ki pokvari vse skupaj, opravi preprosto preverjanje: za vse dohodne pakete spremeni izvorni naslov paketa z naslovom pošiljatelja in preveri, ali paket lahko zapusti prek istega vmesnika, na katerem je bil prejet, če ne, ga bo filtriral.

Težava je v tem, da v našem primeru ne bo delovalo pravilno, vendar ga lahko onemogočimo:

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

Upoštevajte, da prvi ukaz nadzoruje globalno vedenje rp_filter; če ni onemogočen, drugi ukaz ne bo imel učinka. Vendar pa bodo preostali vmesniki ostali z omogočenim rp_filter.

Da ne bi popolnoma omejili delovanja filtra, lahko za netfilter uporabimo implementacijo rp_filter. Z uporabo rpfilterja kot modula iptables lahko konfigurirate precej prilagodljiva pravila, na primer:

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

omogočite rp_filter na vmesniku eth0.100 za vse naslove razen 1.2.3.0/24.

Vir: www.habr.com