सामान्य इंटरव्यू: जब Kubernetes v1.36 स्थायी रूप से gitRepo वॉल्यूम को अक्षम कर दे, तो आप माइग्रेशन कैसे करेंगे?

सवाल और दायरा

एक टीम gitRepo वॉल्यूम का उपयोग करती है ताकि Pod शुरू होने पर रिपॉजिटरी एक माउंट में क्लोन हो जाए। Kubernetes v1.36 इस वॉल्यूम प्लगइन को स्थायी रूप से अक्षम कर देता है और कोई फ़ीचर-गेट एस्केप हैच प्रदान नहीं करता है। माइग्रेशन को डिज़ाइन करें: वर्कलोड और रिपॉजिटरी निर्भरताओं की इन्वेंट्री बनाएं, एक init कंटेनर, बाहरी सिंक्रोनाइज़र या बिल्ड-टाइम पैकेजिंग चुनें, और कमिट अखंडता, क्रेडेंशियल्स, नेटवर्क व्यवहार, अपडेट सिमेंटिक्स और रोलबैक को सत्यापित करें।

Kubernetes दस्तावेज़ बताते हैं कि gitRepo वर्षों से अप्रचलित (deprecated) है और पुराना कार्यान्वयन किसी हमलावर को नोड पर root के रूप में कोड निष्पादित करने की अनुमति दे सकता था। v1.36 द्वारा प्लगइन को अक्षम करने के बाद, किसी पुराने Pod को पुनः शेड्यूल करने से अनुकूलता बहाल नहीं होती है। API परिवर्तन, इमेज रिलीज़ और रनटाइम फ़ेच पथों को अलग करें।

संदर्भ और सीमाएं

वॉल्यूम-प्लगइन लाइफ़साइकिल, Pod स्टार्टअप क्रम, आपूर्ति-श्रृंखला विश्वास (supply-chain trust) और माइग्रेशन सत्यापन पर ध्यान केंद्रित करें। Git होस्टिंग, इमेज रजिस्ट्री, नेटवर्क इग्रेस और सीक्रेट प्रबंधन प्लेटफ़ॉर्म निर्भरताएं हैं; कमिट पिन, न्यूनतम-विशेषाधिकार (least-privilege) क्रेडेंशियल, नेटवर्क-विफलता नीति और फ्रेशनेस लक्ष्य को स्पष्ट करें।

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

• क्या आप gitRepo को इमेज लेयर या ConfigMap के बजाय एक वॉल्यूम प्लगइन के रूप में पहचानते हैं।
• क्या आप पुनरुत्पादकता (reproducibility), फ्रेशनेस और विफलता सिमेंटिक्स के आधार पर बिल्ड-टाइम पैकेजिंग, init कंटेनर और निरंतर सिंक्रोनाइज़र की तुलना करते हैं।
• क्या आप निजी रिपॉजिटरी, known hosts, टोकन, प्रॉक्सी और कमिट अखंडता को संभालते हैं।
• क्या आप प्री-अपग्रेड स्कैन, एडमिशन ब्लॉक, कैनरी नोड्स और रोलबैक डिज़ाइन करते हैं।
• क्या आप empty-directory शेयरिंग, माउंट अनुमतियाँ, रीड-ओनली उपयोग और स्टार्टअप निर्भरता की व्याख्या करते हैं।

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

“मैं gitRepo के लिए Pods, टेम्प्लेट्स और जनरेटर को स्कैन करूँगा, जिसमें रिपॉजिटरी, रिवीज़न, माउंट पाथ, क्रेडेंशियल्स और फ्रेशनेस की ज़रूरतों को रिकॉर्ड किया जाएगा। निश्चित सामग्री को बिल्ड समय पर एक अपरिवर्तनीय (immutable) इमेज में पैक किया जाना चाहिए। यदि रनटाइम फ़ेच आवश्यक है, तो एक न्यूनतम-विशेषाधिकार init कंटेनर पिन किए गए कमिट को एक emptyDir में लिखता है, और मुख्य कंटेनर इसे रीड-ओनली माउंट करता है। निरंतर अपडेट के लिए परमाणु संस्करण स्विचिंग (atomic version switching), पुराने संस्करण को बनाए रखने और अखंडता जांच के साथ एक नियंत्रित सिंक्रोनाइज़र की आवश्यकता होती है। अपग्रेड से पहले, एक नीति नए उपयोग को ब्लॉक करती है; पुराने टेम्प्लेट हटाए जाने से पहले कैनरी रीस्टार्ट नेटवर्क विफलताओं और रोलबैक का परीक्षण करते हैं।”

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

1. वास्तविक निर्भरताओं की इन्वेंट्री बनाएं। gitRepo के लिए Pods, Deployments, StatefulSets, Jobs, Helm चार्ट्स, Kustomize, जनरेटर और एडमिशन म्यूटेशन खोजें। रिपॉजिटरी, रिवीज़न, पाथ, स्टार्टअप रीड्स, रिपॉजिटरी का आकार, अपडेट अंतराल, क्रेडेंशियल स्रोत और इग्रेस पाथ रिकॉर्ड करें।

1. फ्रेशनेस सिमेंटिक्स को वर्गीकृत करें। बिल्ड के समय निश्चित कॉन्फ़िगरेशन या टेम्प्लेट को पैक करें। स्टार्टअप पर आवश्यक सामग्री के लिए init कंटेनर का उपयोग करें। केवल उस सामग्री के लिए सिंक्रोनाइज़र पर विचार करें जिसे निष्पादन के दौरान बदलना आवश्यक हो। “प्रत्येक शुरुआत पर फ़ेच करना” और “हॉट अपडेट” अलग-अलग आवश्यकताएं हैं।

1. बिल्ड के समय पैकेज करें। एक विश्वसनीय CI नेटवर्क में, कमिट डाइजेस्ट द्वारा फ़ेच करें, सामग्री को स्कैन करें, एक अपरिवर्तनीय इमेज बनाएं और प्रोवेनेंस (provenance) संलग्न करें। इमेज डाइजेस्ट द्वारा डिप्लॉय करें ताकि स्टार्टअप Git की उपलब्धता पर निर्भर न हो; रोलबैक पिछले डाइजेस्ट को पुनर्स्थापित करता है।

1. init-कंटेनर प्रतिस्थापन का उपयोग करें। init कंटेनर को एक समर्पित ServiceAccount या Secret दें, क्रेडेंशियल्स को रीड-ओनली माउंट करें, और पिन किए गए कमिट को emptyDir में लिखें। मुख्य कंटेनर उसी डायरेक्टरी को रीड-ओनली माउंट करता है। फ़ेच विफलता आंशिक सामग्री को प्रदर्शित करने के बजाय Pod को Ready बनने से रोकती है।

volumes:
- name: repo-data
  emptyDir: {}
initContainers:
- name: fetch-repo
  image: platform/git-sync:approved
  volumeMounts:
  - name: repo-data
    mountPath: /work
containers:
- name: app
  volumeMounts:
  - name: repo-data
    mountPath: /app/config
    readOnly: true

यह केवल संरचनात्मक मार्गदर्शन है। प्रोडक्शन उपयोग से पहले इमेज, क्रेडेंशियल प्रोजेक्शन, नेटवर्क नीति, सत्यापन कमांड और फ़ेच कमांड को प्लेटफ़ॉर्म मानक द्वारा तय किया जाना चाहिए।

1. आवश्यक होने पर सिंक्रोनाइज़र संचालित करें। हॉट अपडेट के लिए, एक नियंत्रित साइडकार या बाहरी सिंक्रोनाइज़र का उपयोग करें। एक अस्थायी डायरेक्टरी में फ़ेच करें, कमिट, फ़ाइल मेनिफ़ेस्ट और अनुमतियों को सत्यापित करें, फिर परमाणु रूप से (atomically) संस्करण डायरेक्टरी को स्विच करें। विफलता पर वर्तमान में मान्य संस्करण को बनाए रखें। एप्लिकेशन को रीलोड या एक निर्धारित रीस्टार्ट विंडो का समर्थन करना चाहिए।

1. आपूर्ति-श्रृंखला को सुरक्षित रखें। कभी भी Pod स्पेक्स या लॉग में लंबे समय तक चलने वाले टोकन न डालें। रिपॉजिटरी, ब्रांच और इग्रेस को सीमित करें; TLS, known hosts, कमिट हस्ताक्षर या विश्वसनीय डाइजेस्ट को सत्यापित करें। सिंक्रोनाइज़र को root के रूप में होस्ट पाथ को संशोधित नहीं करना चाहिए; एप्लिकेशन माउंट रीड-ओनली होने चाहिए।

1. कैनरी, ब्लॉक और रोलबैक। अपग्रेड करने से पहले, CI आउटपुट को स्कैन करें और माइग्रेशन अनुमति सूची (allowlist) को बनाए रखते हुए नए gitRepo Pods को ब्लॉक करने के लिए ValidatingAdmissionPolicy का उपयोग करें। नोड्स के एक छोटे सेट पर वर्कलोड को रीस्टार्ट करें और कोल्ड स्टार्ट, नेटवर्क लॉस, निजी-रिपॉजिटरी क्रेडेंशियल रोटेशन, रीशेड्यूलिंग और स्केलिंग का परीक्षण करें। पुराने टेम्प्लेट तभी हटाएं जब नई इमेज स्थिर हो। रोलबैक एक पुरानी इमेज या सिंक्रोनाइज़र को पुनर्स्थापित करता है, अक्षम v1.36 प्लगइन को कभी नहीं।

मॉडल उत्तर

मैं API ऑब्जेक्ट्स और रेंडर किए गए Pod टेम्प्लेट्स में gitRepo की इन्वेंट्री बनाऊँगा, फिर प्रत्येक वर्कलोड को निश्चित सामग्री, स्टार्टअप फ़ेच या हॉट अपडेट के रूप में वर्गीकृत करूँगा। निश्चित सामग्री CI-निर्मित अपरिवर्तनीय इमेज में जाती है जिसे डाइजेस्ट द्वारा डिप्लॉय किया जाता है। स्टार्टअप सामग्री पिन किए गए कमिट को emptyDir में लिखने के लिए एक न्यूनतम-विशेषाधिकार init कंटेनर का उपयोग करती है, जिसे मुख्य कंटेनर द्वारा रीड-ओनली माउंट किया जाता है। हॉट अपडेट एक सिंक्रोनाइज़र का उपयोग करते हैं जो एक अस्थायी डायरेक्टरी में नए संस्करण को सत्यापित करता है और विफलता पर पुराने संस्करण को बनाए रखते हुए इसे परमाणु रूप से स्विच करता है।

प्रत्येक पथ रिपॉजिटरी, कमिट, क्रेडेंशियल, नेटवर्क और अनुमति सीमा को बांधता है। टोकन स्पेक्स और लॉग से बाहर रहते हैं; फ़ेच की गई सामग्री की TLS, known hosts, कमिट या इमेज प्रोवेनेंस के लिए जांच की जाती है। अपग्रेड करने से पहले, टेम्प्लेट को स्कैन करें और नए gitRepo को ब्लॉक करें; फिर स्टार्टअप समय, फ़ेच विफलताओं, सामग्री डाइजेस्ट, Ready स्थिति और रोलबैक सफलता का अवलोकन करते हुए कैनरी रीस्टार्ट और रीशेड्यूलिंग करें। चूंकि v1.36 प्लगइन को स्थायी रूप से अक्षम करता है, इसलिए रोलबैक को फ़ीचर गेट के बजाय प्रतिस्थापन या पुराने क्लस्टर संस्करण का उपयोग करना चाहिए।

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

• गलती: ConfigMap में रिपॉजिटरी URL डालना और अपडेट की अपेक्षा करना → यह क्यों विफल होता है: ConfigMaps Git को फ़ेच नहीं करते हैं या संस्करणों को सत्यापित नहीं करते हैं → सुधार: बिल्ड पैकेजिंग, init कंटेनर या सिंक्रोनाइज़र को ज़िम्मेदारी सौंपें।
• गलती: init कंटेनर से डिफ़ॉल्ट ब्रांच फ़ेच करवाना → यह क्यों विफल होता है: रीस्टार्ट पुनरुत्पादक नहीं होते हैं और रोलबैक को साबित नहीं किया जा सकता → सुधार: एक कमिट को पिन करें और उसके डाइजेस्ट व प्रोवेनेंस को रिकॉर्ड करें।
• गलती: होस्ट-शेयर किए गए पाथ पर root के रूप में सिंक्रोनाइज़र चलाना → यह क्यों विफल होता है: यह नोड अटैक सरफेस का विस्तार करता है और Pod आइसोलेशन को बायपास करता है → सुधार: Pod-लोकल वॉल्यूम, गैर-root निष्पादन, न्यूनतम विशेषाधिकार और रीड-ओनली उपयोग का सहारा लें।
• गलती: उस डायरेक्टरी को ओवरराइट करना जिसे एप्लिकेशन पढ़ रहा है → यह क्यों विफल होता है: एप्लिकेशन एक आंशिक ट्री देख सकता है → सुधार: एक अस्थायी डायरेक्टरी में सत्यापित करें और संस्करणों को परमाणु रूप से स्विच करें।
• गलती: v1.36 के बाद GitRepoVolumeDriver को पुनः सक्षम करना → यह क्यों विफल होता है: प्लगइन स्थायी रूप से अक्षम है और सुरक्षा जोखिम बना रहता है → सुधार: माइग्रेशन जारी रखते हुए प्रतिस्थापन या क्लस्टर संस्करण को रोल बैक करें।

फॉलो-अप सवाल और जवाब

जब कोई कमिट पिन किया गया हो तब भी सामग्री को सत्यापित क्यों करें?

कमिट पिन संदर्भ को स्थिर बनाता है लेकिन यह साबित नहीं करता कि रिपॉजिटरी, निर्भरताएं या बिल्ड वातावरण विश्वसनीय हैं। CI को अभी भी हस्ताक्षर, प्रोवेनेंस, फ़ाइल मेनिफ़ेस्ट, मैलवेयर स्कैन और इमेज डाइजेस्ट को सत्यापित करना चाहिए, और साक्ष्यों को रिलीज़ से जोड़ना चाहिए।

निजी-रिपॉजिटरी क्रेडेंशियल्स कहाँ होने चाहिए?

लक्षित नेमस्पेस और रिपॉजिटरी के लिए सीमित एक समर्पित Secret या बाहरी सीक्रेट प्रदाता का उपयोग करें। पर्यावरण चर (environment variable) या माउंट की गई फ़ाइल के माध्यम से इंजेक्ट करें, कभी भी इमेज, एनोटेशन या लॉग में नहीं, और रोटेशन व निरस्तीकरण (revocation) का समर्थन करें।

जब init कंटेनर विफल हो जाता है तो क्या होता है?

Pod उपलब्ध नहीं होता है और मुख्य कंटेनर सामान्य रूप से शुरू नहीं होता है। कारण को स्पष्ट करें, पुनः प्रयास (retry) और बैकऑफ़ लागू करें, और तय करें कि क्या कोई पुरानी इमेज या वार्म किया गया कैश एक वैध व्यावसायिक फ़ॉलबैक प्रदान करता है।

हॉट अपडेट आंशिक सामग्री से कैसे बच सकते हैं?

एक नए संस्करण डायरेक्टरी में फ़ेच करें, कमिट, मेनिफ़ेस्ट और अनुमति जांच पूरी करें, फिर परमाणु रूप से नाम बदलें या सिम्लिंक (symlink) स्विच करें। एप्लिकेशन को एक रीलोड अनुबंध या रीस्टार्ट नीति की आवश्यकता होती है; एक विफल स्विच वर्तमान संस्करण को बनाए रखता है।

आप छूटे हुए gitRepo उपयोग को कैसे खोजते हैं?

API ऑब्जेक्ट्स, Helm/Kustomize स्रोत, रेंडर किए गए आउटपुट और एडमिशन म्यूटेशन को स्कैन करें। अपग्रेड के बाद डेप्रिकेशन या अज्ञात-फ़ील्ड त्रुटियों की निगरानी करें, और स्कैन को CI में रखें ताकि कोई नया टेम्प्लेट प्लगइन को फिर से पेश न कर सके।

संदर्भ

• Kubernetes v1.36 Sneak Peek (Kubernetes ब्लॉग)
• Volumes प्रलेखन (Kubernetes दस्तावेज़)
• Projected Volume कॉन्फ़िगरेशन (Kubernetes दस्तावेज़)
• Kubernetes Deprecation Policy (Kubernetes दस्तावेज़)

इंटरव्यू चेकलिस्ट

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

एक वाक्य में निष्कर्ष

gitRepo माइग्रेशन अंतर्निहित नोड-साइड Git क्लोनिंग को एक पुनरुत्पादक, न्यूनतम-विशेषाधिकार, सत्यापन योग्य सामग्री-वितरण श्रृंखला से बदल देता है।

अभ्यास जारी रखें

यदि रिपॉजिटरी में मल्टी-गीगाबाइट मॉडल और बार-बार बदलने वाले कॉन्फ़िगरेशन शामिल हैं, तो लागत और निरंतरता के आधार पर इमेज लेयर्स, ऑब्जेक्ट स्टोरेज, init कंटेनर और सिंक्रोनाइज़र की तुलना करें।