Jo shumë kohë më parë u përballa me një detyrë shumë të pazakontë të vendosjes së rrugëtimit për MetalLB. Gjithçka do të ishte mirë, sepse... Zakonisht MetalLB nuk kërkon ndonjë veprim shtesë, por në rastin tonë kemi një grup mjaft të madh me një konfigurim rrjeti shumë të thjeshtë.

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

Nuk do të hyj në detaje rreth instalimit dhe konfigurimit të MetalLB, pasi supozoj se tashmë keni një përvojë. Unë sugjeroj që të shkoni direkt në pikën, përkatësisht vendosjen e rrugëzimit. Pra kemi katër raste:

Rasti 1: Kur nuk kërkohet konfigurim

Le të shohim një rast të thjeshtë.

Nuk kërkohet konfigurim shtesë i rrugëzimit kur adresat e lëshuara nga MetalLB janë në të njëjtin nënrrjet me adresat e nyjeve tuaja.

Për shembull, ju keni një nënrrjet 192.168.1.0/24, ka një ruter 192.168.1.1, dhe nyjet tuaja marrin adresat: 192.168.1.10-30, atëherë për MetalLB mund të rregulloni diapazonin 192.168.1.100-120 dhe sigurohuni që do të funksionojnë pa ndonjë konfigurim shtesë.

Pse eshte ajo? Sepse nyjet tuaja kanë tashmë rrugë të konfiguruara:

# 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 i njëjti gamë do t'i ripërdorin ato pa ndonjë veprim shtesë.

Rasti 2: Kur kërkohet personalizim shtesë

Ju duhet të konfiguroni rrugë shtesë sa herë që nyjet tuaja nuk kanë një adresë IP të konfiguruar ose rrugë drejt nënrrjetit për të cilin adresat e çështjeve të MetalLB.

Unë do të shpjegoj pak më në detaje. Sa herë që MetalLB nxjerr një adresë, ajo mund të krahasohet me një detyrë të thjeshtë si:

ip addr add 10.9.8.7/32 dev lo

Kushtojini vëmendje:

• a) Adresa është caktuar me një parashtesë /32 domethënë, një rrugë nuk do të shtohet automatikisht në nënrrjet për të (është thjesht një adresë)
• b) Adresa është e bashkangjitur në çdo ndërfaqe nyje (për shembull loopback). Vlen të përmenden këtu veçoritë e pirgut të rrjetit Linux. Pavarësisht se në cilën ndërfaqe e shtoni adresën, kerneli gjithmonë do të përpunojë kërkesat arp dhe do të dërgojë përgjigje arp për secilën prej tyre, kjo sjellje konsiderohet e saktë dhe, për më tepër, përdoret mjaft gjerësisht në një mjedis kaq dinamik si Kubernetes.

Kjo sjellje mund të personalizohet, për shembull duke aktivizuar arp strikte:

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 në mënyrë eksplicite një adresë IP specifike. Ky cilësim kërkohet nëse planifikoni të përdorni MetalLB dhe kube-proxy juaj po funksionon në modalitetin IPVS.

Megjithatë, MetalLB nuk e përdor kernelin për të përpunuar kërkesat arp, por e bën vetë në hapësirën e përdoruesit, kështu që ky opsion nuk do të ndikojë në funksionimin e MetalLB.

Le të kthehemi në detyrën tonë. Nëse rruga për adresat e lëshuara nuk ekziston në nyjet tuaja, shtoni atë paraprakisht në të gjitha nyjet:

ip route add 10.9.8.0/24 dev eth1

Rasti 3: Kur keni nevojë për rrugëtim të bazuar në burim

Do t'ju duhet të konfiguroni rrugëzimin e bazuar në burim kur merrni paketa përmes një porte të veçantë, jo atë të konfiguruar si parazgjedhje, prandaj edhe paketat e përgjigjes duhet të kalojnë nëpër të njëjtën portë.

Për shembull, ju keni të njëjtin nënrrjet 192.168.1.0/24 dedikuar nyjeve tuaja, por ju dëshironi të lëshoni adresa të jashtme duke përdorur MetalLB. Le të supozojmë se keni shumë adresa nga një nënrrjet 1.2.3.0/24 ndodhet në VLAN 100 dhe ju dëshironi t'i përdorni ato për të aksesuar shërbimet e Kubernetes nga jashtë.

Kur kontakton 1.2.3.4 do të bëni kërkesa nga një nënrrjet i ndryshëm nga ai 1.2.3.0/24 dhe prisni një përgjigje. Nyja që është aktualisht master për adresën e lëshuar nga MetalLB 1.2.3.4, do të marrë paketën nga ruteri 1.2.3.1, por përgjigja për të duhet të shkojë domosdoshmërisht në të njëjtën rrugë, përmes 1.2.3.1.

Meqenëse nyja jonë tashmë ka një portë të paracaktuar të konfiguruar 192.168.1.1, atëherë si parazgjedhje përgjigja do t'i shkojë atij dhe jo 1.2.3.1, përmes së cilës kemi marrë pakon.

Si të përballeni me këtë situatë?

Në këtë rast, ju duhet të përgatisni të gjitha nyjet tuaja në atë mënyrë që ato të jenë gati për të shërbyer adresat e jashtme pa konfigurim shtesë. Kjo do të thotë, për shembullin e mësipërm, ju duhet të krijoni një ndërfaqe VLAN në nyjen paraprakisht:

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

Dhe pastaj shtoni rrugët:

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

Ju lutemi vini re se ne shtojmë rrugë në një tabelë të veçantë të rrugëtimit 100 ai do të përmbajë vetëm dy rrugë të nevojshme për të dërguar një paketë përgjigjeje përmes portës 1.2.3.1, e vendosur prapa ndërfaqes eth0.100.

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

ip rule add from 1.2.3.0/24 lookup 100

i cili shprehimisht thotë: nëse adresa burimore e paketës është në 1.2.3.0/24, atëherë duhet të përdorni tabelën e rrugëzimit 100. Në të kemi përshkruar tashmë rrugën që do ta dërgojë atë 1.2.3.1

Rasti 4: Kur keni nevojë për rrugëzim të bazuar në politika

Topologjia e rrjetit është e njëjtë si në shembullin e mëparshëm, por le të themi se ju gjithashtu dëshironi të keni mundësi të aksesoni adresat e grupit të jashtëm 1.2.3.0/24 nga bishtajat tuaja:

E veçanta është se kur hyni në ndonjë adresë në 1.2.3.0/24, paketa e përgjigjes godet nyjen dhe ka një adresë burimi në interval 1.2.3.0/24 do të dërgohet me bindje në eth0.100, por ne duam që Kubernetes ta ridrejtojë atë në podin tonë të parë, i cili gjeneroi kërkesën origjinale.

Zgjidhja e këtij problemi doli të ishte e vështirë, por u bë e mundur falë rrugëzimit të bazuar në politika:

Për një kuptim më të mirë të procesit, këtu është një diagram bllok i filtrit net:

Së pari, si në shembullin e mëparshëm, le të krijojmë një tabelë shtesë të rrugëtimit:

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 le 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ë shënojnë lidhjet hyrëse në ndërfaqe eth0.100, duke shënuar të gjitha paketat me etiketën 0x100, përgjigjet brenda së njëjtës lidhje do të shënohen gjithashtu me të njëjtën etiketë.

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

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

Kjo është, të gjitha paketat me një adresë burimi 1.2.3.0/24 dhe tag 0x100 duhet të drejtohet duke përdorur një tabelë 100.

Kështu, paketat e tjera të marra në një ndërfaqe tjetër nuk i nënshtrohen këtij rregulli, gjë që do t'i lejojë ato të drejtohen duke përdorur mjete standarde Kubernetes.

Ka edhe një gjë, në Linux ekziston një filtër i ashtuquajtur i rrugës së kundërt, i cili prish të gjithë mjedrën; kryen një kontroll të thjeshtë: për të gjitha paketat hyrëse, ndryshon adresën e burimit të paketës me adresën e dërguesit dhe kontrollon nëse paketa mund të largohet nga e njëjta ndërfaqe në të cilën është marrë, nëse jo, ajo do ta filtojë atë.

Problemi është se në rastin tonë nuk do të funksionojë siç duhet, por ne mund ta çaktivizojmë:

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

Ju lutemi vini re se komanda e parë kontrollon sjelljen globale të rp_filter; nëse nuk është i çaktivizuar, komanda e dytë nuk do të ketë efekt. Megjithatë, ndërfaqet e mbetura do të mbeten me rp_filter të aktivizuar.

Për të mos kufizuar plotësisht funksionimin e filtrit, mund të përdorim zbatimin rp_filter për netfilter. Duke përdorur rpfilter si një modul iptables, mund të konfiguroni rregulla 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: www.habr.com