सिस्टम डिज़ाइन इंटरव्यू: आप Kubernetes Sidecar जॉब के लाइफ़साइकिल को कैसे डिज़ाइन करेंगे?

प्रॉम्प्ट और संदर्भ

एक बैच Job को लॉगिंग, प्रॉक्सी या फ़ाइल-सिंक Sidecar की आवश्यकता होती है। मुख्य कंटेनर समाप्त होने के बाद, Job को Pending अवस्था में नहीं रहना चाहिए क्योंकि कोई हेल्पर हमेशा के लिए चल रहा हो; Pod टर्मिनेशन के दौरान, Sidecar के पास बाहर निकलने से पहले फ्लश करने का अवसर होना चाहिए। Kubernetes Sidecar लाइफ़साइकिल, शेयर्ड रिसोर्सेज और विफलता व्यवहार की व्याख्या करें।

यह प्रश्न सिस्टम-डिज़ाइन, प्लेटफ़ॉर्म-इंजीनियरिंग और क्लाउड-नेटिव भूमिकाओं के लिए उपयुक्त है। मुख्य बात यह है कि ऑब्जर्वेबल और रिट्राइ करने योग्य सीमाओं को डिज़ाइन करते हुए Pod, Job, मुख्य-कंटेनर और Sidecar की कंप्लीशन शर्तों को अलग रखा जाए।

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

एक मजबूत उत्तर में यह रेखांकित किया जाता है कि स्थिर Sidecar मॉडल को restartPolicy: Always वाले एक init कंटेनर के रूप में व्यक्त किया जा सकता है; यह मुख्य कंटेनर के साथ समवर्ती (concurrently) चलता है, नेटवर्क और वैकल्पिक रूप से वॉल्यूम साझा करता है, मुख्य कंटेनर समाप्त होने के बाद Job को पूरा होने की अनुमति देता है, और मुख्य एप्लिकेशन के बाद डिक्लेरेशन के विपरीत क्रम में समाप्त किया जाता है। इसे प्रोब्स, रिसोर्स बजट, रिट्राइज, इडेम्पोटेंसी और सिग्नल्स को भी कवर करना चाहिए।

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

क्या Sidecar लॉगिंग, प्रॉक्सीइंग, सिंक या सुरक्षा प्रदान करता है, और क्या मुख्य कार्य शुरू होने से पहले इसका तैयार होना आवश्यक है?
मुख्य कार्य की सफलता, विफलता, टाइमआउट और रिट्राइ के बाद कौन सा डेटा सुरक्षित रहना चाहिए?
शेयर्ड-वॉल्यूम का आकार, लिखने की दर, अनुमतियाँ और क्लीनअप विंडो क्या हैं?
क्या Job की पूर्णता मुख्य कंटेनर के बाहर निकलने पर आधारित है, एक स्पष्ट Sidecar ड्रेन पर, या दोनों पर?
कौन से मेट्रिक्स, इवेंट्स, लॉग्स और ट्रेसेस दोनों कंटेनरों के बीच विफलताओं का पता लगाते हैं?

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

“मैं Sidecar को एक स्पष्ट रेडीनेस, विफलता और ड्रेन अनुबंध के साथ एक समवर्ती सहायता सेवा के रूप में मॉडल करूँगा। मैं Kubernetes Sidecar सेमांटिक्स का उपयोग करूँगा ताकि शेयर्ड-वॉल्यूम और लॉग-ड्रेन पाथ को संरक्षित करते हुए मुख्य कंटेनर समाप्त होने पर Job पूरा हो सके। प्रत्येक कंटेनर को प्रोब्स, रिसोर्स बजट और ऑब्जर्वेबिलिटी मिलती है; टाइमआउट्स, रिट्राइज, SIGTERM और इडेम्पोटेंट क्लीनअप को परिभाषित किया जाता है। मैं सफलता, विफलता, Sidecar क्रैश और नोड निष्कासन (eviction) का परीक्षण करूँगा।”

चरण-दर-चरण समाधान

चरण 1: भूमिकाओं और पूर्णता को परिभाषित करें

मुख्य कंटेनर व्यावसायिक परिणाम का स्वामी होता है; Sidecar सहायता प्रदान करता है। Job की सफलता मुख्य कार्य पर केंद्रित होनी चाहिए, जबकि यह परिभाषित होना चाहिए कि Sidecar को एक निश्चित विंडो के भीतर क्या ड्रेन करना है। कभी भी किसी असीमित हेल्पर को एकमात्र कंप्लीशन शर्त न बनाएं।

चरण 2: Sidecar प्रतिनिधित्व चुनें

स्थिर Kubernetes मॉडल restartPolicy: Always वाले एक init कंटेनर का उपयोग करता है। यह Pod स्टार्टअप रेडीनेस में भाग लेता है और फिर मुख्य कंटेनर के साथ चलता है, जो लॉगिंग या प्रॉक्सी सेवाओं के लिए उपयुक्त है जिन्हें अपने स्वयं के लाइफ़साइकिल की आवश्यकता होती है।

yaml

initContainers:
  - name: log-shipper
    image: example/log-shipper:1.0
    restartPolicy: Always
    volumeMounts:
      - name: shared-data
        mountPath: /var/app

चरण 3: शेयर्ड वॉल्यूम और बजट डिज़ाइन करें

Sidecar और मुख्य कंटेनर एक नेटवर्क नेमस्पेस साझा करते हैं और आवश्यकता पड़ने पर एक वॉल्यूम साझा कर सकते हैं। राइट वॉल्यूम, रोटेशन, अनुमतियाँ, एफेमरल स्टोरेज, CPU और मेमोरी को सीमित करें ताकि लॉग का अचानक बढ़ना कार्य को बाधित न करे या निष्कासन व्यवहार को विकृत न करे।

चरण 4: प्रोब्स और रेडीनेस स्थापित करें

Sidecar रेडीनेस का अर्थ है कि यह सेवा दे सकता है, यह नहीं कि मुख्य कार्य सफल रहा; लाइवनेस विफलता के लिए पुनरारंभ (restart) और बैकऑफ़ नीति की आवश्यकता होती है। यदि मुख्य कंटेनर को इसके लिए प्रतीक्षा करनी चाहिए, तो एक निश्चित स्लीप का अनुमान लगाने के बजाय एक ऑब्जर्वेबल रेडीनेस सिग्नल प्रदर्शित करें।

चरण 5: सफलता, विफलता और पुनः प्रयास को संभालें

मुख्य कार्य की सफलता के बाद, Sidecar को शेष आउटपुट को पढ़ना और भेजना चाहिए, फिर एक स्पष्ट ड्रेन सिग्नल या टाइमआउट पर बाहर निकलना चाहिए। मुख्य कार्य की विफलता के बाद, डायग्नोस्टिक्स को सुरक्षित रखें। दोहराए गए शुल्कों या अपलोड से बचने के लिए रिट्राइज को वॉल्यूम क्लीनअप, रिमोट डिलीवरी और व्यावसायिक राइट्स को इडेम्पोटेंट बनाना चाहिए।

चरण 6: समाप्ति और सिग्नल्स डिज़ाइन करें

Pod टर्मिनेशन पर, kubelet Sidecars को समाप्त करने से पहले मुख्य एप्लिकेशन कंटेनर के रुकने की प्रतीक्षा करता है, फिर Pod विनिर्देश में उनके दिखने के विपरीत क्रम में Sidecars को बंद करता है। एप्लिकेशन को अभी भी सही SIGTERM हैंडलिंग, एक सीमित समाप्ति ग्रेस अवधि और एक SIGKILL फ़ॉलबैक की आवश्यकता होती है; ग्रेसफुल निकास की गारंटी नहीं है।

चरण 7: Job स्थिति और ऑब्जर्वेबिलिटी को कनेक्ट करें

मुख्य निकास कोड, Sidecar ड्रेन स्थिति, Job शर्तें, रिट्राइ काउंट, वॉल्यूम वॉटरमार्क और डिलीवरी लेटेंसी रिकॉर्ड करें। अलर्ट को केवल एक Pod Ready सिग्नल पर निर्भर रहने के बजाय मुख्य विफलता, Sidecar का कभी तैयार न होना, ड्रेन टाइमआउट और नोड निष्कासन में अंतर करना चाहिए।

चरण 8: विफलता मैट्रिक्स को मान्य करें

त्वरित मुख्य सफलता, व्यावसायिक विफलता, Sidecar क्रैश, अनुपलब्ध लॉग बैकएंड, पूर्ण शेयर्ड वॉल्यूम, Job टाइमआउट, नोड निष्कासन और रोलिंग अपग्रेड का परीक्षण करें। Job पूर्णता, ट्रेस करने योग्य आउटपुट, इडेम्पोटेंट रिट्राइ और अंतिम लॉग सेगमेंट के संरक्षण को सत्यापित करें।

ट्रेड-ऑफ़ और सीमाएँ

Sidecars उन सपोर्ट फ़ंक्शंस के लिए उपयुक्त हैं जो कार्य के साथ मजबूती से जुड़े हैं, जो नेटवर्क या फ़ाइलों को साझा करते हैं और जिन्हें एक स्वतंत्र लाइफ़साइकिल की आवश्यकता होती है। प्रत्येक प्लेटफ़ॉर्म चिंता को Sidecar में रखने से रिसोर्सेज, अपग्रेड और विफलता के क्षेत्र बढ़ जाते हैं; एक नोड-स्तरीय DaemonSet, प्रबंधित लॉगिंग या अलग सेवा एक बेहतर सीमा हो सकती है।

Kubernetes टर्मिनेशन ऑर्डरिंग डेटा हानि के जोखिम को कम करती है लेकिन बाहरी नेटवर्क की उपलब्धता की गारंटी नहीं देती है या एप्लिकेशन के फ्लश, रिट्राइ और निरंतरता लॉजिक की जगह नहीं लेती है। एक स्पष्ट अनुबंध के माध्यम से Job की सफलता और Sidecar ड्रेन को कनेक्ट करें।

रोलआउट योजना और प्रमाण

एक लॉगिंग Job से शुरुआत करें: मुख्य कंटेनर, Sidecar, शेयर्ड वॉल्यूम, प्रोब्स, रिसोर्स सीमाएं और ड्रेन टाइमआउट। रिट्राइज और अलर्ट जोड़ने से पहले पूर्णता की शर्तों और प्रत्येक निकास पथ को रिकॉर्ड करें।

Sidecar संस्करण, इमेज स्रोत, वॉल्यूम अनुमतियाँ, प्रोब्स, समाप्ति विंडो, Job शर्तें और इडेम्पोटेंसी का दस्तावेजीकरण करें। रिसोर्स वॉटरमार्क और अंतिम-आउटपुट ट्रैसेबिलिटी को सत्यापित करने के लिए यथार्थवादी लॉग वॉल्यूम और नोड-निष्कासन प्रयोगों का उपयोग करें।

सामान्य गलतियाँ और फॉलो-अप

एक नियमित init कंटेनर को समवर्ती Sidecar मानना

एक नियमित init कंटेनर मुख्य कंटेनर से पहले समाप्त हो जाता है और एक निरंतर प्रॉक्सी या लॉगर प्रदान नहीं कर सकता है। जब समवर्तीता की आवश्यकता हो तो स्थिर Sidecar सेमांटिक्स का उपयोग करें।

Sidecar के लिए हमेशा प्रतीक्षा करना

Sidecar को एक ड्रेन सिग्नल और टाइमआउट दें। Job की सफलता को मुख्य कार्य पर केंद्रित करें और सत्यापित करें कि कंट्रोलर इसके बाद समाप्त होता है।

केवल मुख्य कंटेनर को सीमित करना

Sidecar का CPU, मेमोरी और एफेमरल स्टोरेज शेड्यूलिंग और निष्कासन को प्रभावित करते हैं। दोनों भूमिकाओं के लिए requests और limits सेट और मॉनिटर करें।

केवल Pod Ready पर निर्भर रहना

Ready व्यावसायिक सफलता या डिलीवर किए गए लॉग को साबित नहीं करता है। Job शर्तों, निकास कोड, ड्रेन स्थिति, कतार वॉटरमार्क और डिलीवरी लेटेंसी को संयोजित करें।

क्या होगा यदि अंतिम लॉग सेगमेंट अभी भी खो जाता है?

वॉल्यूम फ्लश, डिलीवरी रिट्राइ, ड्रेन सिग्नलिंग, समाप्ति ग्रेस अवधि और बैकएंड उपलब्धता का निरीक्षण करें; केवल स्लीप बढ़ाने के बजाय विफलता मैट्रिक्स को पुनः चलाएँ।