प्रॉम्प्ट और दायरा
एक मल्टी-टेनेंट क्लस्टर में GPU मेमोरी और वर्चुअल-NIC बैंडविड्थ है जिसे केवल पूरे डिवाइस के रूप में आवंटित नहीं किया जा सकता है। प्लेटफ़ॉर्म चाहता है कि कई Pods एक ही डिवाइस साझा करें, जबकि प्रत्येक अनुरोध में न्यूनतम, स्टेप (step), ऊपरी सीमा और एक ट्रैक करने योग्य आवंटन पहचान (identity) हो। Kubernetes DRA उपभोग्य क्षमता के साथ संसाधन मॉडल और एंड-टू-एंड फ्लो डिज़ाइन करें।
Kubernetes 1.34 और एक ऐसे ड्राइवर को मानकर चलें जो क्षमता सीमाओं को लागू कर सकता है। शेड्यूलर को डिवाइस को ओवरसब्सक्राइब नहीं करना चाहिए। Kubernetes 1.34 ने कोर DRA APIs को आम तौर पर उपलब्ध (GA) बना दिया है, जबकि उपभोग्य क्षमता एक अल्फा क्षमता है; एक मजबूत उत्तर स्थिर APIs, फ़ीचर गेट्स और ड्राइवर-विशिष्ट गारंटियों के बीच की सीमा को चिह्नित करता है।
इंटरव्यूअर क्या मूल्यांकन करता है
उत्तर में DeviceClass, ResourceSlice, ResourceClaim, DeviceRequest, शेड्यूलर और ड्राइवर को स्पष्ट ज़िम्मेदारियां सौंपी जानी चाहिए। इसे इस इनवेरिएंट को स्पष्ट करना चाहिए कि एक डिवाइस के लिए आवंटित क्षमता कभी भी कुल क्षमता से अधिक नहीं होती है, और allowMultipleAllocations, RequestPolicy, ShareID, और DistinctAttribute की व्याख्या करनी चाहिए।
इंटरव्यूअर यह भी जांचता है कि क्या आप एक सफल शेड्यूलिंग निर्णय को एप्लिकेशन-स्तरीय थ्रॉटलिंग के साथ भ्रमित तो नहीं करते हैं। एक प्रोडक्शन डिज़ाइन के लिए ड्राइवर प्रवर्तन, स्टेटस रिपोर्टिंग, नेमस्पेस प्राधिकरण, नोड-विफलता रिकवरी और एक प्रतिवर्ती (reversible) रोलआउट की आवश्यकता होती है।
स्पष्टीकरण वाले प्रश्न
क्या संसाधन को अलग (isolate) किया जा सकता है?
पुष्टि करें कि क्या हार्डवेयर या ड्राइवर आइसोलेशन लागू कर सकते हैं। यदि यह नहीं हो सकता है, तो प्लेटफ़ॉर्म सॉफ्ट कोटा या पूरे-डिवाइस आवंटन की पेशकश कर सकता है, लेकिन यह केवल API फ़ील्ड से QoS का वादा नहीं कर सकता है।
शेयरिंग और प्राधिकरण की सीमाएं क्या हैं?
पूछें कि क्या नेमस्पेस एक डिवाइस साझा कर सकते हैं, क्या व्यवस्थापक (admin) एक्सेस की अनुमति है, और टेनेंट्स कौन सी डिवाइस विशेषताएं या क्षमताएं पढ़ सकते हैं। उत्तर सेलेक्टर्स, एडमिशन जांच और ऑडिट के दायरे को बदल देते हैं।
विफलता के बाद क्या जीवित रहना चाहिए?
स्पष्ट करें कि शेड्यूलिंग विफलता, ड्राइवर आवंटन विफलता, नोड हानि, या Pod पुनर्निर्माण के बाद क्या होता है: रिलीज़, लीज़ प्रतिधारण, या पुनः कतारबद्ध (requeue) करना। क्षणिक पुनः प्रयासों और स्थायी हार्डवेयर विफलताओं के लिए अलग-अलग स्थितियों की आवश्यकता होती है।
30-सेकंड का उत्तर ढांचा
"मैं पहले क्षमता इनवेरिएंट और टेनेंट सीमा को परिभाषित करता हूं। DeviceClass योग्य डिवाइसों का वर्णन करता है, ResourceSlice क्षमता और अनुरोध नीति प्रकाशित करता है, और ResourceClaim एक Pod की आवश्यकता को व्यक्त करता है। शेड्यूलर क्षमता से अधिक किए बिना एक डिवाइस का चयन करता है; ड्राइवर वास्तविक मेमोरी या बैंडविड्थ सीमा को लागू करने के लिए ShareID का उपयोग करता है और स्टेटस की रिपोर्ट करता है। क्रॉस-नेमस्पेस शेयरिंग के लिए प्राधिकरण और ऑडिट की आवश्यकता होती है। प्रत्येक रिलीज़ इडेम्पोटेंट होती है। मैं एक समय में एक डिवाइस क्लास को रोल आउट करता हूं और आवंटित क्षमता, वास्तविक सीमाओं, शेड्यूलिंग लेटेंसी, अस्वीकृति दर और रिकवरी समय की तुलना करता हूं।"
चरण-दर-चरण गहन विश्लेषण
चरण एक: संसाधन मॉडल को परिभाषित करें
DeviceClass एक डिवाइस प्रकार और CEL सेलेक्टर्स का वर्णन करता है। ResourceSlice प्रत्येक डिवाइस, उसकी विशेषताओं, क्षमता और एकाधिक आवंटन की अनुमति है या नहीं, इसे प्रकाशित करता है। ResourceClaim क्लास और क्षमता को बताने के लिए DeviceRequest का उपयोग करता है। कुल डिवाइस क्षमता को अनुरोध क्षमता से अलग रखें; एक की डिवाइस संख्या कोई क्षमता मान नहीं है।
चरण दो: क्षमता इनवेरिएंट बताएं
प्रत्येक डिवाइस के लिए, आवंटित क्षमता, इकाइयों और अनुरोध नीति को ट्रैक करें। यदि किसी डिवाइस में 40 GiB है और अनुरोध कम से कम 5 GiB के स्टेप्स में कम से कम 5 GiB होने चाहिए, तो प्रत्येक अनुरोध को उन सीमाओं को पूरा करना होगा और सभी सक्रिय ShareIDs का योग अधिकतम 40 GiB होना चाहिए। रिलीज़ और पुनः प्रयास संचालन एक आवंटन संस्करण का उपयोग करते हैं ताकि डुप्लिकेट कॉलबैक दो बार न घट जाएं।
चरण तीन: शेड्यूलिंग और ड्राइवर डेटा फ्लो का वर्णन करें
शेड्यूलर ResourceSlice पढ़ता है, सेलेक्टर्स, क्षमता श्रेणियों और allowMultipleAllocations को फ़िल्टर करता है, एक उम्मीदवार को आरक्षित करता है, और ResourceClaim को बाइंड करता है। ड्राइवर आवंटन प्राप्त करता है, ShareID द्वारा की गई एक स्वतंत्र सीमा बनाता है, इसे डिवाइस पर लागू करता है, और ResourceClaim स्टेटस में गतिशील डेटा की रिपोर्ट करता है। यदि शेड्यूलिंग सफल हो जाती है लेकिन ड्राइवर आवंटन को अस्वीकार कर देता है, तो नियंत्रक एक पुनः प्रयास योग्य या टर्मिनल स्थिति दिखाता है; इसे Pod को Ready नहीं दिखाना चाहिए।
चरण चार: नेमस्पेस और डुप्लिकेट डिवाइस को संभालें
एक साझा डिवाइस ResourceClaim नेमस्पेस सीमा को समाप्त नहीं करता है। एडमिशन को DeviceClass उपयोग, व्यवस्थापक एक्सेस और ड्राइवर कॉन्फ़िगरेशन को प्रतिबंधित करना चाहिए। DistinctAttribute एक ही क्लेम को एक ही अंतर्निहित डिवाइस को दो बार चुनने से रोकता है, जैसे कि जब दो नेटवर्क इंटरफेस को अलग-अलग सबनेट तक पहुंचना होता है। केवल अंतिम डिवाइस नाम के बजाय टेनेंट, क्लेम, ShareID, क्षमता और नीति संस्करण का ऑडिट करें।
चरण पांच: विफलता और रिक्लेमेशन डिज़ाइन करें
ड्राइवर पुनरारंभ के बाद, टिकाऊ स्थिति से ShareIDs और वास्तविक सीमाओं को पुनर्प्राप्त करें। नोड हानि के बाद, आवंटन को अज्ञात के रूप में चिह्नित करें और क्षमता को तुरंत दूसरे Pod को न दें जब तक कि कोई लीज़, डिवाइस फेंस या ड्राइवर पुष्टि यह साबित न कर दे कि पुराना आवंटन समाप्त हो गया है। Pod विलोपन, क्लेम समाप्ति और शेड्यूलिंग रोलबैक दोहराने योग्य होना चाहिए। मौजूदा आवंटन अपना नीति स्नैपशॉट बनाए रखते हैं; नए क्लेम बदली हुई नीति का उपयोग करते हैं।
चरण छह: रोलआउट, SLOs, और क्षमता गणित
प्रत्येक 40 GiB वाले 100 डिवाइस और 70 प्रतिशत लक्ष्य औसत उपयोगिता मान लें। तार्किक शेड्यूल करने योग्य क्षमता लगभग 2,800 GiB है, थ्रूपुट का वादा नहीं; ड्राइवर ओवरहेड, विखंडन (fragmentation) और विफलता हेडरूम आरक्षित करें। शेड्यूलिंग p99, ड्राइवर-कॉन्फ़िगरेशन p99, क्षमता अस्वीकृति दर और स्टेटस अभिसरण (convergence) के लिए SLOs सेट करें। प्रति डिवाइस क्लास फ़ीचर गेट सक्षम करें। पूरे डिवाइस आवंटन के साथ थ्रूपुट, टेल लेटेंसी, विखंडन और रिकवरी की तुलना करें।
चरण सात: एक विकल्प की तुलना करें
यदि हार्डवेयर केवल निश्चित स्लाइस का समर्थन करता है, तो MIG या पूर्व-विभाजित DeviceClasses विखंडन और कम लोच की कीमत पर सरल और साबित करने में आसान हैं। यदि ड्राइवर फाइन-ग्रेन्ड सीमाओं को लागू नहीं कर सकता है, तो पूरे-डिवाइस आवंटन या क्षमता विस्तार पर वापस जाएं; यह दिखावा न करें कि केवल एक क्षमता फ़ील्ड आइसोलेशन प्रदान करता है।
उच्च गुणवत्ता वाला नमूना उत्तर
मैं पहले सत्यापित करता हूं कि क्या डिवाइस क्षमता आइसोलेशन लागू कर सकता है। यदि यह नहीं हो सकता, तो डिज़ाइन केवल घोषणात्मक चयन है और इसमें कोई QoS वादा नहीं है। यदि यह कर सकता है, तो DeviceClass योग्य डिवाइसों का वर्णन करता है, ResourceSlice क्षमता और अनुरोध नीति प्रकाशित करता है, और ResourceClaim टेनेंट अनुरोध को ले जाता है। शेड्यूलर केवल तभी बाइंड करता है जब सेलेक्टर्स मेल खाते हैं और क्षमता का योग डिवाइस सीमा से नीचे रहता है; ड्राइवर तब एक ShareID-स्कोप्ड सीमा बनाता है और स्टेटस की रिपोर्ट करता है।
मैं क्षमता योग, नीति संस्करण और इडेम्पोटेंट रिलीज़ को स्पष्ट इनवेरिएंट बनाता हूं। क्रॉस-नेमस्पेस शेयरिंग एडमिशन, व्यवस्थापक प्राधिकरण और ऑडिट का उपयोग करती है; DistinctAttribute एक क्लेम के भीतर डुप्लिकेट अंतर्निहित-डिवाइस विकल्पों को रोकता है। ड्राइवर या नोड की विफलता पर, मैं इसे पुनः प्राप्त करने से पहले फेंसिंग या पुष्टि होने तक अज्ञात आवंटन बनाए रखता हूं। रोलआउट एक क्लास से शुरू होता है और शेड्यूलिंग p99, ड्राइवर p99, अस्वीकृति, वास्तविक प्रवर्तन और रिकवरी को मापता है। फिक्स्ड-स्लाइस हार्डवेयर पूर्व-विभाजित डिज़ाइन का उपयोग करता है।
सामान्य गलतियाँ
- लक्षण → केवल ResourceClaim में क्षमता मान डालना → यह क्यों विफल होता है → ड्राइवर वास्तविक सीमा लागू नहीं कर सकता है → सुधार → प्रवर्तन और स्टेटस पथ को साबित करें।
- लक्षण → डिवाइस संख्या को क्षमता योग के रूप में उपयोग करना → यह क्यों विफल होता है → समवर्ती अनुरोध ओवरसब्सक्राइब करते हैं या अंशों को बर्बाद करते हैं → सुधार → प्रति डिवाइस और संस्करण आवंटित क्षमता को ट्रैक करें।
- लक्षण → साझा डिवाइसों को बिना शर्त क्रॉस-टेनेंट शेयरिंग के रूप में मानना → यह क्यों विफल होता है → नेमस्पेस और प्राधिकरण सीमाएं गायब हो जाती हैं → सुधार → एडमिशन, व्यवस्थापक एक्सेस नियंत्रण और ऑडिट जोड़ें।
- लक्षण → नोड हानि के तुरंत बाद क्षमता जारी करना → यह क्यों विफल होता है → पुराना ड्राइवर अभी भी आवंटन लागू कर सकता है, जिससे दोहरा असाइनमेंट हो सकता है → सुधार → फेंस करें, लीज़ की पुष्टि करें, या एक स्पष्ट अज्ञात स्थिति बनाए रखें।
- लक्षण → अल्फा फ़ीचर गेट के लिए स्थिर SLOs का वादा करना → यह क्यों विफल होता है → API, ड्राइवर और अपग्रेड व्यवहार भिन्न होते हैं → सुधार → संस्करण सीमाओं को चिह्नित करें और कैनरी के माध्यम से मान्य करें।
फॉलो-अप और मजबूत प्रतिक्रियाएं
फॉलो-अप एक: दो नेमस्पेस एक साथ अंतिम 10 GiB का अनुरोध करते हैं। आप रेस कंडीशन से कैसे बचते हैं?
क्षमता आरक्षित करते समय ResourceSlice संस्करण या समकक्ष ऑप्टिमिस्टिक कॉनकरेन्सी जांच का उपयोग करें। यदि बाइंडिंग विफल हो जाती है, तो वर्तमान स्थिति को फिर से पढ़ें और पुनः प्रयास करें। ड्राइवर कॉलबैक शेड्यूलर के इनवेरिएंट को बायपास नहीं कर सकता है; नियंत्रण तल अंतिम आवंटन की पुष्टि करता है।
फॉलो-अप दो: ड्राइवर एक ShareID की रिपोर्ट करता है, लेकिन Pod कभी शुरू नहीं होता है। क्या होता है?
आवंटन स्थिति को Pod की तत्परता (readiness) से अलग करें। टाइमआउट के बाद, नियंत्रक ShareID, क्लेम संस्करण और कारण को बनाए रखते हुए एक इडेम्पोटेंट रिलीज़ करता है या ऑपरेटर-दृश्यमान स्थिति में प्रवेश करता है। केवल इसलिए क्षमता या ऑडिट डेटा को न छोड़ें क्योंकि Pod Running स्थिति में नहीं है।
फॉलो-अप तीन: नीति 5 GiB न्यूनतम से बदलकर 10 GiB हो जाती है। क्या मौजूदा क्लेम बदलते हैं?
पूर्ण आवंटन उस नीति स्नैपशॉट को बनाए रखते हैं जिसके तहत उन्हें प्रदान किया गया था; नए क्लेम नई नीति का उपयोग करते हैं। पुनर्संतुलन के लिए एक स्पष्ट माइग्रेशन फ्लो, आकार बदलने के लिए ड्राइवर समर्थन और एक प्रतिवर्ती रिलीज़-और-पुनः आवंटन अनुक्रम की आवश्यकता होती है।
फॉलो-अप चार: आप कैसे साबित करते हैं कि साझा बैंडविड्थ वास्तव में लागू की गई है?
निश्चित ट्रैफ़िक, नोड्स और ड्राइवर संस्करणों के साथ एकल-टेनेंट बेसलाइन और मल्टी-ShareID लोड परीक्षण चलाएं। प्रति-टेनेंट थ्रूपुट, p99, ड्रॉप्स और प्रवर्तन सीमा की तुलना करें। अकेले ResourceClaim स्थिति हार्डवेयर QoS को साबित नहीं करती है।