सिस्टम डिज़ाइन इंटरव्यू: Kubernetes DRA के साथ व्याख्या योग्य डिवाइस प्राथमिकताएं और फ़ॉलबैक्स

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

आप ट्रेनिंग और इन्फरेंस जॉब्स के लिए एक Kubernetes क्लस्टर के मालिक हैं। नोड्स में H100s, A100s और छोटे एक्सेलेरेटर शामिल हैं। जब क्षमता अनुपलब्ध हो, तो एक वर्कलोड पहले H100, फिर A100 और उसके बाद किसी अन्य कम्पैटिबल डिवाइस को प्राथमिकता देता है। डिटरमिनिज्म, निष्पक्षता, विफलताओं, ऑब्जर्वेबिलिटी, माइग्रेशन और रोलबैक को कवर करते हुए Dynamic Resource Allocation (DRA) अनुरोध और शेड्यूलिंग फ्लो डिज़ाइन करें। एक सीनियर इंजीनियर के रूप में उत्तर दें जो आर्किटेक्चरल ट्रेड-ऑफ़ तय कर सकता है।

इंटरव्यूअर क्या जांचता है

• क्या प्राथमिकता क्लाइंट-साइड पोलिंग या हार्ड-कोडेड क्लेमिंग के बजाय एक सत्यापन योग्य (verifiable) पॉलिसी है।
• ResourceClaim, ResourceSlice, ड्राइवर और शेड्यूलर के लाइफसाइकिल की समझ।
• डिटरमिनिस्टिक टाई-ब्रेकिंग, हेल्थ में बदलाव, पुनः प्रयास (retries) और टाइमआउट्स।
• निष्पक्ष क्षमता आवंटन, टेनेंट आइसोलेशन, मेट्रिक्स और ऑडिटेबिलिटी।
• डिवाइस प्लगइन्स से DRA तक एक रिवर्सिबल माइग्रेशन पाथ।

स्पष्ट करने योग्य प्रश्न

1. क्या कोई भी उपलब्ध फ़ॉलबैक स्वीकार्य है, या मेमोरी, आर्किटेक्चर और ड्राइवर क्षमता को हार्ड कंस्ट्रेंट्स (कठोर बाधाएं) बने रहना चाहिए?
2. क्या एक Pod अलग-अलग डिवाइस मॉडल स्वीकार कर सकता है? क्या टोपोलॉजी, NUMA और नेटवर्क बैंडविड्थ हार्ड कंस्ट्रेंट्स हैं?
3. क्या व्यवसाय को एक सख्त मॉडल गारंटी की आवश्यकता है, या यह सफलता दर और लागत के लिए मॉडल प्राथमिकता से समझौता कर सकता है?
4. क्या टेनेंट्स के पास कोटा, प्राथमिकताएं और प्रीएम्पशन नियम हैं? किसी अस्वस्थ (unhealthy) डिवाइस को उम्मीदवारों से कब हटाया जाता है?
5. क्या मौजूदा वर्कलोड्स ResourceClaims को अपना सकते हैं, और क्या माइग्रेशन के दौरान पुराने डिवाइस प्लगइन्स का सह-अस्तित्व होना चाहिए?

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

मैं डिवाइस प्राथमिकता को एक DRA अनुरोध में क्रमबद्ध उम्मीदवारों और हार्ड कंस्ट्रेंट्स के रूप में एनकोड करूँगा, जिससे क्लाइंट द्वारा नोड्स को पोल करने के बजाय शेड्यूलर क्लेम लाइफसाइकिल के दौरान संसाधनों का मिलान कर सके। शेड्यूलर पहले ड्राइवर, आर्किटेक्चर, टोपोलॉजी और टेनेंट-कोटा कंस्ट्रेंट्स को फ़िल्टर करता है, फिर क्रम में H100, A100 और अन्य कम्पैटिबल डिवाइसेस का मूल्यांकन करता है। प्रत्येक टियर एक स्थिर टाई-ब्रेकर का उपयोग करता है, और इवेंट्स तथा मेट्रिक्स उम्मीदवारों, अस्वीकृति के कारणों और अंतिम चयन को रिकॉर्ड करते हैं। हेल्थ में बदलाव या बाइंडिंग विफलताएं केवल तभी पुनर्मूल्यांकन ट्रिगर करती हैं जब क्लेम पुनः प्रयास योग्य (retryable) हो। कतार कोटा और टेनेंट वेट निष्पक्षता प्रदान करते हैं। माइग्रेशन डुअल-ट्रैक कैनरी, वर्ज़न किए गए ResourceClaim टेम्प्लेट्स और पुराने प्लगइन पर वापस स्विच करने की व्यवस्था का उपयोग करता है।

चरण-दर-चरण गहन विश्लेषण

1. प्राथमिकता मॉडल को परिभाषित करें

मॉडल क्रम को एक सॉफ्ट प्राथमिकता (soft preference) मानें। ड्राइवर वर्ज़न, आर्किटेक्चर, मेमोरी फ्लोर, टोपोलॉजी और आइसोलेशन को हार्ड कंस्ट्रेंट्स मानें। अनुरोध में "पहले H100, दूसरे स्थान पर A100" कहा जा सकता है, लेकिन फ़ॉलबैक को मेमोरी या टेनेंट कोटा को बायपास नहीं करना चाहिए। ऑडिट और रोलबैक के लिए एक वर्ज़न किया गया पॉलिसी आइडेंटिफ़ायर शामिल करें।

apiVersion: resource.k8s.io/v1
kind: ResourceClaimTemplate
spec:
  spec:
    devices:
      requests:
      - name: accelerator
        exactly:
          deviceClassName: gpu
          selectors:
          - cel: "device.attributes['model'] == 'H100'"
          - cel: "device.attributes['model'] == 'A100'"

क्रमबद्ध उम्मीदवार व्यावसायिक प्राथमिकता व्यक्त करते हैं; परिनियोजन (deployment) को अभी भी क्लस्टर द्वारा समर्थित DRA API वर्ज़न और ड्राइवर क्षमताओं से मेल खाना चाहिए।

2. रिसोर्स क्लेम और शेड्यूलिंग फ्लो

Pod एक क्लेम बनाने के लिए ResourceClaimTemplate का उपयोग करता है। एक DRA ड्राइवर ResourceSlices प्रकाशित करता है जिसमें डिवाइस विशेषताएँ, क्षमता और हेल्थ शामिल होती हैं। प्री-फ़िल्टरिंग के दौरान, शेड्यूलर क्लेम्स और स्लाइस को पढ़ता है, हार्ड कंस्ट्रेंट्स को सत्यापित करता है और क्रम में उम्मीदवारों की खोज करता है। बाइंडिंग के बाद, ड्राइवर कंटेनर को आवंटन प्रदान करता है। क्लेम्स को आइडम्पोटेंट (idempotent) होना चाहिए ताकि पुनः प्रयास ऐसा दूसरा आवंटन न बना सकें जिसे पुनः प्राप्त न किया जा सके।

3. डिटरमिनिस्टिक चयन और व्याख्या

जब किसी टियर में कई डिवाइसेस हों, तो रिसोर्स पूल, ResourceSlice नाम और डिवाइस आइडेंटिफ़ायर पर आधारित एक स्थिर क्रम, या एक स्पष्ट क्षमता और टोपोलॉजी रैंकिंग का उपयोग करें। इस नियम को इंटरफ़ेस अनुबंध (contract) का हिस्सा बनाएं। उम्मीदवारों, फ़िल्टर्स, अस्वीकृति के कारणों, अंतिम डिवाइस और पॉलिसी वर्ज़न को रिकॉर्ड करें। समान इनपुट्स को दोबारा चलाने पर समान परिणाम मिलना चाहिए, और एक ऑपरेटर यह समझा सके कि H100 को क्यों छोड़ा गया था।

4. विफलता, हेल्थ और पुनः प्रयास व्यवहार

नए क्लेम्स को अस्वस्थ चिह्नित किए गए डिवाइसेस को छोड़ देना चाहिए; पहले से बाउंड वर्कलोड्स समाप्ति (termination), माइग्रेशन या पुनः निर्माण के लिए रनटाइम और कंट्रोलर पॉलिसी का पालन करते हैं। बाइंडिंग विवादों, बासी (stale) स्लाइस और नोड हानि को पुनः प्रयास योग्य या टर्मिनल के रूप में वर्गीकृत करें। शेड्यूलर लोड को बढ़ाने वाले बार-बार के स्कैन्स से बचने के लिए पुनः प्रयासों को बैकऑफ़ और एक आइडम्पोटेंसी कुंजी की आवश्यकता होती है। A100 पर फ़ॉलबैक केवल तभी मान्य है जब हार्ड कंस्ट्रेंट्स अभी भी लागू हों, और वास्तविक मॉडल Pod स्थिति में दिखाई देना चाहिए।

5. निष्पक्षता, क्षमता और ऑब्जर्वेबिलिटी

प्राथमिकता ऐसा पास नहीं बननी चाहिए जो H100s को अनिश्चित काल के लिए आरक्षित कर दे। कतार-स्तरीय मध्यस्थता (arbitration) टेनेंट कोटा, वेट और प्रतीक्षा समय का उपयोग करती है; डिवाइस-स्तरीय चयन उम्मीदवार क्रम का पालन करता है। मॉडल द्वारा अनुरोध मात्रा, फ़ॉलबैक दर, प्रतीक्षा समय, बाइंडिंग विफलताएं, हेल्थ परिवर्तन, टेनेंट उपयोग और पॉलिसी हिट दर को ट्रैक करें। लॉग में संवेदनशील टेनेंट डेटा से बचते हुए इवेंट्स में एक पठनीय निर्णय श्रृंखला बनाए रखें।

6. माइग्रेशन और रोलबैक

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

मॉडल उत्तर

मैं प्राथमिकता, कंस्ट्रेंट्स और आवंटन प्रमाण को अलग रखूंगा। प्राथमिकता एक क्रमबद्ध उम्मीदवार सूची है। कंस्ट्रेंट्स मॉडल क्षमता, मेमोरी, ड्राइवर, टोपोलॉजी, टेनेंट कोटा और आइसोलेशन को कवर करते हैं। Pod द्वारा ResourceClaim बनाने के बाद, DRA ड्राइवर ResourceSlices प्रकाशित करता है और शेड्यूलर क्रम में उम्मीदवारों का चयन करने से पहले हार्ड कंस्ट्रेंट्स को फ़िल्टर करता है। एक स्थिर रिसोर्स-पूल और डिवाइस-आइडेंटिफ़ायर क्रम टाई को हल करता है, जिससे रीप्ले डिटरमिनिस्टिक बनता है। इवेंट्स में उम्मीदवार, अस्वीकृति के कारण, पॉलिसी वर्ज़न और वास्तविक मॉडल शामिल होते हैं।

विफलता पथ अस्वस्थ डिवाइसेस, बाइंडिंग विवादों, बासी क्लेम्स और नोड हानि के बीच अंतर करते हैं। केवल पुनः प्रयास योग्य त्रुटियां बैकऑफ़ का उपयोग करती हैं; फ़ॉलबैक कभी भी हार्ड कंस्ट्रेंट को पार नहीं करता है, और अंतिम मॉडल स्थिति (status) में लिखा जाता है। टेनेंट कोटा, कतार वेट और प्रतीक्षा समय निष्पक्षता की रक्षा करते हैं ताकि H100 प्राथमिकता अन्य टेनेंट्स को भूखा न रखे (starvation से बचाए)। माइग्रेशन वर्ज़न किए गए टेम्प्लेट्स और एक परीक्षण किए गए रोलबैक स्विच के साथ पुराने प्लगइन्स और DRA को कैनरी में चलाता है।

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

• बिना हार्ड कंस्ट्रेंट्स या इन-टियर टाई-ब्रेकर के केवल "मॉडल के आधार पर क्रमबद्ध करें" कहना।
• क्लेम्स और शेड्यूलर को दरकिनार करते हुए, क्लाइंट्स को सीधे नोड्स स्कैन करने या डिवाइसेस का दावा करने की अनुमति देना।
• हेल्थ परिवर्तनों, बाइंडिंग विवादों और असंतुष्ट कंस्ट्रेंट्स को अनंत पुनः प्रयासों के रूप में मानना।
• टेनेंट निष्पक्षता, कोटा और प्रतीक्षा समय की अनदेखी करते हुए केवल H100 हिट दर को अनुकूलित करना।
• पुराने डिवाइस प्लगइन्स को एक ही चरण में हटा देना, जिससे कोई त्वरित रोलबैक न बचे।
• केवल अंतिम डिवाइस को रिकॉर्ड करना और उम्मीदवार तथा अस्वीकृति के साक्ष्य को खो देना।

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

यदि H100 और A100 दोनों बाधाओं को पूरा करते हैं, तो यादृच्छिक (randomly) रूप से क्यों न चुनें?

यादृच्छिक चयन पुनरुत्पादन क्षमता (replayability) और निदान को कमजोर करता है। क्षमता संतुलन एक स्थिर क्रम का पालन कर सकता है, लेकिन नियम को व्याख्या योग्य और अवलोकनीय रहना चाहिए; एक यादृच्छिक सीड को एक छिपा हुआ अनुबंध नहीं बनना चाहिए।

क्या होगा यदि कोई डिवाइस प्री-फ़िल्टरिंग के बाद लेकिन बाइंडिंग से पहले अस्वस्थ हो जाता है?

बाइंडिंग के समय वर्ज़न और हेल्थ की दोबारा जांच करें। एक वर्गीकृत त्रुटि लौटाएं और बैकऑफ़ के साथ केवल तभी पुनः प्रयास करें जब क्लेम मान्य रहे और उम्मीदवार मौजूद हों; अन्यथा Pod पर एक स्पष्ट असंतोषजनक कारण प्रदर्शित करें।

आप कैसे साबित करेंगे कि फ़ॉलबैक ने निष्पक्षता को नुकसान नहीं पहुँचाया?

प्रत्येक टेनेंट और मॉडल के अनुसार प्रतीक्षा समय, उपयोग, फ़ॉलबैक दर और कतार हिस्सेदारी को मापें, फिर रीप्ले और कैनरी कोहोर्ट्स की तुलना करें। यदि किसी टेनेंट को शायद ही कभी अपनी पहली पसंद मिलती है, तो अनुरोध प्राथमिकता को लगातार बढ़ाने के बजाय कोटा या वेट को समायोजित करें।