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 सम्पादन गरे पनि सुधारिँदैन।