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 संपादन केले तरी ते सुधारणार नाही।