प्रॉम्प्ट
Kubernetes v1.35 शेड्यूलिंग ग्रुप को एक अल्फा क्षमता (alpha capability) के रूप में दस्तावेज़ित करता है। एक बैच प्लेटफ़ॉर्म डिज़ाइन करें जहाँ आपस में निर्भर (interdependent) वर्कर्स केवल तभी शुरू हों जब कम से कम minCount Pods को एक साथ रखा जा सके। बताएं कि PodGroup, शेड्यूलर, कंट्रोलर, ऑटोस्केलिंग और विफलता से निपटना (failure handling) एक साथ कैसे काम करते हैं। वर्ज़न और फीचर-गेट से जुड़े मान्यताओं (assumptions) को स्पष्ट करें।
इंटरव्यूअर क्या जांच रहा है
मुख्य परीक्षा यह है कि क्या आप API, शेड्यूलिंग और रनटाइम स्थिति को सुसंगत रखते हुए व्यवहार्यता (feasibility) को एक Pod से पूरे ग्रुप तक ले जा सकते हैं। एक मजबूत उत्तर basic और gang के बीच अंतर स्पष्ट करता है, PodGroup के गायब होने, क्षमता की कमी, सदस्य की विफलता, प्रीएम्प्शन और ऑब्जर्वेबिलिटी को संभालता है, और एक अल्फा API को पूरी तरह से प्रोडक्शन के लिए तैयार बताने से बचता है।
स्पष्टीकरण के प्रश्न (Clarifying questions)
- क्या प्रत्येक वर्कर को एक साथ शुरू होना चाहिए, या कम समवर्ती सीमा (concurrent threshold) पर्याप्त है?
- क्या सदस्य वन-शॉट Jobs हैं या लंबे समय तक चलने वाली सेवाएं?
- क्या उन्हें GPUs, टोपोलॉजी प्रतिबंधों (topology constraints), या क्रॉस-क्लस्टर प्लेसमेंट की आवश्यकता है? दस्तावेज़ित संदर्भ समान नेमस्पेस में एक PodGroup है।
- प्रतीक्षा समय सीमा (deadline) क्या है, और क्या कोई जॉब कतार में लग सकती है, क्षमता उधार ले सकती है, या डाउनग्रेड हो सकती है?
एक 30-सेकंड का फ्रेमवर्क
सीमा से शुरुआत करें: Scheduling Group और PodGroup नीतियां v1.35 में अल्फा हैं, डिफ़ॉल्ट रूप से अक्षम हैं, और इसके लिए GenericWorkload फीचर गेट की आवश्यकता होती है। फिर चार परतों को कवर करें: API अनुबंध, ग्रुप शेड्यूलिंग, लाइफसाइकिल और संचालन। एक Workload PodGroup बनाता है; Pods इसे संदर्भित करते हैं; शेड्यूलर नीति और minCount लागू करता है; कंट्रोलर टाइमआउट, पुनः प्रयास (retry), और क्लीनअप का ध्यान रखते हैं; मेट्रिक्स और रोलबैक रोलआउट की सुरक्षा करते हैं।
स्टेप-बाय-स्टेप डिज़ाइन
1. मॉडल और इनवेरिएंट्स
कंट्रोलर वांछित सदस्यों, नीति, वर्ज़न और टेनेंट के साथ प्रति रन एक PodGroup बनाता है। प्रत्येक Pod समान नेमस्पेस में एक PodGroup के लिए spec.schedulingGroup.podGroupName सेट करता है। यह फ़ील्ड अपरिवर्तनीय (immutable) है, इसलिए Pod को स्थानांतरित करने का अर्थ एक नया सेट बनाना है। एक गैंग के लिए, कोई भी सदस्य तब तक बाइंड नहीं होता जब तक कि minCount इनवेरिएंट पूरा न हो जाए।
2. नीति चुनें
basic का उपयोग तब करें जब सदस्य स्वतंत्र रूप से चल सकें और समूहीकरण मुख्य रूप से प्रबंधन और ऑब्जर्वेबिलिटी के लिए हो। कसकर जुड़े (tightly coupled) ट्रेनिंग या बैच कार्य के लिए gang का उपयोग करें; ग्रुप केवल तभी संभव होता है जब कम से कम minCount सदस्यों को एक साथ शेड्यूल किया जा सके। minCount को कुल से कम सेट करने से लोचशीलता (elasticity) मिलती है; इसे कुल के बराबर सेट करने पर सभी सदस्यों की आवश्यकता होती है।
3. सबमिशन और प्रतीक्षा स्टेट मशीन
Pods बनाने से पहले PodGroup बनाएं ताकि संदर्भों का समाधान (resolve) हो सके। यदि संदर्भित ऑब्जेक्ट अनुपस्थित है, तो Pods Pending बने रहते हैं और ग्रुप दिखाई देने के बाद शेड्यूलर पुनः प्रयास करता है। PendingGroup, WaitingCapacity, Feasible, Bound, Running, Failed, और Cancelled जैसी स्थितियों को ट्रैक करें, प्रत्येक एक जनरेशन, कारण और टाइमस्टैम्प के साथ।
4. शेड्यूलिंग और क्षमता समन्वय
शेड्यूलर पहले फ़िल्टर, टोपोलॉजी, डिवाइसेस और प्राथमिकता का उपयोग करके उम्मीदवार नोड्स का मूल्यांकन करता है, फिर ग्रुप व्यवहार्यता की जांच करता है। बाइंड ऑपरेशन पुनः प्रयास करने योग्य (retryable) और इडेम्पोटेंट (idempotent) होने चाहिए, और उम्मीदवार संख्या minCount तक पहुँचने के बाद ही होने चाहिए। ऑटोस्केलर को ग्रुप संसाधन आकार (resource shape) का उपयोग करना चाहिए और केवल पहले Pod के लिए क्षमता जोड़ने के बजाय पूरे अनुरोध के लिए स्केल करना चाहिए।
5. प्रीएम्प्शन, समय सीमा और निष्पक्षता
ग्रुप को लगातार प्राथमिकता और कतार भार (queue weight) दें ताकि प्रीएम्प्शन एक अनुपयोगी आधा-ग्रुप न छोड़े। एक समय सीमा पर, ग्रुप को रद्द करें और आरक्षण जारी करें; पुनः प्रयास एक नई जनरेशन का उपयोग करते हैं ताकि पुराने सदस्य फिर से शामिल न हो सकें। टेनेंट कोटा, अधिकतम ग्रुप आकार, और कतार की आयु (queue aging) बड़े गैंग्स को क्लस्टर पर एकाधिकार करने से रोकते हैं।
6. सदस्य की विफलता और रोलबैक
स्टार्टअप के बाद, क्रैश हुए सदस्य को इस बात के प्रमाण के रूप में नहीं माना जाना चाहिए कि ग्रुप वर्तमान में स्वस्थ है। जॉब सिमेंटिक्स के आधार पर, एक सदस्य को पुनरारंभ करें या ग्रुप को समाप्त करें; ट्रेनिंग जॉब्स आमतौर पर एक चेकपॉइंट को पुनर्स्थापित करते हैं और एक नई जनरेशन बनाते हैं। Workload को हटाने से ऑडिट के लिए टर्मिनल इवेंट्स को संरक्षित करते हुए स्वामित्व वाले Pods और PodGroup को साफ करना चाहिए।
7. ऑब्जर्वेबिलिटी और सुरक्षा सीमाएं
ग्रुप कतार लेटेंसी, व्यवहार्य-सदस्य गणना, minCount, स्केल-अप और प्रीएम्प्शन गणना, और विफलता के कारणों को प्रदर्शित करें। एक एडमिशन वेबहुक नेमस्पेस, कोटा, ग्रुप आकार और फीचर-गेट उपलब्धता को मान्य करता है। चूंकि API अल्फा है, इसलिए एक स्पष्ट रोलआउट स्विच, संगतता परीक्षण (compatibility tests), और एक तेज़ रोलबैक पथ का उपयोग करें।
एक मजबूत उत्तर का उदाहरण
"मैं चाहूंगा कि एक Workload कंट्रोलर गैंग नीति और प्रगति करने के लिए आवश्यक न्यूनतम वर्कर्स के बराबर minCount के साथ समान नेमस्पेस में एक PodGroup बनाए। Pods इसे अपरिवर्तनीय schedulingGroup फ़ील्ड के माध्यम से संदर्भित करते हैं। कंट्रोलर पहले ग्रुप बनाता है; अनसुलझे संदर्भ Pending रहते हैं। शेड्यूलर सभी सदस्यों के लिए संसाधनों, टोपोलॉजी और प्राथमिकता का मूल्यांकन करता है और केवल तभी बाइंड करता है जब व्यवहार्य संख्या minCount तक पहुँच जाती है। ऑटोस्केलर ग्रुप संसाधन आकार से स्केल करता है। एक समय सीमा पूरे ग्रुप को रद्द कर देती है और क्षमता जारी करती है; एक विफल ट्रेनिंग रन को चेकपॉइंट से पुनर्स्थापित एक नई जनरेशन मिलती है। परिनियोजन मैनिफ़ेस्ट स्पष्ट रूप से v1.35 alpha और GenericWorkload रिकॉर्ड करता है, और रोलआउट एक अलग क्लस्टर में शुरू होता है।"
सामान्य विफलता मोड (Common failure modes)
basicको ऑल-ऑर-नथिंग (all-or-nothing) कहना भले ही इसके सदस्य स्वतंत्र रूप से शेड्यूल हो सकते हों।- समान-नेमस्पेस PodGroup संदर्भ और अपरिवर्तनीय फ़ील्ड को समझाए बिना केवल लेबलों का उपयोग करना।
- गायब ग्रुप, स्केल-अप, समय सीमा, प्रीएम्प्शन, या पुनः प्रयास जनरेशन की अनदेखी करना।
- अल्फा स्थिति और
GenericWorkloadफीचर गेट को छोड़ना। - ग्रुप-स्तरीय रद्दीकरण और मेट्रिक्स के बिना केवल एक सफल बाइंड पर चर्चा करना।
फॉलो-अप दिशाएं
क्या होगा यदि PodGroup का निर्माण Pod के बाद किया जाए?
Pod Pending बना रहता है, और PodGroup बनने के बाद शेड्यूलर इस पर पुनर्विचार करता है। समय अंतराल को छोटा करने के लिए कंट्रोलर को फिर भी पहले ग्रुप बनाना चाहिए।
आप minCount का चयन कैसे करते हैं?
एप्लिकेशन की न्यूनतम उपयोगी समानता (parallelism), प्रति-Pod संसाधन, और स्वीकार्य कतार समय का उपयोग करें, फिर कोटा और एक ऊपरी सीमा लागू करें।
आप गैंग भुखमरी (starvation) से कैसे बचते हैं?
ग्रुप प्रतीक्षा समय की निगरानी करते हुए निष्पक्ष कतारों (fair queues), एजिंग, ग्रुप-आकार की सीमाओं, टेनेंट कोटा और समय सीमा रद्दीकरण को संयोजित करें।
यह शेड्यूलिंग गेट्स (scheduling gates) से किस प्रकार भिन्न है?
एक गेट यह नियंत्रित करता है कि एक Pod शेड्यूलेबल कतार में कब प्रवेश करता है। शेड्यूलिंग ग्रुप शेड्यूलर को PodGroup के माध्यम से एक सेट का मूल्यांकन करने के लिए कहता है। उन्हें संयोजित किया जा सकता है, लेकिन उनके मेट्रिक्स और विफलता सिमेंटिक्स को अलग रखा जाना चाहिए।
आप रोलआउट में देरी कब करेंगे?
जब क्लस्टर वर्ज़न, फीचर गेट, शेड्यूलर प्लगइन्स, या ऑटोस्केलर असंगत हों, या जब अल्फा अपग्रेड और रोलबैक का परीक्षण नहीं किया गया हो, तब देरी करें। अंतरिम डिज़ाइन के रूप में एक स्पष्ट कतार कंट्रोलर का उपयोग करें।
संदर्भ
- Kubernetes दस्तावेज़: "Scheduling Group"।
- Kubernetes दस्तावेज़: "PodGroup Scheduling Policies"।
- Kubernetes दस्तावेज़: "Scheduling API Reference"।