Hindi pa nagtagal ay nahaharap ako sa isang hindi pangkaraniwang gawain ng pag-set up ng pagruruta para sa MetalLB. Magiging maayos din ang lahat, dahil... Karaniwan ang MetalLB ay hindi nangangailangan ng anumang karagdagang mga aksyon, ngunit sa aming kaso mayroon kaming isang medyo malaking kumpol na may napakasimpleng pagsasaayos ng network.

Sa artikulong ito, sasabihin ko sa iyo kung paano i-configure ang source-based at policy-based na pagruruta para sa external na network ng iyong cluster.

Hindi ako magdedetalye tungkol sa pag-install at pag-configure ng MetalLB, dahil ipinapalagay ko na mayroon ka nang karanasan. Iminumungkahi kong dumiretso sa punto, lalo na ang pag-set up ng pagruruta. Kaya mayroon kaming apat na kaso:

Case 1: Kapag walang configuration na kailangan

Tingnan natin ang isang simpleng kaso.

Ang karagdagang configuration ng pagruruta ay hindi kinakailangan kapag ang mga address na ibinigay ng MetalLB ay nasa parehong subnet gaya ng mga address ng iyong mga node.

Halimbawa, mayroon kang subnet 192.168.1.0/24, mayroon itong router 192.168.1.1, at ang iyong mga node ay tumatanggap ng mga address: 192.168.1.10-30, pagkatapos ay para sa MetalLB maaari mong ayusin ang hanay 192.168.1.100-120 at siguraduhing gagana ang mga ito nang walang anumang karagdagang configuration.

Bakit ganon? Dahil ang iyong mga node ay mayroon nang mga rutang na-configure:

# 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

At ang mga address mula sa parehong hanay ay muling gagamitin ang mga ito nang walang anumang karagdagang pagkilos.

Kaso 2: Kapag kailangan ang karagdagang pagpapasadya

Dapat mong i-configure ang mga karagdagang ruta sa tuwing ang iyong mga node ay walang naka-configure na IP address o ruta sa subnet kung saan nag-isyu ng mga address ang MetalLB.

Ipapaliwanag ko nang mas detalyado. Sa tuwing maglalabas ang MetalLB ng isang address, maihahambing ito sa isang simpleng takdang-aralin tulad ng:

ip addr add 10.9.8.7/32 dev lo

Bigyang-pansin ang:

• a) Ang address ay itinalaga na may prefix /32 ibig sabihin, ang isang ruta ay hindi awtomatikong idaragdag sa subnet para dito (ito ay isang address lamang)
• b) Ang address ay naka-attach sa anumang node interface (halimbawa loopback). Ito ay nagkakahalaga ng pagbanggit dito ang mga tampok ng Linux network stack. Hindi mahalaga kung saang interface mo idagdag ang address, ang kernel ay palaging magpoproseso ng mga kahilingan sa arp at magpapadala ng mga tugon sa arp sa alinman sa mga ito, ang pag-uugali na ito ay itinuturing na tama at, higit pa rito, ay lubos na ginagamit sa gayong dinamikong kapaligiran gaya ng Kubernetes.

Maaaring i-customize ang gawi na ito, halimbawa sa pamamagitan ng pagpapagana ng mahigpit na arp:

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

Sa kasong ito, ipapadala lamang ang mga tugon ng arp kung ang interface ay tahasang naglalaman ng isang partikular na IP address. Ang setting na ito ay kinakailangan kung plano mong gamitin ang MetalLB at ang iyong kube-proxy ay tumatakbo sa IPVS mode.

Gayunpaman, hindi ginagamit ng MetalLB ang kernel upang iproseso ang mga kahilingan sa arp, ngunit ginagawa ito mismo sa espasyo ng gumagamit, kaya hindi makakaapekto ang opsyong ito sa pagpapatakbo ng MetalLB.

Balik tayo sa ating gawain. Kung ang ruta para sa mga ibinigay na address ay wala sa iyong mga node, idagdag ito nang maaga sa lahat ng mga node:

ip route add 10.9.8.0/24 dev eth1

Case 3: Kapag kailangan mo ng source-based na pagruruta

Kakailanganin mong i-configure ang source-based na pagruruta kapag nakatanggap ka ng mga packet sa pamamagitan ng isang hiwalay na gateway, hindi ang na-configure bilang default, samakatuwid ang mga response packet ay dapat ding dumaan sa parehong gateway.

Halimbawa, mayroon kang parehong subnet 192.168.1.0/24 nakatuon sa iyong mga node, ngunit gusto mong mag-isyu ng mga panlabas na address gamit ang MetalLB. Ipagpalagay natin na marami kang mga address mula sa isang subnet 1.2.3.0/24 na matatagpuan sa VLAN 100 at gusto mong gamitin ang mga ito para ma-access ang mga serbisyo ng Kubernetes sa labas.

Kapag nakikipag-ugnayan 1.2.3.4 gagawa ka ng mga kahilingan mula sa ibang subnet kaysa sa 1.2.3.0/24 at maghintay ng sagot. Ang node na kasalukuyang master para sa address na ibinigay ng MetalLB 1.2.3.4, ay tatanggap ng packet mula sa router 1.2.3.1, ngunit ang sagot para sa kanya ay kinakailangang pumunta sa parehong ruta, sa pamamagitan ng 1.2.3.1.

Dahil ang aming node ay mayroon nang naka-configure na default na gateway 192.168.1.1, pagkatapos bilang default ang tugon ay mapupunta sa kanya, at hindi sa 1.2.3.1, kung saan natanggap namin ang package.

Paano makayanan ang sitwasyong ito?

Sa kasong ito, kailangan mong ihanda ang lahat ng iyong mga node sa paraang handa silang maghatid ng mga panlabas na address nang walang karagdagang configuration. Iyon ay, para sa halimbawa sa itaas, kailangan mong lumikha ng isang interface ng VLAN sa node nang maaga:

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

At pagkatapos ay magdagdag ng mga ruta:

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

Pakitandaan na nagdaragdag kami ng mga ruta sa isang hiwalay na talahanayan ng pagruruta 100 maglalaman lamang ito ng dalawang rutang kinakailangan upang magpadala ng response packet sa pamamagitan ng gateway 1.2.3.1, na matatagpuan sa likod ng interface eth0.100.

Ngayon kailangan nating magdagdag ng isang simpleng panuntunan:

ip rule add from 1.2.3.0/24 lookup 100

na tahasang nagsasabing: kung ang source address ng packet ay nasa 1.2.3.0/24, pagkatapos ay kailangan mong gamitin ang routing table 100. Sa loob nito ay inilarawan na natin ang rutang dadaan sa kanya 1.2.3.1

Case 4: Kapag kailangan mo ng policy-based na pagruruta

Ang topology ng network ay kapareho ng sa nakaraang halimbawa, ngunit sabihin nating gusto mo ring ma-access ang mga panlabas na address ng pool 1.2.3.0/24 mula sa iyong mga pod:

Ang kakaiba ay kapag nag-access sa anumang address sa 1.2.3.0/24, ang response packet ay tumama sa node at mayroong source address sa range 1.2.3.0/24 ay masunuring ipapadala sa eth0.100, ngunit gusto naming i-redirect ito ng Kubernetes sa aming unang pod, na nabuo ang orihinal na kahilingan.

Ang paglutas sa problemang ito ay naging mahirap, ngunit naging posible ito salamat sa pagruruta na nakabatay sa patakaran:

Para sa isang mas mahusay na pag-unawa sa proseso, narito ang isang netfilter block diagram:

Una, tulad ng sa nakaraang halimbawa, gumawa tayo ng karagdagang routing table:

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

Ngayon magdagdag tayo ng ilang panuntunan sa 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

Ang mga panuntunang ito ay magmamarka ng mga papasok na koneksyon sa interface eth0.100, pagmamarka ng lahat ng packet na may tag 0x100, ang mga tugon sa loob ng parehong koneksyon ay mamarkahan din ng parehong tag.

Ngayon ay maaari tayong magdagdag ng panuntunan sa pagruruta:

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

Ibig sabihin, lahat ng packet na may source address 1.2.3.0/24 at tag 0x100 dapat i-ruta gamit ang talahanayan 100.

Kaya, ang ibang mga packet na natanggap sa isa pang interface ay hindi napapailalim sa panuntunang ito, na magbibigay-daan sa kanila na i-ruta gamit ang mga karaniwang tool ng Kubernetes.

May isa pang bagay, sa Linux mayroong tinatawag na reverse path filter, na sumisira sa buong bagay; ito ay nagsasagawa ng isang simpleng pagsusuri: para sa lahat ng mga papasok na packet, binabago nito ang source address ng packet kasama ang address ng nagpadala at sinusuri kung ang packet ay maaaring umalis sa pamamagitan ng parehong interface kung saan ito natanggap, kung hindi, ito ay i-filter ito.

Ang problema ay sa aming kaso hindi ito gagana nang tama, ngunit maaari naming i-disable ito:

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

Pakitandaan na ang unang command ay kumokontrol sa pandaigdigang pag-uugali ng rp_filter; kung hindi ito naka-disable, ang pangalawang command ay walang epekto. Gayunpaman, ang natitirang mga interface ay mananatiling naka-enable ang rp_filter.

Upang hindi ganap na limitahan ang pagpapatakbo ng filter, maaari naming gamitin ang pagpapatupad ng rp_filter para sa netfilter. Gamit ang rpfilter bilang isang module ng iptables, maaari mong i-configure ang medyo nababaluktot na mga panuntunan, halimbawa:

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

paganahin ang rp_filter sa interface eth0.100 para sa lahat ng mga address maliban sa 1.2.3.0/24.

Pinagmulan: www.habr.com