Жакында мен MetalLB үчүн маршрутту орнотуу боюнча өтө адаттан тыш тапшырмага туш болдум. Баары жакшы болмок, анткени... Адатта, MetalLB эч кандай кошумча аракеттерди талап кылбайт, бирок биздин учурда бизде абдан жөнөкөй тармак конфигурациясы бар кыйла чоң кластер бар.

Бул макалада мен сизге кластериңиздин тышкы тармагы үчүн булакка жана саясатка негизделген маршрутту кантип конфигурациялоону айтып берем.

Мен MetalLBди орнотуу жана конфигурациялоо жөнүндө майда-чүйдөсүнө чейин айтпай эле коёюн, анткени сизде кандайдыр бир тажрыйба бар деп ойлойм. Мен түз пунктка барууну сунуштайм, тактап айтканда, маршрутту орнотуу. Ошентип, бизде төрт учур бар:

1-жагдай: Конфигурация талап кылынбаганда

Келгиле, жөнөкөй бир ишти карап көрөлү.

MetalLB тарабынан берилген даректер түйүндөрүңүздүн даректери менен бир ички тармакта болгондо кошумча маршруттук конфигурация талап кылынбайт.

Мисалы, сизде субсет бар 192.168.1.0/24, анын роутери бар 192.168.1.1, жана түйүндөрүңүз даректерди алышат: 192.168.1.10-30, анда MetalLB үчүн диапазону тууралай аласыз 192.168.1.100-120 жана алар эч кандай кошумча конфигурациясыз иштей тургандыгына ишениңиз.

Эмнеге андай? Анткени түйүндөрүңүздө конфигурацияланган маршруттар бар:

# 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

Жана ошол эле диапазондогу даректер аларды эч кандай кошумча аракеттерсиз кайра колдонот.

2-жагдай: Кошумча ыңгайлаштыруу талап кылынганда

Түйүндөрүңүздүн конфигурацияланган IP дареги же MetalLB көйгөйлөрү даректелген субтармакка маршруту жок болгондо, сиз кошумча маршруттарды конфигурациялашыңыз керек.

Мен бир аз майда-чүйдөсүнө чейин түшүндүрүп берем. MetalLB даректи чыгарган сайын, аны төмөнкүдөй жөнөкөй тапшырма менен салыштырууга болот:

ip addr add 10.9.8.7/32 dev lo

Көңүл буруңуз:

• a) Дарек префикс менен дайындалган /32 башкача айтканда, маршрут ал үчүн ички тармакка автоматтык түрдө кошулбайт (бул жөн гана дарек)
• b) Дарек каалаган түйүн интерфейсине тиркелет (мисалы, кайра артка). Бул жерде Linux тармагынын стекинин өзгөчөлүктөрүн белгилей кетүү керек. Кайсы интерфейске даректи кошпоңуз, ядро ​​ар дайым arp суроо-талаптарын иштеп чыгат жана алардын бирине arp жоопторун жөнөтөт, бул жүрүм-турум туура деп эсептелет жана анын үстүнө Kubernetes сыяктуу динамикалык чөйрөдө кеңири колдонулат.

Бул жүрүм-турумду ыңгайлаштырса болот, мисалы, катуу arp иштетүү менен:

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

Бул учурда, arp жооптору интерфейсте ачык-айкын IP даректи камтыса гана жөнөтүлөт. Эгер сиз MetalLB колдонууну пландаштырсаңыз жана kube-прокси IPVS режиминде иштеп жатса, бул жөндөө талап кылынат.

Бирок, MetalLB өзөктү arp сурамдарын иштетүү үчүн колдонбойт, бирок аны колдонуучу мейкиндигинде өзү жасайт, андыктан бул параметр MetalLB иштешине таасирин тийгизбейт.

Келгиле, өзүбүздүн милдетибизге кайрылып көрөлү. Эгерде берилген даректер үчүн маршрут сиздин түйүндөрүңүздө жок болсо, аны бардык түйүндөргө алдын ала кошуңуз:

ip route add 10.9.8.0/24 dev eth1

3-жагдай: Булакка негизделген маршруттоо керек болгондо

Пакеттерди демейки боюнча конфигурацияланган эмес, өзүнчө шлюз аркылуу алганыңызда булакка негизделген маршрутту конфигурациялашыңыз керек болот, андыктан жооп пакеттери да бир шлюз аркылуу өтүшү керек.

Мисалы, сизде бир эле ички тармак бар 192.168.1.0/24 түйүндөрүңүзгө арналган, бирок сиз MetalLB аркылуу тышкы даректерди чыгаргыңыз келет. Сизде бир подтармактан бир нече даректер бар деп коёлу 1.2.3.0/24 VLAN 100дө жайгашкан жана сиз аларды Kubernetes кызматтарына сырттан кирүү үчүн колдонгуңуз келет.

Байланышканда 1.2.3.4 караганда башка ички тармактан суроо-талаптарды жасайсыз 1.2.3.0/24 жана жооп күт. Учурда MetalLB берген даректин кожоюну болгон түйүн 1.2.3.4, роутерден пакетти алат 1.2.3.1, бирок ага жооп сөзсүз түрдө ошол эле жол менен өтүшү керек 1.2.3.1.

Анткени биздин түйүндө конфигурацияланган демейки шлюз бар 192.168.1.1, анда демейки боюнча жооп ага эмес, ага барат 1.2.3.1, ал аркылуу биз пакетти алдык.

Бул кырдаал менен кантип күрөшүүгө болот?

Бул учурда, сиз бардык түйүндөрүңүздү кошумча конфигурациясыз тышкы даректерди тейлөөгө даяр тургандай кылып даярдашыңыз керек. Башкача айтканда, жогорудагы мисал үчүн алдын ала түйүндө VLAN интерфейсин түзүшүңүз керек:

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

Анан маршруттарды кошуңуз:

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

Маршруттарды өзүнчө маршруттук таблицага кошо турганыбызды эске алыңыз 100 ал шлюз аркылуу жооп пакетин жөнөтүү үчүн зарыл болгон эки гана маршрутту камтыйт 1.2.3.1, интерфейстин артында жайгашкан eth0.100.

Эми биз жөнөкөй эрежени кошуу керек:

ip rule add from 1.2.3.0/24 lookup 100

анда ачык айтылган: пакеттин булак дареги болсо 1.2.3.0/24, анда сиз маршруттук таблицаны колдонушуңуз керек 100. Анда биз аны жөнөтө турган маршрутту сүрөттөгөнбүз 1.2.3.1

4-жагдай: Сиз саясатка негизделген багыттоо керек болгондо

Тармак топологиясы мурунку мисалдагыдай эле, бирок сиз дагы тышкы бассейн даректерине кире алгыңыз келет дейли. 1.2.3.0/24 сенин уяңдан:

Өзгөчөлүгү каалаган дарекке кирүүдө 1.2.3.0/24, жооп пакети түйүнгө тийет жана диапазондо булак дареги бар 1.2.3.0/24 баш ийүү менен жөнөтүлөт eth0.100, бирок биз Kubernetes аны баштапкы суроо-талапты жараткан биздин биринчи подъездибизге багыттоосун каалайбыз.

Бул көйгөйдү чечүү кыйын болуп чыкты, бирок саясатка негизделген маршрутизациянын аркасында мүмкүн болду:

Процессти жакшыраак түшүнүү үчүн бул жерде netfilter блок диаграммасы келтирилген:

Биринчиден, мурунку мисалдагыдай эле, кошумча маршруттук таблицаны түзөлү:

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

Эми 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

Бул эрежелер интерфейске кирүүчү байланыштарды белгилейт eth0.100, бардык пакеттерди теги менен белгилөө 0x100, ошол эле байланыштагы жооптор да ошол эле тег менен белгиленет.

Эми биз маршруттук эрежени кошо алабыз:

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

Башкача айтканда, булак дареги бар бардык пакеттер 1.2.3.0/24 жана тег 0x100 столдун жардамы менен багыттоо керек 100.

Ошентип, башка интерфейсте алынган башка пакеттер бул эрежеге баш ийбейт, бул аларды стандарттуу Kubernetes куралдары менен багыттоого мүмкүндүк берет.

Дагы бир нерсе бар, Linux'та тескери жол чыпкасы деп аталган нерсе бар, ал бүт нерсени бузат; ал жөнөкөй текшерүүнү аткарат: бардык келген пакеттер үчүн пакеттин булак дарегин жөнөтүүчүнүн дареги менен өзгөртүп, текшерет. пакет ал кабыл алынган интерфейс аркылуу кете алат, эгерде андай болбосо, аны чыпкалайт.

Маселе, биздин учурда ал туура иштебейт, бирок биз аны өчүрө алабыз:

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

Сураныч, биринчи буйрук rp_filterдин глобалдуу жүрүм-турумун башкарарын эске алыңыз; эгерде ал өчүрүлбөсө, экинчи буйруктун эч кандай таасири болбойт. Бирок, калган интерфейстер rp_filter иштетилген менен кала берет.

Чыпканын иштешин толугу менен чектебөө үчүн, биз netfilter үчүн rp_filter ишке ашырууну колдоно алабыз. Rpfilterди iptables модулу катары колдонуп, сиз абдан ийкемдүү эрежелерди конфигурациялай аласыз, мисалы:

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

интерфейсте rp_filterди иштетүү eth0.100 башка бардык даректер үчүн 1.2.3.0/24.

Source: www.habr.com