GKE पॉड VPN के ज़रिए स्थानीय होस्ट तक क्यों नहीं पहुँचते

नोड से पिंग चलती है और पॉड से विफल होती है, और स्थानीय तरफ़ कुछ नहीं पहुँचता। टनल और रूट ठीक हैं; तार पर मौजूद स्रोत पता ठीक नहीं है। इन दोनों स्थितियों का फ़र्क़ यह है कि क्लस्टर छोड़ते समय पैकेट खुद को क्या कहता है, और GKE का इस पर अपना मत है। तंत्र masquerade अपवादों की सूची है, और उसे पढ़ने में एक ही आदेश लगता है।

कुछ भी बदलने से पहले लागू सूची पढ़ें

GKE एक एजेंट देता है जो हर गंतव्य श्रेणी के लिए तय करता है कि पॉड का ट्रैफ़िक बाहर जाते समय नोड के पते पर फिर से लिखा जाए या नहीं। उसका दिया गया कॉन्फ़िगरेशन तीन RFC1918 ब्लॉक, 10.0.0.0/8, 172.16.0.0/12 और 192.168.0.0/16, को छूट प्राप्त गंतव्य बताता है। इसलिए पॉड से स्थानीय 10.x होस्ट तक भेजा गया हर सामान नोड से पॉड के अपने पते के साथ ही निकलता है। नोड का अपना ट्रैफ़िक फिर से नहीं लिखा जाता, और इसी कारण उसकी पिंग चलती है।

मंशा के अनुसार कॉन्फ़िगरेशन और स्थापित नियम पढ़ें, क्योंकि दोनों मेल नहीं खा सकते। kubectl -n kube-system get configmap ip-masq-agent -o yaml दिखाता है कि एजेंट से क्या कहा गया, और kubectl -n kube-system get pods -l k8s-app=ip-masq-agent दिखाता है कि उसे लागू करने के लिए कुछ चल रहा है या नहीं। नोड पर iptables-save | grep -i masq वे नियम दिखाता है जो कर्नेल में वास्तव में मौजूद हैं। जब ConfigMap एक बात कहता है और नियम दूसरी, तो संदिग्ध नेटवर्क नहीं, एजेंट होता है।

कैप्चर से स्रोत पते की पुष्टि करें

सूची बदलने से पहले कैप्चर करें। एक ही गंतव्य पर फ़िल्टर आउटपुट को पढ़ने योग्य रखता है: tcpdump -ni any host 10.20.30.40।

इसकी तुलना दूसरी तरफ़ की रिपोर्ट से करें। स्थानीय तरफ़ का कैप्चर जिसमें पॉड का पता दिखे और कोई जवाब न हो, चक्र बंद कर देता है: अपवाद सूची बिना किसी टनल खराबी के असमानता समझाती है। एक ही स्रोत पते के दो अवलोकन CNI के बारे में अनुमान लगाना बंद करने के लिए काफ़ी हैं।

अपवाद को पॉड CIDR तक सीमित करें

समर्थित सुधार अपवाद को हटाने के बजाय सीमित करता है: पॉड CIDR को छूट में रखें और 10.x जगह का बाक़ी हिस्सा छोड़ दें। वह सूची एजेंट के ConfigMap में nonMasqueradeCIDRs के अंतर्गत रहती है, और उसे बदलना एक संपादन और उसके बाद रोलआउट है। चौड़ी प्रविष्टि को क्लस्टर की असली पॉड श्रेणी से बदलें, क्लस्टर के भीतर के ट्रैफ़िक को अब भी ज़रूरत हो तो अन्य निजी ब्लॉक रखें, और कारण न हो तो resyncInterval को जैसा है वैसा छोड़ दें। लागू करें, पुष्टि करें कि एजेंट के पॉड फिर से शुरू हुए और पुष्टि करें कि कर्नेल के नियम बदले।

यह असली प्रभाव-दायरे वाला पूरे क्लस्टर का बदलाव है। लागू होने के बाद, जो ट्रैफ़िक पहले अपना पॉड स्रोत बनाए रखता था वह अब नोड पर फिर से लिखा हुआ आता है, इसलिए उन पॉड पतों पर निर्भर हर चीज़ अलग प्रेषक देखती है। शिकार वे लॉग, अनुमति सूचियाँ और स्थानीय फ़ायरवॉल नियम हैं जो पॉड पते बताते हैं, और वे चुपचाप विफल होते हैं। बदलाव को सुधार के बजाय व्यवहार परिवर्तन के रूप में घोषित करें।

कई नोड पूल वाले क्लस्टर में जाँचें कि एजेंट उन नोड पर निर्धारित है जहाँ प्रभावित पॉड वास्तव में चलते हैं। DaemonSet के बिना पूल अपने पुराने नियम रखता है, और ConfigMap में इसे दिखाने वाला कुछ नहीं होगा।

विकल्प और उसकी क़ीमत

दूसरा विकल्प पॉड पतों को अक्षुण्ण रखता है और रास्ते को उनके बारे में सिखाता है। पॉड CIDR Cloud VPN के ट्रैफ़िक चयनकर्ताओं में जाता है, और स्थानीय पक्ष को जवाबों के लिए वापसी मार्ग चाहिए ताकि उन्हें पता हो कि कहाँ जाना है। यह कुछ सुरक्षा मॉडलों की माँगी गई पॉड पहचान बचाता है, और दूसरे पक्ष को स्वीकार करना होने वाले राउटिंग तथा फ़ायरवॉल दोनों के दायरे बढ़ाता है।

सौदा पठनीयता बनाम दायरा है। अनुवाद स्थानीय पक्ष को प्रति नोड एक पता दिखाता है, जिसे अनुमति सूची में डालना आसान है और यह छिपाता है कि कौन सा पॉड क्या भेजता है। अनुवाद न करने पर पॉड पता शुरू से अंत तक बना रहता है, जो आरोपण के लिए बेहतर और नई श्रेणी सीखने वाले रास्ते के हर उपकरण के लिए बदतर है। कोई भी विकल्प Docker या CNI की ख़राबी नहीं; दोनों परिचालन बिल वाले राउटिंग फ़ैसले हैं। वह चुनें जिसका बिल आपकी टीम भर सके, और क्यों लिखें।

सत्यापित करें और वापस लें

वही कैप्चर फिर चलाएँ। आपके संपादन के बाद भी नोड-स्तरीय कैप्चर पॉड का पता छापे तो ConfigMap कुछ भी कहे, नियम कभी नहीं बदले। तार ही सच्चाई है; बाक़ी सब अनुमान।

फिर उलटी दिशा जाँचें, क्योंकि इन बदलावों में से आधे केवल बाहर की दिशा में सत्यापित होते हैं। पुष्टि करें कि जवाब उस नोड या पॉड तक पहुँचता है जिसने अनुरोध भेजा, और पुष्टि करें कि एप्लिकेशन ने केवल SYN लेकर नहीं बल्कि पूरा किया। जवाब के बिना अनुरोध दिखाने वाला कैप्चर दूसरे पक्ष की राउटिंग समस्या है, इस पक्ष की masquerade समस्या नहीं।

वापस लेना पिछला ConfigMap है, उसी तरह लागू, उसी पुष्टि के साथ कि एजेंट फिर से शुरू हुआ और नियम बदले। बदलाव रिकॉर्ड में एक ज्ञात अनुरोध का स्रोत पता पहले और बाद में रखें, क्योंकि वही एक पंक्ति साबित करती है कि बदलाव ने वही किया जो आपने कहा। GKE IP masquerade एजेंट गाइड डिफ़ॉल्ट और ConfigMap फ़ील्ड दर्ज करती है। रोलआउट के बाद स्रोत पता न बदले तो उस नोड पर एजेंट नहीं चल रहा और कितना भी YAML संपादन उसे ठीक नहीं करेगा।