Pirms neilga laika es saskāros ar ļoti neparastu uzdevumu izveidot MetalLB maršrutēšanu. Viss būtu labi, jo... Parasti MetalLB nekādas papildu darbības neprasa, taču mūsu gadījumā mums ir diezgan liels klasteris ar ļoti vienkāršu tīkla konfigurāciju.

Šajā rakstā es jums pastāstīšu, kā konfigurēt uz avotu un politiku balstītu maršrutēšanu jūsu klastera ārējam tīklam.

Es neiedziļināšos par MetalLB instalēšanu un konfigurēšanu, jo pieņemu, ka jums jau ir zināma pieredze. Es iesaku doties tieši pie lietas, proti, maršrutēšanas iestatīšanas. Tātad mums ir četri gadījumi:

1. gadījums: ja nav nepieciešama konfigurācija

Apskatīsim vienkāršu gadījumu.

Papildu maršrutēšanas konfigurācija nav nepieciešama, ja MetalLB izsniegtās adreses atrodas tajā pašā apakštīklā ar jūsu mezglu adresēm.

Piemēram, jums ir apakštīkls 192.168.1.0/24, tam ir maršrutētājs 192.168.1.1, un jūsu mezgli saņem adreses: 192.168.1.10-30, tad MetalLB varat pielāgot diapazonu 192.168.1.100-120 un pārliecinieties, ka tie darbosies bez papildu konfigurācijas.

Kāpēc ir tā, ka? Tā kā jūsu mezglos jau ir konfigurēti maršruti:

# 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

Un adreses no tā paša diapazona tās atkārtoti izmantos bez papildu darbībām.

2. gadījums: ja nepieciešama papildu pielāgošana

Jums ir jākonfigurē papildu maršruti ikreiz, kad jūsu mezgliem nav konfigurētas IP adreses vai maršruta uz apakštīklu, kuram MetalLB izsniedz adreses.

Es paskaidrošu nedaudz sīkāk. Ikreiz, kad MetalLB izvada adresi, to var salīdzināt ar vienkāršu piešķiršanu, piemēram:

ip addr add 10.9.8.7/32 dev lo

Pievērs uzmanību:

• a) Adrese tiek piešķirta ar prefiksu /32 tas ir, maršruts netiks automātiski pievienots tā apakštīklam (tā ir tikai adrese)
• b) Adrese ir pievienota jebkura mezgla saskarnei (piemēram, cilpa). Šeit ir vērts pieminēt Linux tīkla steka funkcijas. Neatkarīgi no tā, kuram interfeisam jūs pievienojat adresi, kodols vienmēr apstrādās arp pieprasījumus un nosūtīs arp atbildes uz jebkuru no tiem, šī uzvedība tiek uzskatīta par pareizu un turklāt tiek diezgan plaši izmantota tik dinamiskā vidē kā Kubernetes.

Šo darbību var pielāgot, piemēram, iespējojot stingru arp:

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

Šajā gadījumā ARP atbildes tiks nosūtītas tikai tad, ja saskarnē ir skaidri norādīta noteikta IP adrese. Šis iestatījums ir nepieciešams, ja plānojat izmantot MetalLB un jūsu kube starpniekserveris darbojas IPVS režīmā.

Tomēr MetalLB neizmanto kodolu, lai apstrādātu ARP pieprasījumus, bet gan pats to veic lietotāja telpā, tāpēc šī opcija neietekmēs MetalLB darbību.

Atgriezīsimies pie sava uzdevuma. Ja izsniegto adrešu maršruts jūsu mezglos nepastāv, pievienojiet to iepriekš visiem mezgliem:

ip route add 10.9.8.0/24 dev eth1

3. gadījums: kad nepieciešama uz avotu balstīta maršrutēšana

Jums būs jākonfigurē uz avotu balstīta maršrutēšana, kad saņemat paketes caur atsevišķu vārteju, nevis to, kas konfigurēta pēc noklusējuma, tāpēc arī atbildes paketēm ir jāiet caur to pašu vārteju.

Piemēram, jums ir tas pats apakštīkls 192.168.1.0/24 veltīts jūsu mezgliem, bet vēlaties izsniegt ārējās adreses, izmantojot MetalLB. Pieņemsim, ka jums ir vairākas adreses no apakštīkla 1.2.3.0/24 atrodas VLAN 100, un vēlaties tos izmantot, lai ārēji piekļūtu Kubernetes pakalpojumiem.

Sazinoties 1.2.3.4 jūs iesniegsit pieprasījumus no cita apakštīkla nekā 1.2.3.0/24 un gaidi atbildi. Mezgls, kas pašlaik ir galvenais MetalLB izsniegtās adreses mezgls 1.2.3.4, saņems paketi no maršrutētāja 1.2.3.1, bet atbilde viņam noteikti jāiet pa to pašu ceļu, cauri 1.2.3.1.

Tā kā mūsu mezglam jau ir konfigurēta noklusējuma vārteja 192.168.1.1, pēc noklusējuma atbilde tiks nosūtīta viņam, nevis 1.2.3.1, caur kuru saņēmām paku.

Kā tikt galā ar šo situāciju?

Šajā gadījumā jums ir jāsagatavo visi mezgli tā, lai tie būtu gatavi apkalpot ārējās adreses bez papildu konfigurācijas. Tas nozīmē, ka iepriekš minētajā piemērā mezglā iepriekš jāizveido VLAN interfeiss:

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

Un pēc tam pievienojiet maršrutus:

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

Lūdzu, ņemiet vērā, ka mēs pievienojam maršrutus atsevišķai maršrutēšanas tabulai 100 tajā būs tikai divi maršruti, kas nepieciešami, lai nosūtītu atbildes paketi caur vārteju 1.2.3.1, kas atrodas aiz interfeisa eth0.100.

Tagad mums jāpievieno vienkāršs noteikums:

ip rule add from 1.2.3.0/24 lookup 100

kas skaidri saka: ja paketes avota adrese ir 1.2.3.0/24, tad jums ir jāizmanto maršrutēšanas tabula 100. Tajā mēs jau esam aprakstījuši maršrutu, kas viņu izsūtīs 1.2.3.1

4. gadījums: ja nepieciešams uz politiku balstīts maršrutēšana

Tīkla topoloģija ir tāda pati kā iepriekšējā piemērā, taču pieņemsim, ka vēlaties piekļūt arī ārējām pūla adresēm 1.2.3.0/24 no jūsu pākstiem:

Īpatnība ir tāda, ka, piekļūstot jebkurai adresei 1.2.3.0/24, atbildes pakete sasniedz mezglu, un diapazonā ir avota adrese 1.2.3.0/24 tiks paklausīgi nosūtīts uz eth0.100, taču mēs vēlamies, lai Kubernetes to novirzītu uz mūsu pirmo podziņu, kas ģenerēja sākotnējo pieprasījumu.

Šīs problēmas risinājums izrādījās sarežģīts, taču tas kļuva iespējams, pateicoties uz politiku balstītai maršrutēšanai:

Lai labāk izprastu procesu, šeit ir tīkla filtra blokshēma:

Vispirms, tāpat kā iepriekšējā piemērā, izveidosim papildu maršrutēšanas tabulu:

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

Tagad pievienosim iptables dažus noteikumus:

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

Šie noteikumi atzīmēs ienākošos savienojumus ar saskarni eth0.100, atzīmējot visas paketes ar tagu 0x100, atbildes tajā pašā savienojumā arī tiks atzīmētas ar to pašu tagu.

Tagad mēs varam pievienot maršrutēšanas noteikumu:

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

Tas ir, visas paketes ar avota adresi 1.2.3.0/24 un atzīmējiet 0x100 jānovirza, izmantojot tabulu 100.

Tādējādi šis noteikums neattiecas uz citām paketēm, kas saņemtas citā saskarnē, kas ļaus tās maršrutēt, izmantojot standarta Kubernetes rīkus.

Ir vēl viena lieta, Linux ir tā sauktais apgrieztā ceļa filtrs, kas visu sabojā, tas veic vienkāršu pārbaudi: visām ienākošajām paketēm maina paketes avota adresi ar sūtītāja adresi un pārbauda, ​​vai Pakete var iziet caur to pašu interfeisu, kurā tā tika saņemta, ja nē, tā to filtrēs.

Problēma ir tāda, ka mūsu gadījumā tas nedarbosies pareizi, bet mēs varam to atspējot:

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

Lūdzu, ņemiet vērā, ka pirmā komanda kontrolē rp_filter globālo darbību; ja tā nav atspējota, otrajai komandai nebūs nekādas ietekmes. Tomēr pārējās saskarnes paliks ar iespējotu rp_filter.

Lai pilnībā neierobežotu filtra darbību, netfilter varam izmantot rp_filter implementāciju. Izmantojot rpfilter kā iptables moduli, varat konfigurēt diezgan elastīgus noteikumus, piemēram:

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

interfeisā iespējot rp_filter eth0.100 visām adresēm, izņemot 1.2.3.0/24.

Avots: www.habr.com