Çox keçməmiş MetalLB üçün marşrutlaşdırma qurmaq kimi çox qeyri-adi bir vəzifə ilə üzləşdim. Hər şey yaxşı olardı, çünki... Adətən MetalLB heç bir əlavə hərəkət tələb etmir, lakin bizim vəziyyətimizdə çox sadə şəbəkə konfiqurasiyasına malik kifayət qədər böyük klasterimiz var.

Bu yazıda mən sizə klasterinizin xarici şəbəkəsi üçün mənbəyə əsaslanan və siyasətə əsaslanan marşrutlaşdırmanı necə konfiqurasiya edəcəyinizi söyləyəcəyəm.

MetalLB-nin quraşdırılması və konfiqurasiyası haqqında təfərrüata varmayacağam, çünki güman edirəm ki, sizin artıq müəyyən təcrübəniz var. Mən birbaşa nöqtəyə getməyi, yəni marşrutlaşdırma qurmağı təklif edirəm. Beləliklə, dörd halımız var:

1-ci hal: Heç bir konfiqurasiya tələb olunmadıqda

Gəlin sadə bir işə baxaq.

MetalLB tərəfindən verilən ünvanlar qovşaqlarınızın ünvanları ilə eyni alt şəbəkədə olduqda əlavə marşrutlaşdırma konfiqurasiyası tələb olunmur.

Məsələn, sizin alt şəbəkəniz var 192.168.1.0/24, onun marşrutlaşdırıcısı var 192.168.1.1, və qovşaqlarınız ünvanları alır: 192.168.1.10-30, sonra MetalLB üçün diapazonu tənzimləyə bilərsiniz 192.168.1.100-120 və heç bir əlavə konfiqurasiya olmadan işləyəcəklərinə əmin olun.

Niyə belədir? Çünki qovşaqlarınız artıq konfiqurasiya edilmiş marşrutlara malikdir:

# 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

Eyni diapazondan olan ünvanlar heç bir əlavə hərəkət etmədən onlardan yenidən istifadə edəcək.

2-ci hal: Əlavə fərdiləşdirmə tələb olunduqda

Qovşaqlarınızın konfiqurasiya edilmiş IP ünvanı və ya MetalLB problemlərinin ünvanlandığı alt şəbəkəyə marşrutu olmadıqda, siz əlavə marşrutları konfiqurasiya etməlisiniz.

Bir az daha ətraflı izah edəcəyəm. MetalLB bir ünvan çıxardıqda, onu sadə tapşırıqla müqayisə etmək olar:

ip addr add 10.9.8.7/32 dev lo

Diqqət edin:

• a) Ünvan prefikslə təyin olunur /32 yəni marşrut onun üçün avtomatik olaraq alt şəbəkəyə əlavə edilməyəcək (bu, sadəcə bir ünvandır)
• b) Ünvan istənilən node interfeysinə əlavə olunur (məsələn, geri dönmə). Burada Linux şəbəkə yığınının xüsusiyyətlərini qeyd etmək yerinə düşər. Ünvanı hansı interfeysə əlavə etməyinizdən asılı olmayaraq, nüvə həmişə arp sorğularını emal edəcək və onlardan hər hansı birinə arp cavabları göndərəcək, bu davranış düzgün hesab olunur və üstəlik Kubernetes kimi dinamik mühitdə kifayət qədər geniş istifadə olunur.

Bu davranış, məsələn, ciddi arp-ı aktivləşdirməklə fərdiləşdirilə bilər:

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

Bu halda, arp cavabları yalnız o halda göndəriləcək ki, interfeys açıq şəkildə konkret IP ünvanını ehtiva edir. Əgər siz MetalLB-dən istifadə etməyi planlaşdırırsınızsa və kube-proksi IPVS rejimində işləyirsə, bu parametr tələb olunur.

Bununla belə, MetalLB arp sorğularını emal etmək üçün nüvədən istifadə etmir, lakin bunu istifadəçi məkanında özü edir, ona görə də bu seçim MetalLB-nin işinə təsir etməyəcək.

Gəlin vəzifəmizə qayıdaq. Verilmiş ünvanlar üçün marşrut qovşaqlarınızda yoxdursa, onu əvvəlcədən bütün qovşaqlara əlavə edin:

ip route add 10.9.8.0/24 dev eth1

3-cü hal: Mənbəyə əsaslanan marşrutlaşdırmaya ehtiyacınız olduqda

Paketləri defolt olaraq konfiqurasiya edilmiş deyil, ayrıca şlüz vasitəsilə qəbul edərkən mənbəyə əsaslanan marşrutlaşdırmanı konfiqurasiya etməlisiniz, buna görə də cavab paketləri eyni şlüzdən keçməlidir.

Məsələn, eyni alt şəbəkəniz var 192.168.1.0/24 qovşaqlarınıza həsr olunmuş, lakin siz MetalLB istifadə edərək xarici ünvanlar vermək istəyirsiniz. Tutaq ki, alt şəbəkədən bir neçə ünvanınız var 1.2.3.0/24 VLAN 100-də yerləşir və siz onlardan Kubernetes xidmətlərinə xaricdən daxil olmaq üçün istifadə etmək istəyirsiniz.

Əlaqə qurarkən 1.2.3.4 fərqli alt şəbəkədən sorğular edəcəksiniz 1.2.3.0/24 və cavab gözləyin. Hal-hazırda MetalLB tərəfindən verilmiş ünvan üçün master olan qovşaq 1.2.3.4, paketi marşrutlaşdırıcıdan alacaq 1.2.3.1, lakin onun üçün cavab mütləq eyni marşrutdan keçməlidir 1.2.3.1.

Çünki bizim node artıq konfiqurasiya edilmiş standart şlüzə malikdir 192.168.1.1, onda standart olaraq cavab ona deyil, ona gedəcək 1.2.3.1, bunun vasitəsilə paketi aldıq.

Bu vəziyyətin öhdəsindən necə gəlmək olar?

Bu halda, bütün qovşaqlarınızı elə hazırlamalısınız ki, onlar əlavə konfiqurasiya olmadan xarici ünvanlara xidmət göstərməyə hazır olsunlar. Yəni yuxarıdakı nümunə üçün əvvəlcədən node üzərində VLAN interfeysi yaratmalısınız:

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

Və sonra marşrutlar əlavə edin:

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

Nəzərə alın ki, biz marşrutları ayrıca marşrut cədvəlinə əlavə edirik 100 o, şlüz vasitəsilə cavab paketini göndərmək üçün lazım olan yalnız iki marşrutdan ibarət olacaq 1.2.3.1, interfeysin arxasında yerləşir eth0.100.

İndi sadə bir qayda əlavə etməliyik:

ip rule add from 1.2.3.0/24 lookup 100

açıq şəkildə deyir: paketin mənbə ünvanı varsa 1.2.3.0/24, onda siz marşrutlaşdırma cədvəlindən istifadə etməlisiniz 100. Biz artıq onu göndərəcək marşrutu təsvir etdik 1.2.3.1

Case 4: Siyasət əsaslı marşrutlaşdırmaya ehtiyacınız olduqda

Şəbəkə topologiyası əvvəlki nümunədəki kimidir, lakin tutaq ki, siz həm də xarici hovuz ünvanlarına daxil olmaq istəyirsiniz 1.2.3.0/24 çubuqlarınızdan:

Xüsusiyyət ondan ibarətdir ki, istənilən ünvana daxil olduqda 1.2.3.0/24, cavab paketi qovşağı vurur və diapazonda mənbə ünvanı var 1.2.3.0/24 itaətlə göndəriləcək eth0.100, lakin biz Kubernetesdən onu orijinal sorğunu yaradan ilk podumuza yönləndirməsini istəyirik.

Bu problemi həll etmək çətin oldu, lakin siyasətə əsaslanan marşrutlaşdırma sayəsində mümkün oldu:

Prosesi daha yaxşı başa düşmək üçün burada netfilter blok diaqramı var:

Əvvəlcə əvvəlki nümunədə olduğu kimi əlavə marşrut cədvəli yaradaq:

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

İndi iptables-ə bir neçə qayda əlavə edək:

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

Bu qaydalar interfeysə daxil olan əlaqələri qeyd edəcək eth0.100, bütün paketləri etiketlə qeyd edin 0x100, eyni əlaqə daxilində cavablar da eyni etiketlə qeyd olunacaq.

İndi marşrutlaşdırma qaydasını əlavə edə bilərik:

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

Yəni mənbə ünvanı olan bütün paketlər 1.2.3.0/24 və etiketləyin 0x100 cədvəldən istifadə etməklə istiqamətləndirilməlidir 100.

Beləliklə, başqa interfeysdə qəbul edilən digər paketlər bu qaydaya tabe deyil, bu da onları standart Kubernetes alətlərindən istifadə etməklə yönləndirməyə imkan verəcək.

Daha bir şey var, Linux-da hər şeyi korlayan sözdə əks yol filtri var; o, sadə bir yoxlama aparır: bütün daxil olan paketlər üçün paketin mənbə ünvanını göndərən ünvanı ilə dəyişir və yoxlayır. paket qəbul edildiyi eyni interfeysdən gedə bilər, əgər olmasa, onu süzəcək.

Problem ondadır ki, bizim vəziyyətimizdə o, düzgün işləməyəcək, lakin biz onu söndürə bilərik:

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

Nəzərə alın ki, birinci əmr rp_filter-in qlobal davranışına nəzarət edir; əgər o, söndürülməyibsə, ikinci əmrin heç bir təsiri olmayacaq. Bununla belə, qalan interfeyslər rp_filter aktiv olaraq qalacaq.

Süzgəcin işini tamamilə məhdudlaşdırmamaq üçün netfilter üçün rp_filter tətbiqindən istifadə edə bilərik. Rpfilterdən iptables modulu kimi istifadə edərək, olduqca çevik qaydaları konfiqurasiya edə bilərsiniz, məsələn:

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

interfeysdə rp_filter aktivləşdirin eth0.100 istisna olmaqla, bütün ünvanlar üçün 1.2.3.0/24.

Mənbə: www.habr.com