सिस्टम डिज़ाइन इंटरव्यू: आप एक ऐसा मेंटेनेंस ऑर्केस्ट्रेटर कैसे डिज़ाइन करेंगे जो PDB और Topology Spread का सम्मान करता हो?

प्रॉम्प्ट और दायरा

एक क्लस्टर को रोलिंग नोड अपग्रेड की आवश्यकता है जबकि वर्कलोड PodDisruptionBudget और topology spread बाधाओं का उपयोग करते हैं। मेंटेनेंस ऑर्केस्ट्रेटर को डिज़ाइन करें, जिसमें कैंडिडेट नोड्स, एविक्शन समवर्तीता (concurrency), अनशेड्यूल करने योग्य रिप्लेसमेंट्स, क्षमता आरक्षण, रिकवरी और ऑब्जर्वेबिलिटी शामिल हों।

Kubernetes स्वैच्छिक व्यवधानों (voluntary disruptions) से प्रभावित Pods को सीमित करने के लिए एक PDB को परिभाषित करता है; मेंटेनेंस टूल्स को Eviction API का उपयोग करना चाहिए ताकि बजट प्रवेश (admission) में भाग ले सके। Topology spread बाधाएं ज़ोन और नोड्स जैसे विफलता डोमेन (failure domains) में विषमता (skew) को नियंत्रित करती हैं। एक मजबूत डिज़ाइन केवल एक बार Pod की संख्या की जांच करने और एक बैच को हटाने के बजाय दोनों बाधाओं को एक ही नियंत्रण लूप में रखता है।

इंटरव्यूअर क्या मूल्यांकन करता है

• स्वैच्छिक व्यवधान को अनैच्छिक विफलता और उसकी गारंटी सीमा से अलग करना।
• Pods को सीधे हटाने के बजाय Eviction API का उपयोग करना।
• maxSkew, whenUnsatisfiable, और topology spread से लेबल चयनकर्ताओं का मूल्यांकन करना।
• प्रति नोड और विफलता डोमेन समवर्तीता और क्षमता आरक्षण डिज़ाइन करना।
• PDB ब्लॉकिंग, अनरेडी Pods, पुनः प्रयास (retries), टाइमआउट और रोलबैक को संभालना।
• घटनाओं (events), मैट्रिक्स और ऑडिट रिकॉर्ड के माध्यम से निर्णयों की व्याख्या करना।

पूछे जाने वाले स्पष्टीकरण प्रश्न

1. क्या यह एक OS अपग्रेड, इंस्टेंस रिप्लेसमेंट, या आपातकालीन मरम्मत है? आपातकालीन विफलता PDB सुरक्षा को बायपास कर सकती है।
2. प्रतिकृति संख्या (replica counts), PDB सेटिंग्स, टोपोलॉजी डोमेन और अतिरिक्त क्षमता क्या हैं?
3. क्या प्राथमिकता कुल अवधि, न्यूनतम उपयोगकर्ता जोखिम, या प्रत्येक ज़ोन में सख्त अतिरेकता (redundancy) है?
4. क्या कोई Cluster Autoscaler, अस्थायी नोड पूल, या क्रॉस-ज़ोन क्षमता सीमा है?
5. रोकने (pausing), डिग्रेड करने, या अनुमोदन का अनुरोध करने से पहले कंट्रोलर PDB पर कब तक प्रतीक्षा कर सकता है?

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

मैं एक डिक्लेरेटिव कंट्रोलर का निर्माण करूँगा जो नोड्स, Pods, PDBs, टोपोलॉजी बाधाओं और शेड्यूल करने योग्य क्षमता को पढ़ता है। यह स्वस्थ प्रतिकृतियों और टोपोलॉजी विषमता (skew) पर एक एविक्शन के प्रभाव का अनुकरण करेगा, फिर Eviction API के माध्यम से छोटे बैचों को निष्पादित करेगा। नोड और विफलता-डोमेन टोकन समवर्तीता को परिभाषित करते हैं; कंट्रोलर जारी रखने से पहले एक रिप्लेसमेंट Pod के Ready होने की प्रतीक्षा करता है। PDB संघर्ष या असंतुष्ट टोपोलॉजी बाधाएं विलोपन को बाध्य करने के बजाय एक कारण के साथ बैच को रोक (pause) देती हैं। प्रत्येक ऑपरेशन इडेम्पोटेंट (idempotent) और अवलोकनीय है, जिसमें टाइमआउट, रोलबैक और अनैच्छिक विफलता के लिए एक अलग जोखिम पथ शामिल है।

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

1. स्थिति और बाधा इनपुट परिभाषित करें

कार्य में लक्ष्य नोड्स, अपग्रेड बैच, अधिकतम समवर्तीता, समय सीमा और रोलबैक नीति शामिल है। नोड लेबल, Pod स्वामियों, तत्परता (readiness), PDB disruptionsAllowed, टोपोलॉजी बाधाओं और अतिरिक्त क्षमता को कैश करें, लेकिन एक पुराने स्नैपशॉट पर भरोसा करने के बजाय प्रत्येक निर्णय से पहले महत्वपूर्ण स्थिति को फिर से पढ़ें।

2. कैंडिडेट नोड्स और सुरक्षित बैच चुनें

Cordoned नोड्स, महत्वपूर्ण सिस्टम Pods ले जाने वाले नोड्स, और बिना रिप्लेसमेंट क्षमता वाले नोड्स को फ़िल्टर करें। उम्मीदवारों को ज़ोन, रैक और वर्कलोड के अनुसार समूहित करें। एक बैच को प्रत्येक वर्कलोड के PDB भत्ते (allowance) के भीतर रहना चाहिए और प्रतिस्थापन के बाद टोपोलॉजी विषमता का अनुकरण करना चाहिए। अतिरिक्त क्षमता वाले उन नोड्स को प्राथमिकता दें जो विफलता डोमेन को सिंगल पॉइंट ऑफ़ फेलियर में नहीं बदलते हैं।

3. Eviction API का उपयोग करें

स्वैच्छिक रखरखाव के लिए, Eviction API को कॉल करें और Kubernetes को PDB का मूल्यांकन करने दें। संघर्ष या अस्वीकृति पर विशिष्ट PDB, वर्कलोड और पुनः प्रयास समय रिकॉर्ड करें। प्रत्यक्ष विलोपन बजट को बायपास करता है और इसे स्पष्ट रूप से स्वीकृत विनाशकारी आपातकालीन पथ के लिए आरक्षित किया जाना चाहिए।

read constraints -> choose one node -> create eviction request
                -> PDB allows? no: back off and re-evaluate
                -> yes: wait for Ready replacement and topology recovery
                -> success: mark node complete; failure: pause and recover

4. टोपोलॉजी और क्षमता फीडबैक पर प्रतिक्रिया दें

एविक्शन पूर्णता नहीं है। DoNotSchedule, गायब टोपोलॉजी कुंजी, एफ़िनिटी, या अपर्याप्त क्षमता के कारण एक रिप्लेसमेंट Pending रह सकता है। शेड्यूलर घटनाओं पर नज़र रखें; उपयुक्त होने पर एक अस्थायी पूल का विस्तार करें या बैच क्रम बदलें, लेकिन वर्कलोड बाधाओं को चुपचाप शिथिल (relax) न करें। ScheduleAnyway के लिए अभी भी वास्तविक विषमता और लागत को रिकॉर्ड करने की आवश्यकता होती है।

5. समवर्तीता, लीज और इडेम्पोटेन्सी डिज़ाइन करें

एक नोड और कंट्रोलर जनरेशन के लिए एक टास्क लीज का उपयोग करें ताकि कई मेंटेनेंस वर्कर्स एक ही लक्ष्य को एविक्ट न कर सकें। प्रति-ज़ोन एक छोटी सीमा या वर्कलोड टोकन बकेट के साथ शुरुआत करें। अगला टोकन केवल तभी प्राप्त करें जब रिप्लेसमेंट Ready हो, PDB बजट पुनर्प्राप्त हो, और टोपोलॉजी विषमता इच्छित सीमा के भीतर हो। दोहराए गए एविक्शन को पहले से ही संभाला हुआ मानें और कंट्रोलर के पुनरारंभ होने के बाद API स्थिति से पुनर्प्राप्त करें।

6. विफलता, टाइमआउट और रोलबैक

यदि कोई Pod Pending रहता है, PDB शून्य पर रहता है, ड्रेनिंग टाइमआउट हो जाती है, या कोई नया नोड अस्वस्थ है, तो बाद के बैचों को रोकें और अनावश्यक कॉर्डन हटा दें। जब एक अपग्रेड किए गए नोड को पुरानी छवि पर वापस नहीं लाया जा सकता है, तो एक पुराने पूल को बनाए रखें या एक मान्य छवि पर स्विच करें। रोलबैक सेवा अतिरेकता (redundancy) को पुनर्स्थापित करता है; यह मेंटेनेंस प्रतिशत को 100% करने के लिए बाध्य नहीं करता है।

7. ऑब्जर्वेबिलिटी और अभ्यास (drills)

चयनित नोड्स, प्रभावित वर्कलोड, पहले और बाद का PDB भत्ता, टोपोलॉजी काउंट, एविक्शन प्रतिक्रियाएं, Pending कारण और अवधि रिकॉर्ड करें। सफल एविक्शन, PDB ब्लॉकिंग समय, अधिकतम विषमता, Ready विलंबता (latency), क्रॉस-ज़ोन ट्रैफ़िक और पुनः प्रयासों को मापें। सिंगल-ज़ोन क्षमता की कमी, शून्य PDB बजट, शेड्यूलर विफलता, कंट्रोलर पुनरारंभ और अचानक नोड हानि का अभ्यास करें।

उच्च गुणवत्ता वाला नमूना उत्तर

मैं ऑर्केस्ट्रेटर को एक डिक्लेरेटिव कंट्रोलर के रूप में मॉडल करूँगा जो नोड और विफलता डोमेन द्वारा आगे बढ़ता है। यह Pod स्वामियों, तत्परता, PDBs, topology spread, नोड लेबल और शेड्यूल करने योग्य क्षमता को पढ़ता है; यह स्वस्थ प्रतिकृतियों और maxSkew पर एक एविक्शन के प्रभाव का अनुकरण करता है, फिर एक छोटा Eviction API बैच सबमिट करता है। प्रत्येक ज़ोन में एक समवर्ती टोकन होता है, और अगला नोड एक Ready रिप्लेसमेंट, एक पुनर्प्राप्त PDB बजट और संतुष्ट टोपोलॉजी बाधाओं की प्रतीक्षा करता है।

PDB संघर्ष, Pending रिप्लेसमेंट्स, क्षमता की कमी, या टाइमआउट बैच को रोकते हैं और एक कारण रिकॉर्ड करते हैं। कंट्रोलर एक अस्थायी पूल का विस्तार कर सकता है या उम्मीदवारों को पुनर्व्यवस्थित कर सकता है, लेकिन यह कभी भी Pods को सीधे नहीं हटाता है या बाधाओं को चुपचाप शिथिल नहीं करता है। लीज और जनरेशन पुनः प्रयासों को इडेम्पोटेंट बनाते हैं, और पुनरारंभ API स्थिति से पुनर्प्राप्त होते हैं। बैच को बड़ा करने से पहले मेट्रिक्स बजट ब्लॉकिंग, अधिकतम विषमता, Ready विलंबता, पुनः प्रयास और क्रॉस-ज़ोन लागत को कवर करते हैं।

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

• तेजी से ड्रेन करने के लिए Pods को हटाना → PDB को बायपास करता है → स्वैच्छिक रखरखाव के लिए Eviction API का उपयोग करें।
• केवल disruptionsAllowed को देखना → रिप्लेसमेंट टोपोलॉजी का उल्लंघन कर सकते हैं या क्षमता की कमी हो सकती है → पहले विषमता और प्लेसमेंट का अनुकरण करें।
• एक साथ कई ज़ोन में प्रतिकृतियों को बेदखल करना → विफलता-डोमेन अतिरेकता खो देता है → ज़ोन और वर्कलोड समवर्ती टोकन का उपयोग करें।
• PDB ब्लॉक होने पर उसे संपादित करना → जोखिम को उपयोगकर्ताओं पर स्थानांतरित करता है → रोकें, क्षमता जोड़ें, या अनुमोदन का अनुरोध करें।
• केवल विलोपन की प्रतीक्षा करना → किसी सेवा में कोई Ready रिप्लेसमेंट नहीं हो सकता है → स्थिति को तत्परता, शेड्यूलर घटनाओं और समय सीमाओं के साथ संचालित करें।
• कंट्रोलर लीज को छोड़ना → कार्यकर्ता संचालन दोहराते हैं → लीज, जनरेशन और इडेम्पोटेंट स्थिति को बनाए रखें।

अनुवर्ती प्रश्न और उत्तर

क्या PDB अचानक नोड के गायब होने से रक्षा कर सकता है?

पूरी तरह से नहीं। एक PDB मुख्य रूप से स्वैच्छिक व्यवधानों को सीमित करता है; हार्डवेयर विफलता और संसाधन की कमी प्रतिकृतियों को सीधे हटा सकती है। अतिरेकता के लिए अभी भी कई विफलता डोमेन, प्रतिकृतियों और अतिरिक्त क्षमता की आवश्यकता होती है।

kubectl delete pod का उपयोग क्यों न करें?

प्रत्यक्ष विलोपन PDB प्रवेश जांच को बायपास करता है। एक मेंटेनेंस कंट्रोलर को Eviction API को कॉल करना चाहिए ताकि API सर्वर अनुमति या संघर्ष का निर्णय लौटाए।

क्या होगा यदि PDB एविक्शन की अनुमति देता है लेकिन रिप्लेसमेंट Pending रहता है?

बैच को रोकें, शेड्यूलर घटनाओं और टोपोलॉजी काउंट का निरीक्षण करें, और क्षमता जोड़ें या कोई अन्य नोड चुनें। एविक्शन जारी रखने से अतिरेकता का एक बड़ा अंतर पैदा होगा।

क्या ScheduleAnyway को विषमता की अनदेखी के रूप में माना जा सकता है?

नहीं। यह शेड्यूलर को उन नोड्स को प्राथमिकता देने के लिए कहता है जो विषमता को कम करते हैं, लेकिन विषमता बनी रह सकती है। वास्तविक वितरण, लागत और अतिरेकता जोखिम रिकॉर्ड करें।

कंट्रोलर पुनरारंभ डुप्लिकेट एविक्शन से कैसे बचता है?

टास्क लीज, नोड लॉक, कंट्रोलर जनरेशन और पर्सिस्टेड स्थिति का उपयोग करें। रिकवरी पर, इन-मेमोरी कतार को फिर से चलाने के बजाय API से Pod, Eviction और नोड स्थिति पर भरोसा करें।

जबरन विलोपन कब स्वीकार्य है?

केवल एक स्पष्ट रूप से स्वीकृत आपात स्थिति के लिए जब स्वैच्छिक पथ जोखिम को संभाल नहीं सकता है, जिसमें उच्च प्राधिकरण और यह रिकॉर्ड शामिल हो कि PDB और अतिरेकता का उल्लंघन हो सकता है।