Net lang lyn waard ik konfrontearre mei in heul ûngewoane taak fan it opsetten fan routing foar MetalLB. Alles soe goed komme, want... Meastal fereasket MetalLB gjin ekstra aksjes, mar yn ús gefal hawwe wy in frij grut kluster mei in heul ienfâldige netwurkkonfiguraasje.

Yn dit artikel sil ik jo fertelle hoe't jo boarne-basearre en beliedsbasearre routing ynstelle kinne foar it eksterne netwurk fan jo kluster.

Ik sil net yn detail gean oer it ynstallearjen en konfigurearjen fan MetalLB, om't ik nim oan dat jo al wat ûnderfining hawwe. Ik stel foar om direkt nei it punt te gean, nammentlik it ynstellen fan routing. Sa hawwe wy fjouwer gefallen:

Gefal 1: As gjin konfiguraasje nedich is

Litte wy nei in ienfâldige saak sjen.

Oanfoljende routingkonfiguraasje is net fereaske as de adressen útjûn troch MetalLB yn itselde subnet binne as de adressen fan jo knopen.

Jo hawwe bygelyks in subnet 192.168.1.0/24, it hat in router 192.168.1.1, en jo knooppunten ûntfange adressen: 192.168.1.10-30, dan kinne jo foar MetalLB it berik oanpasse 192.168.1.100-120 en wês der wis fan dat se sille wurkje sûnder ekstra konfiguraasje.

Wêrom is dat? Om't jo knooppunten al rûtes hawwe konfigureare:

# 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

En adressen út itselde berik sille se opnij brûke sûnder ekstra aksjes.

Gefal 2: As ekstra oanpassing is fereaske

Jo moatte ekstra rûtes konfigurearje as jo knooppunten gjin konfigureare IP-adres hawwe of rûte nei it subnet wêrfoar MetalLB adressen útjout.

Ik sil in bytsje mear detaillearje. Wannear MetalLB in adres útfiert, kin it wurde fergelike mei in ienfâldige opdracht lykas:

ip addr add 10.9.8.7/32 dev lo

Jou oandacht oan:

• a) It adres wurdt tawiisd mei in foarheaksel /32 dat is, in rûte sil net automatysk wurde tafoege oan it subnet foar it (it is gewoan in adres)
• b) It adres is hechte oan elke node-ynterface (bygelyks loopback). It is it wurdich om hjir de funksjes fan 'e Linux-netwurkstapel te neamen. Makket net út hokker ynterface jo it adres tafoegje, de kearn sil altyd arp-oanfragen ferwurkje en arp-antwurden op ien fan harren stjoere, dit gedrach wurdt as korrekt beskôge en wurdt boppedat frijwat brûkt yn sa'n dynamyske omjouwing as Kubernetes.

Dit gedrach kin oanpast wurde, bygelyks troch strikte arp yn te skeakeljen:

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

Yn dit gefal wurde arp-antwurden allinich ferstjoerd as de ynterface eksplisyt in spesifyk IP-adres befettet. Dizze ynstelling is fereaske as jo fan plan binne MetalLB te brûken en jo kube-proxy rint yn IPVS-modus.

MetalLB brûkt de kernel lykwols net om arp-oanfragen te ferwurkjen, mar docht it sels yn brûkersromte, dus dizze opsje sil de wurking fan MetalLB net beynfloedzje.

Lit ús weromgean nei ús taak. As de rûte foar de útjûne adressen net bestiet op jo knopen, foegje it dan fan tefoaren ta oan alle knopen:

ip route add 10.9.8.0/24 dev eth1

Gefal 3: As jo ​​​​boarne-basearre routing nedich binne

Jo moatte boarne-basearre routing ynstelle as jo pakketten ûntfange fia in aparte gateway, net de standert konfigureare, dêrom moatte antwurdpakketten ek troch deselde gateway gean.

Jo hawwe bygelyks itselde subnet 192.168.1.0/24 wijd oan jo knopen, mar jo wolle eksterne adressen útjaan mei MetalLB. Litte wy oannimme dat jo meardere adressen hawwe fan in subnet 1.2.3.0/24 leit yn VLAN 100 en jo wolle se brûke om tagong te krijen ta Kubernetes tsjinsten ekstern.

By kontakt 1.2.3.4 jo sille fersiken meitsje fan in oar subnet as 1.2.3.0/24 en wachtsje op in antwurd. It knooppunt dat op it stuit de master is foar it MetalLB-útjûn adres 1.2.3.4, sil it pakket ûntfange fan 'e router 1.2.3.1, mar it antwurd foar him moat needsaaklikerwize gean deselde rûte, troch 1.2.3.1.

Sûnt ús knooppunt hat al in konfigureare standert gateway 192.168.1.1, dan sil it antwurd standert nei him gean, en net nei 1.2.3.1, dêr't wy it pakket troch krigen.

Hoe om te gean mei dizze situaasje?

Yn dit gefal moatte jo al jo knopen op sa'n manier tariede dat se klear binne om eksterne adressen te tsjinjen sûnder ekstra konfiguraasje. Dat is, foar it boppesteande foarbyld moatte jo foarôf in VLAN-ynterface op 'e knooppunt meitsje:

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

En foegje dan rûtes ta:

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

Tink derom dat wy rûtes tafoegje oan in aparte rûtetabel 100 it sil befetsje mar twa rûtes nedich te stjoeren in antwurd pakket troch de poarte 1.2.3.1, leit efter de ynterface eth0.100.

No moatte wy in ienfâldige regel tafoegje:

ip rule add from 1.2.3.0/24 lookup 100

dy't eksplisyt seit: as it boarneadres fan it pakket yn is 1.2.3.0/24, dan moatte jo de routingtabel brûke 100. Dêryn hawwe wy de rûte al beskreaun dy't him trochstjoere sil 1.2.3.1

Gefal 4: As jo ​​​​op belied basearre routing nedich binne

De netwurktopology is itselde as yn it foarige foarbyld, mar litte wy sizze dat jo ek tagong krije wolle oan eksterne pooladressen 1.2.3.0/24 út dyn pods:

De eigenaardichheid is dat by tagong ta elk adres yn 1.2.3.0/24, it antwurdpakket treft it knooppunt en hat in boarneadres yn it berik 1.2.3.0/24 sil hearrich stjoerd wurde nei eth0.100, mar wy wolle dat Kubernetes it omliedt nei ús earste pod, dy't it orizjinele fersyk generearre.

It oplossen fan dit probleem blykte lestich te wêzen, mar it waard mooglik troch beliedsbasearre routing:

Foar in better begryp fan it proses, hjir is in netfilter blokdiagram:

Litte wy earst, lykas yn it foarige foarbyld, in ekstra routingtabel oanmeitsje:

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

Litte wy no in pear regels tafoegje oan 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

Dizze regels markearje ynkommende ferbiningen mei de ynterface eth0.100, markearje alle pakketten mei de tag 0x100, antwurden binnen deselde ferbining wurde ek markearre mei deselde tag.

No kinne wy ​​in routingregel tafoegje:

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

Dat is, alle pakketten mei in boarneadres 1.2.3.0/24 en tag 0x100 moat wurde trochstjoerd mei de tabel 100.

Sa binne oare pakketten ûntfongen op in oare ynterface net ûnderwurpen oan dizze regel, wêrtroch't se kinne wurde trochstjoerd mei standert Kubernetes-ark.

Der is noch ien ding, yn Linux is d'r in saneamde omkearde paadfilter, dat it hiele ding bedjerret; it docht in ienfâldige kontrôle: foar alle ynkommende pakketten feroaret it it boarneadres fan it pakket mei it stjoerderadres en kontrolearret oft it it pakket kin ferlitte troch deselde ynterface wêrop it waard ûntfongen, as net, sil it filterje.

It probleem is dat it yn ús gefal net goed wurket, mar wy kinne it útskeakelje:

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

Tink derom dat it earste kommando it globale gedrach fan rp_filter kontrolearret; as it net útskeakele is, sil it twadde kommando gjin effekt hawwe. De oerbleaune ynterfaces sille lykwols bliuwe mei rp_filter ynskeakele.

Om de wurking fan it filter net folslein te beheinen, kinne wy ​​​​de ymplemintaasje rp_filter brûke foar netfilter. Mei rpfilter as iptables-module kinne jo frij fleksibele regels ynstelle, bygelyks:

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

ynskeakelje rp_filter op de ynterface eth0.100 foar alle adressen útsein 1.2.3.0/24.

Boarne: www.habr.com