सिस्टम डिज़ाइन साक्षात्कार: आप Kubernetes Node Declared Features को सुरक्षित रूप से कैसे रोल आउट करेंगे?

प्रॉम्प्ट और संदर्भ

आपका क्लस्टर Kubernetes Node Declared Features को अपना रहा है: kubelet नोड स्थिति (Node status) में प्रबंधित नोड क्षमताओं की रिपोर्ट करते हैं, शेड्यूलर उसी के अनुसार Pods को फ़िल्टर करता है, और एक एडमिशन कंट्रोलर Pod अपडेट को मान्य करता है। एक मिक्स्ड-वर्जन क्लस्टर के लिए रोलआउट, ऑब्जर्वेबिलिटी, विफलता से निपटने और रोलबैक को डिज़ाइन करें। मान लें कि केवल नियंत्रित नोड सुविधाओं का उपयोग किया जाता है; एप्लिकेशन टीमें मनमाने क्षमता नाम नहीं लिख सकती हैं।

साक्षात्कारकर्ता क्या मूल्यांकन करता है

• क्या क्षमता घोषणाओं को उपयोगकर्ता-नियंत्रित लेबलों के बजाय नोड-स्थिति के तथ्यों के रूप में माना जाता है।
• क्या kubelet, kube-apiserver, kube-scheduler, और एडमिशन कंट्रोल के बीच निर्भरता क्रम स्पष्ट है।
• क्या पुराने नोड्स, पुरानी स्थिति (stale status), Pod अपडेट और फ़ीचर-गेट रोलबैक को कवर किया गया है।
• क्या सुरक्षा को केवल प्रक्रिया स्टार्टअप से नहीं, बल्कि घोषणा की पूर्णता और शेड्यूलिंग अस्वीकृति के साथ प्रदर्शित किया गया है।

स्पष्टीकरण के लिए प्रश्न

• कौन सा kubelet संस्करण क्षमता उत्पन्न करता है, और क्या पुराने नोड्स सामान्य Pods की सेवा जारी रख सकते हैं?
• क्या लक्ष्य केवल प्लेसमेंट की सुरक्षा करना है, या Pod बाउंड होने के बाद अपडेट की भी सुरक्षा करना है?
• क्या कस्टम शेड्यूलर, एकाधिक API सर्वर, या मल्टी-रीजन कंट्रोल प्लेन मौजूद हैं?
• गलत रिपोर्ट आने पर, क्या नए Pods को रुकना चाहिए जबकि मौजूदा Pods चलना जारी रखें?

30-सेकंड का उत्तर

मैं इसे क्रॉस-कंपोनेंट फैक्ट चेन के रूप में मानूँगा: kubelet status.declaredFeatures प्रकाशित करते हैं, शेड्यूलर प्लगइन PreFilter में Pod आवश्यकताओं का अनुमान लगाता है और नोड्स को फ़िल्टर करता है, और एडमिशन वैलिडेशन बाद के अपडेट की सुरक्षा करता है। मैं इसे पहले एक रिवर्सिबल नोड पूल और एक छोटे वर्कलोड स्लाइस पर सक्षम करूँगा, API सर्वर, शेड्यूलर और kubelet पर मैचिंग फ़ीचर-गेट कॉन्फ़िगरेशन को सत्यापित करूँगा, और फिर विस्तार करूँगा। मैं रिपोर्ट पूर्णता, शेड्यूलिंग अस्वीकृति कारणों, अपडेट अस्वीकृतियों और संस्करण विषमता (version skew) की निगरानी करूँगा। कोई भी विसंगति नई क्षमता की आवश्यकता वाले वर्कलोड को रोकती है और अन्य Pods के लिए सामान्य शेड्यूलिंग पथ को सुरक्षित रखती है।

चरण-दर-चरण समाधान

1. सत्य का स्रोत (Source of Truth) परिभाषित करें। स्टार्टअप पर, kubelet प्रबंधित सुविधाओं का पता लगाता है और उन्हें Node.status.declaredFeatures में लिखता है; एप्लिकेशन लेबल इसके समकक्ष नहीं हैं। क्षमता के नाम प्रबंधित फ़ीचर गेट्स या एक स्पष्ट घटक अनुबंध से आने चाहिए।
2. निर्भरता को स्पष्ट करें। Kubernetes को kube-apiserver, kube-scheduler, और kubelet पर NodeDeclaredFeatures गेट की आवश्यकता होती है। kubelet को अपग्रेड करने से पहले कंट्रोल-प्लेन संस्करणों और कॉन्फ़िगरेशन को सत्यापित करें; केवल एक पक्ष को सक्षम करने से ऐसा फ़ील्ड बनता है जिसका कोई उपयोग नहीं करता या ऐसा शेड्यूलर बनता है जो ऐसी रिपोर्ट की अपेक्षा करता है जो नोड्स उत्पन्न नहीं कर सकते।
3. शेड्यूलिंग पथ डिज़ाइन करें। शेड्यूलर प्लगइन PreFilter में PodSpec से आवश्यक सुविधाओं का अनुमान लगाता है और Filter में नोड घोषणा के साथ उनकी तुलना करता है। आवश्यक घोषणा के बिना नोड उस Pod के लिए unschedulable होता है। इस फ़ील्ड का उपयोग करने वाले कस्टम शेड्यूलर को समान डिफ़ॉल्ट और विफलता सिमेंटिक्स को बनाए रखना चाहिए।
4. अपडेट पथ को सुरक्षित रखें। NodeDeclaredFeatureValidator एडमिशन कंट्रोलर बाउंड नोड के विरुद्ध Pod अपडेट की जाँच करता है, जिससे बाद के अपडेट क्षमता की बाधा को दरकिनार न कर सकें। चुपचाप प्रदर्शन कम करने के बजाय एक स्पष्ट अस्वीकृति दिखाएँ।
5. संस्करण विषमता (Version Skew) को संभालें। एक पुराना kubelet फ़ील्ड को छोड़ सकता है या किसी नई क्षमता को नहीं जान सकता है। एक अघोषित सुविधा को असमर्थित मानें, जिससे आश्रित Pods पेंडिंग रहें जबकि सामान्य Pods संगत नोड्स का उपयोग करें। विषमता को बायपास करने के लिए Node status को मैन्युअली संपादित न करें।
6. चरणों में रोल आउट करें। एक रिवर्सिबल नोड पूल पर गेट को सक्षम करें, क्षमता की आवश्यकता वाला एक प्रोब वर्कलोड रखें, और धीरे-धीरे विस्तार करें। जब रिपोर्ट-मिसिंग दर, शेड्यूलिंग अस्वीकृति, Pod-अपडेट अस्वीकृति, या शेड्यूलर लेटेंसी अपनी बेसलाइन से अधिक हो जाए, तो रुकें।
7. निगरानी और ऑडिट करें। नोड घोषणा संस्करण, क्षमता सेट का एक डाइजेस्ट, शेड्यूलर फ़िल्टर कारण, एडमिशन अस्वीकृति कारण, और गेट कॉन्फ़िगरेशन फ़िंगरप्रिंट एकत्र करें, जिन्हें पूल और Kubernetes संस्करण द्वारा विभाजित किया गया हो। उच्च-कार्डिनैलिटी लॉग में पूर्ण Node ऑब्जेक्ट्स लिखने से बचें।
8. सावधानीपूर्वक रोलबैक करें। सुविधा पर निर्भर Pods बनाना बंद करें, सामान्य शेड्यूलिंग को पुनर्स्थापित करें, और पेंडिंग आश्रित कार्य को संभालने के बाद घटक क्रम में गेट को बंद करें। यदि व्यवसाय पहले से ही क्षमता पर निर्भर करता है, तो घोषणाओं को गायब करने से पहले वर्कलोड को माइग्रेट करें या संगत नोड्स को बनाए रखें।

मॉडल उत्तर

मैं सबसे पहले सत्य के स्रोत और सुरक्षा सीमा की पहचान करूँगा। kubelet प्रबंधित status.declaredFeatures प्रकाशित करते हैं, शेड्यूलर का NodeDeclaredFeatures प्लगइन प्लेसमेंट को फ़िल्टर करता है, और NodeDeclaredFeatureValidator बाइंडिंग के बाद अपडेट की सुरक्षा करता है। चूँकि Kubernetes को kube-apiserver, शेड्यूलर और kubelet पर गेट की आवश्यकता होती है, इसलिए मैं इसे एक रिवर्सिबल पूल पर सक्षम करने से पहले संस्करणों और कॉन्फ़िगरेशन को संरेखित करूँगा। एक प्रोब Pod क्षमता रिपोर्टिंग और प्लेसमेंट की पुष्टि करता है; रिपोर्ट-मिसिंग दर, फ़िल्टर अस्वीकृति, अपडेट अस्वीकृति और शेड्यूलिंग लेटेंसी विस्तार के मानदंड बन जाते हैं। एक पुराना नोड जो सुविधा घोषित नहीं करता है वह असमर्थित होता है, जबकि सामान्य Pods पुराना पथ बनाए रखते हैं। रोलबैक के लिए, मैं नए आश्रित वर्कलोड को रोकूँगा, मौजूदा को माइग्रेट करूँगा, गेट को बंद करूँगा, और पुष्टि करूँगा कि पेंडिंग काउंट और सामान्य शेड्यूलिंग ठीक हो गए हैं।

सामान्य गलतियाँ

• declaredFeatures को एक सामान्य लेबल मानना → उपयोगकर्ता क्षमता को गलत तरीके से बना सकते हैं और शेड्यूलिंग सुरक्षा को पराजित कर सकते हैं → केवल kubelet-प्रबंधित सेट को स्वीकार करें।
• केवल शेड्यूलर में गेट सक्षम करना → नोड्स फ़ील्ड प्रकाशित नहीं करते हैं → API सर्वर, शेड्यूलर, और kubelet कॉन्फ़िगरेशन को एक साथ जांचें।
• "अघोषित" को समर्थित मानना → मिक्स्ड-वर्जन नोड्स असंगत Pods प्राप्त कर सकते हैं → अघोषित का अर्थ असमर्थित है।
• केवल प्रारंभिक प्लेसमेंट का परीक्षण करना → एक Pod अपडेट बाधा को बायपास कर सकता है → एडमिशन वैलिडेशन को भी सक्षम करें और देखें।
• इसे पूरे क्लस्टर में सक्षम करना → विफलताओं को किसी पूल, संस्करण, या वर्कलोड के लिए जिम्मेदार नहीं ठहराया जा सकता है → प्रोब, चरणों और रोकने की शर्तों का उपयोग करें।
• गेट को तुरंत अक्षम करना → आश्रित Pods अप्राप्य हो सकते हैं → पहले निर्माण रोकें और आश्रित वर्कलोड को माइग्रेट करें।

फॉलो-अप और उत्तर

एक नोड ने क्षमता की रिपोर्ट की लेकिन उसकी स्थिति पुरानी (stale) है। शेड्यूलर को क्या करना चाहिए?

रिपोर्ट की आयु को एक ऑपरेशनल सिग्नल बनाएं। सुविधा की आवश्यकता वाले Pod को पुरानी घोषणा पर निर्भर रहने के बजाय प्रतीक्षा करनी चाहिए या एक नए नोड पर जाना चाहिए। ताजगी की समय सीमा (freshness deadline) के बाद, पूल को अलग करें और ऑपरेटर की पुष्टि की आवश्यकता रखें।

आधिकारिक प्लगइन को अनदेखा करने वाले कस्टम शेड्यूलर के साथ क्या गलत हो सकता है?

यह उस Pod की अनुमति दे सकता है जिसे डिफ़ॉल्ट शेड्यूलर अस्वीकार करता है। कस्टम पथ को समकक्ष PreFilter, Filter, डिफ़ॉल्ट और संस्करण सिमेंटिक्स को लागू करना चाहिए; वर्कलोड को इसे चुनने की अनुमति देने से पहले अनुरूपता परीक्षण (conformance tests) चलाएं।

जब तीन घटक गेट बदलते हैं तो आप कॉन्फ़िगरेशन विंडो से कैसे बचते हैं?

रोलआउट चेक में एक कॉन्फ़िगरेशन फ़िंगरप्रिंट डालें, सामान्य वर्कलोड को चालू रखें, और कंट्रोल प्लेन, शेड्यूलर और नोड पूल के माध्यम से एक नियंत्रित क्रम में रोलआउट करें। कोई भी बेमेल विस्तार को रोकता है; केवल प्रक्रिया स्टार्टअप सफलता नहीं है।

व्यवसाय सुविधा पर निर्भर करता है, लेकिन रोलबैक में पाया जाता है कि पुराने नोड इसका समर्थन नहीं करते हैं। अब क्या?

उन नोड्स का एक पूल बनाए रखें जो क्षमता घोषित करते हैं, आश्रित वर्कलोड को माइग्रेट या कम करें, और केवल तभी गेट बंद करें। यदि माइग्रेशन असंभव है, तो रोलबैक को रोकें और शेड्यूलिंग बाधा को अचानक हटाने के बजाय संगत क्षमता जोड़ें।