Hiljuti kohtusin üsna ebatavalise ülesandega MetalLB marsruutimise seadistamiseks. See ei tohiks olla probleem, sest tavaliselt ei ole MetalLB jaoks vaja mingeid lisameetmeid, kuid meie puhul on tegemist piisavalt suure klastriga, millel on üsna lihtne võrgu konfiguratsioon.

Selles artiklis räägin, kuidas seadistada source-based ja policy-based marsruutimist teie klastrisse suunatud välistesse võrkudesse.

Ma ei hakka üksikasjalikult peatuma MetalLB installimisel ja seadistamisel, kuna eeldan, et teil on juba mingit kogemust. Pakun, et liigume kohe asja juurde, nimelt marsruutimise seadistamisele. Seega on meil neli juhtumit:

Juhtum 1: Kui seadistamine ei ole vajalik

Vaatame lihtsat juhtumit.

Lisaks marsruutimise seadistamine ei ole vajalik, kui MetalLB välja antud aadressid asuvad samas alamvõrgus kui teie sõlmede aadressid.

Näiteks teil on alamvõrk 192.168.1.0/24, millel 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 see nii on? 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 jaotuse piires olevad aadressid saavad neid kasutada ilma täiendavate sammudeta.

Juhtum 2: Kui on vajalik täiendav seadistamine

Te peaksite seadistama täiendavad marsruudid iga kord, kui teie noodidel ei ole seadistatud IP-aadressid või marsruuti alamvõrku, mille jaoks MetalLB aadresse väljastab.

Selgitan natuke lähemalt. Iga kord, kui MetalLB aadressi väljastab, sarnaneb see lihtsa määramisega:

ip addr add 10.9.8.7/32 dev lo

Pange tähele:

• a) Aadress määratakse eelistuks /32 st, et marsruuti alamvõrku selle jaoks automaatselt ei lisandu (see on lihtsalt aadress)
• b) Aadress kinnitatakse mistahes noodide liidesele (näiteks loopback). Siinkohal tasub mainida Linuxi võrgu stack'i omadust. Pole tähtis, millisele liidesele aadressi lisate, tuum käsitleb alati arp-päringute ja saadab arp-vastuseid mistahes neist, see käitumine on korrektne ja mida 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

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

Siiski ei kasuta MetalLB kerne arp-päringute töötlemiseks, vaid teeb seda ise kasutajaruumi tasemel. Seetõttu ei mõjuta see valik MetalLB tööd.

Naaseme meie ülesande juurde. Kui teie sõlmedel ei ole väljastatavate aadresside 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, kui saate pakette läbi eraldi värava, mitte selle, mis on teie vaikimisi seadistatud. Seetõttu peavad ka vastavad paketid minema läbi sama värava.

Näiteks, teil on sama alamvõrk 192.168.1.0/24 kasutamiseks teie sõlmedele, kuid soovite väliseid aadresse MetalLB abil väljastada. Oletame, et teil on mitu aadressi alamvõrgus 1.2.3.0/24 VLAN 100, ja soovite neid kasutada Kubernetes teenustele väljastamiseks.

Kui pöördute aadressile 1.2.3.4 teete päringuid teisest alamvõrgust kui 1.2.3.0/24 ja oodata vastust. Sõlm, mis hetkel on MetalLB aadressi jaoks meistriks 1.2.3.4, saab paketi ruuterilt 1.2.3.1, kuid vastus peab liikuma sama marsruudi kaudu, läbi 1.2.3.1.

Kuna meie sõlm on juba seadistatud vaikimisi gateway'iks 192.168.1.1, siis vastus saadetakse vaikimisi sinna, mitte 1.2.3.1, läbi mille me paketi saime.

Kuidas sellises olukorras toime tulla?

Sellisel juhul peate valmistama kõik oma sõlmed ette nii, et need oleksid valmis teenindama väliseid aadresse ilma lisaseadeteta. Nii et ülaltoodud näite puhul 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 siis lisada marsruutide:

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 marsruute lisame eraldi marsruutimistabelisse 100 see sisaldab ainult kahte marsruuti, mis on vajalikud vastupaketi 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 on 1.2.3.0/24, siis tuleb kasutada marsruutimistabelit 100. See on meil juba kirjeldatud marsruut, mis saadab selle läbi 1.2.3.1

Juhtum 4: Kui on vajalik poliitikapõhine marsruutimine

Võrgutopoloogia nagu eelnevas näites, kuid oletame, et soovite ka võimalust pöörduda välistesse aadressidesse grupist 1.2.3.0/24 teie pod'idest:

Eelis seisneb selles, et pöördudes mis tahes aadressi poole 1.2.3.0/24, jõuab vastav pakett sõlme ja sellel on allika aadress vahemikus 1.2.3.0/24 saab see usaldusväärselt saadetud eth0.100, kuid me soovime, et Kubernetes suunaks selle meie esimesse pod'i, mis algselt saatis päringu.

Selle probleemi lahendamine osutus keeruliseks, kuid see sai võimalikuks poliitikapõhise marsruutimise tänu:

Protsessi parema mõistmise nimel toon välja netfilter'i plokkskeemi:

Alustuseks, nagu eelnevas näites, loome lisaks marsruuditabeli:

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 iptables'esse 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ärgistavad sisenevad ühendused liideses eth0.100, tähistades kõiki pakette sildiga 0x100, sama sildiga märgistatakse ka vastused ühe ühenduse raames.

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 paketid, mille allika aadress on 1.2.3.0/24 ja silt 0x100 peavad olema marsruutitud kasutades tabelit 100.

Seega ei kuulu teised paketid, mis saavad teise liidese kaudu, sellele reeglile, mis võimaldab neil olla marsruutitud Kubernetes'e tavaliste vahenditega.

On veel üks aga, Linuxis on olemas nn tagasitee filtrid, mis rikuvad kogu olukorra — nad teevad lihtsa kontrolli: kõikide sisse tulevate pakettide puhul muudavad nad paketi allika aadressi saatja aadressiks ja kontrollivad, kas pakett saab minna sama liidese kaudu, mille kaudu seda saadi; kui ei, siis filtreeritakse see välja.

Probleem on selles, et meie puhul töötab see ebaühtlaselt, aga me 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 kontrollib rp_filter globaalset käitumist; kui seda ei keelata, siis teine käsk ei toimi. Siiski jäävad teised liidesed rp_filteriga sisse lülitatud.

Kuna mitte piirata filtri tööd täielikult, saame kasutada rp_filter'i rakendust netfilter'is. Kasutades rpfilter'it iptables'i moodulina, on võimalik seadistada 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ülitage rp_filter sisse liidesel eth0.100 kõigi aadresse välja arvatud 1.2.3.0/24.

Allikas: habr.com