प्रॉम्प्ट और दायरा
आप सैकड़ों Kubernetes क्लस्टर्स को संचालित करते हैं। v1.36 में, कोर कंपोनेंट्स /statusz को एक्सपोज़ करते हैं, जो डिफ़ॉल्ट रूप से ह्यूमन-रीडेबल टेक्स्ट और स्पष्ट कंटेंट नेगोशिएशन के माध्यम से एक स्ट्रक्चर्ड API रिटर्न करता है। कलेक्शन, परमिशन्स, वर्शन कम्पैटिबिलिटी, अलर्टिंग और फॉल्ट आइसोलेशन डिज़ाइन करें। कुछ क्लस्टर्स अभी भी पुराने रिलीज़ चला रहे हैं, और कंट्रोल-प्लेन एंडपॉइंट्स सार्वजनिक नहीं हो सकते हैं।
इंटरव्यूअर क्या जांच रहा है
इंटरव्यूअर यह देखना चाहता है कि क्या आप कई क्लस्टर्स के लिए ऑथेंटिकेशन, रेट लिमिट्स, वर्शन पार्सिंग और डिग्रेडेशन को डिज़ाइन करते समय हेल्थ प्रोब्स, कंपोनेंट स्टेट और बिज़नेस SLOs को अलग कर पाते हैं या नहीं। एक मजबूत उत्तर संवेदनशील फ़ील्ड्स, अलर्ट स्टॉर्म्स, कलेक्टर विफलताओं और अगम्य (unreachable) कंट्रोल-प्लेन को संभालता है।
पहले स्पष्ट करने योग्य प्रश्न
- क्या आपको लाइवनेस, डिपेंडेंसी स्टेट, या वर्शन्ड डायग्नोस्टिक फ़ील्ड्स की आवश्यकता है?
- क्या कलेक्टर प्रत्येक क्लस्टर के अंदर चलता है, या कोई केंद्रीय प्लेन डेटा पुल करता है?
- कौन सी भूमिकाएँ statusz पढ़ सकती हैं, और क्या प्रतिक्रियाएँ आंतरिक टोपोलॉजी या वर्शन्स को एक्सपोज़ कर सकती हैं?
- क्या डिटेक्शन सेकंडों में अपेक्षित है, या मिनट-स्तरीय क्षमता और रुझान पर्याप्त हैं?
30-सेकंड का उत्तर
“मैं statusz को एक डायग्नोस्टिक सिग्नल मानूँगा, न कि बिज़नेस-हेल्थ सिग्नल। एक इन-क्लस्टर कलेक्टर न्यूनतम विशेषाधिकार (least privilege) के साथ प्राइवेट नेटवर्क पर एंडपॉइंट्स तक पहुँचता है, उपलब्ध होने पर स्ट्रक्चर्ड आउटपुट का अनुरोध करता है, और मानवीय निदान के लिए टेक्स्ट रखता है; पुराने क्लस्टर्स कम्पैटिबिलिटी प्रोब का उपयोग करते हैं। केंद्रीय प्लेटफ़ॉर्म क्लस्टर, कंपोनेंट और वर्शन के अनुसार रेट लिमिट्स, कैशिंग और अलर्ट डिडुप्लिकेशन के साथ एग्रीगेट करता है। एक अगम्य कंट्रोल-प्लेन कलेक्शन-पाथ की विफलता है, स्वचालित रूप से आंतरिक कंपोनेंट की विफलता नहीं।”
चरण-दर-चरण समाधान
1. सिग्नल्स और वर्शन कॉन्ट्रैक्ट्स को परिभाषित करें
कंपोनेंट पहचान, वर्शन, रिस्पॉन्स फॉर्मेट, चेक्स और टाइमस्टैम्प रिकॉर्ड करें। अज्ञात फ़ील्ड्स पर निर्भर किए बिना उन्हें संरक्षित करते हुए, वर्शन के अनुसार स्ट्रक्चर्ड फ़ील्ड्स को पार्स करें; डिस्प्ले और साक्ष्य के लिए टेक्स्ट का उपयोग करें। statusz को /livez, /readyz और बिज़नेस मेट्रिक्स से अलग रखें।
2. कलेक्शन टोपोलॉजी डिज़ाइन करें
प्रत्येक क्लस्टर के अंदर एक लाइटवेट कलेक्टर चलाएं और लोकल नेटवर्किंग पर API सर्वर, शेड्यूलर और कंट्रोलर मैनेजर तक पहुंचें। केंद्र रिडैक्टेड स्टेट इवेंट्स प्राप्त करता है और एग्रीगेट करता है, जिससे सार्वजनिक कंट्रोल-प्लेन एंडपॉइंट्स से बचा जा सकता है। कलेक्टर को एक कतार (queue), बैकऑफ़ और लोकल कैश प्रदान करें।
3. ऑथेंटिकेशन और ऑथराइजेशन लागू करें
कंपोनेंट एंडपॉइंट्स और नेटवर्क पाथ्स को सीमित करते हुए, सबसे छोटे रिसोर्स स्कोप के साथ एक रीड-ओनली कलेक्टर पहचान बनाएं। रीडर, फ़्रीक्वेंसी और रिस्पॉन्स साइज़ का ऑडिट करें; कभी भी एडमिनिस्ट्रेटर क्रेडेंशियल का पुन: उपयोग न करें। आवश्यकता पड़ने पर टेनेंट और ऑपरेशंस रोल द्वारा वर्शन या टोपोलॉजी फ़ील्ड्स को फ़िल्टर करें।
4. लोड और विफलता को नियंत्रित करें
प्रति-कंपोनेंट समवर्तीता (concurrency), टाइमआउट्स, कैश अवधि और अधिकतम रिस्पॉन्स साइज़ सेट करें। रिट्राइज़ के साथ घटना को बढ़ाने के बजाय कंट्रोल-प्लेन के व्यस्त या अगम्य होने पर बैकऑफ़ करें। कंपोनेंट द्वारा रिपोर्ट की गई विफलता, HTTP विफलता, नेटवर्क अगम्यता और कलेक्टर बैकलॉग को अलग-अलग मॉडल करें।
5. एग्रीगेट करें और अलर्ट दें
डिडुप्लिकेशन के लिए इवेंट फिंगरप्रिंट्स का उपयोग करके क्लस्टर, कंपोनेंट, वर्शन और विफलता के प्रकार के आधार पर टाइम सीरीज़ बनाएं। एक निरंतर विंडो और इम्पैक्ट स्कोप की आवश्यकता रखें, जैसे कि कई कंपोनेंट्स का विफल होना या एक वर्शन में संकेंद्रण। एकल टाइमआउट एक कम प्राथमिकता वाला डायग्नोस्टिक सिग्नल है।
6. कैनरी और रोलबैक
पहले v1.36 क्लस्टर्स के एक छोटे सेट पर स्ट्रक्चर्ड कलेक्शन सक्षम करें। विस्तार करने से पहले API लोड, फ़ील्ड स्थिरता, अलर्ट सटीकता और कलेक्शन लेटेंसी की तुलना करें। यदि फ़ील्ड्स या लोड में गिरावट आती है, तो नए पार्सर को अक्षम करें, कम्पैटिबिलिटी प्रोब पर वापस लौटें, और रॉ रिस्पॉन्सेस तथा ऑडिट रिकॉर्ड्स को बनाए रखें।
मॉडल उत्तर
मैं statusz को लाइवनेस प्रोब्स और बिज़नेस SLOs के साथ कंट्रोल-प्लेन डायग्नोस्टिक्स के रूप में स्तरित करूँगा। प्रत्येक क्लस्टर प्राइवेट नेटवर्किंग पर न्यूनतम-विशेषाधिकार वाला रीड-ओनली कलेक्टर चलाता है; केंद्र रिडैक्टेड स्टेट प्राप्त करता है और एग्रीगेट करता है, जबकि पुराने रिलीज़ कम्पैटिबिलिटी प्रोब का उपयोग करते हैं। वर्शन के अनुसार स्ट्रक्चर्ड रिस्पॉन्सेस को पार्स करें, अज्ञात फ़ील्ड्स को सहन करें, और ऑपरेटरों के लिए टेक्स्ट बनाए रखें। समवर्तीता, टाइमआउट, कैश और रिस्पॉन्स साइज़ को सीमित करें, कंपोनेंट विफलता, नेटवर्क विफलता और कलेक्टर बैकलॉग को अलग करें। फिंगरप्रिंट और विंडो द्वारा अलर्ट्स को डिडुप्लिकेट करें। कुछ v1.36 क्लस्टर्स पर कैनरी करें और आवश्यकता पड़ने पर केवल नए पार्सर को अक्षम करें।
सामान्य गलतियाँ
- statusz को बिज़नेस SLO मानना → उपयोगकर्ता अनुभव को गलत तरीके से वर्गीकृत किया जाता है → इसे बिज़नेस मेट्रिक्स के साथ स्तरित करें।
- पब्लिक एंडपॉइंट्स को केंद्रीय रूप से क्वेरी करना → अटैक सर्फेस बढ़ता है → इन-क्लस्टर कलेक्ट करें और स्टेट को केंद्रीय रूप से भेजें।
- एडमिनिस्ट्रेटर क्रेडेंशियल का पुन: उपयोग करना → रीड्स अत्यधिक विशेषाधिकार प्राप्त हो जाते हैं → एक न्यूनतम रीड-ओनली पहचान बनाएं।
- किसी अज्ञात फ़ील्ड पर पूरी पाइपलाइन को विफल करना → अपग्रेड्स कलेक्शन को बाधित करते हैं → वर्शन के अनुसार उदारतापूर्वक (leniently) पार्स करें।
- प्रत्येक टाइमआउट पर अलर्ट करना → अलर्ट स्टॉर्म्स → पाथ विफलता को कंपोनेंट विफलता से अलग करें और डिडुप्लिकेट करें।
फॉलो-अप प्रश्न और उत्तर
टेक्स्ट रिस्पॉन्स को क्यों बनाए रखें?
स्ट्रक्चर्ड फ़ील्ड्स मशीन एग्रीगेशन के लिए हैं; टेक्स्ट एक ऑपरेटर को घटना के साक्ष्य को तुरंत पढ़ने और सुरक्षित रखने में मदद करता है। वे एक ही एंडपॉइंट से आते हैं लेकिन विभिन्न उद्देश्यों की पूर्ति करते हैं।
कंट्रोल-प्लेन के अगम्य होने पर आप फ़ॉल्स पॉज़िटिव से कैसे बचते हैं?
नेटवर्क अगम्यता, ऑथेंटिकेशन विफलता, कलेक्टर बैकलॉग और कंपोनेंट द्वारा रिपोर्ट की गई विफलता को अलग-अलग मॉडल करें। पर्याप्त साक्ष्य होने पर ही कंपोनेंट फॉल्ट को एस्केलेट करें।
आप पुराने क्लस्टर्स का समर्थन कैसे करते हैं?
पहले एंडपॉइंट और वर्शन की जांच करें, फिर स्ट्रक्चर्ड पार्सिंग, टेक्स्ट पार्सिंग या कम्पैटिबिलिटी प्रोब चुनें। यह मानने के बजाय कि प्रत्येक क्लस्टर Beta इंटरफ़ेस का समर्थन करता है, एक कैपेबिलिटी मैट्रिक्स बनाए रखें।
आप कलेक्शन को API सर्वर को धीमा करने से कैसे रोकते हैं?
फ़्रीक्वेंसी और समवर्तीता को सीमित करें, कैश और बैकऑफ़ का उपयोग करें, रिस्पॉन्स साइज़ को सीमित करें, और API-सर्वर लोड बढ़ने पर कलेक्शन फ़्रीक्वेंसी को स्वचालित रूप से कम करें।