Hiljuti sattusin üsna ebatavalisse ülesannetesse MetalLB marsruutimise seadistamiseks. Kõik oleks hästi, sest tavaliselt ei ole MetalLB jaoks vaja täiendavaid samme, kuid meie juhul on tegemist piisavalt suure klastriga üsna lihtsa võrgukonfiguratsiooniga.

Selles artiklis räägin, kuidas seadistada source-based ja policy-based marsruutimist teie klastrite välise võrgu jaoks.

Ma ei peatuks detailselt MetalLB installimise ja seadistamise juures, kuna eeldan, et teil on juba mingi kogemus. Pakun, et läheme kohe asja juurde, nimelt marsruutimise seadistamisele. Niisiis, meil on neli juhtumit:

Juhtum 1: Kui seadistust ei nõuta

Uurime lihtsat juhtumit.

Täiendavat marsruutimise seadistust ei nõuta, kui MetalLB antud aadressid asuvad samas alamvõrgus nagu teie sõlmede aadressid.

Näiteks teil on alamvõrk 192.168.1.0/24, seal on marsruuter 192.168.1.1, ja teie sõlmed saavad aadresse: 192.168.1.10-30, siis saate MetalLB jaoks seadistada vahemiku 192.168.1.100-120 ja olla kindel, et need töötavad ilma igasuguste täiendavate seadistusteta.

Miks mitte? Sest teie sõlmedel on juba seadistatud marsruudid:

# 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

Ja sama vahemiku aadressid kasutavad neid uuesti ilma igasuguste täiendavate sammudeta.

Juhtum 2: Kui on vajalik täiendav seadistus

Te peaksite seadistama täiendavad marsruudid igal ajal, kui teie sõlmedel ei ole seadistatud IP-aadressid või marsruuti alamvõrku, mille jaoks MetalLB aadresse välja annab.

Selgitan veidi põhjalikumalt. Iga kord, kui MetalLB annab välja aadressi, võib seda võrrelda lihtsa määramisega:

ip addr add 10.9.8.7/32 dev lo

Pange tähele:

• a) Aadress määratakse eellaiusega /32 , st marsruut alamvõrku ei lisata automaatselt (see on lihtsalt aadress)
• b) Aadress lisatakse ükskõik millisele sõlme liidesele (näiteks loopback). Siin on oluline mainida Linuxi võrgu stack'i eripära. Pole oluline, millisele liidesele te aadressi lisate, tuum töötleb alati arp-päringuid ja saadab arp-vastuseid igal liidesel, see käitumine on korrektne ja seda kasutatakse laialdaselt dünaamilises keskkonnas nagu Kubernetes.

Seda käitumist saab seadistada, näiteks lubades range arp:

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

Sel juhul saadetakse arp-vastused ainult siis, kui liides sisaldab selgelt konkreetset IP-aadressi. See seadistus on kohustuslik, kui plaanite kasutada MetalLB-d ja teie kube-proxy töötab IPVS-režiimis.

Siiski ei kasuta MetalLB tuuma arp-päringute töötlemiseks, vaid teeb seda iseseisvalt user-space'is, seega ei mõjuta see valik MetalLB tööd.

Naaseme meie ülesande juurde. Kui teie sõlmedel ei ole antud aadresside jaoks marsruuti, lisage see eelnevalt kõikidele sõlmedele:

ip route add 10.9.8.0/24 dev eth1

Juhtum 3: Kui on vajalik source-based routing

Source-based routing tuleb seadistada juhul, kui saate pakette eraldi gateway kaudu, mitte selle kaudu, mis on teie vaikeseade, seega peavad ka vastavad pakettid minema läbi sama gateway.

Näiteks, teil on endiselt sama alamvõrk 192.168.1.0/24 erakordseks oma sõlmede jaoks, kuid soovite väliseid aadresse välja anda MetalLB abil. Oletame, et teil on mõned aadressid alamvõrgust 1.2.3.0/24 VLAN 100-s, ja soovite neid kasutada Kubernetes teenuste ligipääsuks väljastpoolt.

Kui pöördute aadressi poole 1.2.3.4 saate päringuid teisest alamvõrgust kui 1.2.3.0/24 ja ootate vastust. Sõlm, mis on hetkel MetalLB antud aadressi jaoks meistriks 1.2.3.4, saab paketi ruuterilt 1.2.3.1, kuid vastus peab kindlasti minema sama marsruuti pidi, läbi 1.2.3.1.

Kuna meie sõlm juba omab seadistatud vaikeseadet 192.168.1.1, siis lähevad vastused vaikimisi sinna, mitte 1.2.3.1, kaudu, mille kaudu me paketi saime.

Kuidas sellest olukorrast üle saada?

Sel juhul peate valmistama ette kõik oma sõlmed nii, et nad oleksid valmis teenindama väliseid aadresse ilma täiendava seadistamiseta. Seega, antud näite jaoks peate eelnevalt looma VLAN-liidese sõlmes:

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

Ja seejärel lisama marsruudid:

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

Pange tähele, et marsruudid lisame eraldi marsruutimistabelisse 100 see sisaldab ainult kahte marsruuti, mis on vajalikud vastuse saatmiseks läbi gateway 1.2.3.1, mis asub liidese taga eth0.100.

Nüüd peame lisama lihtsa reegli:

ip rule add from 1.2.3.0/24 lookup 100

mis ütleb selgelt: kui paketi allika aadress asub 1.2.3.0/24, siis tuleb kasutada marsruutimistabelit 100. Siin on juba kirjeldatud marsruut, mis saadab selle läbi 1.2.3.1

Juhtum 4: Kui on vaja käsitsemispõhist marsruutimist

Võrgu topoloogia nagu eelnevas näites, kuid oletame, et soovite ka välistele aadressidele ligipääsu teie puu 1.2.3.0/24 teie pod'ide kaudu:

Eripära seisneb selles, et kui pöörduda mistahes aadressi poole, 1.2.3.0/24, tähendades, et vastus pakett, jõudes sõlme ja omades lähteaadressi vahemikus 1.2.3.0/24 saab usaldusväärselt saadetud eth0.100, kuid me soovime, et Kubernetes suunaks selle meie esimese pod'i juurde, mis algselt genereeris päringu.

Selle probleemi lahendamine osutus keeruliseks, kuid see sai võimalikuks tänu käsitsemispõhisele marsruutimisele:

Selle protsessi parema mõistmise jaoks toome kirjeldava skeemi netfilter:

Alustame, nagu eelnevas näites, täiendava marsruuditabeli loomisega:

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üüd lisame iptablesse mõned reeglid:

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

Need reeglid märgivad sissetulevaid ühendusi liidesel eth0.100, märkides kõik paketid sildiga 0x100, sama sildiga märgitakse ka vastused seoses sama ühendusega.

Nüüd saame lisada marsruudireegli:

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

See tähendab, et kõik paketid allika aadressiga 1.2.3.0/24 ja sildiga 0x100 peavad olema marsruudiga, kasutades tabelit 100.

Seetõttu ei jõua teised paketid, mis saabuvad teisele liidesele, selle reegli alla, mis võimaldab neil olla marsruudiga Kubernetes'i standardsete meetoditega.

On veel üks aga, Linuxis on olemas nn pöördfiltri kontroll, mis rikub kogu süsteemi ja teeb lihtsa kontrolli: kõikide sissetulevate paketide jaoks vahetab ta paketil lähteaadressi saatja aadressiga ja kontrollib, kas pakett võib lahkuda sama liidese kaudu, mille kaudu see saadi, kui ei, siis filtreeritakse see välja.

Probleem on selles, et meie juhul töötab see ebaõigesti, kuid me saame selle välja lülitada:

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

Pange tähele, et esimene käsk kontrollib rp_filteri globaalset käitumist, kui seda ei lülita välja, ei oma teine käsk mingit mõju. Sellegipoolest jäävad teised liidesed rp_filteriga sisse lülitatuks.

Kuna filtri töö häirimist vältida, saame kasutada rp_filteri rakendust netfilteris. Kasutades rpfilterit iptablesi moodulina, on võimalik seada piisavalt paindlikke reegleid, näiteks:

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

lülitab rp_filter'i sisse liidese kohta eth0.100 kõigile aadressidele peale 1.2.3.0/24.

Allikas: habr.com