Ora suwe aku ngadhepi tugas sing ora biasa kanggo nyetel rute kanggo MetalLB. Kabeh bakal apik, amarga ... Biasane MetalLB ora mbutuhake tindakan tambahan, nanging ing kasus kita duwe kluster sing cukup gedhe kanthi konfigurasi jaringan sing prasaja.

Ing artikel iki aku bakal pitutur marang kowe carane ngatur basis sumber lan basis kawicaksanan nuntun kanggo jaringan external kluster Panjenengan.

Aku ora bakal rinci babagan nginstal lan ngatur MetalLB, amarga aku nganggep sampeyan wis duwe pengalaman. Aku saranake langsung menyang titik, yaiku nyetel rute. Dadi, kita duwe papat kasus:

Kasus 1: Nalika ora ana konfigurasi sing dibutuhake

Ayo katon ing kasus prasaja.

Konfigurasi nuntun tambahan ora dibutuhake nalika alamat sing diterbitake dening MetalLB ana ing subnet sing padha karo alamat simpul sampeyan.

Contone, sampeyan duwe subnet 192.168.1.0/24, wis router 192.168.1.1, lan simpul sampeyan nampa alamat: 192.168.1.10-30, banjur kanggo MetalLB sampeyan bisa nyetel sawetara 192.168.1.100-120 lan manawa bakal bisa digunakake tanpa konfigurasi tambahan.

Kok ngono? Amarga simpul sampeyan wis duwe rute sing dikonfigurasi:

# 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

Lan alamat saka sawetara sing padha bakal digunakake maneh tanpa tumindak tambahan.

Kasus 2: Nalika kustomisasi tambahan dibutuhake

Sampeyan kudu ngatur rute tambahan nalika simpul ora duwe alamat IP diatur utawa rute menyang subnet sing MetalLB masalah alamat.

Aku bakal nerangake kanthi luwih rinci. Yen MetalLB ngasilake alamat, bisa dibandhingake karo tugas sing gampang kaya:

ip addr add 10.9.8.7/32 dev lo

Pay manungsa waé menyang:

• a) Alamat kasebut diwenehi awalan /32 yaiku, rute ora bakal ditambahake kanthi otomatis menyang subnet kasebut (iku mung alamat)
• b) Alamat kasebut dipasang ing antarmuka simpul (contone loopback). Perlu disebutake ing kene fitur tumpukan jaringan Linux. Ora ketompo kang antarmuka sampeyan nambah alamat kanggo, kernel bakal tansah proses panjalukan arp lan ngirim respon arp kanggo salah siji saka wong-wong mau, prilaku iki dianggep bener lan, malih, cukup digunakake ing lingkungan dinamis kayata Kubernetes.

Prilaku iki bisa disesuaikan, contone kanthi ngaktifake arp sing ketat:

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

Ing kasus iki, respon arp mung bakal dikirim yen antarmuka eksplisit ngemot alamat IP tartamtu. Setelan iki dibutuhake yen sampeyan arep nggunakake MetalLB lan kube-proxy sampeyan mlaku ing mode IPVS.

Nanging, MetalLB ora nggunakake kernel kanggo proses panjalukan arp, nanging iku dhewe ing pangguna-ruang, supaya pilihan iki ora mengaruhi operasi MetalLB.

Ayo bali menyang tugas kita. Yen rute kanggo alamat sing ditanggepi ora ana ing simpul sampeyan, tambahake sadurunge menyang kabeh simpul:

ip route add 10.9.8.0/24 dev eth1

Kasus 3: Nalika sampeyan mbutuhake nuntun basis sumber

Sampeyan kudu ngatur rute basis sumber nalika sampeyan nampa paket liwat gateway kapisah, ora siji diatur minangka standar, mulane paket respon uga kudu liwat gateway padha.

Contone, sampeyan duwe subnet sing padha 192.168.1.0/24 darmabakti kanggo kelenjar Panjenengan, nanging sampeyan pengin ngetokake alamat external nggunakake MetalLB. Ayo nganggep sampeyan duwe sawetara alamat saka subnet 1.2.3.0/24 dumunung ing VLAN 100 lan sampeyan pengin digunakake kanggo ngakses layanan Kubernetes externally.

Nalika ngubungi 1.2.3.4 sampeyan bakal nggawe panjalukan saka subnet liyane saka 1.2.3.0/24 lan ngenteni jawaban. Node sing saiki dadi master kanggo alamat sing diterbitake MetalLB 1.2.3.4, bakal nampa paket saka router 1.2.3.1, nanging jawaban kanggo wong kudu kudu pindhah rute padha, liwat 1.2.3.1.

Amarga simpul kita wis duwe gateway standar sing dikonfigurasi 192.168.1.1, banjur kanthi standar respon bakal pindhah menyang dheweke, lan ora kanggo 1.2.3.1, liwat kang kita nampa paket.

Kepiye carane ngatasi kahanan iki?

Ing kasus iki, sampeyan kudu nyiapake kabeh simpul sampeyan kanthi cara supaya bisa ngladeni alamat eksternal tanpa konfigurasi tambahan. Yaiku, kanggo conto ing ndhuwur, sampeyan kudu nggawe antarmuka VLAN ing simpul sadurunge:

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

Banjur nambah rute:

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

Wigati dimangerteni manawa kita nambah rute menyang tabel rute sing kapisah 100 bakal ngemot mung rong rute sing perlu kanggo ngirim paket respon liwat gateway 1.2.3.1, dumunung ing mburi antarmuka eth0.100.

Saiki kita kudu nambah aturan prasaja:

ip rule add from 1.2.3.0/24 lookup 100

sing tegas ngandika: yen alamat sumber paket ing 1.2.3.0/24, banjur sampeyan kudu nggunakake tabel nuntun 100. Ing kono kita wis nerangake rute sing bakal dikirim 1.2.3.1

Kasus 4: Nalika sampeyan mbutuhake nuntun basis kabijakan

Topologi jaringan padha karo conto sadurunge, nanging ayo ngomong sampeyan uga pengin bisa ngakses alamat blumbang eksternal 1.2.3.0/24 saka polong sampeyan:

Keanehan yaiku nalika ngakses alamat apa wae ing 1.2.3.0/24, paket respon tekan simpul lan duwe alamat sumber ing sawetara 1.2.3.0/24 bakal obediently dikirim menyang eth0.100, nanging kita pengin Kubernetes pangalihan menyang pod pisanan kita, kang kui panjalukan asli.

Ngatasi masalah iki dadi angel, nanging bisa ditindakake amarga rute adhedhasar kebijakan:

Kanggo mangerteni proses sing luwih apik, iki diagram pemblokiran netfilter:

Pisanan, kaya ing conto sadurunge, ayo nggawe tabel routing tambahan:

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

Saiki ayo nambah sawetara aturan menyang 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

Aturan kasebut bakal menehi tandha sambungan mlebu menyang antarmuka eth0.100, menehi tandha kabeh paket nganggo tag 0x100, respon ing sambungan sing padha uga bakal ditandhani karo tag sing padha.

Saiki kita bisa nambah aturan routing:

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

Yaiku, kabeh paket kanthi alamat sumber 1.2.3.0/24 lan tag 0x100 kudu diarahake nggunakake tabel 100.

Mangkono, paket liyane sing ditampa ing antarmuka liyane ora tundhuk karo aturan iki, sing bakal ngidini rute kasebut nggunakake alat Kubernetes standar.

Ana siji liyane, ing Linux ana sing disebut filter path mbalikke, kang ngrusak kabeh, iku nindakake mriksa prasaja: kanggo kabeh paket mlebu, ngganti alamat sumber paket karo alamat pangirim lan mriksa apa paket bisa ninggalake liwat antarmuka sing padha ditampa, yen ora, iku bakal nyaring.

Masalahe yaiku yen ing kasus kita ora bakal bisa digunakake kanthi bener, nanging kita bisa mateni:

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

Wigati dimangerteni manawa printah pisanan ngontrol prilaku global rp_filter; yen ora dipateni, printah kapindho ora bakal ana pengaruhe. Nanging, antarmuka sing isih ana bakal tetep nganggo rp_filter aktif.

Supaya ora rampung matesi operasi saka Filter, kita bisa nggunakake implementasine rp_filter kanggo netfilter. Nggunakake rpfilter minangka modul iptables, sampeyan bisa ngatur aturan sing cukup fleksibel, contone:

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

ngaktifake rp_filter ing antarmuka eth0.100 kanggo kabeh alamat kajaba 1.2.3.0/24.

Source: www.habr.com