सिस्टम डिज़ाइन इंटरव्यू: GPU विफलताओं को नियंत्रित करने के लिए आप Kubernetes डिवाइस हेल्थ का उपयोग कैसे करेंगे?

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

एक मल्टी-टेनेंट GPU इन्फरेंस प्लेटफ़ॉर्म Kubernetes Device Plugins और Dynamic Resource Allocation (DRA) का उपयोग करता है। जब कोई ड्राइवर डिस्कनेक्ट हुए कार्ड का पता लगाता है, तो पुराना सिस्टम त्रुटि को केवल नोड लॉग में दिखाता है; Pod पुनरारंभ (restart) होता है और बार-बार उसी डिवाइस का दावा करता है। Pod .status में allocatedResourcesStatus के आसपास विफलता नियंत्रण (failure governance) डिज़ाइन करें: ऑपरेटरों और कंट्रोलरों को डिवाइस की स्थिति देखनी चाहिए, खराब कार्डों को क्वारंटाइन करना चाहिए, Unknown को सुरक्षित रूप से संभालना चाहिए, और एक क्षणिक सिग्नल के कारण बड़े पैमाने पर विलोपन (mass deletion) से बचना चाहिए।

Kubernetes v1.36 संसाधन स्वास्थ्य स्थिति (resource health status) को बीटा में प्रमोट करता है। आधिकारिक रिलीज़ नोट्स में कहा गया है कि Pod स्थिति आवंटित उपकरणों के स्वास्थ्य की रिपोर्ट करती है और kubectl describe pod Unhealthy या Unknown को उजागर कर सकता है; यह तंत्र पारंपरिक Device Plugins और DRA दोनों मार्गों को कवर करता है।

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

• क्या आप आवंटन सफलता (allocation success), डिवाइस स्वास्थ्य, कंटेनर तैयारी (container readiness), और व्यावसायिक SLO में अंतर कर सकते हैं?
• क्या आप ड्राइवर, kubelet, Pod स्थिति, कंट्रोलर, शेड्यूलर और अलर्टिंग के बीच डेटा प्रवाह तैयार कर सकते हैं?
• क्या आप लापता अवलोकन को एक गंभीर विफलता में बदलने के बजाय Unhealthy और Unknown के साथ अलग-अलग व्यवहार कर सकते हैं?
• क्या आप इडेम्पोटेंट क्वारंटाइन, लीज, पुनः प्रयास (retries), दर सीमाएं (rate limits), और रिकवरी के बाद पुन: प्रवेश डिज़ाइन कर सकते हैं?
• क्या आप यह समझा सकते हैं कि स्थिति एक नैदानिक संकेत (diagnostic signal) है, न कि शेड्यूलिंग नीति या व्यावसायिक जांच का स्वचालित प्रतिस्थापन?

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

• कौन से ड्राइवर स्वास्थ्य स्थिति उत्पन्न करते हैं, और उनके अपडेट विलंब तथा हार्टबीट अवधि क्या हैं?
• एक Pod में कई कार्ड हो सकते हैं; यदि कोई एक विफल हो जाता है, तो क्या कार्य आंशिक रूप से ख़राब (degrade) हो सकता है या इसे एक इकाई के रूप में माइग्रेट होना चाहिए?
• क्या Unknown का अर्थ क्षणिक डिस्कनेक्ट, नोड आउटेज, या असमर्थित ड्राइवर व्यवहार है? सहनशीलता विंडो (tolerance window) क्या है?
• क्या क्वारंटाइन प्रति डिवाइस, नोड, ResourceClaim, या टेनेंट वर्कलोड के अनुसार है, और इसे कौन हटा सकता है?
• क्या जॉब्स में चेकपॉइंट, इडेम्पोटेंट कमिट, और पुनः प्रयास बजट (retry budget) है? माइग्रेशन से कितना GPU चर्न (churn) हो सकता है?

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

"मैं डिवाइस स्वास्थ्य को स्थिति इनपुट के रूप में मानूंगा, न कि Pod हटाने के कमांड के रूप में। ड्राइवर और kubelet द्वारा allocatedResourcesStatus अपडेट करने के बाद, एक कंट्रोलर डिवाइस ID द्वारा डेटा एकत्र करता है: Unhealthy क्वारंटाइन और अलर्टिंग में जाता है, जबकि Unknown को पहले हार्टबीट सहनशीलता विंडो मिलती है। इडेम्पोटेंसी कुंजियाँ और लीज नए आवंटन को रोकते हैं, और चेकपॉइंट किए गए जॉब्स प्रति-नोड दर सीमाओं के साथ माइग्रेट होते हैं। रिकवरी रिलीज से पहले एक जांच और एक छोटा कैनरी चलाती है। मैं स्थिति की आयु (state age), गलत क्वारंटाइन, माइग्रेशन सफलता, और व्यावसायिक SLO को मान्य करूंगा।"

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

1. स्टेट मॉडल को परिभाषित करें। डिवाइस की पहचान, Pod, कंटेनर, ResourceClaim, नोड, स्वास्थ्य मान, संदेश, अवलोकन समय और स्थिति संस्करण रिकॉर्ड करें। Unhealthy (पुष्ट विफलता) को Unknown (अपुष्ट) से अलग रखें ताकि एक बूलियन हर ऑटोमेशन को संचालित न करे।

1. डेटा प्रवाह का निर्माण करें। DRA या Device Plugin किसी Pod को एक डिवाइस आवंटित करता है; kubelet ड्राइवर द्वारा रिपोर्ट किए गए स्वास्थ्य को Pod स्थिति में लिखता है। एक स्टेटस ऑब्जर्वर Pod परिवर्तनों पर नज़र रखता है, डिवाइस कुंजी द्वारा डिडुप्लिकेट करता है, और एक पुनः चलाने योग्य (replayable) डिवाइस डायरेक्टरी लिखता है। एपीआई को स्वतंत्र रूप से स्कैन करने के बजाय अलर्टिंग और कंट्रोलर उस डायरेक्टरी को पढ़ते हैं।

1. नए आवंटन को क्वारंटाइन करें। पुष्ट अस्वस्थ डिवाइस के लिए, एक आंतरिक क्वारंटाइन रिकॉर्ड बनाएं और इसे शेड्यूलर एक्सटेंशन, ResourceClaim चयन, या नोड-क्षमता दृश्यों से बाहर करें। Pod स्थिति को संपादित न करें या किसी एक घटना को तुरंत Node NotReady में न बदलें। क्वारंटाइन कार्रवाई के लिए एक कारण, कर्ता और समाप्ति समय की आवश्यकता होती है।

1. चल रहे कार्यों को संभालें। माइग्रेशन लीज प्राप्त करने से पहले कंट्रोलर चेकपॉइंट और इडेम्पोटेंट कमिट की जांच करता है। एक पुनर्प्राप्त करने योग्य कार्य नए अनुरोधों को रोकता है, एक चेकपॉइंट सहेजता है, डिवाइस को रिलीज़ करता है, और एक स्वस्थ डिवाइस पर पुनर्निर्माण करता है। एक अप्राप्य कार्य साक्ष्य सुरक्षित रखता है और टेनेंट को सूचित करता है। केवल एक माइग्रेशन प्रवाह किसी डिवाइस और कार्य का स्वामी हो सकता है।

1. Unknown को सुरक्षित करें। Unknown kubelet, ड्राइवर, या नोड नेटवर्क रुकावट से आ सकता है। हार्टबीट-आधारित सहनशीलता विंडो और घातीय बैकऑफ़ लागू करें; विंडो के दौरान अलर्ट करें और इसके समाप्त होने के बाद ही आवंटन प्रतिबंधित करें। पूरे नोड के आउटेज के लिए, एकल Pod स्थिति से यह अनुमान लगाने के बजाय कि प्रत्येक डिवाइस टूट गया है, नोड लीज और मौजूदा विफलता पहचान का उपयोग करें।

1. रिकवर करें और सत्यापित करें। जब कोई डिवाइस फिर से स्वस्थ रिपोर्ट करता है, तो क्वारंटाइन जारी करने से पहले एक ड्राइवर जांच, एक छोटा कार्य, और एक स्थिरता विंडो चलाएं। स्थिति आयु, Unknown अवधि, गलत क्वारंटाइन दर, माइग्रेशन सफलता, निष्क्रिय GPU समय, और व्यावसायिक त्रुटियों को ट्रैक करें। डुप्लिकेट और आउट-ऑफ़-ऑर्डर घटनाओं को दोबारा चलाएं और रिकवरी का परीक्षण करने के लिए कंट्रोलर को पुनरारंभ करें।

Device health event
  -> Pod status observer
  -> deduplicate by (node, deviceID, statusVersion)
  -> device quarantine record with lease and expiry
  -> scheduler/claim filter excludes unhealthy device
  -> checkpointed workload migration
  -> probe + canary
  -> release quarantine

मॉडल उत्तर

मैं ड्राइवर, kubelet, Pod, ResourceClaim, और कार्य को जोड़ने वाली एक डिवाइस-स्तरीय स्थिति डायरेक्टरी बनाऊंगा। Unhealthy एक पुष्ट विफलता है, इसलिए मैं समाप्ति समय के साथ एक लीज-समर्थित क्वारंटाइन बनाता हूं, नए आवंटन को रोकता हूं और अलर्ट करता हूं। Unknown पहले एक हार्टबीट सहनशीलता विंडो में प्रवेश करता है और विंडो समाप्त होने के बाद ही आवंटन को प्रतिबंधित करता है। ऑब्जर्वर डिवाइस ID द्वारा डिडुप्लिकेट करता है, और एक पुनरारंभ किया गया कंट्रोलर इन-मेमोरी फ़्लैग के बजाय स्थायी घटनाओं और रिकॉर्ड से पुनर्निर्माण करता है।

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

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

• लक्षण: स्थिति Unknown होने पर प्रत्येक Pod को हटाना → यह क्यों विफल होता है: एक क्षणिक अवलोकन अंतराल क्लस्टर चर्न बन जाता है → सुधार: लीज, हार्टबीट विंडो और दर सीमाओं का उपयोग करें।
• लक्षण: केवल नोड को क्वारंटाइन करना और डिवाइस पहचान को छोड़ना → यह क्यों विफल होता है: एक खराब कार्ड अपने साथ स्वस्थ उपकरणों को भी ले जाता है → सुधार: डिवाइस और ResourceClaim द्वारा रिकॉर्ड को कुंजीबद्ध करें, केवल तभी नोड स्तर पर जाएं जब उचित हो।
• लक्षण: डिवाइस को स्वस्थ दिखाने के लिए Pod स्थिति को संपादित करना → यह क्यों विफल होता है: सत्य का स्रोत दूषित हो जाता है और रिकवरी गलत हो सकती है → सुधार: kubelet स्थिति को सुरक्षित रखें और अलग से एक ऑडिट करने योग्य क्वारंटाइन स्थिति बनाएं।
• लक्षण: पुनर्प्राप्त डिवाइस को तुरंत पूर्ण लोड पर लौटाना → यह क्यों विफल होता है: एक क्षणिक रिकवरी या अस्थिर ड्राइवर फिर से विफल हो सकता है → सुधार: जांचें, कैनरी चलाएं, फिर धीरे-धीरे लोड बढ़ाएं।

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

एक GPU विफल हो गया लेकिन Pod के पास अन्य GPU हैं। क्या कार्य का केवल एक भाग माइग्रेट होना चाहिए?

पहले सत्यापित करें कि क्या फ्रेमवर्क डायनामिक संकुचन (dynamic shrink) और रीबाइंडिंग का समर्थन करता है। यदि मॉडल को निश्चित डिवाइस टोपोलॉजी की आवश्यकता है, तो पूरे कार्य को माइग्रेट करें। यदि यह शार्ड हो सकता है, तो शेष उपकरणों के लिए ResourceClaim और चेकपॉइंट सिमेंटिक्स को संरक्षित करते हुए केवल प्रभावित शार्ड को स्थानांतरित करें।

मान Healthy है लेकिन स्थिति संदेश पुराना है। आप क्या करेंगे?

स्वास्थ्य मान को स्थिति की आयु से अलग करें। हार्टबीट सीमा के बाद, बासी Healthy को वर्तमान प्रमाण के रूप में मानने के बजाय Unknown में स्थानांतरित करें; अलर्टिंग और शेड्यूलिंग सुरक्षा उपाय आयु का उपयोग करते हैं।

आप एकाधिक कंट्रोलरों को एक ही कार्य को माइग्रेट करने से कैसे रोकते हैं?

समाप्ति लीज या आशावादी संस्करण अपडेट (optimistic version update) के साथ डिवाइस ID, जॉब ID और स्थिति संस्करण से बनी इडेम्पोटेंसी कुंजी का उपयोग करें। जो कंट्रोलर लीज खो देता है वह रुक जाता है, और एक प्रतिस्थापन कंट्रोलर स्थायी रिकॉर्ड से कार्य फिर से शुरू करता है।

डिवाइस क्षमता पूल (capacity pool) में कब वापस आ सकता है?

एक स्वस्थ ड्राइवर रिपोर्ट आवश्यक है लेकिन पर्याप्त नहीं है। एक डिवाइस जांच, एक छोटा कार्य, एक स्थिरता विंडो, और एक बंद क्वारंटाइन कारण की आवश्यकता होती है; कोई भी विफलता क्वारंटाइन को बढ़ाती है और मैन्युअल जबरन-रिलीज़ को अवरुद्ध करती है।

संदर्भ

• Kubernetes v1.36: Haru
• Kubernetes v1.36: More Drivers, New Features, and the Next Era of DRA
• Kubernetes v1.34: Pods Report DRA Resource Health
• Dynamic Resource Allocation दस्तावेज़

इंटरव्यू चेकलिस्ट

ड्राइवर-टू-Pod-स्थिति, ऑब्जर्वर, क्वारंटाइन और शेड्यूलिंग-फ़िल्टर प्रवाह बनाएं। Unhealthy को Unknown से अलग करें, फिर लीज, चेकपॉइंट, दर सीमाएं, रिकवरी कैनरी और मेट्रिक्स जोड़ें।

एक-पंक्ति का निष्कर्ष (Takeaway)

डिवाइस स्वास्थ्य Kubernetes में हार्डवेयर विफलताओं को देखने योग्य बनाता है, लेकिन सुरक्षित रिकवरी के लिए अभी भी डिवाइस-स्तरीय क्वारंटाइन, Unknown सुरक्षा उपाय, इडेम्पोटेंट माइग्रेशन और चरणबद्ध पुन: उपयोग की आवश्यकता होती है।