Ddim yn bell yn ôl roeddwn yn wynebu tasg anarferol iawn o sefydlu llwybro ar gyfer MetalLB. Byddai popeth yn iawn, oherwydd ... Fel arfer nid oes angen unrhyw gamau gweithredu ychwanegol ar MetalLB, ond yn ein hachos ni mae gennym glwstwr eithaf mawr gyda chyfluniad rhwydwaith syml iawn.

Yn yr erthygl hon byddaf yn dweud wrthych sut i ffurfweddu llwybro seiliedig ar ffynhonnell a pholisi ar gyfer rhwydwaith allanol eich clwstwr.

Nid af i fanylion am osod a ffurfweddu MetalLB, gan fy mod yn tybio bod gennych rywfaint o brofiad eisoes. Awgrymaf fynd yn syth at y pwynt, sef sefydlu llwybro. Felly mae gennym bedwar achos:

Achos 1: Pan nad oes angen cyfluniad

Gadewch i ni edrych ar achos syml.

Nid oes angen cyfluniad llwybro ychwanegol pan fo'r cyfeiriadau a roddwyd gan MetalLB yn yr un is-rwydwaith â chyfeiriadau eich nodau.

Er enghraifft, mae gennych is-rwydwaith 192.168.1.0/24, mae ganddo lwybrydd 192.168.1.1, ac mae eich nodau yn derbyn cyfeiriadau: 192.168.1.10-30, yna ar gyfer MetalLB gallwch chi addasu'r ystod 192.168.1.100-120 a sicrhewch y byddant yn gweithio heb unrhyw ffurfweddiad ychwanegol.

Pam hynny? Oherwydd bod gan eich nodau lwybrau eisoes wedi'u ffurfweddu:

# 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

A bydd cyfeiriadau o'r un ystod yn eu hailddefnyddio heb unrhyw gamau gweithredu ychwanegol.

Achos 2: Pan fydd angen addasu ychwanegol

Dylech ffurfweddu llwybrau ychwanegol pryd bynnag nad oes gan eich nodau gyfeiriad IP wedi'i ffurfweddu neu lwybr i'r is-rwydwaith y mae MetalLB yn cyhoeddi cyfeiriadau ar ei gyfer.

Egluraf ychydig yn fwy manwl. Pryd bynnag y bydd MetalLB yn allbynnu cyfeiriad, gellir ei gymharu ag aseiniad syml fel:

ip addr add 10.9.8.7/32 dev lo

Rhowch sylw i:

• a) Rhoddir rhagddodiad i'r cyfeiriad /32 hynny yw, ni fydd llwybr yn cael ei ychwanegu'n awtomatig at yr is-rwydwaith ar ei gyfer (cyfeiriad yn unig ydyw)
• b) Mae'r cyfeiriad ynghlwm wrth unrhyw ryngwyneb nod (er enghraifft loopback). Mae'n werth sôn yma am nodweddion pentwr rhwydwaith Linux. Ni waeth pa ryngwyneb rydych chi'n ychwanegu'r cyfeiriad ato, bydd y cnewyllyn bob amser yn prosesu ceisiadau arp ac yn anfon ymatebion arp i unrhyw un ohonynt, ystyrir bod yr ymddygiad hwn yn gywir ac, ar ben hynny, fe'i defnyddir yn eithaf eang mewn amgylchedd mor ddeinamig â Kubernetes.

Gellir addasu'r ymddygiad hwn, er enghraifft trwy alluogi arp llym:

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

Yn yr achos hwn, dim ond os yw'r rhyngwyneb yn cynnwys cyfeiriad IP penodol y bydd ymatebion arp yn cael eu hanfon. Mae angen y gosodiad hwn os ydych chi'n bwriadu defnyddio MetalLB a bod eich kube-proxy yn rhedeg yn y modd IPVS.

Fodd bynnag, nid yw MetalLB yn defnyddio'r cnewyllyn i brosesu ceisiadau arp, ond mae'n ei wneud ei hun yn y gofod defnyddiwr, felly ni fydd yr opsiwn hwn yn effeithio ar weithrediad MetalLB.

Gadewch i ni ddychwelyd at ein tasg. Os nad yw'r llwybr ar gyfer y cyfeiriadau a gyhoeddwyd yn bodoli ar eich nodau, ychwanegwch ef ymlaen llaw at bob nod:

ip route add 10.9.8.0/24 dev eth1

Achos 3: Pan fydd angen llwybro yn seiliedig ar ffynhonnell arnoch

Bydd angen i chi ffurfweddu llwybro seiliedig ar ffynhonnell pan fyddwch yn derbyn pecynnau trwy borth ar wahân, nid yr un a ffurfweddwyd yn ddiofyn, felly dylai pecynnau ymateb hefyd fynd drwy'r un porth.

Er enghraifft, mae gennych yr un is-rwydwaith 192.168.1.0/24 ymroddedig i'ch nodau, ond rydych chi am gyhoeddi cyfeiriadau allanol gan ddefnyddio MetalLB. Gadewch i ni dybio bod gennych chi gyfeiriadau lluosog o is-rwydwaith 1.2.3.0/24 wedi'i leoli yn VLAN 100 ac rydych chi am eu defnyddio i gael mynediad at wasanaethau Kubernetes yn allanol.

Wrth gysylltu 1.2.3.4 byddwch yn gwneud ceisiadau gan is-rwydwaith gwahanol i 1.2.3.0/24 ac aros am ateb. Y nod sydd ar hyn o bryd yn feistr ar y cyfeiriad a gyhoeddwyd gan MetalLB 1.2.3.4, Bydd yn derbyn y pecyn gan y llwybrydd 1.2.3.1, ond rhaid i'r atebiad iddo, o angenrheidrwydd, fyned yr un llwybr, drwodd 1.2.3.1.

Gan fod gan ein nod borth rhagosodedig wedi'i ffurfweddu eisoes 192.168.1.1, yna yn ddiofyn bydd yr ymateb yn mynd iddo, ac nid i 1.2.3.1, trwy yr hwn y derbyniasom y pecyn.

Sut i ymdopi â'r sefyllfa hon?

Yn yr achos hwn, mae angen i chi baratoi'ch holl nodau yn y fath fodd fel eu bod yn barod i wasanaethu cyfeiriadau allanol heb gyfluniad ychwanegol. Hynny yw, ar gyfer yr enghraifft uchod, mae angen i chi greu rhyngwyneb VLAN ar y nod ymlaen llaw:

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

Ac yna ychwanegu llwybrau:

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

Sylwch ein bod yn ychwanegu llwybrau at dabl llwybro ar wahân 100 bydd yn cynnwys dim ond dau lwybr sy'n angenrheidiol i anfon pecyn ymateb drwy'r porth 1.2.3.1, wedi'i leoli y tu ôl i'r rhyngwyneb eth0.100.

Nawr mae angen i ni ychwanegu rheol syml:

ip rule add from 1.2.3.0/24 lookup 100

sy'n dweud yn benodol: os yw cyfeiriad ffynhonnell y pecyn i mewn 1.2.3.0/24, yna mae angen i chi ddefnyddio'r tabl llwybro 100. Ynddo rydym eisoes wedi disgrifio'r llwybr a fydd yn ei anfon drwodd 1.2.3.1

Achos 4: Pan fyddwch angen llwybro seiliedig ar bolisi

Mae topoleg y rhwydwaith yr un peth ag yn yr enghraifft flaenorol, ond gadewch i ni ddweud eich bod chi hefyd am allu cyrchu cyfeiriadau cronfa allanol 1.2.3.0/24 o'ch codennau:

Yr hynodrwydd yw wrth gyrchu unrhyw gyfeiriad yn 1.2.3.0/24, mae'r pecyn ymateb yn taro'r nod ac mae ganddo gyfeiriad ffynhonnell yn yr ystod 1.2.3.0/24 anfonir yn ufudd i eth0.100, ond rydym am i Kubernetes ei ailgyfeirio i'n pod cyntaf, a greodd y cais gwreiddiol.

Bu’n anodd datrys y broblem hon, ond daeth yn bosibl diolch i lwybro ar sail polisi:

I gael gwell dealltwriaeth o'r broses, dyma ddiagram bloc netfilter:

Yn gyntaf, fel yn yr enghraifft flaenorol, gadewch i ni greu tabl llwybro ychwanegol:

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

Nawr, gadewch i ni ychwanegu ychydig o reolau at 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

Bydd y rheolau hyn yn nodi cysylltiadau sy'n dod i mewn i'r rhyngwyneb eth0.100, gan farcio pob pecyn gyda'r tag 0x100, bydd ymatebion o fewn yr un cysylltiad hefyd yn cael eu marcio gyda'r un tag.

Nawr gallwn ychwanegu rheol llwybro:

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

Hynny yw, pob pecyn gyda chyfeiriad ffynhonnell 1.2.3.0/24 a thag 0x100 rhaid ei lwybro gan ddefnyddio tabl 100.

Felly, nid yw pecynnau eraill a dderbynnir ar ryngwyneb arall yn ddarostyngedig i'r rheol hon, a fydd yn caniatáu iddynt gael eu cyfeirio gan ddefnyddio offer Kubernetes safonol.

Mae un peth arall, yn Linux mae hidlydd llwybr cefn fel y'i gelwir, sy'n difetha'r holl beth; mae'n perfformio gwiriad syml: ar gyfer pob pecyn sy'n dod i mewn, mae'n newid cyfeiriad ffynhonnell y pecyn gyda'r cyfeiriad anfonwr ac yn gwirio a yw gall y pecyn adael trwy'r un rhyngwyneb ag y'i derbyniwyd, os na, bydd yn ei hidlo allan.

Y broblem yw na fydd yn gweithio'n gywir yn ein hachos ni, ond gallwn ei analluogi:

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

Sylwch fod y gorchymyn cyntaf yn rheoli ymddygiad byd-eang rp_filter; os nad yw'n anabl, ni fydd yr ail orchymyn yn cael unrhyw effaith. Fodd bynnag, bydd y rhyngwynebau sy'n weddill yn aros gyda rp_filter wedi'i alluogi.

Er mwyn peidio â chyfyngu'n llwyr ar weithrediad yr hidlydd, gallwn ddefnyddio'r gweithrediad rp_filter ar gyfer netfilter. Gan ddefnyddio rpfilter fel modiwl iptables, gallwch chi ffurfweddu rheolau eithaf hyblyg, er enghraifft:

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

galluogi rp_filter ar y rhyngwyneb eth0.100 ar gyfer pob cyfeiriad ac eithrio 1.2.3.0/24.

Ffynhonnell: hab.com