कस्टम संसाधन परिभाषाएँ (Custom Resource Definitions)

यह सर्वोत्तम प्रक्रियाओं मार्गदर्शिका (Best Practices Guide) का वह भाग है जो कस्टम संसाधन परिभाषा (Custom Resource Definition - CRD) ऑब्जेक्ट्स को बनाने और उपयोग करने से संबंधित है।

कस्टम संसाधन परिभाषाओं (CRDs) के साथ काम करते समय, दो अलग-अलग भागों को समझना आवश्यक है:

• एक CRD की घोषणा होती है। यह YAML फ़ाइल होती है, जिसमें CustomResourceDefinition प्रकार (kind) होता है।
• फिर वे संसाधन होते हैं जो इस CRD का उपयोग करते हैं। मान लीजिए कि एक CRD foo.example.com/v1 को परिभाषित करता है।
  कोई भी संसाधन जिसमें apiVersion: example.com/v1 और प्रकार (kind) Foo हो, वह इस CRD का उपयोग करने वाला संसाधन माना जाएगा।

संसाधन का उपयोग करने से पहले एक CRD घोषणा स्थापित करें

Helm को यथासंभव तेज़ी से अधिकतम संसाधनों को Kubernetes में लोड करने के लिए अनुकूलित किया गया है।
डिज़ाइन के अनुसार, Kubernetes पूरी मैनिफेस्ट फ़ाइलों के सेट को एक साथ लोड कर सकता है और उन्हें सक्रिय कर सकता है (इसे समन्वय लूप - reconciliation loop कहा जाता है)।

लेकिन CRDs के मामले में स्थिति अलग होती है।

CRD के लिए, इसकी घोषणा को पंजीकृत (register) करना आवश्यक होता है, इससे पहले कि उस CRD प्रकार (kind) के किसी भी संसाधन का उपयोग किया जा सके।
और यह पंजीकरण प्रक्रिया कभी-कभी कुछ सेकंड तक ले सकती है।

विधि 1: helm को यह काम करने दें

Helm 3 के आने के साथ, हमने पुरानी crd-install hooks को हटा दिया और इसे एक सरल प्रक्रिया से बदल दिया।
अब आपके चार्ट में एक विशेष डायरेक्टरी crds बनाई जा सकती है, जिसमें आपके CRDs रखे जा सकते हैं।
ये CRDs टेम्प्लेटेड नहीं होते, लेकिन जब आप चार्ट के लिए helm install चलाते हैं, तो ये डिफ़ॉल्ट रूप से स्थापित कर दिए जाते हैं।

यदि CRD पहले से मौजूद है, तो इसे छोड़ दिया जाएगा और एक चेतावनी (warning) दिखाई जाएगी।
यदि आप CRD स्थापना चरण को छोड़ना चाहते हैं, तो आप --skip-crds फ़्लैग का उपयोग कर सकते हैं।

कुछ चेतावनियाँ (और स्पष्टीकरण)

वर्तमान में, Helm के माध्यम से CRDs को अपग्रेड या हटाने (delete) का समर्थन नहीं किया गया है।
कई चर्चाओं के बाद, समुदाय ने इसे जानबूझकर हटाने का निर्णय लिया क्योंकि इससे अनजाने में डेटा हानि (data loss) हो सकती थी।
इसके अलावा, अभी तक CRDs और उनके जीवनचक्र (lifecycle) को संभालने के लिए कोई ठोस सामुदायिक सहमति नहीं बनी है।
जैसे-जैसे इस पर प्रगति होगी, Helm इन मामलों के लिए समर्थन जोड़ देगा।

helm install और helm upgrade के --dry-run फ़्लैग का वर्तमान में CRDs के लिए समर्थन नहीं है।
"Dry Run" का उद्देश्य यह सत्यापित करना है कि चार्ट का आउटपुट सर्वर पर भेजे जाने के बाद सही तरीके से कार्य करेगा या नहीं।
लेकिन CRDs सर्वर के व्यवहार (behavior) को संशोधित करते हैं।
Helm ड्राई रन के दौरान CRD को स्थापित नहीं कर सकता, इसलिए डिस्कवरी क्लाइंट उस कस्टम संसाधन (CR) को पहचान नहीं पाएगा,
और इस कारण सत्यापन (validation) विफल हो जाएगा।
इसके बजाय, आप CRDs को उनके स्वयं के चार्ट में स्थानांतरित कर सकते हैं या helm template का उपयोग कर सकते हैं।

CRD समर्थन पर चर्चा करते समय एक और महत्वपूर्ण बिंदु यह है कि टेम्प्लेट्स की रेंडरिंग कैसे की जाती है।
Helm 2 में उपयोग की जाने वाली crd-install विधि की एक बड़ी कमी यह थी कि यह API की उपलब्धता बदलने के कारण चार्ट को सही ढंग से मान्य नहीं कर सकती थी।
(CRD वास्तव में आपके Kubernetes क्लस्टर में एक नई API जोड़ता है।)

यदि किसी चार्ट ने एक CRD स्थापित किया, तो helm के पास एक वैध API संस्करणों का सेट नहीं बचता था।
यही कारण है कि CRDs के लिए टेम्प्लेटिंग समर्थन हटा दिया गया।
नई crds विधि के साथ, अब यह सुनिश्चित किया गया है कि helm के पास क्लस्टर की वर्तमान स्थिति की पूरी तरह से वैध जानकारी हो।

विधि 2: अलग-अलग चार्ट्स

इस कार्य को करने का एक और तरीका यह है कि CRD परिभाषा (definition) को एक चार्ट में रखा जाए,
और उस CRD का उपयोग करने वाले संसाधनों को दूसरे चार्ट में रखा जाए।

इस विधि में, प्रत्येक चार्ट को अलग-अलग स्थापित (install) करना आवश्यक होता है।
हालाँकि, यह प्रक्रिया क्लस्टर ऑपरेटरों के लिए अधिक उपयोगी हो सकती है,
जो क्लस्टर में व्यवस्थापक (admin) एक्सेस रखते हैं।