Pak kohë më parë u përballa me një detyrë mjaft të pazakontë për rregullimin e rrugëzimit për MetalLB. Nuk do të kishte ndonjë problem, për shkak se zakonisht për MetalLB nuk nevojiten veprime të tjera, por në rastin tonë kemi një grup të madh me një konfigurim mjaft të thjeshtë të rrjetit.

Në këtë artikull do të tregoj se si të konfigurojmë rrugëzimin bazuar në burim dhe politikë për rrjetin e jashtëm të grupit tuaj.

Nuk do të ndalem shumë në instalimin dhe konfigurimin e MetalLB, pasi supokoj se keni disa përvojë. Propozoj të kalojmë drejtpërdrejt në punë, konkretisht në rregullimin e rrugëzimit. Pra, kemi katër raste:

Rasti 1: Kur konfigurimi nuk nevojitet

Le të shqyrtojmë një rast të thjeshtë.

Për rregullimin e hollësishëm të rrugëzimit nuk nevojitet, kur adresat e dhëna nga MetalLB janë në të njëjtën nënrrjetë si adresat e nodëve tuaj.

Për shembull, keni një nënrrjetë 192.168.1.0/24, ka një rrugëzim 192.168.1.1, dhe nodët tuaj marrin adresat: 192.168.1.10-30, atëherë për MetalLB mund të konfiguroni një diapazon 192.168.1.100-120 dhe të jeni të sigurt se ata do të funksionojnë pa ndonjë konfigurim të mëtejshëm.

Pse kështu? Sepse nodet tuaja tashmë kanë konfigurime 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

Dhe adresat nga e njëjta rang do të ripërdoren pa ndonjë lëvizje shtesë.

Rasti 2: Kur kërkohet konfigurim shtesë

Ju duhet të konfiguroni rute shtesë sa herë që nodet tuaja nuk kanë një adresat IP ose rrugë në nëndegën për të cilën MetalLB jep adresat.

Do ta shpjegoj pak më në detaje. Sa herë që MetalLB jep një adresë, kjo mund të krahasohet me një caktim të thjeshtë si:

ip addr add 10.9.8.7/32 dev lo

Vini re se:

• a) Adresa caktohet me prefiks /32 pra, ruga në nëndeg për të nuk do të shtohet automatikisht (kjo është thjesht një adresë)
• b) Adresa vendoset në çdo ndërfaqe të nodës (për shembull, loopback). Këtu duhet të përmendim mbi veçorinë e stack-ut rrjetor të Linux. Nuk ka rëndësi në cilën ndërfaqe e shtoni adresën, bërthama gjithmonë do të përpunojë kërkesat arp dhe do të dërgojë përgjigje arp në ndonjë prej tyre, ky sjellje konsiderohet e saktë dhe, për më tepër, përdoret mjaft gjerësisht në një mjedis dinamik si Kubernetes.

Kjo sjellje mund të konfigurohet, për shembull duke aktivizuar arp të ngurtë:

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

Në këtë rast, përgjigjet ARP do të dërgohen vetëm nëse ndërfaqja përmban saktësisht adresën IP specifike. Kjo konfigurim është e domosdoshme nëse planifikoni të përdorni MetalLB dhe kube-proxy juaj funksionon në modalitetin IPVS.

Megjithatë, MetalLB nuk përdor bërthamën për të përpunuar kërkesat ARP, por e bën këtë vetë në hapësirën e përdoruesit; kështu që kjo opsion nuk do të ndikojë në funksionimin e MetalLB.

Të kthehemi në detyrën tonë. Nëse nuk ka rrugë për adresat e lëshuara në nodet tuaja, shtojeni këtë paraprakisht në të gjitha nodet:

ip route add 10.9.8.0/24 dev eth1

Rasti 3: Kur do të nevojitet routing me bazë burimi

Routing me bazë burimi duhet të konfigurohet kur merrni paketa përmes një gateway-i të veçantë, ndryshe nga ai që është konfigurim standard, për rrjedhojë, paketat përgjigje gjithashtu duhet të shkojnë përmes këtij gateway-i.

Për shembull, keni të njëjtën subnet 192.168.1.0/24 të dedikuar për nodet tuaja, por dëshironi të lëshoni adresat e jashtme përmes MetalLB. Supozoni se keni disa adresa nga subneti 1.2.3.0/24 që ndodhen në VLAN 100, dhe dëshironi t'i përdorni ato për qasje në shërbimet Kubernetes nga jashtë.

Kur t'i qaset 1.2.3.4 do të bëni kërkesa nga një subnet tjetër se 1.2.3.0/24 dhe do të prisni përgjigje. Noda që aktualisht është master për adresën MetalLB të dhënë 1.2.3.4, do të këtë paketën nga routeri 1.2.3.1, por përgjigja për të duhet patjetër të shkojë në të njëjtën rrugë, përmes 1.2.3.1.

Duke qenë se noda jonë ka një gateway të paracaktuar 192.168.1.1, përgjigja do të shkojë tek ai, dhe jo tek 1.2.3.1, përmes të cilit morëm paketën.

Si ta zgjidhim këtë situatë?

Në këtë rast, ju duhet të përgatitni të gjithë nodat tuaja në mënyrë që ato të jenë të gatshme për të shërbyer adresat e jashtme pa konfigurim të mëtejshëm. Kështu, për shembullin e mësipërm, ju duhet të krijoni paraprakisht një ndërfaqe VLAN në nodën:

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

Dhe më pas të shtoni ruterat:

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

Vini re se ruterat i shtojmë në një tabelë të veçantë ruterimi 100 ajo do të përmbajë vetëm dy ruterat e nevojshëm për dërgimin e paketës përgjigjëse përmes gateway-it 1.2.3.1, që ndodhet pas ndërfaqes eth0.100.

Tani ne duhet të shtojmë një rregull të thjeshtë:

ip rule add from 1.2.3.0/24 lookup 100

që tregon qartë: nëse adresa e burimit të paketës ndodhet në 1.2.3.0/24, atëherë duhen përdorur tabelat e drejtimit 100. Në të kemi përshkruar tashmë rrugën që do ta dërgojë përmes 1.2.3.1

Rasti 4: Kur do të nevojitet routing i bazuar në politika

Topologjia e rrjetit është si në shembullin e mëparshëm, por le të supozojmë se dëshironi gjithashtu të keni mundësinë për t'u lidhur me adresat e jashtme të grupit 1.2.3.0/24 nga pod-et tuaja:

Karakteristika qëndron në faktin se kur lidheni me çdo adresë në 1.2.3.0/24, paketa përgjigjeje duke mbërritur në nodë dhe duke pasur adresën e burimit në diapazonin 1.2.3.0/24 do të dërgohet në eth0.100, por ne duam që Kubernetes ta redirektojë atë në pod-in tonë të parë, i cili e gjeneroi kërkesën fillestare.

Zgjidhja e këtij problemi doli të ishte e vështirë, por kjo u bë e mundur falë routing-ut të bazuar në politika:

Për të kuptuar më mirë procesin, do të sjell një diagram bllok netto:

Së pari, si në shembullin e mëparshëm, le të krijojmë një tabelë të re drejtimi:

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

Tani do të shtojmë disa rregulla në 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

Këto rregulla do të etiketojnë lidhjet e ardhshme në ndërfaqe eth0.100, duke e etiketuar të gjithë paketat me etiketë 0x100, me të njëjtën etiketë do të etiketohen edhe përgjigjet brenda një lidhjeje.

Tani mund të shtojmë një rregull rrugëzimi:

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

Pra, të gjitha paketat me adresën e burimit 1.2.3.0/24 dhe etiketën 0x100 duhet të rrugëzohen duke përdorur tabelën 100.

Kështu që paketat e tjera, që pranohen në një ndërfaqe tjetër, nuk bien nën këtë rregull, duke lejuar që ato të rrugëzohen në mënyrë standarde nga Kubernetes.

Ka edhe një problem, në Linux ekziston një filtrues i njohur si reverse path filter, i cili prish gjithçka dhe kryen një kontroll të thjeshtë: për të gjitha paketat e ardhshme ai ndryshon adresën e burimit të paketës me adresën e dërguesit dhe kontrollon nëse paketa mund të shkojë nëpër të njëjtën ndërfaqe nga e cila është marrë, nëse jo, atëherë e filtronte atë.

Problemi është se në rastin tonë do të funksionojë në mënyrë të papërshtatshme, por mund ta çaktivizojmë atë:

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

Kujdes, ekipi i parë kontrollon sjelljen globale të rp_filter, nëse nuk e çaktivizoni atë, atëherë ekipi i dytë nuk do të ketë asnjë efekt. Megjithatë, ndërfaqet e tjera do të mbeten me rp_filter të aktivizuar.

Për të mos e kufizuar plotësisht funksionimin e filtrit, mund të përdorim zbatimin e rp_filter për netfilter. Duke përdorur rpfilter si një moduli iptables, mund të konfiguroni rregulla të mjaft fleksibël, për shembull:

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

aktivizoni rp_filter në ndërfaqe eth0.100 për të gjitha adresat përveç 1.2.3.0/24.

Burimi: habr.com