आप Kubernetes image volumes के साथ OCI डेटा एसेट्स को सुरक्षित रूप से कैसे रिलीज़ करते हैं?

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

आप एक इनफ़्रेंस सर्विस के ओनर हैं, जिसे किसी OCI इमेज से मॉडल, वोकैबुलरी या रूल्स पैकेज को रीड-ओनली फ़ाइलों के रूप में माउंट करना आवश्यक है। डाइजेस्ट पिनिंग, स्टेज्ड रोलआउट, डायग्नोसेबल स्टार्टअप विफलताओं और तेज़ रोलबैक के साथ एक रिलीज़ दृष्टिकोण डिज़ाइन करें। Kubernetes image volumes की सीमाओं को समझाएं।

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

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

पहले स्पष्टीकरण वाले प्रश्न

आर्टिफ़ैक्ट लाइफ़साइकिल

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

क्लस्टर और रनटाइम

कौन सा क्लस्टर वर्ज़न, नोड ऑपरेटिंग सिस्टम, कंटेनर रनटाइम और रजिस्ट्री क्रेडेंशियल्स उपलब्ध हैं? क्या अपग्रेड के दौरान मिश्रित नोड वर्ज़न मौजूद हो सकते हैं?

सुरक्षा और रोलबैक

Pod reference को कौन बदल सकता है? क्या रजिस्ट्री प्राइवेट एक्सेस और ऑडिट लॉग प्रदान करती है? क्या रोलबैक के लिए केवल पिछले डाइजेस्ट की आवश्यकता होती है, या पुनरुत्पादक सिग्नेचर, कॉन्फ़िगरेशन और कम्पैटिबिलिटी साक्ष्य की भी आवश्यकता होती है?

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

मैं एक हस्ताक्षरित OCI आर्टिफ़ैक्ट बनाऊंगा और रिलीज़ मैनिफ़ेस्ट में इसके डाइजेस्ट को पिन करूंगा। Pod इसे एक image volume के माध्यम से रीड-ओनली माउंट करता है, जबकि एडमिशन पॉलिसी गैर-स्वीकृत रजिस्ट्रियों या डाइजेस्ट को अस्वीकार करती है। एक कंट्रोलर संगत नोड्स तक सीमित बैचों में Pods को रोल आउट करता है, पुल, माउंट, एप्लिकेशन सेल्फ़-चेक और रिक्वेस्ट मेट्रिक्स का अवलोकन करता है। विफलता पर यह पिछले वर्कलोड और डाइजेस्ट को पुनर्स्थापित करता है। असंदर्भित आर्टिफ़ैक्ट्स को केवल तभी गारबेज-कलेक्ट किया जाता है जब रिटेंशन और ऑडिट आवश्यकताएं पूरी हो जाती हैं।

गहन समाधान

1. आर्टिफ़ैक्ट पहचान को इम्यूटेबल बनाएं

reference किसी OCI इमेज संदर्भ को इंगित कर सकता है; प्रोडक्शन को म्यूटेबल टैग के बजाय डाइजेस्ट का उपयोग करना चाहिए। सिग्नेचर, SBOM और बिल्ड प्रोवेनेंस को उस डाइजेस्ट से बांधें। डाइजेस्ट, पाइपलाइन, कम्पैटिबिलिटी मैट्रिक्स और ओनर को रिलीज़ रिकॉर्ड में स्टोर करें। डाइजेस्ट पिनिंग रिलीज़ को पुनरुत्पादक बनाती है, लेकिन यह वल्नेरेबिलिटी स्कैनिंग या सिग्नेचर सत्यापन का विकल्प नहीं है।

2. Pod माउंट को परिभाषित करें

निम्नलिखित वॉल्यूम कंटेनर के अंदर रीड-ओनली माउंट किया गया है:

volumes:
  - name: model
    image:
      reference: registry.example.com/models/ranker@sha256:0123456789abcdef
      pullPolicy: IfNotPresent
containers:
  - name: api
    image: registry.example.com/services/ranker-api@sha256:abcdef0123456789
    volumeMounts:
      - name: model
        mountPath: /opt/model
        readOnly: true

Kubernetes एक image volume को kubelet होस्ट पर उपलब्ध कराए गए OCI ऑब्जेक्ट के रूप में दस्तावेज़ित करता है, जिसमें रीड-ओनली सामग्री होती है। Always, Never, और IfNotPresent हर बार खींचने, कभी न खींचने, और स्थानीय रूप से अनुपस्थित होने पर खींचने को व्यक्त करते हैं। प्रोडक्शन आमतौर पर एक पिन किए गए डाइजेस्ट को IfNotPresent के साथ जोड़ता है, जबकि एडमिशन और नोड नियंत्रण आपूर्ति-श्रृंखला सीमा को परिभाषित करते हैं।

3. एडमिशन और अनुमति जांच जोड़ें

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

4. नोड और रनटाइम कम्पैटिबिलिटी सत्यापित करें

Image volumes के लिए नोड, कंटेनर रनटाइम और क्लस्टर वर्ज़न से समर्थन की आवश्यकता होती है। नोड लेबल और शेड्यूलिंग बाधाओं के साथ क्षमता का प्रतिनिधित्व करें, और अपग्रेड के दौरान संगत नोड्स पर एक छोटे बैच का परीक्षण करें। कंट्रोल प्लेन द्वारा फ़ील्ड स्वीकार करने से यह साबित नहीं होता कि प्रत्येक नोड इसे माउंट कर सकता है; मिश्रित-वर्ज़न क्लस्टरों को एक स्पष्ट न्यूनतम क्षमता और डाउनग्रेड योजना की आवश्यकता होती है।

5. रोलआउट और कैश वार्मिंग की योजना बनाएं

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

6. स्टार्टअप और व्यावसायिक परिणामों का अवलोकन करें

वर्कलोड, Pod, नोड, आर्टिफ़ैक्ट डाइजेस्ट और रोलआउट बैच को सहसंबंधित करें। पुल लेटेंसी, स्टार्टअप बैकऑफ़, माउंट त्रुटियों, डिस्क उपयोग, सेल्फ़-चेक और रिक्वेस्ट एरर रेट की निगरानी करें। Kubernetes यह भी दस्तावेज़ित करता है कि एक पुनः बनाया गया Pod रिमोट सामग्री को फिर से हल करता है, इसलिए प्रत्येक नए Pod द्वारा वास्तव में उपयोग किए गए डाइजेस्ट को रिकॉर्ड करें और अंतरों पर अलर्ट करें।

7. रोल बैक और गारबेज-कलेक्ट करें

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

एक मजबूत उत्तर का उदाहरण

मैं मॉडल इमेज को एक इम्यूटेबल रिलीज़ मानता हूँ। बिल्ड एक SBOM, सिग्नेचर और डाइजेस्ट बनाता है; रिलीज़ रिकॉर्ड उस डाइजेस्ट और सर्विस कम्पैटिबिलिटी मैट्रिक्स को संग्रहीत करता है। Pod एक image volume को रीड-ओनली माउंट करता है, और एडमिशन रजिस्ट्रियों को प्रतिबंधित करता है और सिग्नेचर को सत्यापित करता है। एक कंट्रोलर नोड क्षमता और कैनरी बैचों द्वारा प्रगति करता है। Kubernetes Pod स्टार्टअप के दौरान image volume तैयार करता है, और पुल विफलताएं स्टार्टअप को रोकती हैं, इसलिए मैं प्रमाणीकरण, नेटवर्क, डिस्क और बैकऑफ़ संकेतों को अलग करता हूँ। प्रत्येक नया Pod अपने वास्तविक डाइजेस्ट को रिकॉर्ड करता है; केवल सफल सेल्फ़-चेक और रिक्वेस्ट मेट्रिक्स ही रोलआउट को आगे बढ़ाते हैं। विफलता पिछले डाइजेस्ट को पुनर्स्थापित करती है, और क्लीनअप तब तक प्रतीक्षा करता है जब तक कि आर्टिफ़ैक्ट असंदर्भित न हो जाए और रिटेंशन अवधि बीत न जाए।

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

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

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

ConfigMap या नियमित persistent volume क्यों नहीं?

OCI आपूर्ति-श्रृंखला नियंत्रण की आवश्यकता वाली बड़ी, वर्ज़न वाली संपत्तियां image volumes के लिए उपयुक्त हैं। ConfigMap छोटे कॉन्फ़िगरेशन के लिए उपयुक्त है, जबकि एक persistent volume राइटेबल या टिकाऊ क्रॉस-Pod डेटा के लिए उपयुक्त है। अंतिम विकल्प अभी भी आकार, अपडेट विधि, अनुमतियों और रिकवरी उद्देश्यों पर निर्भर करता है।

क्या Always अधिक सुरक्षित है?

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

जब कोई Pod पुनः बनाया जाता है तो क्या होता है?

पुनः बनाया गया Pod रिमोट संदर्भ को हल करता है और वॉल्यूम को फिर से तैयार करता है। संदर्भ, हल किए गए डाइजेस्ट और घटनाओं को रिलीज़ ऑडिट डेटा में रिकॉर्ड करें; यह न मानें कि पुराना नोड कैश नई Pod सामग्री को निर्धारित करता है।

आप subPath का उपयोग कब करेंगे?

subPath का उपयोग तब करें जब आर्टिफ़ैक्ट के अंदर की किसी डायरेक्टरी को एक विशिष्ट पथ पर प्रदर्शित होना हो। वर्तमान Kubernetes दस्तावेज़ीकरण बताता है कि image-volume subPath और subPathExpr समर्थन v1.33 में शुरू होता है, इसलिए लक्ष्य क्लस्टर वर्ज़न को सत्यापित करें।

आप digest-status क्षमता अंतरों को कैसे संभालते हैं?

वर्तमान Kubernetes दस्तावेज़ीकरण में, image volumes v1.36 दस्तावेज़ीकरण में स्थिर हैं; ImageVolumeWithDigest स्टेटस फ़ील्ड अभी भी अल्फ़ा के रूप में चिह्नित है और संबंधित वर्ज़न और फ़ीचर गेट पर निर्भर करता है। रोलआउट को उस स्टेटस फ़ील्ड को सार्वभौमिक रूप से उपलब्ध नहीं मानना चाहिए।