Duela ez asko MetalLB-ren bideraketa konfiguratzeko zeregin oso ezohiko baten aurrean egon nintzen. Dena ondo legoke, zeren... Normalean MetalLB-k ez du ekintza gehigarririk behar, baina gure kasuan kluster handi samarra dugu sare konfigurazio oso sinplearekin.

Artikulu honetan esango dizut nola konfiguratu iturburuan oinarritutako eta gidalerroetan oinarritutako bideraketa zure klusterren kanpoko sarerako.

Ez naiz MetalLB instalatzeari eta konfiguratzeari buruzko xehetasunetan sartuko, dagoeneko esperientziaren bat duzula suposatzen baitut. Zuzenean puntura joatea proposatzen dut, hots, bideratzea konfiguratzea. Beraz, lau kasu ditugu:

1. kasua: konfiguraziorik behar ez denean

Ikus dezagun kasu sinple bat.

Bideratze-konfigurazio gehigarria ez da beharrezkoa MetalLB-k emandako helbideak zure nodoen helbideen azpisare berean daudenean.

Adibidez, azpisare bat duzu 192.168.1.0/24, bideratzailea du 192.168.1.1, eta zure nodoek helbideak jasotzen dituzte: 192.168.1.10-30, gero MetalLBrako tartea doi dezakezu 192.168.1.100-120 eta ziurtatu inolako konfigurazio gehigarririk gabe funtzionatuko dutela.

Zergatik da hori? Zure nodoek dagoeneko ibilbideak konfiguratuta dituztelako:

# 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

Eta barruti bereko helbideek berrerabili egingo dituzte ekintza gehigarririk gabe.

2. kasua: pertsonalizazio gehigarria behar denean

Ibilbide gehigarriak konfiguratu behar dituzu zure nodoek IP helbiderik edo MetalLB-k helbideak igortzen dituen azpisarerako biderik ez dutenean.

Xehetasun pixka bat gehiago azalduko dut. MetalLB-k helbide bat ateratzen duen bakoitzean, honelako esleipen sinple batekin aldera daiteke:

ip addr add 10.9.8.7/32 dev lo

Erreparatu:

• a) Helbidea aurrizki batekin esleitzen da /32 hau da, ibilbide bat ez da automatikoki gehituko horren azpisarean (helbide bat besterik ez da)
• b) Helbidea edozein nodoko interfazeari atxikita dago (adibidez, loopback). Hemen aipatzea merezi du Linux sare-pilaren ezaugarriak. Helbidea zein interfazeari gehitzen diozun edozein dela ere, kernelak arp eskaerak prozesatu eta horietako edozeini arp erantzunak bidaliko ditu beti, portaera hau zuzentzat jotzen da eta, gainera, nahiko erabilia da Kubernetes bezalako ingurune dinamiko batean.

Portaera hau pertsonalizatu daiteke, adibidez, arp zorrotza gaituz:

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

Kasu honetan, arp erantzunak interfazeak esplizituki IP helbide zehatz bat badu soilik bidaliko dira. Ezarpen hau beharrezkoa da MetalLB erabiltzeko asmoa baduzu eta kube-proxy IPVS moduan exekutatzen ari bada.

Hala ere, MetalLB-k ez du nukleoa erabiltzen arp eskaerak prozesatzeko, baina erabiltzaile-espazioan egiten du, beraz, aukera honek ez du MetalLBren funtzionamenduan eragingo.

Itzuli gaitezen gure zereginera. Jaulkitako helbideen ibilbidea zure nodoetan ez badago, gehitu aldez aurretik nodo guztietan:

ip route add 10.9.8.0/24 dev eth1

3. kasua: iturburuan oinarritutako bideratzea behar duzunean

Iturburuan oinarritutako bideratzea konfiguratu beharko duzu paketeak atebide bereizi baten bidez jasotzen dituzunean, ez lehenespenez konfiguratutakoaren bidez; beraz, erantzun-paketeek ere atebide beretik pasa beharko dute.

Adibidez, azpisare bera duzu 192.168.1.0/24 zure nodoei eskainita, baina kanpoko helbideak igorri nahi dituzu MetalLB erabiliz. Demagun azpisare batetik hainbat helbide dituzula 1.2.3.0/24 VLAN 100-n dago eta horiek erabili nahi dituzu Kubernetes zerbitzuetatik kanpotik sartzeko.

Harremanetan jartzean 1.2.3.4 beste azpisare batetik egingo dituzu eskaerak 1.2.3.0/24 eta erantzun baten zain. MetalLB-k jaulkitako helbidearen maisua den nodoa 1.2.3.4, router-etik jasoko du paketea 1.2.3.1, baina harentzat erantzunak bide beretik joan behar du nahitaez, bidez 1.2.3.1.

Gure nodoak dagoeneko konfiguratutako atebide lehenetsi bat daukanez 192.168.1.1, orduan lehenespenez erantzuna berari joango zaio, eta ez 1.2.3.1, horren bidez paketea jaso genuen.

Nola egin aurre egoera honi?

Kasu honetan, zure nodo guztiak prestatu behar dituzu kanpoko helbideak konfigurazio gehigarririk gabe zerbitzatzeko prest dauden moduan. Hau da, goiko adibiderako, aldez aurretik VLAN interfaze bat sortu behar duzu nodoan:

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

Eta gero gehitu ibilbideak:

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

Kontuan izan ibilbideak bideratze-taula bereizi batean gehitzen ditugula 100 atebidetik erantzun-pakete bat bidaltzeko beharrezkoak diren bi bide baino ez ditu edukiko 1.2.3.1, interfazearen atzean kokatuta eth0.100.

Orain arau sinple bat gehitu behar dugu:

ip rule add from 1.2.3.0/24 lookup 100

horrek esplizituki esaten du: paketearen iturburu helbidea bertan badago 1.2.3.0/24, orduan bideratze-taula erabili behar duzu 100. Bertan deskribatu dugu jada bidaliko duen ibilbidea 1.2.3.1

4. kasua: Politikan oinarritutako bideratzea behar duzunean

Sarearen topologia aurreko adibideko berdina da, baina demagun kanpoko igerilekuen helbideetara ere sartu nahi duzula 1.2.3.0/24 zure leketatik:

Berezitasuna da edozein helbide sartzean 1.2.3.0/24, erantzun-paketeak nodora jotzen du eta iturburu-helbide bat dauka barrutian 1.2.3.0/24 obeki bidaliko zaio eth0.100, baina Kubernetes-ek jatorrizko eskaera sortu zuen gure lehen podra birbideratzea nahi dugu.

Arazo hau konpontzea zaila izan zen, baina politikan oinarritutako bideratzeari esker posible izan zen:

Prozesua hobeto ulertzeko, hona hemen netfilter bloke-diagrama:

Lehenik eta behin, aurreko adibidean bezala, sor dezagun bideratze-taula gehigarri bat:

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

Orain gehi ditzagun arau batzuk iptables-i:

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

Arau hauek interfazera sarrerako konexioak markatuko dituzte eth0.100, pakete guztiak etiketarekin markatuz 0x100, konexio bereko erantzunak ere etiketa berdinarekin markatuko dira.

Orain bideratze-arau bat gehi dezakegu:

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

Hau da, iturburu helbidea duten pakete guztiak 1.2.3.0/24 eta etiketatu 0x100 taula baten bidez bideratu behar da 100.

Horrela, beste interfaze batean jasotako beste pakete batzuk ez daude arau honen menpe, eta horri esker bideratu ahal izango dira Kubernetes tresna estandarrak erabiliz.

Beste gauza bat dago, Linux-en alderantzizko bide-iragazkia deritzona dago, eta horrek guztia hondatzen du; egiaztapen sinple bat egiten du: sarrerako pakete guztientzat, paketearen iturburu-helbidea aldatzen du igorle-helbidearekin eta egiaztatzen du. paketea jaso den interfaze beretik irten daiteke, hala ez bada, iragazi egingo du.

Arazoa da gure kasuan ez dela behar bezala funtzionatuko, baina desgaitu dezakegu:

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

Kontuan izan lehenengo komandoak rp_filter-en portaera globala kontrolatzen duela; desgaituta ez badago, bigarren komandoak ez du eraginik izango. Hala ere, gainerako interfazeak rp_filter gaituta egongo dira.

Iragazkiaren funtzionamendua guztiz ez mugatzeko, netfilter-erako rp_filter inplementazioa erabil dezakegu. rpfilter iptables modulu gisa erabiliz, nahiko arau malguak konfigura ditzakezu, adibidez:

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

gaitu rp_filter interfazean eth0.100 helbide guztietarako izan ezik 1.2.3.0/24.

Iturria: www.habr.com