प्रॉम्प्ट और दायरा
माइग्रेशन को Ingress संसाधनों और कंट्रोलर-विशिष्ट एनोटेशन से Gateway API संसाधनों पर जाते समय बाहरी रूप से देखे गए स्टेटस कोड, पाथ, हेडर और बैकएंड चयन को सुरक्षित रखना चाहिए। मुख्य कौशल प्रॉक्सी सीमा पर कम्पैटिबिलिटी इंजीनियरिंग है, इसलिए यह प्रश्न backend से संबंधित है। Kubernetes ब्लॉग कई ऐसे Ingress-NGINX व्यवहारों का दस्तावेजीकरण करता है जिन्हें अनदेखा करना आसान है, जिनमें होस्ट-व्यापी regex प्रभाव, अंतर्निहित रीडायरेक्ट और नॉर्मलाइज़ेशन शामिल हैं।
साक्षात्कारकर्ता क्या मूल्यांकन करते हैं
YAML अनुवाद अभ्यास के बजाय वास्तविक ट्रैफ़िक व्यवहार की एक इन्वेंट्री देखें। मजबूत उम्मीदवार कार्यान्वयन-विशिष्ट रेगुलर एक्सप्रेशन से पोर्टेबल Gateway API सेमेंटिक्स को अलग करते हैं, ऐसे अंतर्निहित व्यवहार की पहचान करते हैं जिसे एक स्पष्ट फ़िल्टर की आवश्यकता होती है, और रोलबैक के साथ विभेदक परीक्षण (differential tests) का प्रस्ताव करते हैं। उन्हें स्वामित्व, प्रमाणपत्र और लिसनर निर्भरता, ऑब्जर्वेबिलिटी, और चरणबद्ध DNS या ट्रैफ़िक कटओवर पर भी चर्चा करनी चाहिए।
पहले स्पष्ट करने योग्य प्रश्न
- कौन सा Ingress-NGINX संस्करण, एनोटेशन, Gateway API कंट्रोलर और कन्फर्मेंस स्तर तैनात हैं?
- कौन से होस्ट
use-regex,rewrite-target, auth, canary, या कस्टम स्निपेट का उपयोग करते हैं? - क्या क्लाइंट 301 रीडायरेक्ट, पाथ केस, डुप्लिकेट स्लैश या एन्कोडेड सेगमेंट पर निर्भर हैं?
- क्या नया Gateway समानांतर रूप से चल सकता है और मिरर्ड या सैंपल किया गया ट्रैफ़िक प्राप्त कर सकता है?
- Gateway, HTTPRoute, बैकएंड पॉलिसी और TLS संसाधनों का स्वामी कौन है?
- रोलबैक ट्रिगर क्या है और कितनी जल्दी ट्रैफ़िक पुराने कंट्रोलर पर वापस जा सकता है?
30-सेकंड उत्तर ढांचा
"मैं पहले मैनिफ़ेस्ट, एक्सेस लॉग और ब्लैक-बॉक्स प्रोब से एक व्यवहार इन्वेंट्री तैयार करूँगा। मैं यह मान लेने के बजाय कि एनोटेशन अनुवादित हो जाते हैं, स्पष्ट रूप से regex, रीराइट, रीडायरेक्ट और TLS को मॉडल करते हुए प्रति व्यवहार Gateway API संसाधन उत्पन्न करूँगा। फिर मैं पुराने और नए कंट्रोलर्स के विरुद्ध विभेदक परीक्षण चलाऊँगा, ट्रैफ़िक को शैडो या कैनरी करूँगा, स्थिति, स्थान, चयनित बैकएंड और लेटेंसी की तुलना करूँगा, और DNS या रूटिंग रोलबैक तैयार रखूँगा। केवल शून्य अस्पष्टीकृत अंतरों के बाद ही मैं प्रत्येक होस्ट को माइग्रेट करूँगा।"
चरण-दर-चरण उत्तर
चरण 1: देखे गए अनुबंधों की इन्वेंट्री बनाएँ
प्रत्येक होस्ट और पाथ को पार्स करें, लेकिन अनुरोधों के साथ इसे सत्यापित करें। Ingress-NGINX regex मिलान केस-इनसेंसिटिव और प्रीफ़िक्स-आधारित हो सकता है, और एक एनोटेशन Ingress ऑब्जेक्ट्स में होस्ट के सभी पाथ को प्रभावित कर सकता है। रीडायरेक्ट, नॉर्मलाइज़्ड पाथ, हेडर, प्रमाणीकरण, टाइमआउट और बैकएंड विकल्पों को परीक्षण योग्य अनुबंधों के रूप में रिकॉर्ड करें।
चरण 2: पोर्टेबल और कंट्रोलर-विशिष्ट व्यवहार को वर्गीकृत करें
साधारण होस्ट/पाथ रूटिंग को Gateway और HTTPRoute पर मैप करें। रेगुलर-एक्सप्रेशन मिलान को कार्यान्वयन-विशिष्ट मानें और चयनित कंट्रोलर के सेमेंटिक्स को सत्यापित करें। जहाँ समर्थित हो, रीराइट और रीडायरेक्ट व्यवहार को स्पष्ट HTTPRoute फ़िल्टर में बदलें। असमर्थित एनोटेशन या स्निपेट एक स्वामी और प्रतिस्थापन डिज़ाइन के साथ माइग्रेशन अवरोधक बन जाते हैं।
चरण 3: एक विभेदक परीक्षण मैट्रिक्स बनाएँ
प्रत्येक अनुबंध के लिए, सामान्य और प्रतिकूल पाथ का परीक्षण करें: केस वेरिएंट, ट्रेलिंग स्लैश, . और .. सेगमेंट, डुप्लिकेट स्लैश, एन्कोडेड वर्ण, अनुपलब्ध रूट और बैकएंड विफलताएँ। स्टेटस, Location, बैकएंड द्वारा प्राप्त पाथ, हेडर, चयनित सर्विस और एरर बॉडी की तुलना करें। दोनों कंट्रोलर्स के लिए समान फ़िक्सचर और अनुरोध हेडर का उपयोग करें।
चरण 4: कंट्रोलर और पॉलिसी की तैयारी साबित करें
Gateway और HTTPRoute स्टेटस स्थितियों, लिसनर अटैचमेंट, प्रमाणपत्र तत्परता, क्रॉस-नेमस्पेस संदर्भ नीति और प्रत्येक फ़िल्टर के लिए कार्यान्वयन समर्थन की जाँच करें। API द्वारा स्वीकार किया गया संसाधन इस बात का प्रमाण नहीं है कि डेटाप्लेन प्रत्येक अनुरोधित सुविधा को लागू करता है।
चरण 5: कैनरी और रोलबैक
एक छोटे होस्ट या ट्रैफ़िक स्लाइस के साथ एक समानांतर Gateway चलाएँ। जहाँ संभव हो, सुरक्षित इडेम्पोटेंट अनुरोधों को मिरर करें; अन्यथा सैनिटाइज़्ड फ़िक्सचर को रीप्ले करें। अस्पष्टीकृत रूटिंग अंतर, 4xx/5xx परिवर्तन, रीडायरेक्ट ड्रिफ्ट, या लेटेंसी रिग्रेशन पर निरस्त करें। अवलोकन विंडो बंद होने तक पुराने कंट्रोलर और DNS या ट्रैफ़िक भार को अपरिवर्तित रखें।
मॉडल उत्तर
"मैं वर्तमान Ingress-NGINX व्यवहार को एक बाहरी अनुबंध मानूँगा। मैनिफ़ेस्ट, एनोटेशन, लॉग और प्रोब की इन्वेंट्री तैयार करने के बाद, मैं Gateway और HTTPRoute संसाधनों में प्रत्येक अनुबंध को स्पष्ट रूप से मॉडल करूँगा। Regex, रीराइट, ट्रेलिंग-स्लैश रीडायरेक्ट और URL नॉर्मलाइज़ेशन को कंट्रोलर-विशिष्ट सत्यापन की आवश्यकता होती है; कुछ अंतर्निहित व्यवहारों को स्पष्ट फ़िल्टर बनना चाहिए। मैं स्टेटस, Location, बैकएंड पाथ, हेडर और सर्विस चयन को कवर करने वाला एक विभेदक मैट्रिक्स चलाऊँगा, फिर रोलबैक भार के साथ कैनरी करूँगा। Gateway स्टेटस स्थितियाँ और कन्फर्मेंस दावे आवश्यक हैं लेकिन पर्याप्त नहीं हैं, इसलिए मैं DNS बदलने से पहले ब्लैक-बॉक्स साक्ष्य बनाए रखूँगा।"
सामान्य गलतियाँ
- YAML का आमने-सामने अनुवाद करना → एनोटेशन में छिपे हुए होस्ट-व्यापी प्रभाव हो सकते हैं → रनटाइम व्यवहार की इन्वेंट्री बनाएँ और उसका परीक्षण करें।
- यह मानना कि
Exactका अर्थ समान मिलान है → पुराने कंट्रोलर में regex या नॉर्मलाइज़ेशन के दुष्प्रभाव हो सकते हैं → केस, स्लैश और एन्कोडेड वेरिएंट की जाँच करें। - संसाधन की Accepted स्थिति पर निर्भर रहना → डेटाप्लेन समर्थन अभी भी अधूरा हो सकता है → स्थितियों और ब्लैक-बॉक्स प्रतिक्रियाओं की जाँच करें।
- पहले DNS काटना → रोलबैक धीमा और अस्पष्ट हो जाता है → जब तक पुराना पाथ उपलब्ध रहे, ट्रैफ़िक को कैनरी करें।
- बैकएंड-दृश्यमान पाथ की उपेक्षा करना → रीराइट एप्लिकेशन को तोड़ सकते हैं → बैकएंड द्वारा प्राप्त पाथ और हेडर की पुष्टि करें।
- केवल हैप्पी पाथ का परीक्षण करना → रुकावटें रीडायरेक्ट और विकृत URL में छिपी होती हैं → नकारात्मक और प्रतिकूल फ़िक्सचर शामिल करें।
अनुवर्ती प्रश्न
अनुवर्ती 1: regex माइग्रेशन ट्रैफ़िक को क्यों बदल सकता है?
Ingress-NGINX किसी होस्ट के पाथ पर केस-इनसेंसिटिव प्रीफ़िक्स जैसा regex व्यवहार लागू कर सकता है। Gateway API रेगुलर एक्सप्रेशन कार्यान्वयन-विशिष्ट होते हैं, जबकि Exact और Prefix चुपचाप regex में परिवर्तित नहीं होते हैं।
अनुवर्ती 2: आप ट्रेलिंग-स्लैश रीडायरेक्ट को कैसे सुरक्षित रखते हैं?
इसे एक HTTP रीडायरेक्ट फ़िल्टर के साथ स्पष्ट रूप से मॉडल करें और दोनों स्लैश वेरिएंट का परीक्षण करें। यह न मानें कि कोई Gateway कार्यान्वयन स्वचालित रूप से पुराने 301 को जोड़ता है।
अनुवर्ती 3: एक सुरक्षित रोलबैक सिग्नल क्या है?
एक निश्चित बेसलाइन और एक सीमित अवलोकन विंडो के विरुद्ध मूल्यांकन किए गए स्टेटस, Location, बैकएंड पाथ, सर्विस चयन, एरर दर, या लेटेंसी में अस्पष्टीकृत अंतरों का उपयोग करें।
अनुवर्ती 4: माइग्रेशन टूलिंग क्या साबित करती है?
एक कनवर्टर इन्वेंट्री को गति दे सकता है और उम्मीदवार संसाधन उत्पन्न कर सकता है, लेकिन यह कंट्रोलर-विशिष्ट सेमेंटिक्स, छिपे हुए एनोटेशन इंटरैक्शन या एप्लिकेशन कम्पैटिबिलिटी को साबित नहीं कर सकता है। विभेदक परीक्षणों को रिलीज़ गेट के रूप में बनाए रखें।