Жақында мен 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

Бұл жағдайда интерфейсте нақты IP мекенжайы бар болса ғана arp жауаптары жіберіледі. Бұл параметр 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, бірақ біз Кубернетестің оны бастапқы сұрауды жасаған бірінші бөлімшеге қайта бағыттағанын қалаймыз.

Бұл мәселені шешу қиын болды, бірақ саясатқа негізделген маршрутизацияның арқасында мүмкін болды:

Процесті жақсырақ түсіну үшін мұнда желі сүзгісінің блок диаграммасы берілген:

Алдымен, алдыңғы мысалдағыдай, қосымша маршруттау кестесін жасайық:

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 қосылған күйде қалады.

Сүзгі жұмысын толығымен шектемеу үшін біз rp_filter іске асыруын netfilter үшін пайдалана аламыз. 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.

Ақпарат көзі: www.habr.com