1.14 नंतर GKE पॉड्सनी VPN प्रवेश गमावला: स्रोत दुरुस्त करण्याचे दोन मार्ग
1.14 नंतर पॉड्स स्वतःच्या पत्त्यांसह VPN पर्यंत पोहोचतात, त्यामुळे पीअर उत्तरे टाकून देतात. स्रोत करार निवडा, नंतर nonMasqueradeCIDRs त्यानुसार सेट करा.
एक अपग्रेड येतो, आणि बोगद्याच्या पलीकडील प्रणाली गेल्या आठवड्यात चालणारा पॉड रहदारी नाकारू लागतात. बोगदा सुरू आहे, फायरवॉल नियम अस्पर्शित आहेत, आणि कोणीही पीअर धोरण संपादित केले नाही. जे बदलले ते क्लस्टर लॉगमध्ये अदृश्य आहे: त्या प्रणाली आता जो स्रोत पत्ता पाहतात. हे अंतर नेटवर्क खंडासारखे दिसणाऱ्या आणि परवानगीच्या समस्येसारखे वागणाऱ्या बिघाडाचे स्पष्टीकरण देते.
दोन वैध उत्तरे आहेत, आणि ती तुम्हाला वेगवेगळ्या ठिकाणी नेतात. ConfigMap संपादित करण्यापूर्वी स्रोत करार निवडा.
स्थापित होणे थांबलेला डीफॉल्ट नियम
जुन्या GKE आवृत्त्या masquerade नियम स्थापित करत, जो गंतव्य 10.0.0.0/8 बाहेर असताना पॉड स्रोत नोड पत्त्याने बदलत असे. त्या श्रेणीतील VPN गेटवे पॉड पत्ता पाहत असे, तर त्याहून दूरचे नोडकडून आलेले वाटत असे. पीअरनी नोड पत्त्यांभोवती परवानगी याद्या आणि परतीचे मार्ग बांधले, कारण त्यांनी तेच निरीक्षण केले होते.
नंतरच्या आवृत्त्यांनी तो डीफॉल्ट नियम स्थापित करणे थांबवले. पॉड रहदारी आता गंतव्य काहीही असो, पॉड पत्त्यांसह गेटवेवर पोहोचते. फक्त नोड पत्ते मार्गस्थ करणारा पीअर उत्तरे टाकून देतो, आणि कोणताही पक्ष उपयुक्त लॉग नोंद लिहीत नाही. विनंती दूरच्या टोकावर यशस्वीही होऊ शकते, आणि यामुळेच हा बिघाड मागावणे गोंधळात टाकणारे होते.
मृत घटकाच्या अर्थाने काहीही तुटलेले नाही. दोन्ही बाजू कोणता स्रोत कायदेशीर आहे यावर सहमत नाहीत एवढेच.
पीअरने पाहावा अशा स्रोताची निवड करा
पॉड पत्ते ठेवणे हा अधिक अचूक करार आहे. दूरची बाजू रहदारी निर्माण करणारा वर्कलोड पाहते, लॉग प्रामाणिक राहतात, आणि प्रत्येक पॉडसाठी धोरण शक्य होते. किंमत ही आहे की पीअरला पॉड उपसर्ग वाहून न्यावा लागतो.
नोड पत्ते ठेवणे हा स्वस्त करार आहे. त्या गंतव्यासाठी masquerade पुन्हा चालू करा, आणि पीअर आधीच विश्वास ठेवत असलेला पत्ता पाहत राहील.
एक प्रश्न त्यांच्यात निर्णय घेतो: पीअर स्रोताशी काय करतो? तो लॉग लिहित असेल, प्रति-स्रोत धोरण लागू करत असेल किंवा अरुंद परतीचे मार्गस्थ बंधनकारक करत असेल, तर पॉड पत्ते अतिरिक्त कॉन्फिगरेशनला न्याय देतात. फक्त उत्तरे पाठवायची असतील, तर masquerade कमी खर्चाचे आहे आणि दुसऱ्या बाजूकडून काहीही मागत नाही. दोन्ही संघांनी ते लिहून ठेवले तर कोणतीही निवड समर्थनीय आहे.
तिसरा पर्याय सहसा चूक असते: सर्व काही masquerade करणे आणि रहदारीला जोडण्याची क्षमता गमावणे. पीअर खरोखर नोड पत्त्यांशिवाय काहीही मार्गस्थ करू शकत नसेल तरच ते टाळा.
nonMasqueradeCIDRs खऱ्या श्रेणींकडे निर्देश करा
GKE kube-system मध्ये ip-masq-agent चालवते, आणि त्याचे ConfigMap masquerade वगळणारी गंतव्ये सूचीबद्ध करते. बोगद्याकडे पॉड स्रोत जपण्यासाठी पॉड श्रेणी, नोड सबनेट आणि स्थानिक उपसर्ग सर्व त्या यादीत येतात.
नमुना मूल्ये तुमच्या स्वतःच्या क्लस्टरच्या श्रेणींनी बदला. गरजेपेक्षा यादी रुंद करू नका, कारण प्रत्येक अतिरिक्त नोंद दुसऱ्या गंतव्याला काय दिसते ते बदलते. खालील तीन नोंदी पॉड नेटवर्क, नोड सबनेट आणि बोगद्यामागील उपसर्ग दर्शवतात:
nonMasqueradeCIDRs:
- 10.12.0.0/14
- 10.100.0.0/16
- 172.16.0.0/12
masqLinkLocal: false
resyncInterval: 60s0.0.0.0/0 नोंद सर्व गंतव्यांसाठी masquerade बंद करते, यामुळे असंबंधित वर्कलोड बाह्य सेवांना कसे दिसतात ते बदलते आणि हे क्वचितच हेतुपूर्वक असते. एजंट resyncInterval वर त्याचे कॉन्फिगरेशन पुन्हा वाचतो, त्यामुळे पुन्हा सुरू करणे सहसा आवश्यक नसते. एजंट पॉड चालू आहे का ते तपासा, नंतर त्याच्या आत माउंट केलेली फाईल उघडा. ती फाईल वाचणे हेच बदल पोहोचल्याचा पुरावा आहे.
उत्तराचा मार्ग हा दुसरा अर्धा आहे
masquerade विनंतीचा स्रोत बदलते आणि दुसरे काहीही नाही. पीअरला कोणताही स्रोत मिळाला तरी त्याला तिथे परत जाण्याचा मार्ग अजूनही हवा, आणि क्लस्टरला पीअरकडे जाण्याचा मार्गही अजूनही हवा.
VPN गेटवेवरील कॅप्चर दोन्ही बिघाड वेगाने वेगळे करते. पॉड पत्त्यांसह येऊन कधीही उत्तर न मिळणारे पॅकेट म्हणजे पीअरकडे पॉड उपसर्गासाठी मार्ग नाही. गेटवेवर दिसून क्लस्टरपर्यंत कधीही न पोहोचणारे उत्तर म्हणजे स्थानिक मार्ग गहाळ आहे. कोणत्याही परिस्थितीत करार तिकिटात लिहा: पीअर कोणता स्रोत पाहतो, आणि कोणत्या उपसर्गाकडे परत मार्गस्थ करतो.
प्रत्येक अपग्रेडनंतर पुन्हा तपासा
masquerade चे डीफॉल्ट वर्तन आधीच एकदा बदलले आहे, आणि नोड पूल बदलल्यास क्लस्टर नेटवर्किंग रीसेट होऊ शकते. स्रोत कराराला गृहीत धरण्याची गोष्ट नाही, तपासण्याची गोष्ट माना.
अपग्रेडनंतर एका पॉडमधून स्थानिक सेवेवर एक विनंती पाठवा आणि पीअर लॉग करत असलेला स्रोत वाचा. ते एकच निरीक्षण बोगदा स्थिती पृष्ठ आनंदाने निरोगी म्हणून नोंदवेल अशी रिग्रेशन पकडते. त्याची पुनरावृत्ती एक मिनिट घेते आणि पुढच्या व्यक्तीची एक संध्याकाळ वाचवते.