Nedavno sam se suočio s vrlo neobičnim zadatkom postavljanja usmjeravanja za MetalLB. Sve bi bilo dobro, jer... Obično MetalLB ne zahtijeva nikakve dodatne radnje, ali u našem slučaju imamo prilično velik klaster s vrlo jednostavnom konfiguracijom mreže.

U ovom članku ću vam reći kako konfigurirati usmjeravanje temeljeno na izvoru i politici za vanjsku mrežu vašeg klastera.

Neću ulaziti u detalje o instaliranju i konfiguriranju MetalLB-a, jer pretpostavljam da već imate iskustva. Predlažem da odmah prijeđemo na stvar, naime na postavljanje usmjeravanja. Dakle, imamo četiri slučaja:

Slučaj 1: Kada nije potrebna konfiguracija

Pogledajmo jednostavan slučaj.

Dodatna konfiguracija usmjeravanja nije potrebna kada su adrese koje izdaje MetalLB u istoj podmreži kao i adrese vaših čvorova.

Na primjer, imate podmrežu 192.168.1.0/24, ima ruter 192.168.1.1, a vaši čvorovi primaju adrese: 192.168.1.10-30, onda za MetalLB možete prilagoditi raspon 192.168.1.100-120 i budite sigurni da će raditi bez dodatne konfiguracije.

Zašto je to? Budući da vaši čvorovi već imaju konfigurirane rute:

# 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

A adrese iz istog raspona ponovno će ih upotrijebiti bez dodatnih radnji.

Slučaj 2: Kada je potrebna dodatna prilagodba

Trebali biste konfigurirati dodatne rute kad god vaši čvorovi nemaju konfiguriranu IP adresu ili rutu do podmreže za koju MetalLB izdaje adrese.

Objasnit ću malo detaljnije. Kad god MetalLB ispiše adresu, to se može usporediti s jednostavnom dodjelom kao što je:

ip addr add 10.9.8.7/32 dev lo

Obrati pozornost na:

• a) Adresa se dodjeljuje s prefiksom /32 to jest, ruta neće biti automatski dodana u podmrežu za nju (to je samo adresa)
• b) Adresa je pridružena bilo kojem sučelju čvora (na primjer povratna petlja). Ovdje je vrijedno spomenuti značajke Linux mrežnog skupa. Bez obzira kojem sučelju dodate adresu, kernel će uvijek obraditi arp zahtjeve i poslati arp odgovore na bilo koji od njih, ovo se ponašanje smatra ispravnim i, štoviše, prilično je široko korišteno u tako dinamičnom okruženju kao što je Kubernetes.

Ovo se ponašanje može prilagoditi, na primjer omogućavanjem strogog arp-a:

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

U ovom slučaju, arp odgovori će biti poslani samo ako sučelje eksplicitno sadrži određenu IP adresu. Ova postavka je potrebna ako planirate koristiti MetalLB i vaš kube-proxy radi u IPVS modu.

Međutim, MetalLB ne koristi kernel za obradu arp zahtjeva, već to čini sam u korisničkom prostoru, tako da ova opcija neće utjecati na rad MetalLB-a.

Vratimo se našem zadatku. Ako ruta za izdane adrese ne postoji na vašim čvorovima, dodajte je unaprijed svim čvorovima:

ip route add 10.9.8.0/24 dev eth1

Slučaj 3: Kada trebate usmjeravanje temeljeno na izvoru

Morat ćete konfigurirati usmjeravanje temeljeno na izvoru kada primate pakete preko zasebnog pristupnika, a ne onog koji je konfiguriran prema zadanim postavkama, stoga bi paketi odgovora također trebali proći kroz isti pristupnik.

Na primjer, imate istu podmrežu 192.168.1.0/24 posvećen vašim čvorovima, ali želite izdavati vanjske adrese koristeći MetalLB. Pretpostavimo da imate više adresa iz podmreže 1.2.3.0/24 koji se nalaze u VLAN 100 i želite ih koristiti za eksterni pristup Kubernetes uslugama.

Prilikom kontaktiranja 1.2.3.4 slat ćete zahtjeve s druge podmreže 1.2.3.0/24 i čekati odgovor. Čvor koji je trenutno glavni za adresu koju je izdao MetalLB 1.2.3.4, primit će paket od usmjerivača 1.2.3.1, ali odgovor za njega mora nužno ići istim putem, kroz 1.2.3.1.

Budući da naš čvor već ima konfiguriran zadani pristupnik 192.168.1.1, tada će prema zadanim postavkama odgovor ići njemu, a ne 1.2.3.1, preko koje smo primili paket.

Kako se nositi s ovom situacijom?

U tom slučaju trebate pripremiti sve svoje čvorove na takav način da budu spremni posluživati ​​vanjske adrese bez dodatne konfiguracije. To jest, za gornji primjer morate unaprijed stvoriti VLAN sučelje na čvoru:

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

Zatim dodajte rute:

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

Imajte na umu da rute dodajemo u zasebnu tablicu usmjeravanja 100 sadržavat će samo dvije rute potrebne za slanje paketa odgovora kroz pristupnik 1.2.3.1, koji se nalazi iza sučelja eth0.100.

Sada moramo dodati jednostavno pravilo:

ip rule add from 1.2.3.0/24 lookup 100

koji eksplicitno kaže: ako je izvorišna adresa paketa in 1.2.3.0/24, tada morate koristiti tablicu usmjeravanja 100. U njemu smo već opisali rutu kojom će ga poslati 1.2.3.1

Slučaj 4: Kada trebate usmjeravanje temeljeno na pravilima

Mrežna topologija je ista kao u prethodnom primjeru, ali recimo da također želite imati pristup vanjskim adresama bazena 1.2.3.0/24 iz vaših mahuna:

Posebnost je u tome što prilikom pristupa bilo kojoj adresi u 1.2.3.0/24, paket odgovora pogodi čvor i ima izvornu adresu u rasponu 1.2.3.0/24 bit će poslušno poslan na eth0.100, ali želimo da ga Kubernetes preusmjeri na naš prvi pod, koji je generirao izvorni zahtjev.

Pokazalo se da je rješavanje ovog problema teško, ali postalo je moguće zahvaljujući usmjeravanju temeljenom na pravilima:

Za bolje razumijevanje procesa, ovdje je netfilter blok dijagram:

Prvo, kao u prethodnom primjeru, kreirajmo dodatnu tablicu usmjeravanja:

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

Dodajmo sada nekoliko pravila u 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

Ova pravila će označiti dolazne veze na sučelje eth0.100, označavajući sve pakete oznakom 0x100, odgovori unutar iste veze također će biti označeni istom oznakom.

Sada možemo dodati pravilo usmjeravanja:

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

To jest, svi paketi s izvornom adresom 1.2.3.0/24 i oznaka 0x100 mora se usmjeriti pomoću tablice 100.

Dakle, drugi paketi primljeni na drugom sučelju ne podliježu ovom pravilu, što će omogućiti njihovo usmjeravanje pomoću standardnih Kubernetes alata.

Ima još jedna stvar, u Linuxu postoji takozvani reverse path filter, koji kvari cijelu stvar, on radi jednostavnu provjeru: za sve dolazne pakete mijenja izvornu adresu paketa s adresom pošiljatelja i provjerava je li paket može otići kroz isto sučelje na kojem je primljen, ako ne, filtrirat će ga.

Problem je što u našem slučaju neće raditi ispravno, ali možemo ga onemogućiti:

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

Imajte na umu da prva naredba kontrolira globalno ponašanje rp_filter; ako nije onemogućena, druga naredba neće imati učinka. Međutim, preostala sučelja ostat će s uključenim rp_filterom.

Kako ne bismo potpuno ograničili rad filtera, možemo koristiti implementaciju rp_filter za netfilter. Koristeći rpfilter kao iptables modul, možete konfigurirati prilično fleksibilna pravila, na primjer:

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

omogućiti rp_filter na sučelju eth0.100 za sve adrese osim 1.2.3.0/24.

Izvor: www.habr.com