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) முகவரி எந்த முனை இடைமுகத்திலும் இணைக்கப்பட்டுள்ளது (உதாரணமாக லூப்பேக்). லினக்ஸ் நெட்வொர்க் ஸ்டேக்கின் அம்சங்களை இங்கு குறிப்பிடுவது மதிப்பு. நீங்கள் எந்த இடைமுகத்தில் முகவரியைச் சேர்த்தாலும், கர்னல் எப்பொழுதும் arp கோரிக்கைகளைச் செயல்படுத்தும் மற்றும் அவற்றில் ஏதேனும் arp பதில்களை அனுப்பும், இந்த நடத்தை சரியானதாகக் கருதப்படுகிறது, மேலும், குபெர்னெட்டஸ் போன்ற ஒரு மாறும் சூழலில் மிகவும் பரவலாகப் பயன்படுத்தப்படுகிறது.

இந்த நடத்தை தனிப்பயனாக்கப்படலாம், எடுத்துக்காட்டாக, கடுமையான 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-proxy IPVS பயன்முறையில் இயங்கினால் இந்த அமைப்பு அவசியம்.

இருப்பினும், arp கோரிக்கைகளை செயலாக்க MetalLB கர்னலைப் பயன்படுத்தாது, ஆனால் பயனர் இடத்தில் அதையே செய்கிறது, எனவே இந்த விருப்பம் 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, ஆனால் குபெர்னெட்ஸ் அதை அசல் கோரிக்கையை உருவாக்கிய எங்கள் முதல் பாட்க்கு திருப்பிவிட வேண்டும் என்று நாங்கள் விரும்புகிறோம்.

இந்த சிக்கலைத் தீர்ப்பது கடினமானதாக மாறியது, ஆனால் கொள்கை அடிப்படையிலான ரூட்டிங் மூலம் இது சாத்தியமானது:

செயல்முறையை நன்கு புரிந்துகொள்ள, இங்கே ஒரு 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.

எனவே, மற்றொரு இடைமுகத்தில் பெறப்பட்ட பிற பாக்கெட்டுகள் இந்த விதிக்கு உட்பட்டவை அல்ல, இது நிலையான குபெர்னெட்ஸ் கருவிகளைப் பயன்படுத்தி அவற்றை அனுப்ப அனுமதிக்கும்.

இன்னும் ஒரு விஷயம் உள்ளது, லினக்ஸில் தலைகீழ் பாதை வடிகட்டி உள்ளது, இது முழுவதையும் கெடுக்கிறது; இது ஒரு எளிய சோதனை செய்கிறது: உள்வரும் அனைத்து பாக்கெட்டுகளுக்கும், அனுப்புநர் முகவரியுடன் பாக்கெட்டின் மூல முகவரியை மாற்றி சரிபார்க்கிறது பாக்கெட் பெறப்பட்ட அதே இடைமுகத்தின் வழியாக வெளியேறலாம், இல்லையெனில், அது அதை வடிகட்டிவிடும்.

பிரச்சனை என்னவென்றால், எங்கள் விஷயத்தில் அது சரியாக வேலை செய்யாது, ஆனால் நாம் அதை முடக்கலாம்:

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.

ஆதாரம்: www.habr.com