Mitte kaua aega tagasi seisin silmitsi väga ebatavalise ülesandega seadistada MetalLB jaoks marsruutimine. Kõik oleks hästi, sest... Tavaliselt MetalLB lisatoiminguid ei nõua, kuid meie puhul on meil üsna suur klaster väga lihtsa võrgukonfiguratsiooniga.

Selles artiklis räägin teile, kuidas konfigureerida teie klastri välisvõrgu allikapõhist ja poliitikapõhist marsruutimist.

Ma ei hakka MetalLB installimise ja konfigureerimise kohta üksikasjalikult rääkima, kuna eeldan, et teil on juba kogemusi. Soovitan minna otse asja juurde, nimelt marsruudi seadistamise juurde. Seega on meil neli juhtumit:

1. juhtum: kui konfigureerimist pole vaja

Vaatame lihtsat juhtumit.

Täiendav marsruutimise konfiguratsioon pole vajalik, kui MetalLB väljastatud aadressid on teie sõlmede aadressidega samas alamvõrgus.

Näiteks on teil alamvõrk 192.168.1.0/24, sellel on ruuter 192.168.1.1ja teie sõlmed saavad aadressid: 192.168.1.10-30, siis MetalLB puhul saate vahemikku reguleerida 192.168.1.100-120 ja veenduge, et need töötavad ilma täiendava konfiguratsioonita.

Miks nii? Kuna teie sõlmedes on marsruudid juba konfigureeritud:

# 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 samast vahemikust pärit aadressid kasutavad neid uuesti ilma täiendavate toiminguteta.

2. juhtum: kui on vaja täiendavat kohandamist

Peaksite konfigureerima lisamarsruute alati, kui teie sõlmedel pole konfigureeritud IP-aadressi või marsruuti alamvõrku, mille jaoks MetalLB aadressid väljastab.

Selgitan veidi täpsemalt. Kui MetalLB väljastab aadressi, saab seda võrrelda lihtsa ülesandega, näiteks:

ip addr add 10.9.8.7/32 dev lo

Pööra tähelepanu:

• a) Aadress määratakse eesliitega /32 see tähendab, et marsruuti ei lisata automaatselt selle alamvõrku (see on lihtsalt aadress)
• b) Aadress on lisatud mis tahes sõlme liidesele (näiteks loopback). Siinkohal tasub mainida Linuxi võrgupinu funktsioone. Olenemata sellest, millisele liidesele aadressi lisate, töötleb kernel alati arp-päringuid ja saadab neile arp-vastuseid, seda käitumist peetakse õigeks ja pealegi on see üsna laialt kasutusel sellises dünaamilises keskkonnas nagu Kubernetes.

Seda käitumist saab kohandada, lubades näiteks 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 selgesõnaliselt konkreetset IP-aadressi. See säte on vajalik, kui kavatsete kasutada MetalLB-d ja teie kube-puhverserver töötab IPVS-režiimis.

Kuid MetalLB ei kasuta kernelit arp-päringute töötlemiseks, vaid teeb seda ise kasutajaruumis, nii et see valik ei mõjuta MetalLB tööd.

Tuleme tagasi oma ülesande juurde. Kui väljastatud aadresside marsruuti teie sõlmedes pole, lisage see eelnevalt kõikidele sõlmedele:

ip route add 10.9.8.0/24 dev eth1

3. juhtum: kui vajate allikapõhist marsruutimist

Kui saate pakette eraldi lüüsi kaudu, mitte vaikimisi seadistatud lüüsi kaudu, peate konfigureerima allikapõhise marsruutimise, seetõttu peaksid ka vastusepaketid läbima sama lüüsi.

Näiteks on teil sama alamvõrk 192.168.1.0/24 pühendatud teie sõlmedele, kuid soovite väljastada väliseid aadresse MetalLB abil. Oletame, et teil on alamvõrgust mitu aadressi 1.2.3.0/24 asuvad VLAN 100-s ja soovite neid kasutada väliselt Kubernetese teenustele juurdepääsuks.

Kui ühendust võtta 1.2.3.4 esitate taotlusi teisest alamvõrgust kui 1.2.3.0/24 ja oota vastust. Sõlm, mis on praegu MetalLB väljastatud aadressi juht 1.2.3.4, saab paketi ruuterilt vastu 1.2.3.1, kuid vastus tema jaoks peab tingimata minema sama teed, läbima 1.2.3.1.

Kuna meie sõlmel on juba konfigureeritud vaikelüüs 192.168.1.1, siis vaikimisi saadetakse vastus talle, mitte 1.2.3.1, mille kaudu saime paki kätte.

Kuidas selle olukorraga toime tulla?

Sel juhul peate kõik oma sõlmed ette valmistama nii, et need oleksid valmis teenindama väliseid aadresse ilma täiendava konfiguratsioonita. See tähendab, et ülaltoodud näite puhul peate sõlmes eelnevalt looma VLAN-liidese:

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

Ja siis lisa 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 lisame marsruudid eraldi marsruutimistabelisse 100 see sisaldab ainult kahte marsruuti, mis on vajalikud vastusepaketi saatmiseks läbi lüüsi 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 selgesõnaliselt: kui paketi lähteaadress on sees 1.2.3.0/24, siis peate kasutama marsruutimistabelit 100. Selles oleme juba kirjeldanud marsruuti, mis ta läbi saadab 1.2.3.1

4. juhtum: kui vajate poliitikapõhist marsruutimist

Võrgu topoloogia on sama, mis eelmises näites, kuid oletame, et soovite pääseda juurde ka välistele basseini aadressidele 1.2.3.0/24 teie kaunadest:

Omapära on see, et mis tahes aadressile sisenemisel 1.2.3.0/24, tabab vastusepakett sõlme ja selle lähteaadress on vahemikus 1.2.3.0/24 saadetakse kuulekalt eth0.100, kuid tahame, et Kubernetes suunaks selle ümber meie esimesse kausta, mis genereeris algse taotluse.

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

Protsessi paremaks mõistmiseks on siin netfiltri plokkskeem:

Esiteks, nagu eelmises näites, loome täiendava marsruutimistabeli:

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 iptablesile 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 sissetulevad ühendused liidesega eth0.100, märkides kõik paketid sildiga 0x100, märgitakse sama ühenduse vastused samuti sama sildiga.

Nüüd saame lisada marsruutimise reegli:

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

See tähendab, et kõik lähteaadressiga paketid 1.2.3.0/24 ja märgista 0x100 tuleb suunata tabeli abil 100.

Seega ei kehti see reegel muudele teisele liidesele vastuvõetud pakettidele, mis võimaldab neid marsruutida standardsete Kubernetese tööriistade abil.

On veel üks asi, Linuxis on nn pöördtee filter, mis rikub kogu asja ära, see teeb lihtsa kontrolli: kõikide sissetulevate pakettide puhul muudab paketi lähteaadressi koos saatja aadressiga ja kontrollib, kas pakett võib lahkuda sama liidese kaudu, millel see vastu võeti, kui mitte, filtreerib see selle välja.

Probleem on selles, et meie puhul see ei tööta korralikult, kuid saame selle keelata:

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 juhib rp_filter globaalset käitumist; kui see pole keelatud, siis teisel käsul pole mõju. Ülejäänud liidesed jäävad aga rp_filter lubatud.

Et mitte täielikult filtri tööd piirata, saame netfiltri jaoks kasutada rp_filter teostust. Rpfilterit iptablesi moodulina kasutades saate konfigureerida üsna 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

lubage liidesel rp_filter eth0.100 kõikidele aadressidele v.a 1.2.3.0/24.

Allikas: www.habr.com