प्रॉम्प्ट और संदर्भ
एक HA Kubernetes क्लस्टर अपने कंट्रोल प्लेन को v1.35 से v1.36 में रोल कर रहा है। इस विंडो के दौरान, अलग-अलग kube-apiserver इंस्टेंस अलग-अलग रिसोर्स वर्ज़न जान सकते हैं, इसलिए किसी पुराने सर्वर पर रूट किए गए क्लाइंट को ऐसे रिसोर्स के लिए भ्रामक 404 मिल सकता है जो किसी नए पीयर पर मौजूद है। डिज़ाइन करें और समझाएं कि Mixed Version Proxy को अनुरोधों को कैसे रूट करना चाहिए, ट्रस्ट को सीमित करना चाहिए, ऑब्ज़र्वेबिलिटी प्रदान करनी चाहिए और रोलबैक का समर्थन करना चाहिए। सामान्य वर्ज़न-स्क्यू पॉलिसी (version-skew policy) से Kubernetes v1.36 Beta व्यवहार में अंतर स्पष्ट करें।
इंटरव्यूअर क्या मूल्यांकन करता है
- वर्ज़न स्क्यू, डिस्कवरी कैश और API विज़िबिलिटी को अलग-अलग विफलता डोमेन में विभाजित करना।
- यह जानना कि प्रॉक्सी रिसोर्स रिक्वेस्ट्स को रूट करती है; यह API कन्वर्ज़न या स्टोरेज माइग्रेशन का स्थान नहीं लेती है।
- पीयर डिस्कवरी, फ़ॉरवर्डिंग, आइडेंटिटी प्रोपेगेशन और लूप प्रिवेंशन की व्याख्या करना।
- अपग्रेड सुरक्षा, ऑडिटेबिलिटी, टाइमआउट्स, पुनः प्रयास (retries) और रोलबैक को कवर करना।
पूछे जाने वाले स्पष्टीकरण प्रश्न
- क्या यह एक क्लस्टर के भीतर रोलिंग रिप्लेसमेंट है या क्रॉस-क्लस्टर माइग्रेशन? कई पीयर API सर्वरों वाले एक क्लस्टर को मान कर चलें।
- क्या क्लाइंट केवल बिल्ट-इन Kubernetes रिसोर्सेज़ का उपयोग कर रहे हैं, या एग्रीगेटेड API सर्वर और CRDs का भी? अज्ञात रिसोर्स वर्ज़न्स के लिए प्रॉक्सी के कवरेज की पुष्टि करें।
- क्या शेयर्ड लोड बैलेंसर, mTLS, सेंट्रलाइज़्ड ऑडिट और मेट्रिक्स पहले से उपलब्ध हैं? वे आइडेंटिटी प्रोपेगेशन और डायग्नोसिस का निर्धारण करते हैं।
- अतिरिक्त लेटेंसी, अनुपलब्धता और रोलबैक समय के लिए बजट क्या हैं?
30-सेकंड का उत्तर फ़्रेमवर्क
विफलता के साथ शुरुआत करें: रोलिंग अपग्रेड के दौरान, एक पुराना API सर्वर नए रिसोर्स वर्ज़न को अनुपलब्ध रिसोर्स समझने की गलती कर सकता है। फिर पाथ बताएं: एंट्री API सर्वर डिस्कवरी और एक स्थानीय निर्णय करता है; जब वर्ज़न स्थानीय रूप से अज्ञात होता है, तो यह एक कम्पैटिबल पीयर को फ़ॉरवर्ड करता है, कॉलर को पीयर रिस्पॉन्स, स्टेटस और ऑडिट आइडेंटिटी लौटाता है। सीमाओं के साथ समाप्त करें: वर्ज़न-स्क्यू पॉलिसी का पालन करें, प्रॉक्सी लूप्स को प्रतिबंधित करें, प्रॉक्सी आइडेंटिटी को सीमित करें, स्पष्ट फ़ॉरवर्डिंग विफलताएं लौटाएं, ऐसे पुनः प्रयासों से बचें जो कंट्रोल-प्लेन दोषों को छिपाते हैं, और मेट्रिक्स तथा एक चरणबद्ध फ़ीचर स्विच के माध्यम से रोलबैक करें।
चरण-दर-चरण विस्तृत विश्लेषण
1. अनुरोध को वर्गीकृत करें और तय करें कि फ़ॉरवर्ड करना है या नहीं
API सर्वर ग्रुप, वर्ज़न, रिसोर्स और वर्ब को पार्स करता है। यदि रिसोर्स स्थानीय रूप से पंजीकृत है, तो यह स्थानीय प्रमाणीकरण, प्राधिकरण, एडमिशन और स्टोरेज का पालन करता है। यदि अनुरोधित वर्ज़न स्थानीय डिस्कवरी में अज्ञात है, तो सर्वर जांचता है कि कौन से पीयर उस रिसोर्स वर्ज़न का विज्ञापन करते हैं। यह पीयर द्वारा स्पष्ट रूप से समर्थन की पुष्टि करने के बाद ही फ़ॉरवर्ड करता है; अन्यथा यह एक विशिष्ट एरर लौटाता है। प्रॉक्सी को वर्ज़न का अनुमान नहीं लगाना चाहिए या हर सामान्य बिज़नेस 404 को फ़ॉरवर्डिंग ट्रिगर में नहीं बदलना चाहिए।
2. पीयर्स को खोजें, आइडेंटिटी सुरक्षित रखें और लूप्स को रोकें
पीयर्स एक नियंत्रित कंट्रोल-प्लेन मेंबरशिप लिस्ट या एक विश्वसनीय आंतरिक डिस्कवरी तंत्र से आने चाहिए। कनेक्शन मौजूदा कंट्रोल-प्लेन सर्विस आइडेंटिटी और एन्क्रिप्टेड चैनल का उपयोग करते हैं। फ़ॉरवर्ड किया गया अनुरोध मूल उपयोगकर्ता पहचान, ग्रुप्स, प्राधिकरण हेडर और ऑडिट संदर्भ को वहन करता है, जबकि प्रॉक्सी अभी भी अपनी स्वयं की प्राधिकरण सीमा लागू करती है। एक हॉप मार्कर या समकक्ष आंतरिक मेटाडेटा जोड़ें; मार्कर देखने वाले सर्वर को दोबारा फ़ॉरवर्ड नहीं करना चाहिए, जिससे A-से-B-से-A लूप को रोका जा सके।
3. कंसिस्टेंसी और विफलताओं को संभालें
एक रीड ऑपरेशन API सर्वरों में डिस्कवरी कैश के बीच थोड़े समय के लिए अंतर देख सकता है, इसलिए क्लाइंट्स को सर्वर के रिसोर्स वर्ज़न और resourceVersion पर निर्भर रहना चाहिए। फ़ॉरवर्डिंग केवल तभी होती है जब टारगेट तक पहुँचा जा सकता हो और वह वर्ज़न-कम्पैटिबल हो; टाइमआउट, अस्वीकृति, या वर्ज़न-मिसमैच रिस्पॉन्स एक रिकॉर्ड किए गए कारण के साथ तुरंत विफल (fail fast) हो जाते हैं। राइट्स पर असीमित पुनः प्रयास लागू न करें, जो साइड इफेक्ट्स को दोहरा सकते हैं। यदि पुनः प्रयास आवश्यक है, तो एक आइडम्पोटेंसी कुंजी या स्पष्ट क्लाइंट पुनः प्रयास नीति का उपयोग करें।
4. रोल आउट करें, निरीक्षण करें और रोल बैक करें
ऑफ-पीक समय में एक API सर्वर को अपग्रेड करें, फिर बैच का विस्तार करने से पहले प्रॉक्सी हिट दर, फ़ॉरवर्डिंग लेटेंसी, अज्ञात-वर्ज़न त्रुटियाँ, 5xx प्रतिक्रियाएं, ऑडिट पूर्णता और डिस्कवरी कन्वर्जेंस की निगरानी करें। Mixed Version Proxy v1.36 में बीटा है और डिफ़ॉल्ट रूप से सक्षम है, लेकिन यह वितरण के वर्ज़न-स्क्यू मैट्रिक्स को मान्य करने की आवश्यकता को समाप्त नहीं करता है। यदि सिग्नल बिगड़ते हैं, तो रिप्लेसमेंट रोकें, ट्रैफ़िक को ज्ञात-कम्पैटिबल पीयर्स पर रखें, और जहां समर्थित हो, फ़ीचर गेट को अक्षम करें और कंट्रोल प्लेन को रोल बैक करें। ऑडिट रिकॉर्ड में फ़ॉरवर्डिंग चेन और मूल पहचान को बनाए रखें।
आदर्श उत्तर
मैं Mixed Version Proxy को एक नए API गेटवे के रूप में नहीं, बल्कि एक अस्थायी कंट्रोल-प्लेन कम्पैटिबिलिटी लेयर के रूप में मानूँगा। एंट्री सर्वर अनुरोध को प्रमाणित, अधिकृत और वर्गीकृत करता है। जिस रिसोर्स को वह स्थानीय रूप से जानता है वह स्थानीय पाथ का पालन करता है; स्थानीय रूप से अज्ञात रिसोर्स वर्ज़न केवल तभी फ़ॉरवर्ड किया जाता है जब कोई पीयर स्पष्ट रूप से उसका विज्ञापन करता है। कनेक्शन मौजूदा कंट्रोल-प्लेन आइडेंटिटी का उपयोग करता है, मूल उपयोगकर्ता और ऑडिट संदर्भ को वहन करता है, और लूप को रोकने के लिए एकल-हॉप मार्कर जोड़ता है। पीयर स्थिति और रिस्पॉन्स सिमेंटिक्स सुरक्षित रहते हैं। टाइमआउट्स तुरंत विफल होते हैं, और राइट्स को असीमित स्वचालित पुनः प्रयास नहीं मिलते हैं।
मैं एक चरणबद्ध अपग्रेड के साथ पाथ को मान्य करूँगा: स्थानीय हिट्स, प्रॉक्सी हिट्स, टारगेट वर्ज़न, लेटेंसी, एरर क्लास और एक ऑडिट कोरिलेशन ID रिकॉर्ड करें। जब हिट दर या 5xx एक सीमा से अधिक हो जाए तो बैच को रोकें। v1.36 में डिफ़ॉल्ट रूप से बीटा होना वितरण की स्क्यू पॉलिसी या एग्रीगेटेड APIs और CRDs के कवरेज की जाँच करने का विकल्प नहीं है। रोलबैक का अर्थ है रिप्लेसमेंट को रोकना, कंट्रोल-प्लेन मेंबर सेट को पुनर्स्थापित करना, समर्थित होने पर फ़ीचर गेट को अक्षम करना, और डिस्कवरी कैश की जाँच करना ताकि क्लाइंट पुरानी क्षमताओं का उपयोग करना जारी न रखें।
सामान्य गलतियाँ
- प्रॉक्सी को अज्ञात रिसोर्स वर्ज़न्स के रूट के बजाय एक मनमाना API वर्ज़न कन्वर्टर बताना।
- पीयर डिस्कवरी, आइडेंटिटी प्रोपेगेशन या लूप प्रोटेक्शन के बिना केवल "नए नोड पर फ़ॉरवर्ड करें" कहना।
- हर 404 को फ़ॉरवर्ड करना, जिससे वास्तविक मिसिंग रिसोर्सेज़ कंट्रोल-प्लेन ट्रैफ़िक में बदल जाएं।
- राइट्स को बिना शर्त पुनः प्रयास करना और डुप्लिकेट साइड इफेक्ट्स बनाना।
- डिस्कवरी कन्वर्जेंस, ऑडिट इंटीग्रिटी या स्क्यू प्रतिबंधों को छोड़कर केवल औसत लेटेंसी पर ध्यान देना।
फ़ॉलो-अप प्रश्न और प्रतिक्रियाएं
फ़ॉलो-अप 1: क्या एग्रीगेटेड API सर्वर या CRDs स्वचालित रूप से प्रॉक्सी किए जा सकते हैं?
पुष्टि करें कि क्या वह रिसोर्स कार्यान्वित Mixed Version Proxy के दायरे में है। एग्रीगेटेड API सर्वरों की स्वतंत्र डिस्कवरी, प्रमाणीकरण और उपलब्धता सीमाएं होती हैं; बिल्ट-इन रिसोर्सेज़ के लिए समर्थन का अर्थ उनके लिए समर्थन होना नहीं है। असमर्थित रिसोर्सेज़ के लिए एक कैपेबिलिटी मैट्रिक्स और एक स्पष्ट फास्ट-फेल पाथ प्रदान करें।
फ़ॉलो-अप 2: आप फ़ॉरवर्डिंग को कंट्रोल-प्लेन आउटेज को बढ़ाने से कैसे रोकते हैं?
सिंगल-हॉप मार्कर, डेडलाइन्स, कॉनकरेंसी लिमिट्स और एक सर्किट ब्रेकर का उपयोग करें। स्रोत पर अनिश्चित काल तक पुनः प्रयास न करें। प्रॉक्सी हिट दर, टारगेट एरर्स और कतार की गहराई पर अलर्ट सेट करें, और जब वे सिग्नल सीमाओं को पार करें तो अपग्रेड कंट्रोलर को बैच को रोकने दें।
फ़ॉलो-अप 3: क्या होगा यदि क्लाइंट का डिस्कवरी कैश पुराना है?
क्लाइंट अभी भी Kubernetes डिस्कवरी और वर्ज़न-स्क्यू नियमों का पालन करता है। सर्वर-साइड फ़ॉरवर्डिंग रोलिंग अपग्रेड के दौरान गलत 404 को कम कर सकती है; यह क्लाइंट्स के लिए नए रिसोर्सेज़ को स्थायी रूप से कैश नहीं कर सकती है या API वर्ज़न माइग्रेशन का स्थान नहीं ले सकती है। आवश्यकता पड़ने पर क्लाइंट को पुनः डिस्कवर करने और एक स्पष्ट API वर्ज़न का उपयोग करने दें।