प्रॉम्प्ट और संदर्भ
आप पांच-रेप्लिका वाली एक स्टेटफुल सर्विस के मालिक हैं, जिसे नोड मेंटेनेंस और क्लस्टर स्केल-डाउन के दौरान कोरम बनाए रखना चाहिए। एक PDB डिज़ाइन करें, minAvailable और maxUnavailable के बीच चयन करें, और समझाएं कि इसे कॉन्फ़िगर करने के बाद भी आउटेज क्यों हो सकते हैं। मान लें कि एक StatefulSet है और एक ऐसा मेंटेनेंस टूल है जो Eviction API का उपयोग करता है।
इंटरव्यूअर क्या जांच रहा है
- क्या आप YAML लिखने से पहले उपलब्धता और कोरम की बाध्यता (constraint) को परिभाषित करते हैं।
- क्या आप वॉलंटरी व्यवधान (voluntary disruption) को नोड विफलता, रिसोर्स दबाव और अन्य इनवॉलंटरी व्यवधान (involuntary disruption) से अलग पहचानते हैं।
- क्या आप समझते हैं कि एक PDB इविक्शन को सीमित करता है, हर समय स्वस्थ (healthy) Pods की पूर्ण संख्या को नहीं।
- क्या आप रोलिंग-अपग्रेड अपवादों, सिलेक्टर्स, प्रतिशत राउंडिंग और क्षमता-संबंधी ड्रेन रुकावटों (drain stalls) को पकड़ पाते हैं।
उत्तर देने से पहले स्पष्ट करने वाले प्रश्न
- कोरम क्या है? पांच-रेप्लिका वाली सहमति (consensus) सर्विस के लिए तीन स्वस्थ रेप्लिकेस की आवश्यकता हो सकती है; एक स्टेटलेस सर्विस क्षमता प्रतिशत को लक्षित कर सकती है।
- इविक्शन कौन करता है? PDB का सम्मान Eviction API द्वारा किया जाता है; Deployment या Pod को सीधे हटाने (direct deletion) से उन्हें बायपास किया जा सकता है।
- क्या मेंटेनेंस में एप्लिकेशन रोलआउट शामिल है? PDBs Deployment या StatefulSet के रोलिंग अपडेट को सीमित नहीं करते हैं; वर्कलोड रणनीति ऐसा करती है।
- क्या रिप्लेसमेंट Pods के लिए क्षमता उपलब्ध है? एक स्वीकृत इविक्शन का मतलब यह नहीं है कि रिप्लेसमेंट तुरंत शेड्यूल हो सकता है; क्षमता की कमी ड्रेन को ब्लॉक कर सकती है।
30-सेकंड का उत्तर फ्रेमवर्क
"मैं पहले स्वस्थ रेप्लिका आवश्यकता और इविक्शन पथ की पुष्टि करता हूँ। पांच रेप्लिकेस और तीन के कोरम के लिए, मैं StatefulSet से मेल खाने वाले सिलेक्टर के साथ minAvailable: 3, या रेप्लिका स्केल बदलने पर इसके समकक्ष maxUnavailable: 2 का उपयोग करूँगा। एक PDB केवल वॉलंटरी इविक्शन को सीमित करता है; यह नोड विफलता को नहीं रोक सकता है और न ही रोलआउट रणनीति की जगह ले सकता है। रोलआउट से पहले मैं एक नियंत्रित kubectl drain चलाऊँगा, disruptionsAllowed का निरीक्षण करूँगा, और सत्यापित करूँगा कि रिप्लेसमेंट Pods के पास शेड्यूलिंग योग्य क्षमता है।"
चरण-दर-चरण विस्तृत उत्तर
1. उपलब्धता को बजट में बदलें
PDB बजट रेप्लिकेस की वह संख्या है जिसे एक वॉलंटरी व्यवधान एक बार में हटा सकता है। यदि पांच रेप्लिकेस को तीन स्वस्थ Pods बनाए रखने हैं, तो बजट अधिकतम दो है। minAvailable: 3 शेष स्वस्थ संख्या बताता है; maxUnavailable: 2 अनुमत अनुपलब्ध (unavailable) संख्या बताता है। ये फ़ील्ड्स परस्पर अनन्य (mutually exclusive) हैं।
2. वह अभिव्यक्ति चुनें जो स्केलिंग से मेल खाती हो
minAvailable एक निश्चित कोरम के लिए सीधा है। यदि रेप्लिकेस ऑटोस्केल होते हैं, तो Kubernetes दस्तावेज़ maxUnavailable पर विचार करने की अनुशंसा करता है, जिसका मूल्यांकन वांछित रेप्लिकेस के आधार पर किया जाता है। प्रतिशत को राउंड अप किया जाता है: सात वांछित रेप्लिकेस और maxUnavailable: 30% के साथ, दो के बजाय तीन Pods अनुपलब्ध हो सकते हैं। क्षमता योजना (capacity planning) में उस राउंडिंग को शामिल किया जाना चाहिए।
3. सही वर्कलोड को बाइंड करें
PDB लेबल सिलेक्टर को StatefulSet सिलेक्टर से मेल खाना चाहिए। अन्यथा यह किसी भी लक्षित Pod को सुरक्षित नहीं कर सकता है या गलती से कई एप्लिकेशनों को मिला सकता है। लेबल्स को स्थिर रखें; बजट से बचने के लिए रिलीज़ के दौरान उन्हें न बदलें।
4. PDB की सीमा बताएं
PDB केवल kubectl drain और स्वचालित मेंटेनेंस जैसे वॉलंटरी व्यवधान को सीमित करता है। हार्डवेयर विफलता, नोड का नुकसान, और रिसोर्स-दबाव के कारण होने वाले इविक्शन इनवॉलंटरी होते हैं; PDB उन्हें रोक नहीं सकता है, और वे अभी भी बजट के विरुद्ध गिने जाते हैं। किसी Pod या Deployment का सीधा विलोपन भी इसे बायपास कर सकता है।
5. अटके हुए ड्रेन (stalled drain) की व्याख्या करें
जब बजट समाप्त हो जाता है, तो Eviction API नए इविक्शन को अस्वीकार कर देता है और ड्रेन पुनः प्रयास करता है। यहाँ तक कि एक स्वीकृत इविक्शन भी अपने रिप्लेसमेंट को Pending छोड़ सकता है जब किसी नोड में क्षमता नहीं होती है, इसलिए ड्रेन ब्लॉक रहता है। Pod रिक्वेस्ट्स, ज़ोन स्प्रेडिंग, स्टार्टअप समय और नोड हेडरूम को शामिल करें; PDB कोई क्षमता प्रणाली (capacity system) नहीं है।
6. रोलआउट और स्वास्थ्य नीति को अलग करें
PDB किसी Deployment या StatefulSet के रोलिंग अपडेट को सीमित नहीं करता है; अपडेट रणनीति फ़ील्ड्स जैसे maxUnavailable, maxSurge, और रेडीनेस रिलीज़ के दौरान रिप्लेसमेंट को नियंत्रित करते हैं। Kubernetes एक अस्वस्थ-Pod इविक्शन नीति (unhealthy-Pod eviction policy) भी प्रदान करता है, जिसे इस आधार पर चुना जाना चाहिए कि क्या विफल हो रहे Pods को पहले साफ़ किया जाना चाहिए। रोलआउट, मेंटेनेंस और घटना रिकवरी का अलग-अलग परीक्षण करें।
उच्च गुणवत्ता वाला नमूना उत्तर
मैं पुष्टि करूँगा कि पांच-रेप्लिका वाली सर्विस को कोरम के लिए तीन स्वस्थ रेप्लिकेस की आवश्यकता है और मेंटेनेंस टूल Eviction API को कॉल करता है। बुनियादी PDB StatefulSet के सटीक सिलेक्टर के साथ minAvailable: 3 है। यदि रेप्लिकेस ऑटोस्केल होते हैं, तो मैं maxUnavailable: 2 या इसके राउंडिंग व्यवहार के साथ एक प्रतिशत का मूल्यांकन करूँगा। PDB केवल वॉलंटरी इविक्शन को सीमित करता है; यह नोड विफलता, रिसोर्स दबाव, सीधे विलोपन या रोलिंग-अपडेट नीति को नहीं रोकता है।
रोलआउट के दौरान मैं disruptionsAllowed का निरीक्षण करूँगा, एक नियंत्रित ड्रेन चलाऊँगा, और समाप्ति समय, रिप्लेसमेंट शेड्यूलिंग और कोरम स्थिति का अवलोकन करूँगा। बजट समाप्त होने पर ड्रेन का रुकना अपेक्षित है। यदि रिप्लेसमेंट Pending हैं, तो मैं बजट को बढ़ाने के बजाय क्षमता जोड़ूँगा या रिक्वेस्ट्स को समायोजित करूँगा। अंत में मैं अपग्रेड, नोड-लॉस और मेंटेनेंस रोलबैक पथों का अलग-अलग परीक्षण करूँगा।
सामान्य गलतियाँ
- गलती → यह मान लेना कि PDB हर आउटेज को रोकता है। यह क्यों विफल होता है: इनवॉलंटरी व्यवधान इसके नियंत्रण से बाहर हैं। समाधान: नोड विफलता, दबाव और मेंटेनेंस इविक्शन के लिए सीमा बताएं।
- गलती → केवल
maxUnavailable: 50%लिखना। यह क्यों विफल होता है: राउंड-अप व्यवहार अंतर्ज्ञान के सुझाव से अधिक रेप्लिका नुकसान की अनुमति दे सकता है। समाधान: वांछित रेप्लिकेस से इसकी गणना करें। - गलती → PDB को रोलआउट नीति के रूप में मानना। यह क्यों विफल होता है: Deployment और StatefulSet अपडेट PDB द्वारा सीमित नहीं होते हैं। समाधान: वर्कलोड अपडेट रणनीति को अलग से कॉन्फ़िगर करें।
- गलती → अटके हुए ड्रेन के लिए PDB को दोष देना। यह क्यों विफल होता है: समाप्त बजट और नोड क्षमता की कमी के अलग-अलग कारण होते हैं। समाधान:
disruptionsAllowed, Pending Pods, रिक्वेस्ट्स और क्षमता का एक साथ निरीक्षण करें।
फॉलो-अप प्रश्न और उत्तर
पांच में से केवल तीन रेप्लिकेस स्वस्थ हैं। क्या किसी अन्य Pod को निकाला (evict किया) जा सकता है?
minAvailable: 3 के साथ, वॉलंटरी इविक्शन को Eviction API द्वारा अस्वीकार कर दिया जाना चाहिए। एक स्वस्थ रेप्लिका को पुनर्स्थापित करें या मेंटेनेंस में रोक को स्वीकार करें; ड्रेन को पूरा करने के लिए PDB को हटाने से कोरम सुरक्षा समाप्त हो जाएगी।
क्लस्टर ऑटोस्केलर अटका हुआ है। क्या आपको PDB को ढीला करना चाहिए?
पहले सत्यापित करें कि स्केल-डाउन वॉलंटरी है, बजट समाप्त हो गया है, और रिप्लेसमेंट Pods शेड्यूल हो सकते हैं। कोरम सर्विस के बजट को ढीला करने से निरंतरता (consistency) टूट सकती है। हर एप्लिकेशन के बजट को कमजोर करने के बजाय क्षमता जोड़ें, ड्रेन बैच बदलें, या स्टेटलेस वर्कलोड के लिए क्षमता प्रतिशत का उपयोग करें।
सीधा Pod विलोपन PDB को बायपास क्यों कर सकता है?
PDB केवल Eviction API के माध्यम से वॉलंटरी इविक्शन रिक्वेस्ट्स को नियंत्रित करता है, हर डिलीट ऑपरेशन को नहीं। सीधे हटाने की अनुमतियों को प्रतिबंधित करें और मेंटेनेंस ऑटोमेशन को API का उपयोग करने के लिए बाध्य करें, जबकि आपात स्थिति के लिए एक स्पष्ट व्यवस्थापक (administrator) बायपास बनाए रखें।
maxUnavailable: 0 का क्या जोखिम है?
इसके लिए शून्य वॉलंटरी अनुपलब्ध Pods की आवश्यकता होती है, इसलिए जब तक चयनित वर्कलोड वहां रहता है तब तक नोड ड्रेन कभी पूरा नहीं हो सकता है। इसका उपयोग केवल तभी करें जब व्यवसाय वॉलंटरी व्यवधान को बिल्कुल बर्दाश्त न कर सके और एक समन्वित मेंटेनेंस प्रक्रिया मौजूद हो।