प्रॉम्प्ट और संदर्भ
आप एक Kubernetes GPU प्लेटफ़ॉर्म संचालित करते हैं। ट्रेनिंग और बैच-इन्फरेंस जॉब्स को Pods बनाए जाने से पहले कोटा, नोड रिसोर्सेज, मेंटेनेंस विंडो और सुरक्षा नीति की प्रतीक्षा करनी होगी। Kueue Workloads, ClusterQueues, ResourceFlavors, और AdmissionChecks के साथ एडमिशन डिज़ाइन करें, साथ ही स्टार्वेशन और असुरक्षित रिलीज़ को रोकें।
इंटरव्यूअर क्या जांच रहा है
कतारबद्ध करने (queueing) को एडमिशन से अलग करना: कतार में Workload के प्रवेश करने का अर्थ यह नहीं है कि Pods बनाए जा सकते हैं। एक ClusterQueue रिसोर्स ग्रुप्स और नॉमिनल कोटे से फ्लेवर्स चुनती है, जबकि AdmissionChecks आंतरिक या बाहरी कंट्रोलर्स को रिलीज़ को प्रभावित करने की अनुमति देते हैं। स्टेट कंसिस्टेंसी, निरस्तीकरण (revocation), आंशिक एडमिशन, टेनेंट निष्पक्षता, बैकऑफ़, और ऑडिटेबिलिटी को कवर करें।
पहले पूछे जाने वाले स्पष्टीकरण प्रश्न
रिसोर्सेज और प्राथमिकता
GPU मॉडल, मेमोरी, CPU, टोपोलॉजी, प्रीइम्पशन, टेनेंट प्राथमिकता, कतार निष्पक्षता, और अधिकतम प्रतीक्षा समय स्पष्ट करें। केवल GPU की गिनती करने से गलत क्षमता उत्पन्न हो सकती है जब मेमोरी या टोपोलॉजी फिट नहीं होती है।
बाहरी एडमिशन निर्भरताएं
मेंटेनेंस विंडो, इमेज स्कैनिंग, बजट अनुमोदन, और डेटा एक्सेस के लिए कंट्रोलर्स की पहचान करें। तय करें कि क्या परिणाम पुन: प्रयोज्य (replayable) हैं और क्या टाइमआउट का अर्थ अस्वीकार करना है या प्रतीक्षा करना। प्रत्येक बाहरी चेक के लिए एक ओनर और TTL की आवश्यकता होती है।
विफलता और निरस्तीकरण नीति
परिभाषित करें कि जब नोड्स बदलते हैं, कोटा वापस लिया जाता है, या एडमिशन के बाद नीति रद्द कर दी जाती है तो क्या होता है। डुप्लिकेट रिलीज़ को रोकने के लिए एडमिशन रिकॉर्ड्स, Pod क्रिएशन, और बाहरी चेक्स को एक इडेम्पोटेंट (idempotent) सहसंबंध की आवश्यकता होती है।
30-सेकंड उत्तर रूपरेखा
“एक Workload एक LocalQueue में प्रवेश करता है, और इसकी ClusterQueue रिसोर्स ग्रुप्स, फ्लेवर्स, और कोहोर्ट कोटे का मूल्यांकन करती है। एडमिशन से पहले सभी आवश्यक AdmissionCheckStates का Ready होना अनिवार्य है; Pending कतार में बना रहता है, जबकि Rejected या टाइमआउट एक सीमित पुनः प्रयास या समाप्ति नीति का पालन करता है। एक ट्रेस करने योग्य वर्कलोड स्थिति बनाए रखें, Pods बनाने से पहले रिसोर्सेज और नीति की पुन: जांच करें, और सुरक्षा और निष्पक्षता को मान्य करने के लिए कोटा उपयोग, प्रतीक्षा समय, चेक लेटेंसी, अस्वीकृति, और निरस्तीकरण को मापें।”
चरण-दर-चरण गहन उत्तर
चरण 1: Workload और कतार की सीमाओं को परिभाषित करें
उपयोगकर्ता Job को PodSets, रिसोर्स अनुरोधों, प्राथमिकता, और टेनेंट कतार के साथ एक शेड्यूलेबल Workload में बदलें। एक LocalQueue क्रमबद्ध करती है और प्रतीक्षा करती है; इसे Pods नहीं बनाने चाहिए और न ही ClusterQueue रिसोर्स बाधाओं को बायपास करना चाहिए।
चरण 2: ClusterQueue के माध्यम से ResourceFlavors का चयन करें
ResourceGroups के साथ CPU, मेमोरी, और GPU रिसोर्सेज का वर्णन करें, फिर उपलब्ध नॉमिनल कोटे के साथ एक फ्लेवर संयोजन चुनें। फ्लेवर बाधाओं में GPU मॉडल, क्षेत्र (region), नोड लेबल, और टोपोलॉजी डालें ताकि “पर्याप्त GPUs” एक गलत एडमिशन न बन जाए।
चरण 3: AdmissionCheck स्टेट मशीन को ऑर्केस्ट्रेट करें
अवलोकन योग्य Pending, Ready, Rejected, और टर्मिनल स्थितियों को प्रदर्शित करें। सुरक्षा, मेंटेनेंस, और बजट कंट्रोलर्स Workload UID का उपयोग करके स्थिति को इडेम्पोटेंट तरीके से अपडेट करते हैं। Kueue केवल तभी अनुमति देता है जब प्रत्येक आवश्यक चेक Ready हो; Pending को गलत तरीके से विफलता के रूप में लेबल नहीं किया जाना चाहिए, और Rejected को चुपचाप अनदेखा नहीं किया जा सकता है।
चरण 4: आंशिक एडमिशन और रिसोर्स परिवर्तनों को संभालें
यदि आंशिक एडमिशन की अनुमति है, तो रिड्यूसिबल PodSet समानांतरता, न्यूनतम आकार, और बाद के विस्तार नियमों को परिभाषित करें। कोटा रिलीज़ या नोड विफलता के बाद फ्लेवर्स और चेक्स का पुनर्मूल्यांकन करें; कभी भी एक्सपायर हो चुके एडमिशन स्नैपशॉट का पुन: उपयोग न करें। स्थायी रूप से अव्यवहार्य अनुरोधों के लिए अनंत पुनः प्रयासों के बजाय एक व्याख्यात्मक अस्वीकृति की आवश्यकता होती है।
चरण 5: निष्पक्षता बनाए रखें और स्टार्वेशन को रोकें
टेनेंट्स, कतारों, और प्राथमिकताओं में कोहोर्ट शेयरिंग और बॉरोइंग सीमाओं को परिभाषित करें। उच्च-प्राथमिकता वाले जॉब्स को अनिश्चित काल तक दुर्लभ GPUs पर कब्जा करने से रोकें; कम प्राथमिकताओं के लिए प्रतीक्षा या एजिंग (aging) नियम जोड़ें। कोटा आवंटन, चेक प्रतीक्षा, और वास्तविक Pod स्टार्टअप को अलग से मापें ताकि धीमे स्टार्टअप के साथ तेज़ एडमिशन स्पष्ट रूप से दिखाई दे।
चरण 6: निरस्तीकरण, पुनः प्रयास, और ऑडिट डिज़ाइन करें
कंट्रोलर टाइमआउट या विफलता के लिए जिटर्ड बैकऑफ़ और पुनः प्रयास सीमाओं का उपयोग करें। निरस्तीकरण को केवल एक फ़ील्ड बदलने के बजाय Workload और PodSets में सुरक्षित रूप से प्रसारित होना चाहिए। कर्ता (actor), समय, कारण, फ्लेवर, कोटा वर्शन, और बाहरी-चेक वर्शन को रिकॉर्ड करें ताकि निर्णय पुन: प्रयोज्य हों।
चरण 7: ऑब्ज़र्वेबिलिटी और विफलता अभ्यासों को मान्य करें
कतार प्रतीक्षा, एडमिशन लेटेंसी, प्रत्येक चेक की Pending अवधि, अस्वीकृति, निरस्तीकरण, कोटा उपयोग, फ्लेवर चयन, निष्क्रिय GPUs, और Pod स्टार्टअप की निगरानी करें। यह साबित करने के लिए कि सिस्टम न तो असुरक्षित रूप से रिलीज़ करता है और न ही हमेशा के लिए अटका रहता है, कंट्रोलर आउटेज, डुप्लिकेट कॉलबैक, कोटा रिक्लेमेशन, नोड विफलता, और नेटवर्क विभाजन का अभ्यास (drill) करें।
उच्च-गुणवत्ता वाला नमूना उत्तर
मैं Workload को एक LocalQueue में रखूंगा, ClusterQueue को फ्लेवर्स और कोहोर्ट कोटे से एक व्यवहार्य रिसोर्स संयोजन का चयन करने दूंगा, और सुरक्षा, मेंटेनेंस, और बजट शर्तों के लिए AdmissionChecks का उपयोग करूंगा। केवल तभी अनुमति दें जब प्रत्येक आवश्यक चेक Ready हो और रिसोर्स स्नैपशॉट अभी भी मान्य हो; Pending कतार में रहता है और Rejected या टाइमआउट सीमित बैकऑफ़ का उपयोग करता है। GPU मॉडल, टोपोलॉजी, और क्षेत्र फ्लेवर्स से संबंधित हैं। टेनेंट कोटा और एजिंग निष्पक्षता की रक्षा करते हैं, जबकि इडेम्पोटेंट कॉलबैक और निरस्तीकरण Workload और PodSets में सुरक्षित रूप से प्रसारित होते हैं।
सामान्य गलतियाँ
- गलती: कतार में प्रवेश को Pods बनाने की अनुमति मानना। → यह क्यों विफल होता है: कतारबद्ध करना और एडमिशन अलग-अलग स्थितियाँ हैं। → सुधार: ClusterQueue आवंटन और सभी चेक्स के Ready होने की आवश्यकता रखें।
- गलती: केवल GPU गणना द्वारा रिसोर्सेज का चयन करना। → यह क्यों विफल होता है: मॉडल, मेमोरी, टोपोलॉजी, या क्षेत्र उपयुक्त नहीं हो सकते हैं। → सुधार: ResourceFlavors के साथ हार्डवेयर बाधाओं को व्यक्त करें।
- गलती: Pending चेक का हमेशा के लिए पुनः प्रयास करना। → यह क्यों विफल होता है: स्थायी अव्यवहार्यता या कंट्रोलर विफलता छिपी रहती है। → सुधार: सीमाओं और बैकऑफ़ के साथ Pending, Rejected, और कारणों में अंतर करें।
- गलती: केवल एक Workload फ़ील्ड को रद्द करना। → यह क्यों विफल होता है: मौजूदा Pods रिसोर्सेज का उपभोग करना जारी रख सकते हैं। → सुधार: PodSet कार्रवाई, ऑडिट, और रोलबैक व्यवहार को परिभाषित करें।
फॉलो-अप प्रश्न और उत्तर
फॉलो-अप 1: AdmissionCheck एक Kubernetes Admission Webhook से कैसे भिन्न है?
AdmissionCheck यह निर्धारित करने के लिए Kueue की व्यावसायिक स्थिति है कि क्या कोई Workload शुरू हो सकता है। एक वेबहुक API अनुरोध पथ का विस्तार करता है। वे सहयोग कर सकते हैं, लेकिन वेबहुक पास होने का अर्थ यह नहीं है कि रिसोर्सेज आवंटित किए गए हैं।
फॉलो-अप 2: ResourceFlavors की आवश्यकता क्यों है?
समान GPU गणना विभिन्न मॉडलों, क्षेत्रों, या टोपोलॉजी का प्रतिनिधित्व कर सकती है। एक फ्लेवर उन शेड्यूलेबल विशेषताओं को रिसोर्स-ग्रुप कोटे से बांधता है, जिससे चयन व्याख्या योग्य और सुरक्षित हो जाता है।
फॉलो-अप 3: आप डुप्लिकेट कॉलबैक को स्थिति को पीछे ले जाने से कैसे रोकते हैं?
Workload UID, चेक नाम, और वर्शन को एक इडेम्पोटेंसी कुंजी के रूप में उपयोग करें। पुराने वर्शन को अस्वीकार करें और सुनिश्चित करें कि बार-बार Ready अपडेट Pod के दूसरे क्रिएशन को ट्रिगर न कर सकें।
फॉलो-अप 4: किसी अनुरोध को Pending रखने के बजाय कब अस्वीकार किया जाना चाहिए?
जब इसका रिसोर्स फ्लेवर, नीति, या बजट कभी संतुष्ट नहीं हो सकता है, तो इसे अस्वीकार करें और कारण प्रदान करें। अस्थायी नोड की कमी, मेंटेनेंस विंडो, या कंट्रोलर पुनः प्रयास Pending रह सकते हैं, लेकिन इसके लिए अधिकतम प्रतीक्षा समय और अलर्ट की आवश्यकता होती है।