Ní fada ó shin bhí tasc an-neamhghnách le sárú agam maidir le socrú a dhéanamh do MetalLB. Bheadh ​​gach rud go breá, mar... De ghnáth ní éilíonn MetalLB aon ghníomhartha breise, ach inár gcás tá braisle sách mór againn le cumraíocht líonra an-simplí.

San Airteagal seo inseoidh mé duit conas ródú foinse-bhunaithe agus beartas-bhunaithe a chumrú do líonra seachtrach do bhraisle.

Ní rachaidh mé isteach go mion maidir le MetalLB a shuiteáil agus a chumrú, ós rud é go gceapaim go bhfuil roinnt taithí agat cheana féin. Molaim dul díreach go dtí an pointe, eadhon socrú a dhéanamh ar ródú. Mar sin tá ceithre chás againn:

Cás 1: Nuair nach bhfuil aon chumraíocht ag teastáil

Breathnaímid ar chás simplí.

Ní theastaíonn cumraíocht ródaithe bhreise nuair a bhíonn na seoltaí arna n-eisiúint ag MetalLB san fholíon céanna le seoltaí do nóid.

Mar shampla, tá subnet agat 192.168.1.0/24, tá ródaire aige 192.168.1.1, agus faigheann do nóid seoltaí: 192.168.1.10-30, ansin le haghaidh MetalLB is féidir leat an raon a choigeartú 192.168.1.100-120 agus bí cinnte go n-oibreoidh siad gan aon chumraíocht bhreise.

Cén fáth é sin? Toisc go bhfuil bealaí cumraithe ag do nóid cheana féin:

# 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

Agus déanfaidh seoltaí ón raon céanna iad a athúsáid gan aon ghníomhartha breise.

Cás 2: Nuair is gá saincheaptha breise

Ba cheart duit bealaí breise a chumrú aon uair nach bhfuil seoladh IP cumraithe ag do nóid nó bealach chuig an bhfolíon a eisíonn MetalLB seoltaí dó.

Míneoidh mé beagán níos mine. Aon uair a chuireann MetalLB seoladh amach, is féidir é a chur i gcomparáid le tasc simplí mar:

ip addr add 10.9.8.7/32 dev lo

Aird a thabhairt ar:

• a) Tugtar réimír don seoladh /32 is é sin, ní chuirfear bealach isteach go huathoibríoch leis an bhfo-líon dó (níl ann ach seoladh)
• b) Tá an seoladh ceangailte le haon chomhéadan nód (mar shampla loopback). Is fiú a lua anseo gnéithe an chairn líonra Linux. Is cuma cén comhéadan a gcuireann tú an seoladh leis, próiseálfaidh an t-eithne iarratais arp i gcónaí agus seolfaidh sé freagraí stua chuig aon cheann acu, meastar go bhfuil an iompar seo ceart agus, ina theannta sin, úsáidtear go forleathan é i dtimpeallacht chomh dinimiciúil le Kubernetes.

Is féidir an iompar seo a shaincheapadh, mar shampla trí stua dian a chumasú:

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

Sa chás seo, ní sheolfar freagraí arp ach amháin má tá seoladh IP sonrach sa chomhéadan. Tá an socrú seo ag teastáil má tá sé beartaithe agat MetalLB a úsáid agus do sheachvótálaí kube ag rith i mód IPVS.

Mar sin féin, ní úsáideann MetalLB an eithne chun iarratais arp a phróiseáil, ach déanann sé é féin i spás úsáideora, mar sin ní dhéanfaidh an rogha seo difear d'oibriú MetalLB.

Fillfimid ar ár dtasc. Mura bhfuil an bealach do na seoltaí eisithe ar do nóid, cuir leis na nóid go léir é roimh ré:

ip route add 10.9.8.0/24 dev eth1

Cás 3: Nuair a bhíonn ródú foinse-bhunaithe de dhíth ort

Beidh ort ródú foinse-bhunaithe a chumrú nuair a fhaigheann tú paicéid trí gheata ar leith, ní an ceann atá cumraithe de réir réamhshocraithe, mar sin ba cheart go rachadh paicéid freagartha tríd an ngeata céanna freisin.

Mar shampla, tá an subnet céanna agat 192.168.1.0/24 tiomanta do do nóid, ach ba mhaith leat seoltaí seachtracha a eisiúint ag baint úsáide as MetalLB. Glacaimid leis go bhfuil seoltaí iolracha agat ó fholíon 1.2.3.0/24 lonnaithe i VLAN 100 agus ba mhaith leat iad a úsáid chun rochtain a fháil ar sheirbhísí Kubernetes go seachtrach.

Nuair a dhéanann tú teagmháil 1.2.3.4 beidh tú ag déanamh iarratais ó fholíon eile seachas 1.2.3.0/24 agus fan le freagra. An nód atá faoi láthair ina mháistir don seoladh eisithe MetalLB 1.2.3.4, gheobhaidh tú an paicéad ón ródaire 1.2.3.1, ach caithfidh an freagra dó dul ar an mbealach céanna, tríd 1.2.3.1.

Ós rud é go bhfuil geata réamhshocraithe cumraithe ag ár nód cheana féin 192.168.1.1, ansin de réir réamhshocraithe rachaidh an freagra chuige, agus ní chuig 1.2.3.1, trína bhfuaireamar an pacáiste.

Conas déileáil leis an staid seo?

Sa chás seo, ní mór duit do nóid go léir a ullmhú sa chaoi is go bhfuil siad réidh chun seoltaí seachtracha a sheirbheáil gan cumraíocht bhreise. Is é sin, don sampla thuas, ní mór duit comhéadan VLAN a chruthú ar an nód roimh ré:

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

Agus ansin cuir bealaí leis:

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

Tabhair faoi deara go gcuirimid bealaí le tábla ródaithe ar leith 100 ní bheidh ann ach dhá bhealach is gá chun paicéad freagartha a sheoladh tríd an ngeata 1.2.3.1, atá suite taobh thiar den chomhéadan eth0.100.

Anois ní mór dúinn riail shimplí a chur leis:

ip rule add from 1.2.3.0/24 lookup 100

a deir go sainráite: má tá seoladh foinse an phaicéid isteach 1.2.3.0/24, ansin ní mór duit an tábla ródaithe a úsáid 100. In sé tá cur síos déanta againn cheana ar an mbealach a sheolfaidh tríd 1.2.3.1

Cás 4: Nuair a bhíonn ródú bunaithe ar bheartais uait

Tá topology an líonra mar an gcéanna leis an sampla roimhe seo, ach abair linn gur mhaith leat rochtain a fháil ar sheoltaí comhthiomsaithe seachtracha freisin 1.2.3.0/24 ó do phodaí:

Is é an peculiarity go nuair a rochtain a fháil ar aon seoladh i 1.2.3.0/24, buaileann an paicéad freagartha an nód agus tá seoladh foinse sa raon 1.2.3.0/24 a sheoladh go obediently chuig eth0.100, ach ba mhaith linn Kubernetes é a atreorú chuig ár gcéad pod, a ghin an t-iarratas bunaidh.

Bhí sé deacair an fhadhb seo a réiteach, ach d’éirigh sé indéanta a bhuí le ródú bunaithe ar bheartas:

Chun tuiscint níos fearr a fháil ar an bpróiseas, seo léaráid bloc netfilter:

Ar dtús, mar atá sa sampla roimhe seo, cruthaímid tábla ródaithe breise:

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

Anois cuirimis roinnt rialacha le 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

Marcálfaidh na rialacha seo naisc isteach leis an gcomhéadan eth0.100, ag marcáil na paicéid go léir leis an gclib 0x100, marcálfar freagraí laistigh den nasc céanna leis an gclib céanna freisin.

Anois is féidir linn riail ródúcháin a chur leis:

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

Is é sin, gach paicéad le seoladh foinse 1.2.3.0/24 agus clib 0x100 Ní mór é a ródú ag baint úsáide as tábla 100.

Mar sin, níl paicéid eile a fhaightear ar chomhéadan eile faoi réir na rialach seo, rud a ligfidh dóibh a bheith ródaithe ag baint úsáide as uirlisí caighdeánacha Kubernetes.

Tá rud amháin eile ann, i Linux tá scagaire cosáin droim ar ais, mar a thugtar air, a mhilleann an rud ar fad; déanann sé seiceáil simplí: i gcás gach paicéad a thagann isteach, athraíonn sé seoladh foinse an phaicéid le seoladh an tseoltóra agus seiceálann sé an bhfuil is féidir leis an bpaicéad imeacht tríd an gcomhéadan céanna ar a bhfuarthas é , mura bhfuil, déanfaidh sé é a scagadh.

Is í an fhadhb atá ann inár gcás nach n-oibreoidh sé i gceart, ach is féidir linn é a dhíchumasú:

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

Tabhair faoi deara le do thoil go rialaíonn an chéad ordú iompar domhanda rp_filter; mura bhfuil sé díchumasaithe, ní bheidh aon éifeacht ag an dara ordú. Mar sin féin, fanfaidh na comhéadain atá fágtha le rp_filter cumasaithe.

D'fhonn gan teorainn a chur le hoibriú an scagaire go hiomlán, is féidir linn cur i bhfeidhm rp_filter a úsáid le haghaidh netfilter. Ag baint úsáide as rpfilter mar mhodúl iptables, is féidir leat rialacha sách solúbtha a chumrú, mar shampla:

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

cumasaigh rp_filter ar an gcomhéadan eth0.100 do gach seoladh ach amháin 1.2.3.0/24.

Foinse: will.com