არც ისე დიდი ხნის წინ მე დამეწყო ძალიან უჩვეულო დავალება 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) მისამართი მიმაგრებულია ნებისმიერი კვანძის ინტერფეისზე (მაგალითად, loopback). აქ უნდა აღინიშნოს 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-proxy მუშაობს 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 ჩართულით.

იმისათვის, რომ მთლიანად არ შევზღუდოთ ფილტრის მოქმედება, შეგვიძლია გამოვიყენოთ 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