Neseniai susidūriau su labai neįprasta užduotimi – nustatyti „MetalLB“ maršrutą. Viskas būtų gerai, nes... Paprastai MetalLB nereikalauja jokių papildomų veiksmų, tačiau mūsų atveju turime gana didelį klasterį su labai paprasta tinklo konfigūracija.

Šiame straipsnyje papasakosiu, kaip sukonfigūruoti šaltiniu ir politika pagrįstą maršrutą jūsų klasterio išoriniame tinkle.

Aš nesigilinsiu į MetalLB diegimą ir konfigūravimą, nes manau, kad jau turite tam tikros patirties. Siūlau eiti tiesiai prie reikalo, ty maršruto nustatymo. Taigi turime keturis atvejus:

1 atvejis: kai nereikia konfigūruoti

Pažiūrėkime į paprastą atvejį.

Papildomos maršruto parinkimo konfigūracijos nereikia, kai MetalLB išduoti adresai yra tame pačiame potinklyje kaip ir jūsų mazgų adresai.

Pavyzdžiui, turite potinklį 192.168.1.0/24, jame yra maršrutizatorius 192.168.1.1, o jūsų mazgai gauna adresus: 192.168.1.10-30, tada MetalLB galite reguliuoti diapazoną 192.168.1.100-120 ir įsitikinkite, kad jie veiks be jokios papildomos konfigūracijos.

Kodėl taip? Kadangi jūsų mazgai jau sukonfigūruoti maršrutai:

# 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

Ir adresai iš to paties diapazono juos naudos pakartotinai be jokių papildomų veiksmų.

2 atvejis: kai reikia papildomo tinkinimo

Turėtumėte konfigūruoti papildomus maršrutus, kai mazgai neturi sukonfigūruoto IP adreso arba maršruto į potinklį, kuriam MetalLB išduoda adresus.

Paaiškinsiu šiek tiek plačiau. Kai MetalLB išveda adresą, jį galima palyginti su paprasta užduotimi, tokia kaip:

ip addr add 10.9.8.7/32 dev lo

Atkreipkite dėmesį į:

• a) Adresas priskiriamas su priešdėliu /32 tai yra, maršrutas nebus automatiškai įtrauktas į jo potinklį (tai tik adresas)
• b) Adresas pridedamas prie bet kurios mazgo sąsajos (pavyzdžiui, grįžtamojo ryšio). Čia verta paminėti „Linux“ tinklo krūvos ypatybes. Nesvarbu, prie kurios sąsajos pridėsite adresą, branduolys visada apdoros arp užklausas ir siųs arp atsakymus į bet kurią iš jų, toks elgesys laikomas teisingu ir, be to, yra gana plačiai naudojamas tokioje dinamiškoje aplinkoje kaip Kubernetes.

Šį elgesį galima tinkinti, pavyzdžiui, įgalinant griežtą arp:

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

Tokiu atveju arp atsakymai bus siunčiami tik tuo atveju, jei sąsajoje yra aiškiai nurodytas konkretus IP adresas. Šis nustatymas reikalingas, jei planuojate naudoti MetalLB ir jūsų kube tarpinis serveris veikia IPVS režimu.

Tačiau MetalLB nenaudoja branduolio ARP užklausoms apdoroti, o tai atlieka pats vartotojo erdvėje, todėl ši parinktis neturės įtakos MetalLB veikimui.

Grįžkime prie savo užduoties. Jei maršruto išduotiems adresams jūsų mazguose nėra, iš anksto pridėkite jį prie visų mazgų:

ip route add 10.9.8.0/24 dev eth1

3 atvejis: kai reikia šaltiniu pagrįsto maršruto

Turėsite sukonfigūruoti šaltiniu pagrįstą maršrutą, kai gaunate paketus per atskirą šliuzą, o ne tą, kuris sukonfigūruotas pagal numatytuosius nustatymus, todėl atsakymo paketai taip pat turėtų eiti per tą patį šliuzą.

Pavyzdžiui, jūs turite tą patį potinklį 192.168.1.0/24 skirta jūsų mazgams, bet norite išduoti išorinius adresus naudodami MetalLB. Tarkime, kad iš potinklio turite kelis adresus 1.2.3.0/24 esančius VLAN 100 ir norite juos naudoti norėdami pasiekti Kubernetes paslaugas iš išorės.

Susisiekus 1.2.3.4 teiksite užklausas iš kito potinklio nei 1.2.3.0/24 ir laukti atsakymo. Mazgas, kuris šiuo metu yra pagrindinis MetalLB išduoto adreso 1.2.3.4, gaus paketą iš maršrutizatoriaus 1.2.3.1, bet atsakymas jam būtinai turi eiti tuo pačiu keliu, per 1.2.3.1.

Kadangi mūsų mazgas jau turi sukonfigūruotą numatytąjį šliuzą 192.168.1.1, tada pagal numatytuosius nustatymus atsakymas bus išsiųstas jam, o ne 1.2.3.1, per kurią gavome siuntinį.

Kaip susidoroti su šia situacija?

Tokiu atveju turite paruošti visus mazgus taip, kad jie būtų pasirengę aptarnauti išorinius adresus be papildomos konfigūracijos. Tai reiškia, kad aukščiau pateiktame pavyzdyje turite iš anksto sukurti VLAN sąsają mazge:

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

Tada pridėkite maršrutus:

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

Atkreipkite dėmesį, kad maršrutus įtraukiame į atskirą maršruto lentelę 100 jame bus tik du maršrutai, reikalingi atsakymo paketui išsiųsti per šliuzą 1.2.3.1, esantis už sąsajos eth0.100.

Dabar turime pridėti paprastą taisyklę:

ip rule add from 1.2.3.0/24 lookup 100

kuri aiškiai sako: jei paketo šaltinio adresas yra 1.2.3.0/24, tuomet reikia naudoti maršruto parinkimo lentelę 100. Jame mes jau aprašėme maršrutą, kuriuo jis pasiųs 1.2.3.1

4 atvejis: kai reikia politika pagrįsto maršruto

Tinklo topologija yra tokia pati kaip ir ankstesniame pavyzdyje, bet tarkime, kad taip pat norite turėti prieigą prie išorinių telkinių adresų 1.2.3.0/24 iš jūsų ankščių:

Ypatumas yra tas, kad pasiekiant bet kurį adresą 1.2.3.0/24, atsakymo paketas patenka į mazgą ir turi šaltinio adresą diapazone 1.2.3.0/24 bus klusniai nusiųstas į eth0.100, bet norime, kad „Kubernetes“ nukreiptų jį į mūsų pirmąjį bloką, kuris sugeneravo pradinę užklausą.

Išspręsti šią problemą pasirodė sunku, tačiau tai tapo įmanoma dėl politika pagrįsto maršruto parinkimo:

Norėdami geriau suprasti procesą, pateikiame tinklo filtro blokinę diagramą:

Pirmiausia, kaip ir ankstesniame pavyzdyje, sukurkime papildomą maršruto parinkimo lentelę:

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

Dabar pridėkime keletą taisyklių prie 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

Šios taisyklės pažymės gaunamus ryšius su sąsaja eth0.100, pažymėdami visus paketus žyma 0x100, to paties ryšio atsakymai taip pat bus pažymėti ta pačia žyma.

Dabar galime pridėti maršruto parinkimo taisyklę:

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

Tai yra, visi paketai su šaltinio adresu 1.2.3.0/24 ir pažymėkite 0x100 turi būti nukreiptas naudojant lentelę 100.

Taigi kitiems paketams, gautiems kitoje sąsajoje, ši taisyklė netaikoma, todėl juos bus galima nukreipti naudojant standartinius Kubernetes įrankius.

Yra dar vienas dalykas, Linuxe yra vadinamasis atvirkštinio kelio filtras, kuris sugadina viską, jis atlieka paprastą patikrinimą: visiems įeinantiems paketams pakeičia paketo šaltinio adresą su siuntėjo adresu ir patikrina, ar paketas gali išeiti per tą pačią sąsają, kurioje buvo gautas, jei ne, jis jį išfiltruos.

Problema ta, kad mūsų atveju jis neveiks tinkamai, bet galime jį išjungti:

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

Atkreipkite dėmesį, kad pirmoji komanda valdo visuotinį rp_filter elgesį; jei ji nėra išjungta, antroji komanda neturės jokios įtakos. Tačiau likusios sąsajos liks su įjungta rp_filter.

Kad visiškai neapribotume filtro veikimo, netfilter galime naudoti rp_filter įgyvendinimą. Naudodami rpfilter kaip iptables modulį, galite sukonfigūruoti gana lanksčias taisykles, pavyzdžiui:

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

sąsajoje įgalinkite rp_filter eth0.100 visiems adresams, išskyrus 1.2.3.0/24.

Šaltinis: www.habr.com