Неотдавна бях изправен пред много необичайна задача да настроя маршрутизиране за 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 да го пренасочи към първия ни pod, който генерира оригиналната заявка.

Решаването на този проблем се оказа трудно, но стана възможно благодарение на базираното на политики маршрутизиране:

За по-добро разбиране на процеса, ето блокова диаграма на 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.

За да не ограничим напълно работата на филтъра, можем да използваме имплементацията 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