Haud ita pridem susceptus eram cum rarissimo munere pro MetalLB excitandi. Omnia denique essent, quia... Plerumque MetalLB actiones additas non requirit, sed in casu nostro magnum botrum habemus cum configuratione network simplicissima.

In hoc articulo tibi dicam quomodo configurare principium substructum et consilium substructum fundere ad retis externi tui botri.

Non singula persequar de inaugurandi et configurandi MetalLB, quandoquidem te jam experientiam aliquam suppono. Recta ad punctum proficiscendum suadeo, nempe fundere excitandum. Ita habemus quattuor casus;

Causam I: Cum nulla configuratione non requiritur

Intueamur causam simplicem.

Additae figurae fusurae non requiritur cum inscriptiones a MetalLB editae in eodem subnet ac inscriptiones nodis tuae sunt.

Exempli gratia, habes subnet 192.168.1.0/24, habet iter 192.168.1.1, et nodos excipe verba: 192.168.1.10-30, deinde pro MetalLB accommodare potes latitudinem 192.168.1.100-120 et scito se sine ulla addita configuratione operari.

Cur est? Quia nodi tui iam ambages configurantur;

# 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

Et inscriptiones ex eodem ambitu reddet sine ullis adiectis actionibus.

Causa II, cum additional customization est requiratur

Additiones itinera configurare debes, quoties nodi nodi tui figuratum non habent IP inscriptionem aut meatum ad subnet, pro quo MetalLB quaestiones inscriptiones habent.

Explicabo paulo subtilius. Quotiens MetalLB inscriptionem emittit, comparari potest cum simplici assignatione simili:

ip addr add 10.9.8.7/32 dev lo

Adtende:

• a) Oratio ponitur cum praepositione /32 hoc est, via non sponte addita subnet ei (sicut oratio est)
• b) Oratio cuilibet nodi interfaciei adhaeret (exempli gratia loopback). Memorabile est hic lineamenta acervi Linux retis. Quocumque interfacies electronicam addas, nucleus semper processit arp petitiones et arp responsa cuivis ex eis mittes, hic modus recte consideratur et praeterea satis late adhibetur in dynamica rerum ambitu qualis Kubernetes.

Mores hic nativus esse potest, exempli gratia, quod arp stricte dando;

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

Hoc in casu, responsiones arp tantum mittentur si interface expressis verbis IP peculiarem contineat. Hic occasus requiritur si vis MetalLB uti et kube-procurator tuus in IPVS modo currit.

Attamen, MetalLB nucleo non utitur ad petitiones arp processus, sed ipsa in spatio usoris facit, ergo haec optio operationem MetalLB non afficit.

Redeamus ad negotium nostrum. Si via inscriptionum editarum in nodis tuis non est, ante omnes nodos adde:

ip route add 10.9.8.0/24 dev eth1

Causa III, cum opus est fons-fundatur fuso

Fons-fundatur fuso configurare debes cum facis per portam separatam recipias, non figuratum per defaltam, ergo responsionis fasciculi etiam per eandem ianuam ire debent.

Exempli gratia idem subnet 192.168.1.0/24 nodi tuis dicata, sed externas inscriptiones uti vis MetalLB. Sit scriptor plures inscriptiones habes ex subnet 1.2.3.0/24 sita in VLAN 100 ac Kubernetes operas extrinsecus accedere voles uti.

Cum contingentes 1.2.3.4 aliud subnet quam petens eris 1.2.3.0/24 et responsum expectamus. Nodus qui nunc est dominus pro inscriptione MetalLB-edita 1.2.3.4, accipiet fasciculum de iter 1.2.3.1responsum autem ei necesse est ut eadem via vadat 1.2.3.1.

Cum nos nodi iam default porta figuram habet 192.168.1.1tunc vadat responsio ei per defaltam et non 1.2.3.1per quam sarcinam recepimus.

Quomodo hanc rem tolerare?

Hoc in casu, omnes nodos tuos ita praeparare debes ut inscriptionibus externis sine addita configuratione servire parati sint. Hoc est, exempli gratia, interface VLAN nodi in antecessum creare debes:

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

Et adde uias;

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

Lorem quod addimus itinera ad mensam separatam excitandam 100 duas tantum vias continebit necesse est ut responsionem fasciculum per ianuam mittat 1.2.3.1, sita post interface eth0.100.

Nunc opus est regulam simplicem addere;

ip rule add from 1.2.3.0/24 lookup 100

quod diserte dicit: si fons electronica fasciculus inest 1.2.3.0/24ergo opus est uti ad excitandas mensas 100. In eo iam demonstravimus viam, quae eum per- mitteret 1.2.3.1

Causa IV: cum opus est consilium-fundatur fuso

Topologia retiacula eadem est quae in priore exemplo, sed te quoque dicamus velle posse accedere ad inscriptiones piscinae externae 1.2.3.0/24 de siliquis tuis:

Proprium est, quod cum aliqua inscriptione accessio 1.2.3.0/24, responsio fasciculum nodi ferit et fontem electronicum habet in ambitu 1.2.3.0/24 obedienter ad eth0.100sed volumus Kubernetes redirect ad primum vasculum nostrum, quod generavit petitionem originalium.

Hoc problema solvendum evasit difficilis, sed fieri potest ut per fusione consiliorum facta sit:

Ad meliorem processum intelligendum, hic in diagrammate netfilter scandalum est:

Primum, ut in exemplo praecedente, additam mensam fusuram faciamus;

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

Nunc paucas regulas iptables addamus:

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

Hae regulae notabunt hospites advenientes ad interface eth0.100Notans omnes facis cum tag 0x100responsiones intra eundem nexum etiam cum eodem tag notandae sunt.

Nunc regulam routing addere possumus:

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

Hoc est, omnia cum fonte inscriptionem facis 1.2.3.0/24 et tag 0x100 pulsos per mensam 100.

Sic aliae fasciculi in alium interfacium receptae huic regulae non subduntur, quae permittunt ut instrumenta Kubernetes vexillum fusa sint.

Unum plus est, in Linux est via transversa sic dicta colum, quae totam rem corrumpit, simplex perscriptio facit: omnes enim ineuntes facis, mutat principium electronicum conleci cum electronica mittentis et cohibet an. fasciculus per idem interface quod receptum est relinquere potest, si minus, illud eliquare.

Problema est quod in casu nostro non recte operari, sed inaccipere possumus;

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

Quaeso nota quod primum imperium globalem filtri moderatur: si minus debilis est, secundum mandatum nullum effectum habebit. Attamen reliquiae interfaces e filtro cinematographico manent.

Ut operationem colum non omnino circumscribat, exsequendam filter pro netfilter uti possumus. Ratione uti moduli iptables, regulas flexibiles satis configurare potes, exempli gratia:

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

enable rp_filter in interface eth0.100 omnibus oratio nisi 1.2.3.0/24.

Source: www.habr.com