काही काळापूर्वी मला 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) पत्ता कोणत्याही नोड इंटरफेसशी संलग्न आहे (उदाहरणार्थ लूपबॅक). लिनक्स नेटवर्क स्टॅकच्या वैशिष्ट्यांचा येथे उल्लेख करणे योग्य आहे. तुम्‍ही कोणत्‍या इंटरफेसमध्‍ये पत्ता जोडला हे महत्त्वाचे नाही, कर्नल नेहमी एआरपी विनंत्‍यांवर प्रक्रिया करेल आणि त्‍यापैकी कोणालाही एआरपी प्रतिसाद पाठवेल, हे वर्तन बरोबर मानले जाते आणि शिवाय, कुबरनेट सारख्या गतिमान वातावरणात मोठ्या प्रमाणावर वापरले जाते.

हे वर्तन सानुकूलित केले जाऊ शकते, उदाहरणार्थ कठोर एआरपी सक्षम करून:

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

या प्रकरणात, जर इंटरफेसमध्ये विशिष्ट IP पत्ता असेल तरच arp प्रतिसाद पाठवले जातील. जर तुम्ही MetalLB वापरण्याची योजना आखत असाल आणि तुमची क्युब-प्रॉक्सी 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 मध्‍ये स्थित आहे आणि तुम्‍हाला ते कुबरनेट सेवा बाहेरून प्रवेश करण्‍यासाठी वापरायचे आहेत.

संपर्क करताना 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 ने ते आमच्या पहिल्या पॉडवर पुनर्निर्देशित करायचे आहे, ज्याने मूळ विनंती व्युत्पन्न केली.

या समस्येचे निराकरण करणे कठीण झाले, परंतु धोरण-आधारित राउटिंगमुळे ते शक्य झाले:

प्रक्रियेच्या चांगल्या प्रकारे समजून घेण्यासाठी, येथे एक नेटफिल्टर ब्लॉक आकृती आहे:

प्रथम, मागील उदाहरणाप्रमाणे, अतिरिक्त राउटिंग टेबल तयार करूया:

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

L2 मोडमध्ये MetalLB साठी फाइन-ट्यूनिंग रूटिंग

केस 1: जेव्हा कोणतेही कॉन्फिगरेशन आवश्यक नसते

केस 2: जेव्हा अतिरिक्त सानुकूलन आवश्यक असते

केस 3: जेव्हा तुम्हाला स्त्रोत-आधारित राउटिंगची आवश्यकता असते

केस 4: जेव्हा तुम्हाला पॉलिसी-आधारित राउटिंगची आवश्यकता असते

एक टिप्पणी जोडा Отменить ответ