प्रॉम्प्ट और स्कोप
एक HTTP सर्विस Deployment में चलती है। Pod डिलीट होने के बाद भी, कुछ रिक्वेस्ट्स पुराने इंस्टेंस तक पहुँचती हैं, जबकि लॉन्ग पोलिंग और बैकग्राउंड जॉब्स बाधित हो जाती हैं। Kubernetes, Service, लोड बैलेंसर और प्रोसेस में टर्मिनेशन की टाइमलाइन समझाएं, फिर ड्रेनिंग, कैंसिलेशन, रीट्राइज़ और वेरिफिकेशन को डिज़ाइन करें। मुख्य कौशल शटडाउन के दौरान कनेक्शन्स और साइड इफेक्ट्स को सीमित करना है, इसलिए यह बैकएंड से संबंधित है।
इंटरव्यूअर क्या मूल्यांकन करता है
एक बेहतरीन उत्तर Pod डिलीशन, EndpointSlice अपडेट्स, लोड-बैलेंसर प्रोपेगेशन, preStop, SIGTERM और SIGKILL को अलग-अलग स्पष्ट करता है। SIGTERM प्राप्त होने का अर्थ यह नहीं है कि ट्रैफ़िक रुक गया है। लंबे समय तक चलने वाले कनेक्शन्स, कतार (queue) जॉब्स, इडेम्पोटेंट रीट्राइज़, अचानक नोड पावर लॉस और अपर्याप्त ग्रेस पीरियड को कवर करें।
पहले स्पष्ट करने योग्य प्रश्न
- क्या सर्विस शॉर्ट रिक्वेस्ट, SSE, WebSocket, या लॉन्ग पोलिंग है? क्या कनेक्शन्स को माइग्रेट किया जा सकता है?
- readiness, liveness, और startup प्रोब्स क्या चेक करते हैं, और क्या एप्लिकेशन ड्रेन स्टेट को एक्सपोज़ करता है?
- क्या preStop एक sleep, एक HTTP हुक, या एप्लिकेशन ड्रेन एंडपॉइंट है? अंतिम एग्जिट कौन करता है?
- क्या Pod वर्कर्स चलाता है, और लीज़ तथा डुप्लिकेट डिलीवरी को कैसे संभाला जाता है?
- इनग्रेस लोड बैलेंसर, सर्विस मेश और क्लाउड LB के प्रोपेगेशन डिले क्या हैं?
30-सेकंड उत्तर फ्रेमवर्क
“पहले एप्लिकेशन को not-ready मार्क करें और नया काम स्वीकार करना बंद करें, फिर एंडपॉइंट और लोड-बैलेंसर प्रोपेगेशन का इंतज़ार करें। ड्रेनिंग शुरू करें: शॉर्ट रिक्वेस्ट्स को पूरा करें, लॉन्ग-लिव्ड कनेक्शन्स को बंद या माइग्रेट करें, और वर्कर्स को नए जॉब्स क्लेम करने से रोकें जबकि वे उन लीज़ को रिलीज़ कर दें जिन्हें वे पूरा नहीं कर सकते। preStop केवल एक समन्वय विंडो (coordination window) है; SIGTERM क्लीनअप करता है। ग्रेस पीरियड में p99 प्रोपेगेशन, ड्रेनिंग और क्लीनअप शामिल होना चाहिए, जिसमें SIGKILL केवल इसकी समाप्ति के बाद ही भेजा जाए। यह साबित करने के लिए कि कोई रिक्वेस्ट नहीं छूटी या कोई डुप्लिकेट प्रभाव नहीं हुआ, कनेक्शन और जॉब मेट्रिक्स के साथ रिलीज़ का परीक्षण करें।”
चरण-दर-चरण समाधान
टाइमलाइन बनाएं: कंट्रोलर Pod को डिलीट करता है, kubelet टर्मिनेशन शुरू करता है, EndpointSlice और लोड बैलेंसर एसिंक्रोनस रूप से एंडपॉइंट को हटाते हैं, और कंटेनर SIGTERM से पहले preStop चला सकता है। क्योंकि प्रोपेगेशन एसिंक्रोनस है, एप्लिकेशन को ड्रेनिंग की जानकारी मिलते ही नए काम को अस्वीकार कर देना चाहिए, भले ही ट्रैफ़िक अभी भी पुराने पते पर आ रहा हो।
ready और draining स्टेट्स को अलग रखें। शटडाउन पाथ ड्रेनिंग सेट करता है, readiness को फ़ेल करता है, और नए कनेक्शन्स स्वीकार करना बंद कर देता है या रीट्राई करने योग्य रिस्पॉन्स लौटाता है। मौजूदा शॉर्ट रिक्वेस्ट्स पूरी होती हैं। SSE, WebSocket और लॉन्ग पोलिंग को क्लोज़ सिग्नल, कर्सर या रिज़्यूमे टोकन प्राप्त होना चाहिए ताकि क्लाइंट सुरक्षित रूप से पुनः कनेक्ट हो सके।
preStop sleep एप्लिकेशन लॉजिक की जगह नहीं ले सकता। यह केवल प्रोपेगेशन का समय खरीदता है और ग्रेस पीरियड की खपत करता है। ऐसे एप्लिकेशन ड्रेन एंडपॉइंट को प्राथमिकता दें जो स्टार्ट टाइम और शेष बजट रिकॉर्ड करता है; SIGTERM हैंडलर नए काम को रोकता है, लिसनर को बंद करता है, सक्रिय रिक्वेस्ट्स की प्रतीक्षा करता है, और कनेक्शन पूल्स को रिलीज़ करता है।
वर्कर ड्रेनिंग को HTTP ड्रेनिंग से अलग डिज़ाइन करें। नए संदेश क्लेम करना बंद करें। सक्रिय जॉब्स को लीज़ या विज़िबिलिटी टाइमआउट से सुरक्षित रखें, और जब शेष बजट अपर्याप्त हो तो उन्हें रिलीज़ करें ताकि दूसरा वर्कर रीट्राई कर सके। जॉब राइट्स और बाहरी प्रभावों के लिए इडेम्पोटेंसी कीज़ की आवश्यकता होती है; एक जबरन बंद किए गए Pod को दो बार चार्ज या शिप नहीं करना चाहिए।
मापे गए p99 मानों के आधार पर terminationGracePeriodSeconds चुनें: इनग्रेस प्रोपेगेशन, सबसे लंबी अनुमत रिक्वेस्ट, कनेक्शन क्लोज़, वर्कर क्लीनअप और लॉग फ़्लशिंग, साथ ही जिटर मार्जिन। एक बार डेडलाइन समाप्त हो जाने पर kubelet जबरन टर्मिनेशन कर सकता है; अधूरी रिक्वेस्ट्स और इन-प्रोसेस स्टेट finally के निष्पादित होने पर निर्भर नहीं रह सकते।
नोड मेंटेनेंस Pod डिलीशन से भिन्न है। Kubernetes ग्रेसफुल नोड शटडाउन kubelet और Pods को एक नियोजित विंडो देता है, लेकिन पावर लॉस, कर्नेल पैनिक और जबरन होस्ट रीस्टार्ट ऐसा नहीं करते। महत्वपूर्ण जॉब्स के लिए ड्यूरेबल चेकपॉइंट्स, मल्टीपल रेप्लिकास और कतार-आधारित रिकवरी की आवश्यकता होती है।
रोलिंग रिलीज़, मैन्युअल डिलीशन, नोड ड्रेन, धीमे LB प्रोपेगेशन, लंबे कनेक्शन्स और SIGTERM के बाद टाइमआउट को वेरिफ़ाय करें। 5xx, डिस्कनेक्ट्स, कंप्लीशन रेट, ड्रेनिंग रिजेक्शन, जॉब रीट्राइज़, डुप्लिकेट इफेक्ट्स, एंडपॉइंट-रिमूवल डिले और फोर्स्ड Pod किल्स की जाँच करें, जो सभी रिलीज़ वर्ज़न से संबंधित हों।
मॉडल उच्च-गुणवत्ता उत्तर
“मैं preStop: sleep 30 को ग्रेसफुल शटडाउन नहीं मानूँगा। शटडाउन सिग्नल पर, एप्लिकेशन खुद को ड्रेनिंग के रूप में मार्क करता है, readiness को फ़ेल करता है, और नया काम स्वीकार करना बंद कर देता है। एंडपॉइंट और LB अपडेट्स एसिंक्रोनस रूप से प्रोपेगेट होते हैं, इसलिए पुराना इंस्टेंस अभी भी नई रिक्वेस्ट्स को अस्वीकार करता है। शॉर्ट रिक्वेस्ट्स पूरी होती हैं; SSE और WebSocket कनेक्शन्स को क्लोज़ या रिज़्यूमे टोकन मिलता है; वर्कर्स जॉब क्लेम करना बंद कर देते हैं और उन लीज़ को रिलीज़ करते हैं जिन्हें वे पूरा नहीं कर सकते।
preStop केवल प्रोपेगेशन का समय खरीदता है। SIGTERM हैंडलर लिसनर को बंद करता है, सक्रिय रिक्वेस्ट्स की प्रतीक्षा करता है, पूल्स को रिलीज़ करता है, और एक तय डेडलाइन से पहले एग्जिट करता है। मैं मापे गए p99 प्रोपेगेशन, सबसे लंबी रिक्वेस्ट, वर्कर क्लीनअप और लॉग फ़्लशिंग से ग्रेस पीरियड का आकार तय करता हूँ। परीक्षण रोलिंग रिलीज़, नोड ड्रेन, लंबे कनेक्शन्स, क्रैश और फ़ोर्स किल को कवर करते हैं, जिससे यह सुनिश्चित होता है कि कोई खोई हुई रिक्वेस्ट, डुप्लिकेट प्रभाव, या अनरिकवर्ड जॉब्स न हों।”
सामान्य गलतियाँ
- केवल SIGTERM का इंतज़ार करना → प्रोपेगेटेड ट्रैफ़िक अभी भी पुराने Pod तक पहुँचता है → readiness को फ़ेल करें और पहले ड्रेनिंग में प्रवेश करें।
- ड्रेनिंग के बजाय एक निश्चित sleep का उपयोग करना → प्रोपेगेशन या रिक्वेस्ट की अवधि बदलने पर यह टूट जाता है → शेष डेडलाइन के आधार पर लॉजिक चलाएं।
- Pod को रोकना लेकिन कतार के जॉब्स को क्लेम करते रहना → फोर्स्ड किल से काम डुप्लिकेट होता है → क्लेम करना बंद करें और लीज़ रिलीज़ करें।
- लंबे कनेक्शन्स को सामान्य रिक्वेस्ट मानना → क्लाइंट्स रिज़्यूमे नहीं कर पाते → क्लोज़ सिग्नल्स और कर्सर भेजें।
- औसत लेटेंसी से ग्रेस का आकार निर्धारित करना → p99 रिक्वेस्ट्स को SIGKILL मिलता है → टेल लेटेंसी और प्रोपेगेशन को मापें।
- यह मान लेना कि
finallyहमेशा चलता है → फ़ोर्स किल और पावर लॉस क्लीनअप को स्किप कर देते हैं → महत्वपूर्ण स्टेट को परसिस्ट करें। - केवल Pod स्टेटस देखना → धीमे LB प्रोपेगेशन और डिस्कनेक्ट्स को मिस करना → एंडपॉइंट्स, रिक्वेस्ट्स और रिलीज़ मेट्रिक्स को सहसंबंधित करें।
- ड्रेनिंग के दौरान liveness को फ़ेल करना → रीस्टार्ट स्टॉर्म शुरू होना → readiness का अर्थ ट्रैफ़िक पात्रता है; liveness का अर्थ प्रोसेस हेल्थ है।
फ़ॉलो-अप प्रश्न और उत्तर
फ़ॉलो-अप 1: readiness फ़ेल होने के बाद भी रिक्वेस्ट्स क्यों आ सकती हैं?
एंडपॉइंट, सर्विस-मेश और क्लाउड लोड-बैलेंसर अपडेट्स देरी से प्रोपेगेट होते हैं, और मौजूदा कनेक्शन्स अपने आप माइग्रेट नहीं होते हैं। ड्रेनिंग एप्लिकेशन को नए काम को अस्वीकार करना चाहिए और मौजूदा कनेक्शन्स को सुरक्षित रूप से बंद करना चाहिए।
फ़ॉलो-अप 2: preStop sleep कितनी लंबी होनी चाहिए?
अनुमान न लगाएं। एंडपॉइंट और LB प्रोपेगेशन p99 को मापें, इसे रिक्वेस्ट और वर्कर क्लीनअप बजट के साथ जोड़ें, और sleep को एक सीमित समन्वय विंडो के रूप में मानें।
फ़ॉलो-अप 3: आप WebSockets को ग्रेसफुली कैसे बंद करते हैं?
नए कनेक्शन्स स्वीकार करना बंद करें और पुनः कनेक्ट करने के मार्गदर्शन के साथ एक क्लोज़ कोड भेजें। क्लाइंट्स को सेशन या कर्सर के साथ फिर से शुरू करने दें, और साइड इफेक्ट्स को दोबारा दोहराने से बचने के लिए पर्याप्त स्टेट परसिस्ट करें।
फ़ॉलो-अप 4: क्या होगा यदि कोई Pod किसी जॉब के बीच में ही समाप्त हो जाए?
जॉब स्टेट और एक लीज़ को परसिस्ट करें। विज़िबिलिटी टाइमआउट के बाद एक नया वर्कर इसे क्लेम करता है; इडेम्पोटेंसी कीज़ या स्टेटस क्वेरीज़ बाहरी प्रभावों की रक्षा करती हैं। इन-प्रोसेस finally पर निर्भर न रहें।
फ़ॉलो-अप 5: क्या नोड पावर लॉस ग्रेसफुल हो सकता है?
विश्वसनीय रूप से नहीं। नियोजित नोड-शटडाउन हैंडलिंग केवल देखने योग्य मेंटेनेंस फ़्लो को कवर करती है; पावर लॉस और कर्नेल क्रैश के लिए रेप्लिकास, ड्यूरेबल चेकपॉइंट्स और रीट्राई करने योग्य जॉब्स की आवश्यकता होती है।
फ़ॉलो-अप 6: आप ग्रेस पीरियड कैसे चुनते हैं?
एंडपॉइंट प्रोपेगेशन, अधिकतम रिक्वेस्ट, लॉन्ग-कनेक्शन क्लोज़, लीज़ रिलीज़, कनेक्शन क्लीनअप और लॉग फ़्लश को जोड़ें, फिर औसतों के बजाय मापे गए p99 और मार्जिन के साथ सत्यापित करें।
फ़ॉलो-अप 7: ड्रेनिंग के दौरान रीस्टार्ट स्टॉर्म से कैसे बचें?
liveness को स्वस्थ रखते हुए readiness को फ़ेल करें। प्रोब की ज़िम्मेदारियों को अलग करें ताकि “अस्थायी रूप से ट्रैफ़िक स्वीकार न करने” को क्रैश हुई प्रोसेस न समझ लिया जाए।