Kubernetes इंटरव्यू: आप init container के साथ रनटाइम एनवायरनमेंट वेरिएबल्स को सुरक्षित रूप से कैसे इंजेक्ट करेंगे?

प्रश्न और संदर्भ

एक इम्यूटेबल एप्लिकेशन इमेज प्रोसेस शुरू होने पर ही DB_ADDRESS और TENANT_MODE को पढ़ती है। प्रत्येक Pod के लिए, एक init container को टेनेंट कॉन्फ़िगरेशन से एक एनवायरनमेंट फ़ाइल जनरेट करनी होगी; मुख्य कंटेनर को लेखक की डायरेक्टरी को माउंट किए बिना चुनी गई कुंजियों (keys) को पढ़ना चाहिए। Kubernetes EnvFiles और fileKeyRef का उपयोग करें, और बताएं कि कब ConfigMap या Secret बेहतर विकल्प रहता है।

Kubernetes v1.35 दस्तावेज़ EnvFiles को Beta और डिफ़ॉल्ट रूप से सक्षम के रूप में सूचीबद्ध करता है; सर्वर कम से कम v1.34 होना चाहिए। यह कोई लाइव फ़ाइल-टू-एनवायरनमेंट मैपिंग नहीं है: कंटेनर के इनिशियलाइज़ होने के दौरान kubelet फ़ाइल को पढ़ता है, और परिणामी वेरिएबल्स उस कंटेनर के लिए स्थिर रहते हैं।

साक्षात्कारकर्ता क्या जांच रहा है

• क्या आप initContainer से emptyDir, fileKeyRef और kubelet के माध्यम से डेटा को ट्रेस कर सकते हैं?
• क्या आप Pod एडमिशन विफलता, init विफलता, मिसिंग-की विफलता और मुख्य प्रोसेस शुरू होने के बाद फ़ाइल परिवर्तनों के बीच अंतर कर सकते हैं?
• क्या आप env-फ़ाइल सिंटैक्स, optional, पाथ प्रतिबंधों और उपभोक्ता को वॉल्यूम माउंट करने की आवश्यकता है या नहीं, इसका सटीक वर्णन कर सकते हैं?
• क्या आप संवेदनशील मानों, नोड एक्सेस, लॉग एक्सपोज़र और Secret ट्रेड-ऑफ़ के बारे में तर्क कर सकते हैं?
• क्या आप केवल YAML प्रस्तुत करने के बजाय वर्ज़न गेट्स, ऑब्ज़र्वेबिलिटी, रोलआउट और रोलबैक डिज़ाइन कर सकते हैं?

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

• कंट्रोल प्लेन और नोड्स पर कौन से Kubernetes वर्ज़न चल रहे हैं, और क्या लक्षित क्लस्टर में EnvFiles सक्षम है?
• क्या कॉन्फ़िगरेशन एक स्टार्टअप स्नैपशॉट है या इसे हॉट-रीलोड होना चाहिए? यदि हॉट रीलोड की आवश्यकता है, तो क्या एप्लिकेशन किसी फ़ाइल को वॉच कर सकता है या सुरक्षित रूप से पुनरारंभ हो सकता है?
• कौन सा init container फ़ाइल बनाता है, और क्या इसकी विफलता से Pod को अनरेडी रहना चाहिए और मुख्य कंटेनर को ब्लॉक करना चाहिए?
• क्या मानों में पासवर्ड, टोकन या व्यक्तिगत डेटा शामिल हैं? नोड-व्यवस्थापक और लॉग-कलेक्टर ट्रस्ट सीमाएं क्या हैं?
• यदि कोई कुंजी गायब है या डुप्लिकेट है, तो क्या पूरे Pod को विफल होना चाहिए या कोई सुरक्षित डिफ़ॉल्ट है?

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

"मैं सर्वर वर्ज़न और EnvFiles फ़ीचर गेट को सत्यापित करूँगा, फिर एक नियंत्रित KEY=value फ़ाइल बनाने के लिए init container के लिए emptyDir का उपयोग करूँगा। मुख्य कंटेनर env.valueFrom.fileKeyRef के साथ चुनी गई कुंजियों को पढ़ता है और राइटर वॉल्यूम को माउंट नहीं करता है; एक आवश्यक मिसिंग कुंजी स्टार्टअप को रोकती है। मान केवल कंटेनर स्टार्टअप पर इंजेक्ट किया जाता है, इसलिए बाद के फ़ाइल परिवर्तन एनवायरनमेंट को अपडेट नहीं करते हैं। संवेदनशील मानों के लिए Secret को प्राथमिकता दी जानी चाहिए; EnvFiles वर्ज़न जांच, मेट्रिक्स, रिडैक्टेड लॉग्स और कैनरी रोलबैक के साथ Pod-लोकल स्टार्टअप स्नैपशॉट को संभालता है।"

चरण-दर-चरण गहन विश्लेषण

1. क्षमता और अनुकूलता की पुष्टि करें। Kubernetes, EnvFiles को न्यूनतम v1.34 सर्वर के साथ v1.35 में Beta (डिफ़ॉल्ट रूप से सक्षम) के रूप में दस्तावेज़ित करता है। API, kubelet और नोड वर्ज़न के लिए एडमिशन और रिलीज़ जांच जोड़ें; मिश्रित-वर्ज़न क्लस्टरों का परीक्षण सबसे पुराने नोड के विरुद्ध किया जाना चाहिए।

1. इनिशियलाइज़ेशन के दौरान फ़ाइल जनरेट करें। Pod में एक emptyDir का उपयोग करें। init container इसे माउंट करता है, अनुमत और आवश्यक कुंजियों, स्रोत वर्ज़न और अनुमतियों को मान्य करता है, फिर एक अस्थायी फ़ाइल लिखता है और इसे एटॉमिक रूप से रीनेम करता है। यदि init container विफल हो जाता है, तो मुख्य कंटेनर शुरू नहीं होता है।

1. केवल आवश्यक कुंजियों का चयन करें। मुख्य कंटेनर का fileKeyRef एक volumeName, सापेक्ष path और key निर्दिष्ट करता है। optional: false (डिफ़ॉल्ट व्यवहार) के लिए फ़ाइल और कुंजी आवश्यक है; केवल तभी optional: true का उपयोग करें जब कोई सुरक्षित डिफ़ॉल्ट मौजूद हो। मुख्य कंटेनर को वॉल्यूम माउंट करने की आवश्यकता नहीं है, जिससे असंबद्ध कुंजियों तक पहुंच कम हो जाती है।

apiVersion: v1
kind: Pod
metadata:
  name: envfile-demo
spec:
  restartPolicy: Never
  initContainers:
    - name: render-config
      image: busybox:1.36
      command: ["sh", "-c", "printf \"DB_ADDRESS='db.internal'\\nTENANT_MODE='isolated'\\n\" > /config/.env.tmp && mv /config/.env.tmp /config/runtime.env"]
      volumeMounts:
        - name: runtime-config
          mountPath: /config
  containers:
    - name: app
      image: example/app:2026-08-01
      env:
        - name: DB_ADDRESS
          valueFrom:
            fileKeyRef:
              volumeName: runtime-config
              path: runtime.env
              key: DB_ADDRESS
              optional: false
        - name: TENANT_MODE
          valueFrom:
            fileKeyRef:
              volumeName: runtime-config
              path: runtime.env
              key: TENANT_MODE
              optional: false
  volumes:
    - name: runtime-config
      emptyDir: {}

1. लाइफ़साइकिल परिभाषित करें। कंटेनर को इनिशियलाइज़ करते समय kubelet फ़ाइल को पढ़ता है और एनवायरनमेंट सेट करता है। प्रोसेस शुरू होने के बाद runtime.env को फिर से लिखने से इसका मौजूदा DB_ADDRESS नहीं बदलता है; नए मानों के लिए एक नए Pod या एप्लिकेशन-स्तरीय हॉट-रीलोड तंत्र की आवश्यकता होती है।

1. सुरक्षा सीमा निर्धारित करें। emptyDir, Secret की सुरक्षा प्रदान नहीं करता है, और नोड फ़ाइल सिस्टम रीडर Pod डायरेक्टरी तक पहुँच सकता है। अत्यधिक संवेदनशील मानों को लॉग न करें। कुंजियों के लिए Secret, अल्पकालिक क्रेडेंशियल्स और न्यूनतम-विशेषाधिकार RBAC का उपयोग करें, और उन भूमिकाओं को प्रतिबंधित करें जो नोड फ़ाइलों या Pod डिबगिंग डेटा का निरीक्षण कर सकती हैं।

1. निरीक्षण करें और रोल बैक करें। मानों को छिपाते (redacting) हुए कॉन्फ़िगरेशन वर्ज़न, init निकास कोड, मिसिंग-की इवेंट्स, Pod स्टार्टअप समय और तत्परता (readiness) रिकॉर्ड करें। पहले एक छोटे सेट पर कैनरी परीक्षण करें। यदि टेम्पलेट या फ़ीचर गेट असंगत है, तो ConfigMap/Secret संदर्भों या पूर्व इमेज पर वापस स्विच करें और खराब स्नैपशॉट ले जाने वाले Pods को बदलें।

आदर्श उत्तर

मैं जनरेशन को init container के अंदर ही रखूँगा। यह अधिकृत टेनेंट कॉन्फ़िगरेशन को पढ़ता है, कुंजी सेट और वर्ज़न को मान्य करता है, एक अस्थायी फ़ाइल लिखता है, और इसे emptyDir में एटॉमिक रूप से रीनेम करता है। ऐप कंटेनर fileKeyRef के माध्यम से केवल DB_ADDRESS और TENANT_MODE का उपभोग करता है और वॉल्यूम को माउंट नहीं करता है; आवश्यक कुंजियाँ optional: false रहती हैं, इसलिए init या कुंजी की विफलताएं इनिशियलाइज़ेशन के दौरान ही Pod को रोक देती हैं।

एडमिशन और रिलीज़ पाइपलाइन के लिए कम से कम v1.34 सर्वर की आवश्यकता होगी और यह v1.35 Beta EnvFiles व्यवहार को सत्यापित करेगी। ये वेरिएबल्स स्टार्टअप स्नैपशॉट हैं, इसलिए डायनामिक कॉन्फ़िगरेशन के लिए एप्लिकेशन-समर्थित फ़ाइल वॉचर, कॉन्फ़िगरेशन सेवा या रोलिंग रीस्टार्ट का उपयोग किया जाना चाहिए। पासवर्ड और टोकन के लिए emptyDir को गुप्त स्टोरेज मानने के बजाय Secret का उपयोग किया जाना चाहिए। ऑब्ज़र्वेबिलिटी वर्ज़न, स्थिति और रिडैक्टेड डाइजेस्ट रिकॉर्ड करती है, जिसमें कैनरी और पुराने टेम्पलेट पर वापस जाने का एक परीक्षित पाथ होता है।

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

• लक्षण: मुख्य कंटेनर में पूरे emptyDir को माउंट करना → यह विफल क्यों होता है: ऐप असंबद्ध कुंजियों को पढ़ सकता है, जिससे जोखिम बढ़ता है → समाधान: fileKeyRef के साथ केवल आवश्यक कुंजियों को ही इंजेक्ट करें।
• लक्षण: फ़ाइल को दोबारा लिखने के बाद प्रोसेस को नए मान मिलने की अपेक्षा करना → यह विफल क्यों होता है: एनवायरनमेंट वेरिएबल्स कंटेनर स्टार्टअप पर बनाए जाते हैं → समाधान: Pod को रोल करें या हॉट-रीलोड कॉन्फ़िगरेशन तंत्र का उपयोग करें।
• लक्षण: emptyDir में पासवर्ड लिखना और इसे Secret के रूप में मानना → यह विफल क्यों होता है: नोड और डिबगिंग एक्सेस अभी भी फ़ाइल को पढ़ सकते हैं → समाधान: Secret, अल्पकालिक क्रेडेंशियल्स और न्यूनतम विशेषाधिकार का उपयोग करें।
• लक्षण: optional और कुंजी वैलिडेशन को अनदेखा करना → यह विफल क्यों होता है: एक Pod खाली कॉन्फ़िगरेशन के साथ शुरू हो सकता है या केवल एप्लिकेशन लॉग में विफल हो सकता है → समाधान: आवश्यक कुंजियों को गैर-वैकल्पिक बनाएं और init के दौरान विफल करें।

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

EnvFiles की तुलना ConfigMap और Secret से कैसे की जाती है?

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

फ़ाइल में कौन सा सिंटैक्स स्वीकार किया जाता है?

Kubernetes env-फ़ाइल प्रारूप का उपयोग करें जैसे कि VAR='value'; खाली लाइनें, शुरुआती स्पेस और = के चारों ओर स्पेस दस्तावेज़ित नियमों का पालन करते हैं। यह न मानें कि प्रत्येक POSIX शेल एक्सटेंशन स्वीकार किया जाता है; लक्षित Kubernetes वर्ज़न पर पार्सिंग का परीक्षण करें।

fileKeyRef पर कौन से पाथ प्रतिबंध लागू होते हैं?

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

आप कैसे साबित करेंगे कि संवेदनशील मान उजागर नहीं हुए थे?

init और ऐप लॉग्स, Events, डिबग एंडपॉइंट्स, नोड अनुमतियों और बैकअप कलेक्टर्स का निरीक्षण करें; केवल कुंजी के नाम, वर्ज़न और अपरिवर्तनीय डाइजेस्ट रिकॉर्ड करें। यदि नोड व्यवस्थापक थ्रेट मॉडल में हैं, तो Secret नोड ट्रस्ट को नहीं हटाता है; नोड और संचालन एक्सेस को भी सख्त करें।

संदर्भ

• एक Init Container का उपयोग करके एनवायरनमेंट वेरिएबल मान परिभाषित करना
• Kubernetes v1.34: ऐप एनवायरनमेंट वेरिएबल्स को परिभाषित करने के लिए एक Init Container का उपयोग करना
• Feature Gates
• Pod API संदर्भ: FileKeySelector

साक्षात्कार चेकलिस्ट

init द्वारा emptyDir पर लिखने, कुंजी-स्तरीय fileKeyRef, और स्टार्टअप स्नैपशॉट से शुरुआत करें। फिर वर्ज़न गेट्स, विफलता सिमेंटिक्स, सुरक्षा सीमा और अपडेट पाथ को कवर करें। EnvFiles को हॉट रीलोड या Secret प्रतिस्थापन के रूप में वर्णित न करें।

एक-वाक्य का निष्कर्ष

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