Nie lank gelede nie het ek 'n baie ongewone taak gehad om roetering vir MetalLB op te stel. Alles sal reg wees, want... Gewoonlik vereis MetalLB geen bykomende aksies nie, maar in ons geval het ons 'n redelike groot groepie met 'n baie eenvoudige netwerkkonfigurasie.

In hierdie artikel sal ek jou vertel hoe om brongebaseerde en beleidgebaseerde roetering vir die eksterne netwerk van jou groepering op te stel.

Ek sal nie in detail ingaan oor die installering en konfigurasie van MetalLB nie, aangesien ek aanvaar dat u reeds 'n bietjie ondervinding het. Ek stel voor om reguit na die punt te gaan, naamlik die opstel van roetering. Ons het dus vier gevalle:

Geval 1: Wanneer geen konfigurasie vereis word nie

Kom ons kyk na 'n eenvoudige geval.

Bykomende roetekonfigurasie word nie vereis wanneer die adresse wat deur MetalLB uitgereik is in dieselfde subnet as die adresse van jou nodusse is nie.

Byvoorbeeld, jy het 'n subnet 192.168.1.0/24, dit het 'n router 192.168.1.1, en jou nodusse ontvang adresse: 192.168.1.10-30, dan vir MetalLB kan jy die reeks aanpas 192.168.1.100-120 en maak seker dat hulle sal werk sonder enige bykomende konfigurasie.

Hoekom is dit? Omdat jou nodusse reeds roetes opgestel het:

# 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 adresse van dieselfde reeks sal hulle hergebruik sonder enige bykomende aksies.

Geval 2: Wanneer bykomende aanpassing vereis word

Jy moet bykomende roetes opstel wanneer jou nodusse nie 'n gekonfigureerde IP-adres of roete het na die subnet waarvoor MetalLB adresse uitreik nie.

Ek sal in 'n bietjie meer detail verduidelik. Wanneer MetalLB 'n adres uitstuur, kan dit vergelyk word met 'n eenvoudige opdrag soos:

ip addr add 10.9.8.7/32 dev lo

Gee aandag aan:

• a) Die adres word met 'n voorvoegsel toegeken /32 dit wil sê, 'n roete sal nie outomaties by die subnet daarvoor gevoeg word nie (dit is net 'n adres)
• b) Die adres is geheg aan enige nodus koppelvlak (byvoorbeeld terugloop). Dit is die moeite werd om hier die kenmerke van die Linux-netwerkstapel te noem. Maak nie saak by watter koppelvlak jy die adres byvoeg nie, die kern sal altyd arp-versoeke verwerk en arp-antwoorde na enige van hulle stuur, hierdie gedrag word as korrek beskou en word boonop nogal wyd gebruik in so 'n dinamiese omgewing soos Kubernetes.

Hierdie gedrag kan aangepas word, byvoorbeeld deur streng arp te aktiveer:

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

In hierdie geval sal arp-antwoorde slegs gestuur word as die koppelvlak uitdruklik 'n spesifieke IP-adres bevat. Hierdie instelling is nodig as jy van plan is om MetalLB te gebruik en jou kube-instaanbediener loop in IPVS-modus.

MetalLB gebruik egter nie die kern om arp-versoeke te verwerk nie, maar doen dit self in gebruikersruimte, so hierdie opsie sal nie die werking van MetalLB beïnvloed nie.

Kom ons keer terug na ons taak. As die roete vir die uitgereikte adresse nie op jou nodusse bestaan ​​nie, voeg dit vooraf by alle nodusse:

ip route add 10.9.8.0/24 dev eth1

Geval 3: Wanneer jy brongebaseerde roetering benodig

Jy sal brongebaseerde roetering moet konfigureer wanneer jy pakkies deur 'n aparte poort ontvang, nie die een wat by verstek opgestel is nie, daarom moet antwoordpakkies ook deur dieselfde poort gaan.

Byvoorbeeld, jy het dieselfde subnet 192.168.1.0/24 toegewy aan u nodusse, maar u wil eksterne adresse met MetalLB uitreik. Kom ons neem aan jy het verskeie adresse van 'n subnet 1.2.3.0/24 geleë in VLAN 100 en jy wil dit gebruik om ekstern toegang tot Kubernetes-dienste te verkry.

By kontak 1.2.3.4 jy sal versoeke van 'n ander subnet as 1.2.3.0/24 en wag vir 'n antwoord. Die nodus wat tans die meester is vir die MetalLB-uitgereikte adres 1.2.3.4, sal die pakkie van die router ontvang 1.2.3.1, maar die antwoord vir hom moet noodwendig dieselfde roete gaan, deur 1.2.3.1.

Aangesien ons nodus reeds 'n gekonfigureerde verstekpoort het 192.168.1.1, dan sal die antwoord by verstek na hom gaan, en nie na nie 1.2.3.1, waardeur ons die pakkie ontvang het.

Hoe om hierdie situasie te hanteer?

In hierdie geval moet jy al jou nodusse op so 'n manier voorberei dat hulle gereed is om eksterne adresse te bedien sonder bykomende konfigurasie. Dit wil sê, vir die bogenoemde voorbeeld moet u vooraf 'n VLAN-koppelvlak op die nodus skep:

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

En voeg dan roetes by:

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

Neem asseblief kennis dat ons roetes by 'n aparte roetetabel voeg 100 dit sal slegs twee roetes bevat wat nodig is om 'n antwoordpakkie deur die poort te stuur 1.2.3.1, geleë agter die koppelvlak eth0.100.

Nou moet ons 'n eenvoudige reël byvoeg:

ip rule add from 1.2.3.0/24 lookup 100

wat uitdruklik sê: as die pakkie se bronadres in is 1.2.3.0/24, dan moet jy die roeteringtabel gebruik 100. Daarin het ons reeds die roete beskryf wat hom sal deurstuur 1.2.3.1

Geval 4: Wanneer jy beleidgebaseerde roetering benodig

Die netwerktopologie is dieselfde as in die vorige voorbeeld, maar kom ons sê jy wil ook toegang tot eksterne swembadadresse hê 1.2.3.0/24 uit jou peule:

Die eienaardigheid is dat wanneer toegang tot enige adres in 1.2.3.0/24, tref die antwoordpakkie die nodus en het 'n bronadres in die reeks 1.2.3.0/24 sal gehoorsaam gestuur word aan eth0.100, maar ons wil hê Kubernetes moet dit na ons eerste pod herlei, wat die oorspronklike versoek gegenereer het.

Om hierdie probleem op te los blyk moeilik te wees, maar dit het moontlik geword danksy beleidsgebaseerde roetering:

Vir 'n beter begrip van die proses, hier is 'n netfilter blokdiagram:

Kom ons skep eers, soos in die vorige voorbeeld, 'n bykomende roeteringtabel:

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

Kom ons voeg nou 'n paar reëls by 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

Hierdie reëls sal inkomende verbindings na die koppelvlak merk eth0.100, merk alle pakkies met die etiket 0x100, antwoorde binne dieselfde verbinding sal ook met dieselfde merker gemerk word.

Nou kan ons 'n roetereël byvoeg:

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

Dit wil sê, alle pakkies met 'n bronadres 1.2.3.0/24 en merk 0x100 moet deur 'n tabel gestuur word 100.

Dus, ander pakkies wat op 'n ander koppelvlak ontvang is, is nie onderhewig aan hierdie reël nie, wat dit sal toelaat om hulle deur te stuur met behulp van standaard Kubernetes-nutsgoed.

Daar is nog een ding, in Linux is daar 'n sogenaamde omgekeerde padfilter, wat die hele ding bederf; dit voer 'n eenvoudige kontrole uit: vir alle inkomende pakkies verander dit die bronadres van die pakkie met die senderadres en kontroleer of die pakkie kan deur dieselfde koppelvlak vertrek waarop dit ontvang is, indien nie, sal dit dit uitfiltreer.

Die probleem is dat dit in ons geval nie reg sal werk nie, maar ons kan dit deaktiveer:

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

Neem asseblief kennis dat die eerste opdrag die globale gedrag van rp_filter beheer; as dit nie gedeaktiveer is nie, sal die tweede opdrag geen effek hê nie. Die oorblywende koppelvlakke sal egter bly met rp_filter geaktiveer.

Om nie die werking van die filter heeltemal te beperk nie, kan ons die rp_filter-implementering vir netfilter gebruik. Deur rpfilter as 'n iptables-module te gebruik, kan u redelik buigsame reëls instel, byvoorbeeld:

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

aktiveer rp_filter op die koppelvlak eth0.100 vir alle adresse behalwe 1.2.3.0/24.

Bron: will.com