प्रॉम्प्ट और स्कोप
एक मल्टी-टेनेंट मशीन-लर्निंग प्लेटफ़ॉर्म GPU, FPGA और हाई-स्पीड NIC का उपयोग करता है। इसका वर्तमान डिज़ाइन नोड लेबल, एक्सटेंडेड रिसोर्स और डिवाइस प्लगइन्स के माध्यम से संपूर्ण डिवाइस आवंटित करता है, जिससे डिवाइस एट्रिब्यूट, शेयरिंग और टेनेंट आइसोलेशन को व्यक्त करना कठिन हो जाता है। टीम Dynamic Resource Allocation (DRA) को अपनाना चाहती है, जिसके मुख्य resource.k8s.io/v1 API Kubernetes 1.34 में स्थिर (stable) हो गए हैं।
माइग्रेशन को डिज़ाइन करें और ResourceClaim, DeviceClass, ResourceClaimTemplate, ResourceSlice, ड्राइवर और शेड्यूलर की ज़िम्मेदारियों की व्याख्या करें। क्लस्टर को एक साथ प्रत्येक वर्कलोड को पुनरारंभ किए बिना धीरे-धीरे माइग्रेट होना चाहिए।
इंटरव्यूअर क्या मूल्यांकन करता है
इंटरव्यूअर डिवाइस की आवश्यकता घोषित करने और एक ठोस डिवाइस आवंटित करने के बीच अलगाव देखना चाहता है। कंट्रोल-प्लेन API, शेड्यूलर, नोड ड्राइवर और kubelet के बीच डेटा फ़्लो की व्याख्या करें, और स्थिर DRA API को उन क्षमताओं से अलग करें जो प्रायोगिक या ड्राइवर-विशिष्ट बनी हुई हैं।
मजबूत उत्तर केवल रिसोर्स प्रकारों को सूचीबद्ध करने के बजाय क्षमता शेयरिंग, क्रॉस-नेमस्पेस संदर्भ, ड्राइवर विफलता, Pod रिप्लेसमेंट, पुराने वर्कलोड के साथ सहअस्तित्व, न्यूनतम विशेषाधिकार (least privilege) और रोलबैक संकेतों को कवर करते हैं।
उत्तर देने से पहले स्पष्ट करने वाले प्रश्न
- क्या अनुरोध संपूर्ण डिवाइस, स्लाइस करने योग्य क्षमता, या विशेषताओं से मेल खाने वाले किसी भी डिवाइस के लिए है?
- क्या ड्राइवर DRA का समर्थन करता है, और क्या माइग्रेशन के दौरान पुराना डिवाइस प्लगइन चल सकता है?
- क्या वर्कलोड को सीधे Claims बनाना चाहिए, या प्लेटफ़ॉर्म टेम्प्लेट को उन्हें बनाना चाहिए?
- क्या टेनेंट नेमस्पेस में Claims का पुन: उपयोग कर सकते हैं, और प्लेटफ़ॉर्म कंट्रोलर किन ऑब्जेक्ट्स को लिख सकता है?
- माइग्रेशन के दौरान, क्या प्राथमिकता जॉब निरंतरता, शेड्यूलिंग थ्रूपुट, या उपयोग (utilization) है?
30-सेकंड का उत्तर ढांचा
"मैं डिवाइस की जरूरतों को Claims के रूप में मॉडल करूँगा, ड्राइवर को डिवाइसों को खोजने, आवंटित करने और कॉन्फ़िगर करने दूँगा, और शेड्यूलर को Claims और ResourceSlices से व्यवहार्यता निर्णय लेने दूँगा। मैं एक अलग नेमस्पेस में एक छोटे डिवाइस क्लास का कैनरी परीक्षण करूँगा। पुराना प्लगइन और DRA पूल द्वारा सहअस्तित्व में रह सकते हैं, लेकिन उन्हें कभी भी एक ही डिवाइस का स्वामित्व नहीं लेना चाहिए। प्रत्येक चरण Claim स्थिति, Pod बाइंडिंग, नोड दृश्यता, ड्राइवर त्रुटियों, आवंटन विलंबता और टेनेंट सीमाओं को मापता है। यदि आवंटन विफल हो जाता है, तो मैं नए Claims को रोकता हूँ, चल रहे जॉब्स को सुरक्षित रखता हूँ, और नए वर्कलोड को पुराने पथ पर वापस भेजता हूँ।"
चरण-दर-चरण विस्तृत उत्तर
पहले DRA डेटा फ़्लो बनाएं
एक वर्कलोड Pod के resourceClaims फ़ील्ड के माध्यम से एक Claim को संदर्भित करता है। एक Claim सीधे बनाया जा सकता है या ResourceClaimTemplate द्वारा किसी Job के लिए उत्पन्न किया जा सकता है। एक DeviceClass डिवाइसों के एक चयन योग्य वर्ग का वर्णन करता है, जबकि एक ड्राइवर ResourceSlice के माध्यम से नोड डिवाइस और विशेषताओं को प्रकाशित करता है। शेड्यूलर नोड का चयन करने के लिए Pod, Claim, DeviceClass और ResourceSlice को जोड़ता है; नोड ड्राइवर तब ठोस आवंटन और कॉन्फ़िगरेशन करता है।
यह एप्लिकेशन YAML से डिवाइस चयन को अलग करता है और लेबल सम्मेलनों में हार्डवेयर टोपोलॉजी को एन्कोड करने से बचाता है।
Claim टेम्प्लेट और टेनेंट सीमाएं डिज़ाइन करें
केवल टेनेंट-फ़ेसिंग पैरामीटर जैसे मेमोरी टियर, इंटरकनेक्ट प्रकार, या नेटवर्क बैंडविड्थ को उजागर करें। ड्राइवर-आंतरिक पहचानकर्ताओं को उजागर न करें। एक प्लेटफ़ॉर्म कंट्रोलर नेमस्पेस प्रवेश नीति, कोटा और जीवनचक्र सफाई लागू करता है। क्रॉस-नेमस्पेस Claim उपयोग के लिए स्पष्ट संदर्भ अनुमतियों और ऑडिट घटनाओं की आवश्यकता होती है। टेनेंट हटाने के दौरान, नए Claims को रोकें, Pods द्वारा डिवाइस जारी करने की प्रतीक्षा करें, और फिर डिवाइस स्थिति को पुनः प्राप्त करें।
संपूर्ण डिवाइस और साझा करने योग्य क्षमता को संभालें
संपूर्ण-डिवाइस आवंटन एक DeviceRequest को एक डिवाइस में मैप कर सकता है। मेमोरी, बैंडविड्थ, या टाइम स्लाइस साझा करने के लिए ड्राइवर को क्षमता प्रकाशित करने और प्रासंगिक DRA उपभोग्य-क्षमता व्यवहार का समर्थन करने की आवश्यकता होती है। शेड्यूलर लेबल के साथ शेयरिंग का अनुकरण न करें; शेड्यूलिंग सफल हो सकती है जबकि नोड वास्तविक क्षमता को ओवरसेल करता है। इकाइयों, समवर्ती सीमाओं, रिलीज समय और विखंडन नीति को परिभाषित करें।
डिवाइस प्लगइन्स के साथ सहअस्तित्व
माइग्रेशन को डिवाइस क्लास या नोड पूल द्वारा विभाजित करें ताकि पुराना प्लगइन और DRA कभी भी एक ही हार्डवेयर के स्वामित्व का विज्ञापन न करें। मौजूदा वर्कलोड विस्तारित संसाधनों को बनाए रखते हैं; नए वर्कलोड DRA Claims को संदर्भित करते हैं। पूल लेबल एक माइग्रेशन सीमा हैं, डिवाइस विशेषताओं का अंतिम स्रोत नहीं। डुप्लिकेट ड्राइवर आरंभीकरण को रोकने के लिए प्रत्येक पूल को स्पष्ट स्वामित्व और एक अक्षम स्विच की आवश्यकता होती है।
शेड्यूलिंग, प्रीइम्प्शन और विफलता को संभालें
जब कोई Claim प्रतीक्षा करता है या विफल हो जाता है, तो Pod को एक स्पष्ट करने योग्य Pending कारण प्रदर्शित करना चाहिए। नोड का चयन करने का अर्थ यह नहीं है कि डिवाइस कॉन्फ़िगर किया गया है; नोड सेटअप के दौरान ड्राइवर विफल हो सकता है। एक कंट्रोलर को विफलताओं को पुन: प्रयास करने योग्य, गैर-पुन: प्रयास करने योग्य, या सफाई की आवश्यकता वाले के रूप में वर्गीकृत करना चाहिए और प्रत्येक वर्ग को सही अलर्ट पर भेजना चाहिए। प्रीइम्प्शन को केवल CPU या मेमोरी ही नहीं, बल्कि Pod प्राथमिकता, अधिकृत Claim क्षमता और रिलीज विलंबता पर विचार करना चाहिए।
क्षमता का निरीक्षण और योजना बनाएं
Claim निर्माण से बाइंडिंग, बाइंडिंग से नोड आवंटन, और आवंटन से Pod Ready तक को अलग-अलग चरणों के रूप में मापें। निष्क्रिय, आवंटित, अनुपलब्ध, विखंडित क्षमता और ड्राइवर त्रुटियों को ट्रैक करें। ResourceSlices द्वारा विज्ञापित क्षमता को नोड्स द्वारा वास्तव में प्रदर्शित की जाने वाली क्षमता के साथ मिलाएँ (reconcile करें); जब वे विचलित हों तो कैनरी विस्तार को रोकें। प्रशिक्षण प्लेटफ़ॉर्म को पुनः प्रयास, चेकपॉइंट रिकवरी और डिवाइस-स्वास्थ्य घटनाओं को भी रिकॉर्ड करना चाहिए।
कैनरी, रोलबैक और निरंतरता
पुन: प्रयास करने योग्य जॉब्स का उपयोग करके एक ड्राइवर और एक नोड पूल के साथ शुरुआत करें। इसके बाद एकाधिक टेनेंट्स और टेम्प्लेट में विस्तार करें; लंबे समय तक चलने वाले, गैर-बाधित करने योग्य जॉब्स को अंतिम रूप से माइग्रेट करें। रोलबैक का अर्थ बाउंड Claims को हटाना नहीं है। नए Claim निर्माण को रोकें, चल रहे Pods को समाप्त होने दें या माइग्रेट करें, ड्राइवर परिवर्तनों को फ़्रीज़ करें, और नए जॉब्स को पुराने प्लगइन पर रूट करें। Claim, Pod और ड्राइवर घटनाओं को बनाए रखें ताकि घटना का निदान किया जा सके।
API और सुरक्षा सीमाओं को मान्य करें
तैनाती से पहले, Claim, Template, DeviceClass और ResourceSlice संस्करणों, स्थिति संक्रमण और हटाने के क्रम के लिए resource.k8s.io/v1 API के विरुद्ध अनुबंध परीक्षण चलाएं। ड्राइवर रीस्टार्ट, नोड हानि, डुप्लिकेट आवंटन, लीक हुए Claims और क्रॉस-नेमस्पेस एक्सेस को इंजेक्ट करें। प्रवेश, RBAC, ऑडिट और नोड-एजेंट अनुमतियों की जांच करें। कार्यक्षमता, अलगाव और रिकवरी मेट्रिक्स पास होने के बाद ही डिवाइस पूल का विस्तार करें।
उच्च गुणवत्ता वाला मॉडल उत्तर
"मैं माइग्रेशन को रिसोर्स मॉडल, ड्राइवर, शेड्यूलिंग और रनटाइम लेयर्स में विभाजित करूँगा। वर्कलोड Claims घोषित करते हैं; Templates उन्हें उत्पन्न करते हैं; DeviceClass चयन को व्यक्त करता है; ड्राइवर ResourceSlices प्रकाशित करता है और नोड पर आवंटित करता है; शेड्यूलर व्यवहार्यता और नोड विकल्प को संभालता है। पुराने प्लगइन्स और DRA पूल या डिवाइस क्लास द्वारा सहअस्तित्व में रहते हैं, कभी भी दोहरे स्वामित्व के साथ नहीं। शेयरिंग के लिए, मुझे लेबल-आधारित ओवरसेलिंग के बजाय ड्राइवर क्षमता मॉडल और रिलीज सेमेंटिक्स की आवश्यकता होती है। मैं पुन: प्रयास करने योग्य जॉब्स से शुरुआत करता हूँ, Claim-से-Ready विलंबता, आवंटन विफलताएं, विखंडन, ड्राइवर स्वास्थ्य और टेनेंट उल्लंघनों को मापता हूँ, फिर नए Claims को रोकता हूँ और रोलबैक के दौरान नए जॉब्स को वापस रूट करने से पहले स्थिति को सुरक्षित रखता हूँ।"
सामान्य गलतियाँ
- DRA को नए डिवाइस लेबल के रूप में मानना → नोड-स्तरीय पूर्ति के बिना शेड्यूलिंग सफल होती है → ड्राइवर को संरचित डिवाइस और क्षमता प्रकाशित करने दें।
- प्लगइन और DRA को एक डिवाइस का मालिक बनने देना → डुप्लिकेट आरंभीकरण या आवंटन → पूल या डिवाइस क्लास द्वारा स्वामित्व को विभाजित करें।
- पुनर्प्राप्ति (reclamation) के बिना Claims को डिज़ाइन करना → डिवाइस और कोटा लीक जमा होते हैं → रिलीज, टाइमआउट, विलोपन और सुलह (reconciliation) को परिभाषित करें।
- लेबल के साथ शेयरिंग का अनुकरण करना → शेड्यूलर वास्तविक शेष क्षमता नहीं देख सकता → ड्राइवर को क्षमता और समवर्तीता प्रकाशित करने दें।
- नोड चयन को आवंटन की सफलता के बराबर मानना → ड्राइवर त्रुटियाँ Pods को अनिश्चित काल के लिए Pending छोड़ देती हैं → शेड्यूलिंग, नोड आवंटन और Ready मेट्रिक्स को अलग करें।
- रोलबैक के दौरान प्रत्येक Claim को हटाना → चल रहे जॉब्स और साक्ष्य गायब हो जाते हैं → नए आवंटन को फ़्रीज़ करें और स्थिति को सुरक्षित रखें।
फॉलो-अप प्रश्न और उत्तर
फॉलो-अप 1: GPU को विस्तारित संसाधनों के रूप में पंजीकृत क्यों न रखा जाए?
विस्तारित संसाधन सरल मात्रा अनुरोधों के अनुकूल होते हैं लेकिन डिवाइस विशेषताओं, विकल्पों, साझा क्षमता, या जटिल कॉन्फ़िगरेशन को अच्छी तरह से व्यक्त नहीं करते हैं। यदि आवश्यकता केवल संपूर्ण-डिवाइस गिनती है और ड्राइवर परिपक्व है, तो पुराना पथ बना रह सकता है। DRA को तब पेश किया जाना चाहिए जब डिवाइस चयन और जीवनचक्र की जटिलता इसे उचित ठहराती हो।
फॉलो-अप 2: जब कई Pods एक Claim को संदर्भित करते हैं तो आप ओवरसेलिंग को कैसे रोकते हैं?
पुन: उपयोग सेमेंटिक्स ड्राइवर और प्लेटफ़ॉर्म नीति में स्पष्ट होना चाहिए, YAML से अनुमानित नहीं होना चाहिए। साझा क्षमता के लिए, ड्राइवर आवंटित क्षमता, समवर्ती सीमाओं और रिलीज स्थिति को रिकॉर्ड करता है; प्रवेश उन संदर्भों को सीमित करता है जो टेनेंट नीति का उल्लंघन करते हैं।
फॉलो-अप 3: क्या शेड्यूलर को नोड सेटअप के दौरान ड्राइवर विफलता का पुन: प्रयास करना चाहिए?
पहले क्षणिक नोड विफलता, डिवाइस-स्वास्थ्य विफलता और अमान्य Claim पैरामीटर को वर्गीकृत करें। बैकऑफ़ के साथ क्षणिक विफलताओं का पुन: प्रयास करें; अमान्य पैरामीटर को गैर-पुन: प्रयास करने योग्य चिह्नित करें; अस्वस्थ नोड्स को अलग करें ताकि शेड्यूलर बार-बार एक ही विफलता डोमेन पर काम न भेजे।
फॉलो-अप 4: आप कैसे साबित करते हैं कि माइग्रेशन ने उपयोगिता को कम नहीं किया?
एक ही डिवाइस पूल में समान वर्कलोड के लिए आवंटन सफलता, प्रतीक्षा समय, विखंडन, उपयोगी गणना समय और जॉब पुन: प्रयास दर की तुलना करें। DRA और पुराने प्लगइन को डिवाइस क्लास द्वारा विभाजित करें; एक क्लस्टर-व्यापी औसत GPU उपयोग अपर्याप्त है।