For ikke længe siden stod jeg over for en meget usædvanlig opgave med at opsætte routing for MetalLB. Alt ville være fint, fordi... Normalt kræver MetalLB ingen yderligere handlinger, men i vores tilfælde har vi en ret stor klynge med en meget simpel netværkskonfiguration.

I denne artikel vil jeg fortælle dig, hvordan du konfigurerer kildebaseret og politikbaseret routing for det eksterne netværk i din klynge.

Jeg vil ikke gå i detaljer om installation og konfiguration af MetalLB, da jeg antager, at du allerede har en vis erfaring. Jeg foreslår at gå direkte til sagen, nemlig at opsætte routing. Så vi har fire sager:

Tilfælde 1: Når ingen konfiguration er påkrævet

Lad os se på en simpel sag.

Yderligere routingkonfiguration er ikke påkrævet, når adresserne udstedt af MetalLB er i det samme undernet som adresserne på dine noder.

For eksempel har du et undernet 192.168.1.0/24, den har en router 192.168.1.1, og dine noder modtager adresser: 192.168.1.10-30, så for MetalLB kan du justere rækkevidden 192.168.1.100-120 og vær sikker på, at de vil fungere uden yderligere konfiguration.

Hvorfor det? Fordi dine noder allerede har konfigureret ruter:

# 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

Og adresser fra det samme område vil genbruge dem uden yderligere handlinger.

Tilfælde 2: Når yderligere tilpasning er påkrævet

Du bør konfigurere yderligere ruter, når dine noder ikke har en konfigureret IP-adresse eller rute til det undernet, som MetalLB udsteder adresser til.

Jeg vil forklare lidt mere detaljeret. Når MetalLB udsender en adresse, kan den sammenlignes med en simpel opgave som:

ip addr add 10.9.8.7/32 dev lo

Vær opmærksom på:

• a) Adressen tildeles med et præfiks /32 det vil sige, at en rute ikke automatisk bliver tilføjet til undernettet for den (det er kun en adresse)
• b) Adressen er knyttet til enhver nodegrænseflade (for eksempel loopback). Det er værd at nævne her funktionerne i Linux-netværksstakken. Uanset hvilken grænseflade du tilføjer adressen til, vil kernen altid behandle arp-anmodninger og sende arp-svar til enhver af dem, denne adfærd anses for at være korrekt og er desuden ret udbredt i et så dynamisk miljø som Kubernetes.

Denne adfærd kan tilpasses, for eksempel ved at aktivere streng arp:

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

I dette tilfælde vil arp-svar kun blive sendt, hvis grænsefladen eksplicit indeholder en specifik IP-adresse. Denne indstilling er påkrævet, hvis du planlægger at bruge MetalLB, og din kube-proxy kører i IPVS-tilstand.

MetalLB bruger dog ikke kernen til at behandle arp-anmodninger, men gør det selv i brugerområdet, så denne mulighed vil ikke påvirke driften af ​​MetalLB.

Lad os vende tilbage til vores opgave. Hvis ruten for de udstedte adresser ikke findes på dine noder, skal du tilføje den på forhånd til alle noder:

ip route add 10.9.8.0/24 dev eth1

Case 3: Når du har brug for kildebaseret routing

Du bliver nødt til at konfigurere kildebaseret routing, når du modtager pakker gennem en separat gateway, ikke den, der er konfigureret som standard, derfor bør svarpakker også gå gennem den samme gateway.

For eksempel har du det samme undernet 192.168.1.0/24 dedikeret til dine noder, men du vil udstede eksterne adresser ved hjælp af MetalLB. Lad os antage, at du har flere adresser fra et undernet 1.2.3.0/24 placeret i VLAN 100, og du vil bruge dem til at få adgang til Kubernetes-tjenester eksternt.

Ved henvendelse 1.2.3.4 du vil komme med anmodninger fra et andet undernet end 1.2.3.0/24 og vent på svar. Den node, der i øjeblikket er master for den MetalLB-udstedte adresse 1.2.3.4, modtager pakken fra routeren 1.2.3.1, men svaret for ham må nødvendigvis gå samme vej, igennem 1.2.3.1.

Da vores node allerede har en konfigureret standardgateway 192.168.1.1, så vil svaret som standard gå til ham, og ikke til 1.2.3.1, hvorigennem vi modtog pakken.

Hvordan håndterer man denne situation?

I dette tilfælde skal du forberede alle dine noder på en sådan måde, at de er klar til at betjene eksterne adresser uden yderligere konfiguration. Det vil sige, for ovenstående eksempel skal du oprette en VLAN-grænseflade på noden på forhånd:

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

Og tilføj derefter ruter:

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

Bemærk venligst, at vi tilføjer ruter til en separat rutetabel 100 den vil kun indeholde to nødvendige ruter for at sende en svarpakke gennem gatewayen 1.2.3.1, placeret bag grænsefladen eth0.100.

Nu skal vi tilføje en simpel regel:

ip rule add from 1.2.3.0/24 lookup 100

som udtrykkeligt siger: hvis pakkens kildeadresse er i 1.2.3.0/24, så skal du bruge routingtabellen 100. I den har vi allerede beskrevet den rute, som vil sende ham igennem 1.2.3.1

Case 4: Når du har brug for politikbaseret routing

Netværkstopologien er den samme som i det foregående eksempel, men lad os sige, at du også vil have adgang til eksterne pooladresser 1.2.3.0/24 fra dine pods:

Det ejendommelige er, at når man får adgang til en hvilken som helst adresse i 1.2.3.0/24, rammer svarpakken noden og har en kildeadresse i området 1.2.3.0/24 vil lydigt blive sendt til eth0.100, men vi vil have Kubernetes til at omdirigere den til vores første pod, som genererede den oprindelige anmodning.

At løse dette problem viste sig at være svært, men det blev muligt takket være politikbaseret routing:

For en bedre forståelse af processen er her et netfilter blokdiagram:

Lad os først, som i det foregående eksempel, oprette en ekstra routingtabel:

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

Lad os nu tilføje et par regler til 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

Disse regler vil markere indgående forbindelser til grænsefladen eth0.100, markerer alle pakker med tagget 0x100, vil svar inden for samme forbindelse også blive markeret med det samme tag.

Nu kan vi tilføje en routingregel:

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

Det vil sige alle pakker med en kildeadresse 1.2.3.0/24 og tag 0x100 skal dirigeres ved hjælp af en tabel 100.

Således er andre pakker modtaget på en anden grænseflade ikke underlagt denne regel, som vil tillade dem at blive rutet ved hjælp af standard Kubernetes-værktøjer.

Der er en ting mere, i Linux er der et såkaldt omvendt sti-filter, som ødelægger hele hindbæret; det udfører en simpel kontrol: for alle indgående pakker ændrer den pakkens kildeadresse med afsenderadressen og kontrollerer, om pakken kan forlade den samme grænseflade, som den blev modtaget på, hvis ikke, vil den filtrere den fra.

Problemet er, at i vores tilfælde vil det ikke fungere korrekt, men vi kan deaktivere det:

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

Bemærk venligst, at den første kommando styrer den globale opførsel af rp_filter; hvis den ikke er deaktiveret, vil den anden kommando ikke have nogen effekt. De resterende grænseflader forbliver dog med rp_filter aktiveret.

For ikke at begrænse funktionen af ​​filteret fuldstændigt, kan vi bruge implementeringen rp_filter til netfilter. Ved at bruge rpfilter som et iptables-modul kan du konfigurere ret fleksible regler, for eksempel:

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

aktiver rp_filter på grænsefladen eth0.100 for alle adresser undtagen 1.2.3.0/24.

Kilde: www.habr.com