लगभग। ट्रांस। : लेख स्कॉट लोवे द्वारा लिखा गया था, जो एक वरिष्ठ आईटी इंजीनियर थे जिन्होंने सात मुद्रित पुस्तकों (मुख्य रूप से वीएमवेयर वीस्फेयर के लिए) का सह-लेखन / सह-लेखन किया था। वह वर्तमान में क्लाउड कंप्यूटिंग और कुबेरनेट्स में विशेषज्ञता रखने वाले अपने वीएमवेयर सहायक हेप्टियो (2016 में अधिग्रहीत) में काम करता है। पाठ स्वयं Kustom के लिए Kubernetes के लिए कॉन्फ़िगरेशन प्रबंधन के लिए एक कैपेसिटिव और आसानी से समझने वाले परिचय के रूप में कार्य करता है, हाल ही में K8s के साथ शामिल है।
Kustomize एक ऐसा उपकरण है, जो उपयोगकर्ताओं को विभिन्न उद्देश्यों के लिए सरल और टेम्पलेट-मुक्त YAML फ़ाइलों को अनुकूलित करने की अनुमति देता है, जिससे मूल YAML बरकरार और प्रयोग करने योग्य हो जाता है "(विवरण सीधे
GitHub पर कस्टमाइज़ रिपॉजिटरी से उधार लिया
गया है )। Kustomernetes 1.14 के साथ शुरू करके Kustomern सीधे चलाया जा सकता है या, अपने कार्यों तक पहुंचने के लिए
kubectl -k का उपयोग करें (हालांकि Kubernetes 1.15 के रूप में, एक अलग बाइनरी Kubectl में निर्मित सुविधाओं की तुलना में नया है)।
( नोट : हाल के कुबेरनेट्स 1.16 रिलीज के साथ, कुबेदम उपयोगिता में kustomize का भी समर्थन किया गया है।) इस पोस्ट में, मैं पाठकों को kustomize की मूल बातें से परिचित कराना चाहता हूं।
इसके सरलतम रूप / अनुप्रयोग में, kustomize केवल संसाधनों का एक संग्रह है (YAML फाइलें जो कुबेरनेट वस्तुओं को परिभाषित करती हैं: तैनाती, सेवाएं, आदि) प्लस इन संसाधनों पर किए जाने वाले परिवर्तनों की निर्देशों की एक सूची। जैसे
Makefile में निहित अनुदेश सेट का उपयोग करता है, और Docker, Dockerfile के निर्देशों के आधार पर
Dockerfile कंटेनर
Dockerfile , उपयोगकर्ता को संसाधन सेट में क्या परिवर्तन करना है, इस बारे में निर्देशों को संग्रहीत करने के लिए kustomization.yaml का उपयोग करता है।
यहाँ एक उदाहरण है
kustomization.yaml फ़ाइल:
resources: - deployment.yaml - service.yaml namePrefix: dev- namespace: development commonLabels: environment: development
मैं
kustomization.yaml फ़ाइल में सभी संभावित क्षेत्रों के बारे में बात करने की कोशिश नहीं करूँगा (यह अच्छी तरह से
यहां लिखा गया
है ), लेकिन मैं एक विशिष्ट उदाहरण का संक्षिप्त विवरण दूंगा:
resources फ़ील्ड इंगित करता है कि (कौन से संसाधन) kustomize बदल जाएगा। इस स्थिति में, यह अपनी निर्देशिका (यदि आवश्यक हो, तो आप पूर्ण या सापेक्ष पथ निर्दिष्ट कर सकते हैं) में deployment.yaml और service.yaml फ़ाइलों के लिए संसाधन देखेंगे।namePrefix फ़ील्ड, resources फ़ील्ड में परिभाषित सभी संसाधनों के name विशेषता के लिए एक विशिष्ट उपसर्ग (इस मामले में, dev- ) जोड़ने के लिए kustomize करने का निर्देश देती है। इस प्रकार, यदि मूल्य nginx- परिनियोजन के साथ परिनियोजन में एक name है, तो kustomize इसमें से dev-nginx-deployment nginx- nginx-deployment करेगा।namespace फ़ील्ड सभी संसाधनों में निर्दिष्ट नाम स्थान जोड़ने के लिए kustomize करने का निर्देश देती है। इस स्थिति में, परिनियोजन और सेवा development नामस्थान में आ जाएगी।- अंत में,
commonLabels फ़ील्ड में लेबल का एक सेट होता है जिसे सभी संसाधनों में जोड़ा जाएगा। हमारे उदाहरण में, kustomize नाम environment और मूल्य development साथ संसाधनों पर एक लेबल प्रदान करेगा।
यदि उपयोगकर्ता
kustomize build . निर्देशिका में
kustomization.yaml फ़ाइल और आवश्यक संसाधन (यानी
deployment.yaml kustomization.yaml और
service.yaml फ़ाइलें) के साथ, फिर आउटपुट पर यह पाठ
kustomization.yaml में पंजीकृत परिवर्तनों के साथ प्राप्त करेगा।
लगभग। ट्रांस। : कस्टमाइज़ के "सरल" उपयोग के लिए परियोजना प्रलेखन से चित्रणयदि आपको परिवर्तन करने की आवश्यकता है तो आउटपुट को पुनर्निर्देशित किया जा सकता है:
kustomize build . > custom-config.yaml
आउटपुट नियतात्मक है (एक ही इनपुट के साथ, एक ही आउटपुट प्राप्त किया जाएगा), इसलिए आप परिणाम को एक फ़ाइल में सहेज नहीं सकते हैं। इसके बजाय, आप तुरंत इसे किसी अन्य कमांड में भेज सकते हैं:
kustomize build . | kubectl apply -f -
Kustomectl फ़ंक्शन को
kubectl -k (
kubectl -k संस्करण 1.14 के बाद से) तक पहुँचा जा सकता है। हालांकि, यह ध्यान रखें कि एक अलग kustomize पैकेज kubectl में एक एकीकृत (तेजी से कम से कम Kubernetes 1.15 के रिलीज के साथ मामला है) की तुलना में तेजी से अपडेट किया जाता है।
पाठक पूछ सकते हैं: "ये सभी कठिनाइयाँ, यदि आप सीधे फाइलों को संपादित कर सकते हैं?"। बड़ा सवाल है। हमारे उदाहरण में,
deployment.yaml .
deployment.yaml और
service.yaml फ़ाइलों को सीधे संशोधित करना वास्तव में
संभव है , लेकिन क्या होगा यदि वे किसी और की परियोजना के कांटे हैं? जब स्रोत / स्रोत में परिवर्तन किए जाते हैं, तो फोर्क को फिर से रिबास करने के लिए सीधे फाइलों को बदलना (यदि असंभव नहीं है तो) मुश्किल हो जाता है। Kustomize का उपयोग करने से आप
kustomization.yaml फ़ाइल में इन परिवर्तनों को केंद्रीकृत कर सकते हैं, मूल फ़ाइलों को बरकरार
kustomization.yaml सकते हैं और इस प्रकार यदि आवश्यक हो तो स्रोत फ़ाइलों को फिर से बनाना आसान बना सकते हैं।
अधिक जटिल उपयोग मामलों में kustomize के लाभ स्पष्ट हो जाते हैं। उपरोक्त उदाहरण में,
kustomization.yaml और संसाधन एक ही निर्देशिका में हैं। हालाँकि, जब एक बुनियादी विन्यास और उसके कई प्रकार हैं, जिसे
ओवरले भी कहा जाता है, तब kustomize समर्थन परिदृश्यों का समर्थन करता है। उदाहरण के लिए, एक उपयोगकर्ता nginx के लिए परिनियोजन और सेवा लेना चाहता था, जिसे मैंने एक उदाहरण के रूप में उपयोग किया था, और उन फ़ाइलों के विकास-, मंचन और उत्पादन-संस्करण (या संस्करण) बना रहा था। ऐसा करने के लिए, उसे ऊपर बताए गए ओवरले और, वास्तव में, बुनियादी संसाधनों की आवश्यकता होगी।
ओवरले और
आधार संसाधनों के विचार को समझने के लिए मान लीजिए कि निर्देशिकाओं में निम्नलिखित संरचना है:
- base - deployment.yaml - service.yaml - kustomization.yaml - overlays - dev - kustomization.yaml - staging - kustomization.yaml - prod - kustomization.yaml
base/kustomization.yaml उपयोगकर्ता केवल उन
resources को घोषित करने के लिए
resources फ़ील्ड का उपयोग करते हैं, जिन्हें kustomize को सक्षम करना चाहिए।
प्रत्येक
overlays/{dev,staging,prod}/kustomization.yaml उपयोगकर्ता
resources क्षेत्र में मूल कॉन्फ़िगरेशन का संदर्भ
overlays/{dev,staging,prod}/kustomization.yaml , और फिर
इस वातावरण के लिए विशिष्ट परिवर्तनों का संकेत देते
हैं । उदाहरण के लिए,
overlays/dev/kustomization.yaml पहले दिए गए उदाहरण की तरह दिख सकती है:
resources: - ../../base namePrefix: dev- namespace: development commonLabels: environment: development
उसी समय,
overlays/prod/kustomization.yaml पूरी तरह से अलग हो सकती है:
resources: - ../../base namePrefix: prod- namespace: production commonLabels: environment: production sre-team: blue
जब उपयोगकर्ता
kustomize build . शुरू
kustomize build . overlays/dev , kustomize एक विकास विकल्प उत्पन्न करेगा। यदि आप
kustomize build . चलाते हैं
kustomize build . overlays/prod निर्देशिका में - आपको उत्पादन विकल्प मिलता है। और यह सब - मूल
(आधार) फ़ाइलों में कोई बदलाव किए बिना, और यह सब - एक घोषणात्मक और निर्धारक तरीके से। आप मूल कॉन्फ़िगरेशन और ओवरले निर्देशिकाओं को सीधे संस्करण नियंत्रण प्रणाली पर कर सकते हैं, यह जानते हुए कि इन फ़ाइलों के आधार पर आप किसी भी समय वांछित कॉन्फ़िगरेशन को पुन: उत्पन्न कर सकते हैं।
लगभग। ट्रांस। : कस्टमाइज़ में ओवरले का उपयोग करने के लिए परियोजना प्रलेखन से चित्रइस लेख में वर्णित की तुलना में Kustomize अधिक कर सकता है। हालाँकि, मुझे उम्मीद है कि यह एक अच्छे परिचय के रूप में काम करेगा।
अतिरिक्त संसाधन
Kustomize के बारे में कई अच्छे लेख और प्रकाशन हैं। यहाँ कुछ हैं जो मुझे विशेष रूप से उपयोगी लगे:
लगभग। ट्रांस। : आप उपयोगिता वेबसाइट पर संसाधन के रूप में प्रकाशित लिंक के ब्लॉक, और कस्टमाइज़ के बारे में नवीनतम रिपोर्ट के साथ वीडियो के बाद के संग्रह की सलाह दे सकते हैं।यदि आपके पास इस सामग्री को बेहतर बनाने के लिए प्रश्न या सुझाव हैं, तो मैं हमेशा प्रतिक्रिया के लिए खुला हूं। आप मुझसे
ट्विटर पर या
कुबेरनेट्स स्लैक चैनल पर संपर्क कर सकते हैं। मज़े करो अपने मैनिफ़ेस्ट को संशोधित करके kustomize करें!
अनुवादक से पी.एस.
हमारे ब्लॉग में भी पढ़ें: