No fa molt, em vaig enfrontar a una tasca molt inusual de configurar l'encaminament per a MetalLB. Tot aniria bé, perquè... Normalment MetalLB no requereix cap acció addicional, però en el nostre cas tenim un clúster bastant gran amb una configuració de xarxa molt senzilla.

En aquest article us explicaré com configurar l'encaminament basat en la font i basat en polítiques per a la xarxa externa del vostre clúster.

No entraré en detalls sobre la instal·lació i la configuració de MetalLB, ja que suposo que ja teniu una mica d'experiència. Suggereixo anar directament al punt, és a dir, configurar l'encaminament. Per tant, tenim quatre casos:

Cas 1: quan no es requereix cap configuració

Vegem un cas senzill.

No es requereix una configuració d'encaminament addicional quan les adreces emeses per MetalLB es troben a la mateixa subxarxa que les adreces dels vostres nodes.

Per exemple, teniu una subxarxa 192.168.1.0/24, té un encaminador 192.168.1.1, i els vostres nodes reben adreces: 192.168.1.10-30, llavors per a MetalLB podeu ajustar el rang 192.168.1.100-120 i assegureu-vos que funcionaran sense cap configuració addicional.

Per què això? Com que els vostres nodes ja tenen rutes configurades:

# 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

I les adreces del mateix rang les reutilitzaran sense cap acció addicional.

Cas 2: quan es requereix una personalització addicional

Hauríeu de configurar rutes addicionals sempre que els vostres nodes no tinguin una adreça IP configurada o una ruta a la subxarxa per a la qual MetalLB emet adreces.

Ho explicaré amb una mica més de detall. Sempre que MetalLB emet una adreça, es pot comparar amb una assignació senzilla com:

ip addr add 10.9.8.7/32 dev lo

Para atenció a:

• a) L'adreça s'assigna amb un prefix /32 és a dir, una ruta no s'afegirà automàticament a la subxarxa (és només una adreça)
• b) L'adreça s'adjunta a qualsevol interfície de node (per exemple, loopback). Val la pena esmentar aquí les característiques de la pila de xarxa Linux. Independentment de la interfície a la qual afegiu l'adreça, el nucli sempre processarà les sol·licituds arp i enviarà respostes arp a qualsevol d'elles, aquest comportament es considera correcte i, a més, s'utilitza força en un entorn tan dinàmic com Kubernetes.

Aquest comportament es pot personalitzar, per exemple, activant l'arp estricte:

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

En aquest cas, les respostes arp només s'enviaran si la interfície conté explícitament una adreça IP específica. Aquesta configuració és necessària si teniu previst utilitzar MetalLB i el vostre kube-proxy s'està executant en mode IPVS.

Tanmateix, MetalLB no utilitza el nucli per processar sol·licituds arp, sinó que ho fa a l'espai d'usuari, de manera que aquesta opció no afectarà el funcionament de MetalLB.

Tornem a la nostra tasca. Si la ruta per a les adreces emeses no existeix als vostres nodes, afegiu-la per endavant a tots els nodes:

ip route add 10.9.8.0/24 dev eth1

Cas 3: quan necessiteu un enrutament basat en font

Haureu de configurar l'encaminament basat en la font quan rebeu paquets a través d'una passarel·la separada, no la configurada per defecte, per tant, els paquets de resposta també haurien de passar per la mateixa passarel·la.

Per exemple, teniu la mateixa subxarxa 192.168.1.0/24 dedicat als vostres nodes, però voleu emetre adreces externes mitjançant MetalLB. Suposem que teniu diverses adreces d'una subxarxa 1.2.3.0/24 situat a la VLAN 100 i voleu utilitzar-los per accedir als serveis de Kubernetes de manera externa.

En contactar 1.2.3.4 fareu sol·licituds des d'una subxarxa diferent de la 1.2.3.0/24 i esperar una resposta. El node que actualment és el mestre de l'adreça emesa per MetalLB 1.2.3.4, rebrà el paquet de l'encaminador 1.2.3.1, però la resposta per a ell ha de seguir necessàriament el mateix camí, a través 1.2.3.1.

Com que el nostre node ja té una passarel·la predeterminada configurada 192.168.1.1, aleshores, per defecte, la resposta anirà a ell i no a 1.2.3.1, a través del qual vam rebre el paquet.

Com afrontar aquesta situació?

En aquest cas, heu de preparar tots els vostres nodes de manera que estiguin preparats per servir adreces externes sense configuració addicional. És a dir, per a l'exemple anterior, heu de crear una interfície VLAN al node per endavant:

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

I després afegiu rutes:

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

Tingueu en compte que afegim rutes a una taula d'encaminament independent 100 només contindrà dues rutes necessàries per enviar un paquet de resposta a través de la passarel·la 1.2.3.1, situat darrere de la interfície eth0.100.

Ara hem d'afegir una regla senzilla:

ip rule add from 1.2.3.0/24 lookup 100

que diu explícitament: si l'adreça d'origen del paquet és a 1.2.3.0/24, llavors heu d'utilitzar la taula d'encaminament 100. En ella ja hem descrit la ruta que el farà passar 1.2.3.1

Cas 4: quan necessiteu un encaminament basat en polítiques

La topologia de la xarxa és la mateixa que a l'exemple anterior, però suposem que també voleu poder accedir a les adreces de grups externs 1.2.3.0/24 de les teves beines:

La particularitat és que en accedir a qualsevol adreça en 1.2.3.0/24, el paquet de resposta arriba al node i té una adreça d'origen a l'interval 1.2.3.0/24 serà enviat amb obediència eth0.100, però volem que Kubernetes el redirigeixi al nostre primer pod, que va generar la sol·licitud original.

Resoldre aquest problema va resultar difícil, però va ser possible gràcies a l'encaminament basat en polítiques:

Per a una millor comprensió del procés, aquí teniu un diagrama de blocs de netfilter:

Primer, com a l'exemple anterior, creem una taula d'encaminament addicional:

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

Ara afegim unes quantes regles a 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

Aquestes regles marcaran les connexions entrants a la interfície eth0.100, marcant tots els paquets amb l'etiqueta 0x100, les respostes dins de la mateixa connexió també es marcaran amb la mateixa etiqueta.

Ara podem afegir una regla d'encaminament:

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

És a dir, tots els paquets amb una adreça d'origen 1.2.3.0/24 i etiquetar 0x100 s'ha d'encaminar mitjançant una taula 100.

Per tant, altres paquets rebuts en una altra interfície no estan subjectes a aquesta regla, la qual cosa permetrà encaminar-los mitjançant eines estàndard de Kubernetes.

Hi ha una cosa més, a Linux hi ha l'anomenat filtre de camí invers, que fa malbé tot; fa una comprovació senzilla: per a tots els paquets entrants, canvia l'adreça d'origen del paquet amb l'adreça del remitent i comprova si el paquet pot sortir per la mateixa interfície on es va rebre, si no, el filtrarà.

El problema és que en el nostre cas no funcionarà correctament, però podem desactivar-lo:

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

Tingueu en compte que la primera ordre controla el comportament global de rp_filter; si no està desactivada, la segona ordre no tindrà cap efecte. Tanmateix, les interfícies restants es mantindran amb rp_filter habilitat.

Per no limitar completament el funcionament del filtre, podem utilitzar la implementació rp_filter per a netfilter. Utilitzant rpfilter com a mòdul d'iptables, podeu configurar regles força flexibles, per exemple:

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

habiliteu rp_filter a la interfície eth0.100 per a totes les adreces excepte 1.2.3.0/24.

Font: www.habr.com