सिस्टम डिज़ाइन इंटरव्यू: आप Kubernetes नेटिव साइडकार पर सुरक्षित रूप से माइग्रेट कैसे करेंगे?

प्रॉम्प्ट और लागू संदर्भ

आप एक ऐसे Kubernetes वर्कलोड के मालिक हैं जो किसी एप्लिकेशन के साथ एक लॉग एजेंट, सर्विस-मेश प्रॉक्सी, या लोकल कैश डीमन चलाता है। टीम उस हेल्पर को एक नियमित कंटेनर से Kubernetes नेटिव साइडकार में माइग्रेट करना चाहती है। एप्लिकेशन को हेल्पर के तैयार होने तक प्रतीक्षा करनी चाहिए, हेल्पर की विफलताओं के लिए स्पष्ट उपलब्धता सीमाएं (availability boundaries) होनी चाहिए, और डिज़ाइन में Jobs, रोलिंग रिलीज़, रिसोर्स कोटा और रोलबैक शामिल होने चाहिए। एक माइग्रेशन योजना का प्रस्ताव दें और वर्ज़न स्क्यू (version skew), प्रोब्स, समाप्ति क्रम और विफलता प्रबंधन की व्याख्या करें।

यह एक सिस्टम-डिज़ाइन प्रश्न है। यहां मूल्यांकन आपकी सीमाओं और ट्रेड-ऑफ़ पर सोचने की क्षमता का है, न कि रटे हुए YAML अंश का। लाइफसाइकिल, कम्पैटिबिलिटी, रिसोर्सेज, ऑब्ज़र्वेबिलिटी और रोलबैक को कवर करें।

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

• सर्विस-लेवल ऑब्जेक्टिव्स (SLO) को स्टार्टअप, तत्परता (readiness), समाप्ति और विफलता नीतियों में बदलना।
• एक नेटिव साइडकार, एक नियमित कंटेनर, एक अलग Deployment और एक DaemonSet के बीच की सीमा को समझाना।
• API सर्वर, नोड्स, वेबहुक्स और क्लाइंट्स के बीच वर्ज़न जोखिमों की पहचान करना।
• रिसोर्स बजट, चरणबद्ध रोलआउट, मेट्रिक्स और रोलबैक के साथ माइग्रेशन जोखिम को कम करना।
• Job समाप्ति, अटकी हुई प्रॉक्सी, विफल प्रोब्स और नोड अपग्रेड जैसे विपरीत उदाहरणों (counterexamples) को संभालना।

Amazon की SDE II तैयारी सामग्री सिस्टम-डिज़ाइन मूल्यांकन को व्यावहारिकता, सटीकता, दक्षता, विश्वसनीयता, अनुकूलन और स्केलेबिलिटी के संदर्भ में वर्णित करती है। यह प्रश्न आपसे उन लक्ष्यों को Pod लाइफसाइकिल और रिलीज़ नियंत्रणों पर लागू करने के लिए कहता है।

स्पष्टीकरण हेतु प्रश्न

1. क्या हेल्पर प्रति Pod एक कॉपी है या प्रति नोड एक कॉपी? क्या इसे एप्लिकेशन के नेटवर्क नेमस्पेस या वॉल्यूम को साझा करना होगा?
2. क्या हेल्पर के तैयार होने से पहले एप्लिकेशन ट्रैफ़िक प्राप्त कर सकता है? क्या स्टार्टअप विफलता रिलीज़ को रोकती है, व्यवहार को ख़राब करती है, या बायपास की अनुमति देती है?
3. क्या यह एक लंबे समय तक चलने वाली सेवा है, एक बार चलने वाला Job है, या दोनों? क्या इसे समाप्ति के दौरान लॉग्स को फ्लश करना चाहिए या डेटा अपलोड करना चाहिए?
4. क्या क्लस्टर, API सर्वर और नोड्स में Kubernetes वर्ज़न संरेखित हैं? क्या कोई एडमिशन वेबहुक, टेम्पलेट रेंडरर या क्लाइंट अज्ञात फ़ील्ड्स को छोड़ सकता है?
5. हेल्पर के CPU, मेमोरी, एफेमरल-स्टोरेज और नेटवर्क बजट क्या हैं? क्या इसकी विफलता एप्लिकेशन के एरर बजट की खपत करती है?
6. क्या आप नियमित-कंटेनर टेम्पलेट को रोलबैक स्विच के रूप में बनाए रखते हुए नेमस्पेस या वर्कलोड द्वारा कैनरी रोलआउट कर सकते हैं?

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

लक्ष्य से शुरुआत करें: हेल्पर और एप्लिकेशन को एक ही Pod में रखें, उन्हें क्रम में शुरू करें, व्यवहार को देखने योग्य बनाएं, और अनिश्चित काल तक अवरोधित करने वाले हेल्पर की अनुमति दिए बिना रोलबैक को तेज़ रखें। कंटेनर-स्तरीय restartPolicy: Always, एक सार्थक तत्परता प्रोब (readiness probe), और एक स्पष्ट रिसोर्स बजट के साथ initContainers में एक नेटिव साइडकार लागू करें। क्लस्टर और एडमिशन जांच के साथ कम्पैटिबिलिटी की रक्षा करें। दो टेम्पलेट्स को चरणों में रोल आउट करें, स्टार्टअप लेटेंसी और त्रुटि दरों की तुलना करें, सीमा उल्लंघन होने पर पुराने रूप में वापस लौटें, और Job समाप्ति तथा समाप्ति फ्लश का अलग से परीक्षण करें।

चरण-दर-चरण विस्तृत उत्तर

1. पहले लाइफसाइकिल सीमा तय करें

एक Kubernetes नेटिव साइडकार एक विशेष init कंटेनर है: कंटेनर-स्तरीय restartPolicy: Always इसे इनिशियलाइज़ेशन के दौरान शुरू होने और चलते रहने की अनुमति देता है। यह अभी भी init-कंटेनर क्रम का पालन करता है, इसलिए बाद के init कंटेनर और एप्लिकेशन कंटेनर इसके उपयोग योग्य होने की प्रतीक्षा करते हैं। "प्रॉक्सी पहले तैयार है" एप्लिकेशन पोलिंग लूप के बजाय एक Pod-स्तरीय संरचनात्मक गारंटी बन जाती है।

एप्लिकेशन और साइडकार Pod नेटवर्क और स्टोरेज नेमस्पेस साझा करते हैं। यह Unix सॉकेट, लॉग वॉल्यूम या लोकल प्रॉक्सी पोर्ट के लिए उपयोगी है। यदि हेल्पर केवल नोड-स्तरीय क्षमता प्रदान करता है, तो प्रति Pod लागत चुकाने के बजाय DaemonSet का मूल्यांकन करें।

2. तत्परता (Readiness) और विफलता नीति को परिभाषित करें

हेल्पर को एक readinessProbe दें जो वास्तविक क्षमता का प्रतिनिधित्व करता हो: कंट्रोल-प्लेन कॉन्फ़िगरेशन लोड हो गया है, लिसनिंग पोर्ट उपलब्ध है, और महत्वपूर्ण प्रमाणपत्र मान्य हैं। साइडकार की तत्परता Pod की तत्परता को प्रभावित कर सकती है, इसलिए एक विफल प्रोब पूरे Pod को सेवा से हटा सकता है। एक प्रोब केवल स्थिति की रिपोर्ट करता है; यह पुनः प्रयासों (retries), दर सीमाओं (rate limits), या ग्रेसफुल डिग्रेडेशन का विकल्प नहीं है।

स्टार्टअप विफलता, चलते समय क्रैश (in-process crash), और अस्थायी रूप से अनुपलब्ध निर्भरता को अलग करें। स्टार्टअप विफलता आम तौर पर Pod को सेवा से बाहर रखती है। चलते समय होने वाले क्रैश को Always द्वारा पुनः प्रारंभ किया जाता है, लेकिन पुनः आरंभ गणना (restart count), पुनर्प्राप्ति समय और त्रुटि दर को यह दिखाना चाहिए कि क्या SLO पहले ही खो चुका है। एक वैकल्पिक हेल्पर में बायपास हो सकता है; एक सुरक्षा या ऑथराइजेशन प्रॉक्सी को विफल होने पर बंद (fail closed) होना चाहिए और इसका एरर बजट पार होने पर रोलआउट को तुरंत रोक देना चाहिए।

3. समाप्ति, Jobs और फ्लशिंग को संभालें

नेटिव साइडकार एप्लिकेशन कंटेनर के बाद समाप्त होते हैं, और एकाधिक साइडकार उल्टे क्रम में बंद होते हैं। इसलिए एप्लिकेशन के बाहर निकलने के बाद एक लॉग एजेंट बफ़र्स को खाली कर सकता है, लेकिन समाप्ति ग्रेस अवधि (termination grace period) की एक सख्त ऊपरी सीमा होनी चाहिए। फ्लशिंग टाइमआउट होने पर खोए हुए डेटा की मात्रा रिकॉर्ड करें; कभी भी अनिश्चित काल तक प्रतीक्षा न करें।

किसी Job के लिए, सत्यापित करें कि कंट्रोलर मुख्य कंटेनर के पूरा होने को ही Job की समाप्ति माने, न कि साइडकार के लिए हमेशा प्रतीक्षा करता रहे। Job पूरा होने से पहले साइडकार पुनः प्रारंभ होना जारी रख सकता है, इसलिए कार्य परिणाम, साइडकार फ्लश परिणाम और अंतिम डेटा अखंडता को अलग-अलग संकेतों और अलर्ट्स के रूप में प्रदर्शित करें।

4. वर्ज़न और म्यूटेशन पथों की जांच करें

नेटिव साइडकार Kubernetes v1.33 में स्थिर (stable) हैं और डिफ़ॉल्ट रूप से सक्षम हैं; यह क्षमता v1.29 से बीटा थी और डिफ़ॉल्ट रूप से सक्षम थी। माइग्रेशन से पहले, प्रत्येक नोड पूल पर वास्तविक kubelet, API-सर्वर, एडमिशन घटकों और फीचर गेट्स की जांच करें।

एक पुराना म्यूटेटिंग वेबहुक, टेम्पलेट टूल या क्लाइंट कंटेनर-स्तरीय restartPolicy को नहीं समझ सकता है और ऑब्जेक्ट को दोबारा लिखते समय इसे छोड़ सकता है। CI में अंतिम ऑब्जेक्ट को मान्य करें, एडमिशन लॉग्स में साइडकार संरचना रिकॉर्ड करें, और एक प्रोब Pod चलाएं जो रनटाइम क्रम की पुष्टि करता हो। यदि श्रृंखला पर भरोसा नहीं किया जा सकता है, तो एक नियमित-कंटेनर फ़ॉलबैक बनाए रखें या माइग्रेशन को रोकें।

5. रिसोर्स और शेड्यूलिंग प्रभाव की गणना करें

साइडकार मुफ़्त नहीं है। इसके CPU, मेमोरी और एफेमरल-स्टोरेज अनुरोध Pod की प्रभावी रिसोर्स गणना में भाग लेते हैं, जो QoS, कोटा और शेड्यूलिंग को प्रभावित करते हैं। requests और limits की गणना के लिए एप्लिकेशन पीक्स, हेल्पर स्टार्टअप पीक्स और बफ़र सीमाओं का उपयोग करें; नोड विखंडन, निष्कासन (evictions), OOMs और स्टार्टअप कतार समय पर नज़र रखें।

यदि हेल्पर को स्वतंत्र स्केलिंग, एक अलग रिलीज़ चक्र, या एक व्यापक विफलता डोमेन की आवश्यकता है, तो एक अलग Deployment अधिक उपयुक्त हो सकता है। एक नेटिव साइडकार शेड्यूलिंग, रिसोर्सेज और रिलीज़ को एक इकाई में जोड़ते हुए स्थानीय साझाकरण और लाइफसाइकिल क्रम प्रदान करता है।

6. कैनरी, ऑब्ज़र्वेबिलिटी और रोलबैक डिज़ाइन करें

दो Pod टेम्पलेट तैयार करें: नेटिव साइडकार और पुराना नियमित-कंटेनर रूप। प्रत्येक बैच के लिए एक स्वचालित स्टॉप स्थिति के साथ, नेमस्पेस, लेबल या वर्कलोड द्वारा रोल आउट करें। कम से कम Pod-निर्माण-से-Ready लेटेंसी, साइडकार तत्परता विफलताएं, पुनः आरंभ गणना, एप्लिकेशन अनुरोध त्रुटियां, बफ़र गहराई, फ्लश हानि, CPU और मेमोरी पीक्स, और Job समाप्ति लेटेंसी को ट्रैक करें।

माइग्रेशन के दौरान, अपेक्षित आकार और देखे गए आकार को रिकॉर्ड करें; केवल एक सफल Deployment ऑब्जेक्ट पर्याप्त नहीं है। यदि कोई वेबहुक फ़ील्ड्स को छोड़ देता है, Ready लेटेंसी बिगड़ जाती है, या हेल्पर पुनः आरंभ सीमा पार कर जाता है, तो विस्तार रोकें और पुराने टेम्पलेट पर स्विच करें। रोलबैक को यह भी जांचना चाहिए कि पुराने टेम्पलेट नए कॉन्फ़िगरेशन, वॉल्यूम प्रारूपों या पोर्ट मान्यताओं को इनहेरिट न करें।

7. सुरक्षा और ऑब्ज़र्वेबिलिटी को सीमा के भीतर रखें

चूंकि साइडकार Pod नेटवर्क और वॉल्यूम साझा करता है, इसलिए इसके पास Pod का एक्सेस सरफेस होता है। इसे न्यूनतम विशेषाधिकार (least privilege), केवल-पढ़ने-योग्य रूट फ़ाइल सिस्टम, एक स्पष्ट सर्विस अकाउंट और नेटवर्क नीति दें। ऑडिट नियंत्रणों को केवल इसलिए न छोड़ें क्योंकि यह "केवल एक हेल्पर" है। लॉग्स, मेट्रिक्स और ट्रेसेस में Pod, कंटेनर और रिलीज़-वर्ज़न लेबल जोड़ें ताकि एप्लिकेशन विफलताओं को हेल्पर विफलताओं से अलग किया जा सके।

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

मैं पहले हेल्पर को प्रति-Pod निर्भरता के रूप में वर्गीकृत करूंगा और पुष्टि करूंगा कि क्या इसे वास्तव में साझा नेटवर्किंग या स्टोरेज की आवश्यकता है। यदि यह एक नोड-स्तरीय क्षमता है, तो मैं DaemonSet चुनूंगा। माइग्रेशन टेम्पलेट एक नेटिव साइडकार का उपयोग करता है: हेल्पर को initContainers में रखें और कंटेनर-स्तरीय restartPolicy: Always सेट करें। यह init क्रम में शुरू होता है, इसका readinessProbe पुष्टि करता है कि कॉन्फ़िगरेशन और पोर्ट उपयोग योग्य हैं, और उसके बाद ही एप्लिकेशन सेवा में प्रवेश करता है।

मैं विफलता को स्टार्टअप विफलता, चलते समय क्रैश और अस्थायी रूप से अनुपलब्ध निर्भरता में विभाजित करूंगा। एक सुरक्षा प्रॉक्सी विफल होने पर बंद (fail closed) होती है; एक वैकल्पिक संवर्द्धन एक बायपास रखता है। समाप्ति के दौरान, साइडकार का एप्लिकेशन-के-बाद शटडाउन क्रम सीमित फ्लशिंग की अनुमति देता है। Jobs के लिए, मैं मुख्य-कंटेनर समाप्ति और साइडकार फ्लशिंग को अलग से सत्यापित करूंगा ताकि लंबे समय तक चलने वाला हेल्पर Job की स्थिति को अवरुद्ध न कर सके।

रोलआउट से पहले, मैं API सर्वर, प्रत्येक नोड पूल, फीचर गेट्स, वेबहुक्स और टेम्पलेट क्लाइंट्स की जांच करूंगा क्योंकि पुराने उपकरण restartPolicy को छोड़ सकते हैं। CI अंतिम ऑब्जेक्ट को मान्य करता है, और एक कैनरी वास्तविक Pod क्रम और तत्परता को मान्य करता है। रिसोर्स बजट में QoS, कोटा और शेड्यूलिंग में हेल्पर पीक्स शामिल हैं; डैशबोर्ड Ready लेटेंसी, पुनः आरंभ, त्रुटियां, बफ़र्स और हानि दिखाते हैं। दो टेम्पलेट्स बैचों में रोल आउट होते हैं, जिसमें किसी भी सीमा के उल्लंघन पर विस्तार रुक जाता है और पुराने रूप में वापस आ जाता है। यह वर्ज़न, रिसोर्स और विफलता सीमाओं को देखने योग्य रिलीज़ गेट्स में बदलते हुए नेटिव लाइफसाइकिल गारंटी का उपयोग करता है।

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

• यह समझाए बिना YAML पेस्ट करना कि नेटिव साइडकार की आवश्यकता क्यों है या नियमित कंटेनर या अलग वर्कलोड कब बेहतर है।
• restartPolicy: Always को साइडकार कंटेनर परिभाषा के अंदर लिखने के बजाय Pod स्तर पर लिखना।
• केवल livenessProbe को कॉन्फ़िगर करना और यह छोड़ देना कि तत्परता विफलता ट्रैफ़िक और रोलआउट व्यवहार को कैसे बदलती है।
• नोड, वेबहुक और क्लाइंट स्क्यू की जांच किए बिना यह मान लेना कि Kubernetes वर्ज़न पर्याप्त है।
• साइडकार को मुफ़्त मानना और रिसोर्स कोटा, स्टार्टअप पीक्स, बफ़रिंग और QoS प्रभावों को अनदेखा करना।
• केवल लंबे समय तक चलने वाली सेवाओं का परीक्षण करना और Job समाप्ति, फ्लश टाइमआउट और उल्टे समाप्ति क्रम को भूल जाना।
• पुराने टेम्पलेट, पोर्ट्स, वॉल्यूम और एडमिशन आउटपुट की जांच किए बिना केवल इमेज को रोलबैक करना।

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

क्या होगा यदि कोई पुराना नोड नेटिव साइडकार का समर्थन नहीं करता है?

रोलआउट रोकें और नोड पूल द्वारा अलग करें। यदि ऑब्जेक्ट पर कंटेनर-स्तरीय नीति को बनाए रखने के लिए भरोसा नहीं किया जा सकता है, तो नियमित-कंटेनर टेम्पलेट का उपयोग करें या नोड्स को अपग्रेड करें; किसी अज्ञात फ़ील्ड को चुपचाप छोड़ देना कम्पैटिबिलिटी नहीं है।

क्या होता है जब साइडकार तत्परता विफल होती रहती है?

Pod को Ready स्थिति से बाहर रहना चाहिए और रोलआउट कंट्रोलर को विस्तार रोक देना चाहिए। कॉन्फ़िगरेशन त्रुटियों, अनुपलब्ध निर्भरताओं और प्रोब बग्स के बीच अंतर करें, फिर ठीक करें या रोलबैक करें। प्रोब को अत्यधिक अनुमतिपूर्ण बनाकर वास्तविक अनुपलब्धता को न छिपाएं।

क्या Job के मुख्य कंटेनर से बाहर निकलने के बाद भी साइडकार चलता रहता है?

एक नेटिव साइडकार चलना और पुनः प्रारंभ होना जारी रख सकता है, जबकि Job कंट्रोलर मुख्य कंटेनर के पूरा होने को पहचान सकता है। फ्लशिंग को सीमित करें और कार्य परिणाम को डेटा अखंडता से अलग रिकॉर्ड करें ताकि लंबे समय तक चलने वाली हेल्पर गतिविधि को गलत तरीके से कार्य विफलता न समझा जाए।

प्रॉक्सी के लिए एक अलग Deployment का उपयोग क्यों न करें?

अलगाव तब चुनें जब प्रॉक्सी को स्वतंत्र स्केलिंग, रिलीज़ या व्यापक विफलता डोमेन की आवश्यकता हो। नेटिव साइडकार तब चुनें जब स्थानीय सॉकेट्स, साझा नेटवर्किंग और सख्त स्टार्टअप क्रम आवश्यक हों। निर्णय कपलिंग और SLOs पर निर्भर करता है।

माइग्रेशन के बाद बढ़े हुए रिसोर्स दबाव का निदान कैसे करेंगे?

माइग्रेशन से पहले और बाद में प्रभावी Pod अनुरोधों, स्टार्टअप पीक्स, नोड विखंडन, निष्कासन और OOMs की तुलना करें; हेल्पर बफ़र्स और समवर्तीता (concurrency) का निरीक्षण करें। यदि हेल्पर केवल नोड-स्तरीय क्षमता प्रदान करता है, तो DaemonSet का मूल्यांकन करें। यदि इसे Pod में ही रहना है, तो बजट को संशोधित करें या कैनरी आकार को कम करें।

आप कैसे साबित करेंगे कि रोलबैक सुरक्षित है?

पुराना टेम्पलेट हैश बनाए रखें। रोलबैक के दौरान, कंटेनर संरचना, पोर्ट्स, वॉल्यूम, सर्विस अकाउंट और वेबहुक आउटपुट को मान्य करें, फिर Ready लेटेंसी, त्रुटि दर और फ्लश हानि के लिए एक कैनरी बैच की निगरानी करें। संकेतों के सामान्य होने के बाद ही विस्तार जारी रखें।