प्रॉम्प्ट और दायरा
क्लस्टर GPU या नेटवर्क डिवाइस के लिए Dynamic Resource Allocation (DRA) का उपयोग करता है। एक कंटेनर को उसके आवंटित डिवाइस के लिए PCI, इंटरफ़ेस या ड्राइवर विशेषताओं की आवश्यकता होती है, लेकिन उसे Kubernetes API एक्सेस नहीं मिलना चाहिए। ड्राइवर-टू-कंटेनर मेटाडेटा पाथ डिज़ाइन करें और वर्ज़निंग, आइसोलेशन, विफलता और अपग्रेड व्यवहार को समझाएं।
इंटरव्यूअर क्या जांच रहा है
- क्या आप DRA ड्राइवर, ResourceClaim, kubelet और कंटेनर के बीच ज़िम्मेदारी की सीमा को समझते हैं।
- क्या आप मेटाडेटा पाथ, जनरेशन टाइमिंग, माउंटिंग और क्लीनअप लाइफ़साइकिल को निर्दिष्ट कर सकते हैं।
- क्या आप अविश्वसनीय ड्राइवर फ़ील्ड्स, क्रॉस-नोड लीकेज, वर्ज़न संगतता और Pod रीस्टार्ट को संभालते हैं।
- क्या आप alpha को एक स्थिर अनुबंध मानने के बजाय फीचर स्थिति और समर्थित वर्ज़न की जांच करते हैं।
स्पष्टीकरण वाले प्रश्न
- क्या मेटाडेटा डिस्कवरी डेटा है, नेटवर्क कॉन्फ़िगरेशन है, या क्रेडेंशियल जैसी संवेदनशील सामग्री है?
- कौन से फ़ील्ड और स्कीमा वर्ज़न आवश्यक हैं, और क्या एप्लिकेशन गायब या विलंबित डेटा को सहन कर सकता है?
- क्या क्लस्टर और नोड्स DRA डिवाइस मेटाडेटा का समर्थन करते हैं, और क्या ड्राइवर आधिकारिक लाइब्रेरी का उपयोग करता है?
- पुनरावंटन (reallocation), Pod रीस्टार्ट, ड्राइवर अपग्रेड, या नोड विफलता के बाद फ़ाइल को क्या अमान्य करता है?
30-सेकंड का उत्तर
मैं ड्राइवर से केवल वर्तमान ResourceClaim के लिए गैर-संवेदनशील मेटाडेटा एक्सपोज़ करवाऊंगा और kubelet को डिवाइस तैयारी के दौरान वर्ज़न किया हुआ JSON जनरेट करने दूंगा, जिसे एक प्रलेखित पाथ पर केवल-पढ़ने के लिए (read-only) माउंट किया जाएगा। एप्लिकेशन फ़ाइल पढ़ता है, API नहीं; निर्माण, अपडेट, अनमाउंट और क्लीनअप Pod लाइफ़साइकिल का पालन करते हैं। फ़ील्ड और आकार को मान्य करें, और आंशिक फ़ाइलों को एक्सपोज़ करने के बजाय ड्राइवर विफलताओं को अवलोकनीय (observable) बनाएं। चूंकि यह क्षमता alpha है, इसलिए वर्ज़न डिटेक्शन बनाए रखें और पर्यावरण चर (environment variables), प्रोब्स, या पुराने ड्राइवर पाथ के लिए फ़ॉलबैक रखें।
चरण-दर-चरण डिज़ाइन
1. डेटा और ट्रस्ट सीमा को परिभाषित करें
DRA किसी ResourceClaim को एक डिवाइस आवंटित करता है, ड्राइवर भौतिक डिवाइस को जानता है, और एप्लिकेशन परिणाम का उपभोग करता है। मेटाडेटा डिवाइस विशेषताओं या इंटरफ़ेस विवरण तक सीमित होना चाहिए, कभी भी निजी कुंजियाँ, टोकन या क्रॉस-किरायेदार (cross-tenant) पहचानकर्ता नहीं। ड्राइवर इनपुट को क्लेम, रिक्वेस्ट और नोड से बाइंड करें ताकि कोई अन्य डिवाइस Pod में प्रोजेक्ट न हो सके।
2. एक स्थिर डिलीवरी तंत्र का उपयोग करें
दस्तावेज़ीकरण कंटेनर के अंदर एक प्रसिद्ध पाथ और डिवाइस विशेषताओं के लिए JSON फ़ाइलों को परिभाषित करता है। केवल-पढ़ने के लिए माउंट और नियतात्मक (deterministic) डायरेक्टरी स्तरों का उपयोग करें ताकि एप्लिकेशन API से पूछताछ करने के बजाय फ़ाइलें पढ़ें। एक स्कीमा या वर्ज़न फ़ील्ड शामिल करें ताकि एप्लिकेशन अज्ञात वर्ज़न को अस्वीकार कर सकें और संगतता तर्क चुन सकें।
3. लाइफ़साइकिल और विफलता को संभालें
आवंटन और तैयारी सफल होने के बाद ही फ़ाइल बनाएं; इसे अनप्रिपेयर (unprepare), Pod हटाने, या क्लेम रिलीज़ के दौरान हटा दें। जनरेशन, राइट, या JSON-सत्यापन विफलता को आंशिक फ़ाइल को उजागर नहीं करना चाहिए। एक अवलोकनीय ड्राइवर या kubelet त्रुटि की रिपोर्ट करें और एप्लिकेशन को अमान्य डेटा का उपयोग करने से रोकें। रीस्टार्ट के बाद, किसी पुरानी नोड फ़ाइल का पुन: उपयोग करने के बजाय वर्तमान क्लेम से पुन: उत्पन्न करें।
4. अपग्रेड और अवलोकनीयता की योजना बनाएं
ड्राइवर लाइब्रेरी, kubelet, नोड और एप्लिकेशन के लिए एक वर्ज़न मैट्रिक्स का दस्तावेज़ीकरण करें। जनरेशन विलंबता (latency), विफलता दर, स्कीमा अस्वीकृति, ड्राइवर वर्ज़न और Pod रीस्टार्ट की निगरानी करें; मेटाडेटा सामग्री के बिना क्लेम, रिक्वेस्ट और नोड पहचानकर्ताओं को लॉग करें। संगत स्कीमा, फीचर गेट्स और एक परीक्षण किए गए रोलबैक के साथ alpha अपग्रेड को नियंत्रित करें।
मॉडल उच्च-गुणवत्ता वाला उत्तर
मैं डिवाइस मेटाडेटा को DRA आवंटन का केवल-पढ़ने योग्य प्रोजेक्शन बनाऊंगा। ड्राइवर केवल वर्तमान ResourceClaim और नोड के लिए गैर-संवेदनशील विशेषताएँ लिखता है; kubelet उन्हें वर्ज़न किए गए JSON में बदल देता है और डिवाइस की तैयारी के बाद इसे एक प्रसिद्ध पाथ पर केवल-पढ़ने के लिए माउंट करता है। एप्लिकेशन को किसी Kubernetes API अनुमति की आवश्यकता नहीं है। लिखने से पहले, क्लेम, रिक्वेस्ट, नोड बाइंडिंग, एक अनुमति सूची (allowlist) और आकार को मान्य करें; लिखने के बाद, स्कीमा को मान्य करें। विफलता पर, आंशिक फ़ाइल माउंट न करें और एक अवलोकनीय त्रुटि एक्सपोज़ करें। रिलीज़ या Pod हटाने पर क्लीनअप करें और रीस्टार्ट के बाद पुन: उत्पन्न करें। चूंकि यह क्षमता alpha है, इसलिए समर्थन का पता लगाएं, एक फीचर गेट का उपयोग करें, पुराने-पाथ या स्पष्ट-पर्यावरण फ़ॉलबैक को बनाए रखें, और वर्ज़न-पार फ़ाइल स्थिरता का वादा करने के बजाय विफलताओं, विलंबता और ड्राइवर वर्ज़न की निगरानी करें।
सामान्य गलतियाँ
- कंटेनर को Kubernetes API एक्सेस या अत्यधिक व्यापक RBAC देना।
- क्रेडेंशियल या किसी अन्य किरायेदार के डिवाइस डेटा सहित प्रत्येक ड्राइवर फ़ील्ड को उजागर करना।
- वर्ज़न फ़ील्ड, अनुमति सूची और JSON स्कीमा सत्यापन को छोड़ना।
- Pod रीस्टार्ट या क्लेम रिलीज़ के बाद एक पुरानी नोड फ़ाइल को बनाए रखना।
- जनरेशन विफलता के बाद एक खाली फ़ाइल माउंट करना ताकि एप्लिकेशन मान ले कि डिवाइस उपयोग करने योग्य है।
- सभी वर्ज़न में एक alpha सुविधा को एक स्थिर API के रूप में मानना।
अनुवर्ती प्रश्न और उत्तर
सीधे पर्यावरण चर (environment variables) का उपयोग क्यों न करें?
पर्यावरण चर कुछ स्थिर मानों के लिए उपयुक्त होते हैं लेकिन कई डिवाइस, संरचित फ़ील्ड और लाइफ़साइकिल परिवर्तनों के लिए असुविधाजनक होते हैं। केवल-पढ़ने योग्य JSON फ़ाइल संरचना और स्पष्ट वर्ज़न व विफलता शब्दार्थ (semantics) ले जाती है।
आप क्रॉस-किरायेदार लीकेज को कैसे रोकते हैं?
राइट प्राधिकरण सीमा के रूप में क्लेम, रिक्वेस्ट और नोड का उपयोग करें; ड्राइवर को केवल आवंटित डिवाइस लिखने की अनुमति दें, संवेदनशील फ़ील्ड को फ़िल्टर करें, प्रति Pod माउंट को अलग करें, और परीक्षण करें कि कोई अन्य क्लेम अपठनीय है।
आप alpha क्षमता कैसे लॉन्च करेंगे?
क्लस्टर वर्ज़न, फीचर स्थिति, ड्राइवर लाइब्रेरी और kubelet संगतता की पुष्टि करें; फीचर गेट के पीछे एक छोटे नोड पूल को कैनरी करें, एक एप्लिकेशन या ड्राइवर फ़ॉलबैक रखें, और रोलबैक और अलर्टिंग में स्कीमा परिवर्तनों को शामिल करें।