Net viru laanger Zäit war ech mat enger ganz ongewéinlecher Aufgab konfrontéiert fir Routing fir MetalLB opzestellen. Alles wier gutt, well ... Normalerweis erfuerdert MetalLB keng zousätzlech Aktiounen, awer an eisem Fall hu mir e zimlech grousse Cluster mat enger ganz einfacher Netzwierkkonfiguratioun.

An dësem Artikel wäert ech Iech soen wéi Dir Quell-baséiert a Politik-baséiert Routing fir den externen Netzwierk vun Ärem Cluster konfiguréiert.

Ech ginn net am Detail iwwer d'Installatioun an d'Konfiguratioun vun MetalLB, well ech huelen un datt Dir schonn e puer Erfahrung hutt. Ech proposéieren direkt op de Punkt ze goen, nämlech Routing opzestellen. Also hu mir véier Fäll:

Fall 1: Wann keng Konfiguratioun néideg ass

Loosst eis en einfache Fall kucken.

Zousätzlech Routingkonfiguratioun ass net erfuerderlech wann d'Adressen, déi vum MetalLB erausginn, am selwechte Subnet sinn wéi d'Adressen vun Ären Noden.

Zum Beispill hutt Dir e Subnet 192.168.1.0/24, et huet e Router 192.168.1.1, an Är Noden kréien Adressen: 192.168.1.10-30, dann fir MetalLB kënnt Dir d'Gamme upassen 192.168.1.100-120 a gitt sécher datt se ouni zousätzlech Konfiguratioun funktionnéieren.

Firwat? Well Är Noden scho Strecken konfiguréiert hunn:

# 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

An Adressen aus der selwechter Gamme wäerte se weiderbenotzen ouni zousätzlech Aktiounen.

Fall 2: Wann zousätzlech Personnalisatioun néideg ass

Dir sollt zousätzlech Strecken konfiguréieren wann Är Wirbelen keng konfiguréiert IP Adress oder Wee op d'Subnet hunn, fir déi MetalLB Adressen erausginn.

Ech wäert e bësse méi am Detail erklären. All Kéier wann MetalLB eng Adress ausgëtt, kann et mat enger einfacher Aufgab verglach ginn wéi:

ip addr add 10.9.8.7/32 dev lo

Opgepasst op:

• a) D'Adress gëtt mat engem Präfix zougewisen /32 dat heescht, e Wee gëtt net automatesch an d'Subnet dofir bäigefüügt (et ass just eng Adress)
• b) D'Adress ass un all Node-Interface befestegt (zum Beispill Loopback). Et ass derwäert hei d'Features vum Linux Netzwierkstack ze ernimmen. Egal op wéi eng Interface Dir d'Adress bäidréit, de Kernel wäert ëmmer arp Ufroe veraarbecht an arp Äntwerten op jiddereng vun hinnen schécken, dëst Verhalen gëtt als korrekt ugesinn an ass och zimlech wäit an esou engem dynamesche Ëmfeld wéi Kubernetes benotzt.

Dëst Verhalen kann personaliséiert ginn, zum Beispill andeems Dir strikt arp aktivéiert:

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

An dësem Fall ginn arp Äntwerte nëmmen geschéckt wann d'Interface explizit eng spezifesch IP Adress enthält. Dës Astellung ass erfuerderlech wann Dir plangt MetalLB ze benotzen an Äre Kube-Proxy leeft am IPVS Modus.

Wéi och ëmmer, MetalLB benotzt de Kernel net fir arp Ufroen ze veraarbecht, awer mécht et selwer am Benotzerraum, sou datt dës Optioun net d'Operatioun vu MetalLB beaflosst.

Komme mer zréck op eis Aufgab. Wann de Wee fir déi erausginn Adressen net op Ären Wirbelen existéiert, füügt se am Viraus un all Wirbelen:

ip route add 10.9.8.0/24 dev eth1

Fall 3: Wann Dir Quell-baséiert Routing braucht

Dir musst Quell-baséiert Routing konfiguréieren wann Dir Päckelcher duerch eng separat Paart kritt, net deen, deen als Standard konfiguréiert ass, dofir sollten Äntwertpakete och duerch déiselwecht Paart goen.

Zum Beispill, hutt Dir déi selwecht Subnet 192.168.1.0/24 fir Är Wirbelen gewidmet, awer Dir wëllt extern Adresse mat MetallLB ausginn. Loosst eis unhuelen datt Dir verschidde Adresse vun engem Subnet hutt 1.2.3.0/24 am VLAN 100 läit an Dir wëllt se benotze fir extern op Kubernetes Servicer ze kommen.

Beim Kontakt 1.2.3.4 Dir wäert Ufroe vun engem anere Subnet maachen wéi 1.2.3.0/24 a waart op eng Äntwert. Den Node deen de Moment de Master fir d'MetalLB-erausginn Adress ass 1.2.3.4, kritt de Paket vum Router 1.2.3.1, mä d'Äntwert fir hien muss onbedéngt déi selwecht Wee goen, duerch 1.2.3.1.

Zënter eisem Node huet schonn e konfiguréierte Standardgateway 192.168.1.1, da gëtt par défaut d'Äntwert un hien, an net op 1.2.3.1, duerch déi mir de Pak krut.

Wéi mat dëser Situatioun eens?

An dësem Fall musst Dir all Är Wirbelen esou virbereeden datt se prett sinn fir extern Adressen ouni zousätzlech Konfiguratioun ze déngen. Dat ass, fir dat uewe genannte Beispill, musst Dir am Viraus e VLAN Interface um Node erstellen:

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

An dann d'Strecken derbäi:

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

Notéiert w.e.g. datt mir Strecken op eng separat Routingtabelle addéieren 100 et wäert nëmmen zwou routes enthalen déi néideg sinn fir en Äntwertpaket duerch de Paart ze schécken 1.2.3.1, hannert der Interface läit eth0.100.

Elo musse mir eng einfach Regel derbäi:

ip rule add from 1.2.3.0/24 lookup 100

déi explizit seet: wann d'Quelladress vum Paket an ass 1.2.3.0/24, da musst Dir d'Routing-Table benotzen 100. An et hu mir schonn de Wee beschriwwen, deen hien duerchschécke wäert 1.2.3.1

Fall 4: Wann Dir Politik-baséiert Routing braucht

D'Netzwierktopologie ass d'selwecht wéi am virege Beispill, awer loosst eis soen datt Dir och Zougang zu externe Pooladressen wëllt kréien 1.2.3.0/24 vun dengen Pods:

D'Besonderheet ass datt wann Dir Zougang zu all Adress an 1.2.3.0/24, den Äntwertpaket trefft den Node an huet eng Quelladress am Beräich 1.2.3.0/24 wäert gehorsam geschéckt ginn eth0.100, awer mir wëllen datt Kubernetes et op eisen éischte Pod redirectéiert, deen déi ursprénglech Ufro generéiert huet.

D'Léisung vun dësem Problem huet sech schwéier erausgestallt, awer et gouf méiglech dank der Politik-baséiert Routing:

Fir e bessert Verständnis vum Prozess, hei ass en Netfilter Blockdiagramm:

Als éischt, wéi am virege Beispill, loosst eis eng zousätzlech Routing-Table erstellen:

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

Loosst eis elo e puer Reegele fir iptables addéieren:

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

Dës Regele markéieren erakommen Verbindunge mat der Interface eth0.100, markéiert all Pakete mam Tag 0x100, Äntwerte bannent der selwechter Verbindung ginn och mam selwechte Tag markéiert.

Elo kënne mir eng Routing Regel derbäi:

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

Dat ass, all Pakete mat enger Quelladress 1.2.3.0/24 en tag 0x100 muss mat engem Dësch geréckelt ginn 100.

Also, aner Pakete, déi op enger anerer Interface empfaangen sinn, sinn net ënner dëser Regel ënnerleien, wat et erlaabt datt se mat Standard Kubernetes Tools geréckelt ginn.

Et gëtt nach eng Saach, am Linux gëtt et e sougenannte Reverse-Path-Filter, deen dat Ganzt verwinnt; et mécht en einfache Scheck: fir all erakommen Pakete ännert en d'Quelladress vum Paket mat der Senderadress a kontrolléiert ob de Pak kann duerch déi selwecht Interface verloossen op deem et kritt gouf, wann net, filtert et aus.

De Problem ass datt an eisem Fall et net richteg funktionnéiert, awer mir kënnen et auszeschalten:

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

Notéiert w.e.g. datt den éischte Kommando d'global Verhalen vum rp_filter kontrolléiert; wann et net behënnert ass, huet den zweete Kommando keen Effekt. Wéi och ëmmer, déi verbleiwen Interfaces bleiwen mat rp_filter aktivéiert.

Fir d'Operatioun vum Filter net komplett ze limitéieren, kënne mir d'rp_filter Implementatioun fir Netfilter benotzen. Mat rpfilter als iptables Modul kënnt Dir zimmlech flexibel Regelen konfiguréieren, zum Beispill:

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

aktivéiert rp_filter op der Interface eth0.100 fir all Adressen ausser 1.2.3.0/24.

Source: will.com