बैकएंड इंटरव्यू: Job लाइफसाइकिल के लिए आप Kubernetes नेटिव साइडकार्स का उपयोग कैसे करेंगे?

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

एक Job Pod में एक बैच कंटेनर, एक लॉग-फॉरवर्डिंग कंटेनर और एक कॉन्फ़िगरेशन-सिंक कंटेनर शामिल हैं। बैच कंटेनर समाप्त हो जाता है, लेकिन लॉग कंटेनर चलता रहता है और Job अधूरी रह जाती है; बैच शुरू होने से पहले सिंक कंटेनर को कॉन्फ़िगरेशन भी तैयार करना होगा। बताएं कि Kubernetes नेटिव साइडकार सेमेंटिक्स किस प्रकार टेल लॉग्स (tail logs) के नुकसान और संस्करण-निर्भर व्यवहार से बचते हुए स्टार्टअप, टर्मिनेशन और Job कंप्लीशन का समाधान करते हैं।

ये घटक और समय इंटरव्यू की मान्यताएं हैं, हर क्लस्टर के लिए डिफ़ॉल्ट नहीं। यह प्रश्न बैकएंड प्लेटफॉर्म, क्लाउड-नेटिव रनटाइम और SRE भूमिकाओं के लिए उपयुक्त है। इसका मुख्य कौशल Pod लाइफसाइकिल विश्वसनीयता है, इसलिए यह backend से संबंधित है।

इंटरव्यूअर्स क्या आंकते हैं

पहला, क्या आप सामान्य containers, initContainers और नेटिव साइडकार्स में अंतर कर सकते हैं? एक नेटिव साइडकार को init-container सेक्शन में एक ऐसी रीस्टार्ट पॉलिसी के साथ व्यक्त किया जाता है जो इसे इनिशियलाइज़ेशन के बाद भी चलते रहने देती है।

दूसरा, क्या आप Job कंप्लीशन की व्याख्या कर सकते हैं? एक नेटिव साइडकार को नियमित कंटेनरों के पूरा होने के बाद समाप्त (terminate) कर दिया जाता है और यह पारंपरिक लंबे समय तक चलने वाले साइडकार की तरह Job को खुला नहीं रखता है।

तीसरा, क्या आप निर्भरताओं और सिग्नलों को संभाल सकते हैं? मुख्य कंटेनर शुरू होने से पहले सिंक साइडकार को तत्परता (readiness) की रिपोर्ट करनी होगी; टर्मिनेशन के दौरान इसे मुख्य कंटेनर के बाद एक सिग्नल प्राप्त होना चाहिए और इसके पास एक सीमित फ़ोर्स्ड-स्टॉप पाथ होना चाहिए।

चौथा, क्या आप विफलताओं को संभाल सकते हैं? साइडकार स्टार्टअप विफलता, रीस्टार्ट लूप्स, अनुपलब्ध लॉग बैकएंड और शुरुआती मुख्य-कंटेनर विफलता के लिए स्पष्ट पुनः प्रयास (retry), डिग्रेडेशन और ऑब्जर्वेबिलिटी नियमों की आवश्यकता होती है।

पांचवां, क्या आप कम्पैटिबिलिटी की योजना बना सकते हैं? ऐसा क्लस्टर जो नेटिव-साइडकार सेमेंटिक्स को नहीं समझता है, वह मेनिफेस्ट को अस्वीकार कर सकता है या पुराना व्यवहार चला सकता है। कैपेबिलिटी गेट्स, वर्ज़न चेक्स और फ़ॉलबैक मेनिफेस्ट का उपयोग करें।

पहले स्पष्ट करने योग्य प्रश्न

कौन सा Kubernetes वर्ज़न और एडमिशन पॉलिसी नेटिव साइडकार्स का समर्थन करती है?
क्या कॉन्फ़िगरेशन सिंक एकमुश्त (one-time) इनिशियलाइज़ेशन है या जॉब के दौरान निरंतर रीफ़्रेश है?
लॉग कहाँ डिलीवर होने चाहिए, और कितना टेल लॉस स्वीकार्य है?
मुख्य-कंटेनर, साइडकार और Job रीट्राई एग्ज़िट कोड कैसे परिभाषित हैं?
क्या Pod restartPolicy: Never या OnFailure का उपयोग करता है?
क्या साइडकार्स के बीच कोई ऑर्डरिंग निर्भरता या शेयर्ड-वॉल्यूम कंटेंशन है?

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

“मैं उन कंटेनरों को initContainers में रखूंगा जिन्हें जल्दी शुरू होना है और जीवित रहना है, साइडकार रीस्टार्ट पॉलिसी सेट करूंगा, और सिंक प्रोसेस को मान्य कॉन्फ़िगरेशन तैयार होने पर सिग्नल देने के लिए कहूंगा। मुख्य कंटेनर के पूरा होने के बाद, कंट्रोलर नेटिव साइडकार को समाप्त कर देता है ताकि Job समाप्त हो सके; लॉगिंग साइडकार इनपुट रोककर और एक मजबूर टाइमआउट से पहले बफ़र्स को फ़्लश करके SIGTERM को संभालता है। पुराने क्लस्टर वर्ज़न डिटेक्शन और पारंपरिक-कंटेनर फ़ॉलबैक का उपयोग करते हैं। मैं ऑर्डरिंग, एग्ज़िट कोड, टेल-लॉग पूर्णता, रीट्राई और Job कंप्लीशन लेटेंसी को सत्यापित करूंगा।”

चरण-दर-चरण उत्तर

चरण 1: नेटिव-साइडकार समर्थन सत्यापित करें

Kubernetes नेटिव साइडकार्स को कंटेनर-स्तरीय restartPolicy: Always के साथ initContainers में व्यक्त करता है, जिससे वे इनिशियलाइज़ेशन के बाद भी जारी रह सकते हैं। API-सर्वर वर्ज़न, फ़ीचर गेट्स, एडमिशन कंट्रोलर्स और डिप्लॉयमेंट टूलिंग की जाँच करें; केवल एक kubectl क्लाइंट वर्ज़न पर्याप्त नहीं है।

चरण 2: स्टार्टअप क्रम को व्यक्त करें

Init कंटेनर क्रम से शुरू होते हैं; एक नेटिव साइडकार शुरू होने के बाद भी चलता रह सकता है जबकि बाद का इनिशियलाइज़ेशन और मुख्य कंटेनर आगे बढ़ते हैं। सिंक साइडकार को 'फ़ाइल लिखी गई, अनुमतियाँ सही हैं, वर्ज़न मान्य है' को अपनी तत्परता (readiness) स्थिति बनाना चाहिए। मुख्य कंटेनर को शेयर्ड वॉल्यूम पढ़ने से पहले उस स्थिति की जाँच करनी चाहिए।

yaml

initContainers:
- name: config-sync
  image: example/config-sync:v2
  restartPolicy: Always
  readinessProbe:
    exec:
      command: ["/bin/sh", "-c", "test -f /work/config.ready"]
- name: migrate
  image: example/migrate:v4
  command: ["/bin/sh", "-c", "./migrate && touch /work/migrate.done"]
containers:
- name: batch
  image: example/batch:v7

चरण 3: टर्मिनेशन और लॉग फ़्लशिंग को डिज़ाइन करें

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

चरण 4: विफलता और पुनः प्रयास (retry) को परिभाषित करें

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

चरण 5: Job कंप्लीशन सेमेंटिक्स को संभालें

नेटिव साइडकार्स को सभी नियमित कंटेनरों के पूरा होने के बाद समाप्त कर दिया जाता है, इसलिए Job खुला नहीं रहता है जैसा कि एक सामान्य रेजिडेंट साइडकार के साथ हो सकता है। यदि कोई साइडकार जल्दी विफल हो जाता है, तो किसी आरेख पर भरोसा करने के बजाय एक इंटीग्रेशन टेस्ट के साथ तत्परता, रीस्टार्ट और Job स्थितियों के लिए वास्तविक क्लस्टर व्यवहार को सत्यापित करें।

चरण 6: पुराने क्लस्टरों का समर्थन करें

एक वर्ज़न गेट का उपयोग करें: असमर्थित क्लस्टरों को एक पारंपरिक containers मेनिफेस्ट प्राप्त होता है, और एक रैपर मुख्य कंटेनर समाप्त होने पर लॉगिंग प्रोसेस को बाहर निकलने के लिए कहता है। मेनिफेस्ट को परस्पर अनन्य (mutually exclusive) रखें। माइग्रेशन के दौरान, Job पूरा होने का समय, विफलता के कारण और टेल-लॉग पूर्णता का निरीक्षण करें।

चरण 7: संसाधनों और सुरक्षा को सत्यापित करें

साइडकार Pod नेटवर्क, वॉल्यूम और रिसोर्स कोटा साझा करते हैं। सिंक और लॉगिंग कंटेनरों को अलग-अलग requests और limits दें ताकि लॉग की वृद्धि बैच को भूखा न रखे; कॉन्फ़िगरेशन पढ़ने या लॉग लिखने के लिए आवश्यक केवल ServiceAccount अनुमतियाँ दें। प्रोब्स को क्रेडेंशियल्स उजागर नहीं करना चाहिए, और अस्थायी फ़ाइलों को प्रतिबंधात्मक अनुमतियों की आवश्यकता होती है।

मॉडल उत्तर

“मैं पहले API सर्वर और एडमिशन चेन में नेटिव-साइडकार समर्थन की पुष्टि करूंगा। सिंक प्रोसेस restartPolicy: Always के साथ initContainers में जाती है; यह एक वर्ज़न को मान्य करती है और मुख्य कंटेनर के आगे बढ़ने से पहले कॉन्फ़िगरेशन को एटॉमिक रूप से लिखती है। एकमुश्त माइग्रेशन एक सामान्य init कंटेनर बना रहता है। लॉगिंग साइडकार मुख्य कंटेनर के बाद टर्मिनेशन को संभालता है, इनपुट रोकता है, एक सीमित ग्रेस पीरियड के भीतर डिलीवरी को फ़्लश और कन्फ़र्म करता है, फिर यदि फ़ोर्स्ड टर्मिनेशन होता है तो अलर्ट करता है।

मैं मुख्य एग्ज़िट कोड, साइडकार रीस्टार्ट, Pod कंडीशंस, Job बैकऑफ़ और टेल-लॉग लॉस को अलग से रिकॉर्ड करूंगा। पुराने क्लस्टर पारंपरिक-कंटेनर फ़ॉलबैक मेनिफेस्ट का चयन करते हैं, जिसमें एक रैपर होता है जो लॉगर को बाहर निकलने का संकेत देता है। एक कैनरी ऑर्डरिंग, Job कंप्लीशन लेटेंसी, रीट्राई, एटॉमिक कॉन्फ़िगरेशन, रिसोर्स लिमिट्स और लॉग पूर्णता की पुष्टि करता है।”

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

containers में एक सामान्य साइडकार का उपयोग करना → Job हमेशा के लिए प्रतीक्षा कर सकती है → नेटिव सेमेंटिक्स या स्पष्ट एग्ज़िट समन्वय का उपयोग करें।
एक सतत सिंक प्रोसेस को वन-शॉट init बनाना → यह जॉब के दौरान रीफ़्रेश नहीं हो सकता → पहले लाइफसाइकिल आवश्यकताओं को परिभाषित करें।
एटॉमिक राइट्स के बिना तत्परता (readiness) का उपयोग करना → मुख्य प्रोसेस आंशिक स्थिति को पढ़ती है → एक अस्थायी फ़ाइल को मान्य करें, फिर नाम बदलें।
फ़्लश विंडो की उपेक्षा करना → SIGKILL टेल लॉग्स खो देता है → सबसे खराब स्थिति में डिलीवरी के लिए ग्रेसफुल टर्मिनेशन का बजट बनाएं।
साइडकार विफलता को व्यावसायिक विफलता के रूप में गिनना → रीट्राई मेट्रिक्स भ्रामक हो जाते हैं → कंटेनर और Job स्थिति को अलग करें।
यह मान लेना कि प्रत्येक क्लस्टर फ़ील्ड का समर्थन करता है → पुराने वर्ज़न इसे अस्वीकार करते हैं या व्यवहार बदलते हैं → वर्ज़न गेट्स और फ़ॉलबैक मेनिफेस्ट का उपयोग करें।
साइडकार संसाधनों को असीमित छोड़ना → लॉग बर्स्ट बैच के काम को प्रभावित करते हैं → स्वतंत्र requests, limits और अलर्ट सेट करें।
शेयर्ड वॉल्यूम को अत्यधिक अनुमति देना → कॉन्फ़िगरेशन या लॉग बदले जा सकते हैं → कम से कम विशेषाधिकार वाली पहचान और फ़ाइल मोड का उपयोग करें।

फॉलो-अप प्रश्न

फॉलो-अप 1: नेटिव साइडकार्स को initContainers में क्यों व्यक्त किया जाता है?

यह इनिशियलाइज़ेशन ऑर्डरिंग को बनाए रखता है जबकि एक कंटेनर-स्तरीय रीस्टार्ट पॉलिसी साइडकार को स्टार्टअप के बाद सक्रिय रहने देती है। बाद के कंटेनर आवश्यक इनिशियलाइज़ेशन स्थितियों की प्रतीक्षा करते हैं, और कंट्रोलर Job पूरा होने पर साइडकार टर्मिनेशन को संभालता है।

फॉलो-अप 2: क्या कोई साइडकार हमेशा लॉग भेजना समाप्त कर सकता है?

नहीं। नेटवर्क विफलता, थ्रॉटलिंग, या एक छोटी ग्रेस अवधि डेटा खो सकती है। बाउंडेड फ़्लशिंग, टिकाऊ बफ़रिंग या रीट्राई का उपयोग करें, और टेल-लॉग पूर्णता और हानि अलर्ट को मापें।

फॉलो-अप 3: क्या मुख्य कंटेनर विफल होने के बाद सिंक जारी रहना चाहिए?

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

फॉलो-अप 4: आप स्टार्टअप क्रम का परीक्षण कैसे करते हैं?

सिंक प्रोसेस में देरी करें, आंशिक स्थिति लिखें, और जबरन वैलिडेशन विफलता उत्पन्न करें; सत्यापित करें कि मुख्य कंटेनर शुरू नहीं होता है। फिर एक कंप्लीशन मार्कर लिखें और सत्यापित करें कि यह एक पूर्ण वर्ज़न पढ़ता है। रीस्टार्ट, शेयर्ड-वॉल्यूम दृश्यता और प्रोब रेस का परीक्षण करें।

फॉलो-अप 5: आप पुराने-क्लस्टर फ़ॉलबैक को कैसे सुसंगत रखते हैं?

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

फॉलो-अप 6: आपको कैसे पता चलेगा कि Job वास्तव में पूरी हो गई है?

Job कंडीशंस, मुख्य एग्ज़िट कोड, Pod फ़ेज़, साइडकार टर्मिनेशन कारण और लॉग-डिलीवरी कन्फ़र्मेशन मार्कर को एक साथ जांचें। एक Succeeded Pod अकेले गायब टेल लॉग्स या सिंक विफलता को छुपा सकता है।