प्रॉम्प्ट और उपयोग का मामला (Use case)
एक बैच प्लेटफ़ॉर्म एक साथ हज़ारों Pods बनाता है, लेकिन इमेजिस, कोटा, टोपोलॉजी या बाहरी संसाधन तैयार नहीं हैं। एक ऐसा तंत्र डिज़ाइन करें जो Pods को तुरंत Kubernetes शेड्यूलर के पास भेजे बिना बनाता है, और फिर स्थितियाँ पूरी होने पर उन्हें रिलीज़ करता है। यह स्पष्ट करें कि अमान्य Pending Pods पर शेड्यूलर और Cluster Autoscaler के अनावश्यक काम से कैसे बचा जाए, और गेट टाइमआउट, कंट्रोलर की विफलता और टेनेंट आइसोलेशन को कैसे संभाला जाए।
इंटरव्यूअर क्या टेस्ट कर रहा है
- निर्मित स्थिति (created state) को शेड्यूलेबल स्थिति (schedulable state) से अलग करना।
spec.schedulingGatesके निर्माण, निष्कासन और नया न जोड़ने (no-addition) के प्रतिबंध को समझना।- इडेम्पोटेंट रिलीज़, टाइमआउट, ऑथराइजेशन और रिकवरी फ्लो को डिज़ाइन करना।
- SchedulingGated, Unschedulable और रनटाइम विफलता के बीच अंतर करना।
- मेट्रिक्स, इवेंट्स और ऑडिट रिकॉर्ड के साथ यह साबित करना कि सिस्टम बिना सूचना के रुक (silently stall) नहीं सकता।
पहले स्पष्ट करने योग्य प्रश्न
- प्रत्येक गेट को कौन जोड़ता है, और इसकी स्थिति की पुष्टि कौन करता है?
- क्या स्थिति Pod-, बैच- या टेनेंट-स्कोप वाली है, और क्या गैंग शेड्यूलिंग की आवश्यकता है?
- रिलीज़ लेटेंसी, समाप्ति नीति (expiry policy), समवर्ती सीमा (concurrency limit) और लागत लक्ष्य क्या हैं?
- कंट्रोलर रीस्टार्ट, API पुनः प्रयास (retries), नोड स्केलिंग और निरस्त की गई अनुमतियों को कैसा व्यवहार करना चाहिए?
तीस सेकंड का उत्तर
मैं नेमस्पेस-स्कोप्ड schedulingGates के साथ Pod बनाऊँगा और इमेज वार्मिंग, कोटा और बाहरी-संसाधन की तत्परता को अवलोकनीय (observable) स्थितियाँ बनाऊँगा। एक कंट्रोलर केवल उन्हीं गेट्स को हटाता है जिनका वह स्वामी है और निर्माण के बाद कभी भी नया गेट नहीं जोड़ता है; यह रिलीज़ से पहले टेनेंट कोटा और बैच नीति की फिर से जाँच करता है। मेट्रिक्स गेटेड Pods को वास्तव में नॉन-शेड्यूलेबल Pods से अलग करते हैं, और समय समाप्ति वर्जन्ड स्थितियों और ऑडिट रिकॉर्ड के साथ एक स्पष्ट विफलता या मानवीय समीक्षा स्थिति में प्रवेश करती है।
चरण-दर-चरण गहन उत्तर
1. स्टेट मशीन को परिभाषित करें
Created, SchedulingGated, ReadyToSchedule, Unschedulable, Running, और Expired को अलग करें। API अभी भी एक Pod को पढ़ सकता है, लेकिन शेड्यूलर उस Pod का प्रयास नहीं करता है जिसकी गेट सूची खाली नहीं है।
2. गेट के नाम चुनें
प्रत्येक गेट एक स्ट्रिंग स्थिति है, जैसे कि batch.example.com/image-ready। नेमस्पेस, बैच और कंट्रोलर वर्ज़न को लेबल्स या एनोटेशन में रखें; गेट के नाम को डायनेमिक डेटा के कंटेनर के बजाय एक अधूरी स्थिति के विवरण के रूप में रखें।
3. निर्माण के समय गेट्स सेट करें
Pod निर्माण के समय क्लाइंट या एडमिशन म्यूटेटर द्वारा एक गेट को इनिशियलाइज़ किया जा सकता है। निर्माण के बाद मौजूदा गेट्स को किसी भी क्रम में हटाया जा सकता है, लेकिन कोई नया गेट नहीं जोड़ा जा सकता है, इसलिए प्रत्येक संभावित अवरोधक स्थिति को निर्माण के समय ही सूचीबद्ध किया जाना चाहिए।
4. रिलीज़ कंट्रोलर को डिज़ाइन करें
कंट्रोलर Pods, कोटा, इमेज वार्मिंग और बाहरी-संसाधन इवेंट्स को देखता है, स्थिति सेट की गणना करता है, और एक रिसोर्स-वर्जन्ड पैच लागू करता है। डुप्लिकेट इवेंट्स को एक ही परिणाम पर अभिसरण (converge) होना चाहिए; प्रत्येक कंट्रोलर केवल अपने स्वयं के गेट्स को हटाता है ताकि कंट्रोलर एक-दूसरे को ओवरराइट न करें।
5. बैच और कॉन्करेंसी को संभालें
बैच-स्तरीय संसाधनों को एक अलग ऑब्जेक्ट में रिकॉर्ड करें, जबकि एक Pod गेट बैच कंट्रोलर के निर्णय की प्रतीक्षा करता है। टेनेंट-, प्राथमिकता- और कॉन्करेंसी-जागरूक बैचों में गेट्स को हटाएँ ताकि शेड्यूलर और ऑटोस्केलर पर अचानक दबाव का स्पाइक न आए।
6. समाप्ति और मानवीय हस्तक्षेप को डिज़ाइन करें
निर्माण समय, अंतिम स्थिति की प्रगति और समय सीमा (deadline) को सुरक्षित रखें। समाप्ति पर, चुपचाप गेट न हटाएँ; एक कारण रिकॉर्ड करें, एक इवेंट उत्सर्जित करें, और रद्दीकरण, पुनः प्रयास या एक मानवीय कतार चुनें। पुनः प्रयासों के लिए बैकऑफ़ और अधिकतम सीमा की आवश्यकता होती है।
7. वास्तविक कतारों का निरीक्षण करें
Kubernetes स्पष्ट रूप से तैयार न होने वाले Pods को उन Pods से अलग करने के लिए scheduler_pending_pods पर gated लेबल दिखाता है जिन्हें आज़माया गया और शेड्यूलिंग के अयोग्य पाया गया। अड़चनों (bottlenecks) का पता लगाने के लिए इसे Pod स्थितियों, इवेंट्स, कंट्रोलर कतार की लंबाई, गेट-आयु पर्सेंटाइल और ऑटोस्केलर गतिविधि के साथ संयोजित करें।
8. प्राधिकरण को सीमित करें और पुनर्प्राप्त करें
एडमिशन नीति यह सीमित करती है कि कौन गेट्स बना सकता है, और कंट्रोलर केवल अनुमत नेमस्पेस और उपसर्ग (prefix) वाले गेट्स को ही हटा सकता है। रीस्टार्ट के बाद, API से स्थिति का पुनर्निर्माण करें; पैच विरोध पर, रिसोर्स वर्ज़न को फिर से पढ़ें और तुलना करें। यदि कंट्रोलर अनुपलब्ध रहता है, तो ऑन-कॉल कर्मचारियों को ऑडिट ट्रेल द्वारा समर्थित एक सुरक्षित रद्दीकरण या रिलीज़ प्रक्रिया की आवश्यकता होती है।
ट्रेड-ऑफ़ और सीमाएँ
शेड्यूलिंग गेट्स यह नियंत्रित करते हैं कि Pod शेड्यूलिंग में प्रवेश करता है या नहीं; वे नोड एफ़िनिटी, संसाधन अनुरोधों, टोपोलॉजी बाधाओं या रनटाइम तत्परता को प्रतिस्थापित नहीं करते हैं। बहुत अधिक गेट्स एक एप्लिकेशन लेयर में वास्तविक क्षमता समस्याओं को छिपाते हैं; बहुत कम गेट्स बिना तैयारी वाले Pods को शेड्यूलर के पास भेजते हैं। अधूरी स्थितियों को बिना क्षमता वाले क्लस्टर से अलग रखें, और गेट को एक सामान्य क्रॉस-ऑब्जेक्ट ट्रांज़ैक्शन लॉक के रूप में न मानें।
रोलआउट योजना और प्रमाण
- प्रत्येक गेट के मालिक, स्थिति स्रोत, समाप्ति और निष्कासन अनुमति को रिकॉर्ड करें।
- एडमिशन में गेट प्रीफिक्स, टेनेंट कोटा और निर्माण-समय की पूरी स्थिति सेट को मान्य करें।
- पहले छोटे बैचों के साथ शेड्यूलर, ऑटोस्केलर, API सर्वर और कंट्रोलर पैच विरोधों का लोड-टेस्ट करें।
scheduler_pending_pods{queue="gated"}, गेट आयु, समाप्ति दर, रिलीज़ थ्रूपुट और प्रति-टेनेंट कॉन्करेंसी की निगरानी करें।- कंट्रोलर रीस्टार्ट, नेटवर्क विभाजन, अनुमति निरस्तीकरण, बैच रद्दीकरण और डुप्लिकेट पैच का परीक्षण करें, फिर ऑडिट लॉग सत्यापित करें।
सामान्य गलतियाँ और फॉलो-अप
गलती 1: निर्माण के बाद एक गेट जोड़ना
API केवल निर्माण के समय गेट्स की अनुमति देता है और बाद में हटाने की अनुमति देता है। डायनेमिक स्थितियों को निर्माण से पहले एकत्र किया जाना चाहिए या Pod बनाने से पहले एक अलग ऑब्जेक्ट के माध्यम से प्रतीक्षा की जानी चाहिए।
गलती 2: SchedulingGated को शेड्यूलिंग विफलता कहना
गैर-रिक्त गेट्स वाले Pod को शेड्यूलर द्वारा आज़माया नहीं गया है। गेटेड, Unschedulable, ImagePullBackOff और एप्लिकेशन तत्परता के बीच अंतर करें।
गलती 3: कोटा नियंत्रण के रूप में गेट निष्कासन का उपयोग करना
गेट हटाने से केवल शेड्यूलिंग प्रयास की अनुमति मिलती है; यह संसाधनों की गारंटी नहीं देता है। रिलीज़ से पहले कोटा, प्राथमिकता और बैच कॉन्करेंसी की दोबारा जाँच करें।
गलती 4: गेट-आयु और समाप्ति अलर्ट को छोड़ना
आयु पर्सेंटाइल के बिना, एक मूक ठहराव (silent stall) अदृश्य होता है। स्थिति, जिम्मेदार कंट्रोलर, अंतिम प्रगति और एक स्पष्ट रद्दीकरण पथ रिकॉर्ड करें।
गलती 5: ऑटोस्केलर लागत की अनदेखी करना
अतैयार Pods का एक बड़ा सेट निरर्थक स्केल-अप मूल्यांकन को ट्रिगर कर सकता है। यह सत्यापित करने के लिए कि लागत वास्तव में कम हो रही है, गेटेड-कतार मेट्रिक्स और रिलीज़ थ्रॉटलिंग का उपयोग करें।