Kustomize के लिए एक संक्षिप्त परिचय

टिप्पणी। अनुवाद।: यह लेख आईटी में व्यापक अनुभव वाले एक इंजीनियर स्कॉट लोव द्वारा लिखा गया था, जो सात मुद्रित पुस्तकों (मुख्य रूप से VMware vSphere पर) के लेखक/सह-लेखक हैं। वह अब इसकी VMware सहायक कंपनी हेप्टियो (2016 में अधिग्रहीत) के लिए काम करता है, जो क्लाउड कंप्यूटिंग और कुबेरनेट्स में विशेषज्ञता रखती है। पाठ स्वयं प्रौद्योगिकी का उपयोग करके कुबेरनेट्स के लिए कॉन्फ़िगरेशन प्रबंधन के लिए एक संक्षिप्त और समझने में आसान परिचय के रूप में कार्य करता है अनुकूलित करें, जो हाल ही में K8s का हिस्सा बन गया है।

कस्टमाइज़ एक उपकरण है जो उपयोगकर्ताओं को "मूल वाईएएमएल को बरकरार और प्रयोग करने योग्य छोड़कर, विभिन्न उद्देश्यों के लिए सरल, टेम्पलेट-मुक्त वाईएएमएल फ़ाइलों को अनुकूलित करने की अनुमति देता है" (विवरण सीधे से उधार लिया गया है) GitHub पर रिपॉजिटरी को अनुकूलित करें). कस्टमाइज़ को सीधे चलाया जा सकता है या कुबेरनेट्स 1.14 के अनुसार उपयोग किया जा सकता है kubectl -k इसकी कार्यक्षमता तक पहुँचने के लिए (हालाँकि कुबेरनेट्स 1.15 के अनुसार, अलग बाइनरी कुबेक्टल में निर्मित क्षमताओं की तुलना में नई है)। (टिप्पणी। अनुवाद।: और हालिया रिलीज के साथ कुबेरनेट्स 1.16 अनुकूलित करें का समर्थन किया kubeadm उपयोगिता में भी।) इस पोस्ट में, मैं पाठकों को कस्टमाइज़ की मूल बातों से परिचित कराना चाहता हूँ।

अपने सरलतम रूप/अनुप्रयोग में, कस्टमाइज़ केवल संसाधनों का एक संग्रह है (YAML फ़ाइलें जो Kubernetes ऑब्जेक्ट को परिभाषित करती हैं: परिनियोजन, सेवाएँ, आदि) और साथ ही उन संसाधनों में किए जाने वाले परिवर्तनों के लिए निर्देशों की एक सूची है। जैसे मेक में निहित अनुदेश सेट का उपयोग करता है Makefile, और डॉकर निर्देशों के आधार पर कंटेनर बनाता है Dockerfile,उपयोग अनुकूलित करें kustomization.yaml उपयोगकर्ता संसाधनों के सेट में क्या परिवर्तन करना चाहता है, इसके बारे में निर्देश संग्रहीत करना।

यहाँ एक उदाहरण फ़ाइल है kustomization.yaml:

resources:
- deployment.yaml
- service.yaml
namePrefix: dev-
namespace: development
commonLabels:
  environment: development

मैं फ़ाइल में सभी संभावित फ़ील्ड के बारे में बात करने का प्रयास नहीं करूंगा। kustomization.yaml (इसके बारे में अच्छा लिखा है यहां), लेकिन मैं एक विशिष्ट उदाहरण का संक्षिप्त विवरण दूंगा:

• क्षेत्र resources इंगित करता है कि क्या (कौन से संसाधन) अनुकूलन बदल जाएगा। इस स्थिति में, यह फ़ाइलों में संसाधनों की तलाश करेगा deployment.yaml и service.yaml अपनी निर्देशिका में (यदि आवश्यक हो तो आप पूर्ण या सापेक्ष पथ निर्दिष्ट कर सकते हैं)।
• क्षेत्र namePrefix एक निश्चित उपसर्ग जोड़ने के लिए अनुकूलित करने का निर्देश देता है (इस मामले में - dev-) विशेषता हेतु name क्षेत्र में परिभाषित सभी संसाधन resources. इस प्रकार, यदि परिनियोजन है name अर्थ सहित nginx-deployment, अनुकूलित यह बना देगा dev-nginx-deployment.
• क्षेत्र namespace सभी संसाधनों में दिए गए नेमस्पेस को जोड़ने के लिए कस्टमाइज़ को निर्देश देता है। इस स्थिति में, परिनियोजन और सेवा नामस्थान में आ जाएंगे development.
• अंत में, मैदान commonLabels इसमें लेबल का एक सेट शामिल है जिसे सभी संसाधनों में जोड़ा जाएगा। हमारे उदाहरण में, कस्टमाइज़ संसाधनों को नाम के साथ एक लेबल निर्दिष्ट करेगा environment और अर्थ development.

यदि उपयोगकर्ता करता है kustomize build . फ़ाइल के साथ निर्देशिका में kustomization.yaml और आवश्यक संसाधन (अर्थात् फ़ाइलें deployment.yaml и service.yaml), फिर आउटपुट पर इसे निर्दिष्ट परिवर्तनों के साथ एक टेक्स्ट प्राप्त होगा kustomization.yaml.

टिप्पणी। अनुवाद।: कस्टमाइज़ के "सरल" उपयोग पर परियोजना दस्तावेज़ीकरण से चित्रण

यदि परिवर्तन करने की आवश्यकता हो तो आउटपुट को पुनर्निर्देशित किया जा सकता है:

kustomize build . > custom-config.yaml

आउटपुट डेटा नियतात्मक है (समान इनपुट डेटा समान आउटपुट परिणाम देगा), इसलिए आपको परिणाम को फ़ाइल में सहेजने की ज़रूरत नहीं है। इसके बजाय, इसे सीधे किसी अन्य कमांड में भेजा जा सकता है:

kustomize build . | kubectl apply -f -

अनुकूलित सुविधाओं को इसके माध्यम से भी एक्सेस किया जा सकता है kubectl -k (कुबेरनेट्स संस्करण 1.14 के बाद से)। हालाँकि, ध्यान रखें कि स्टैंडअलोन कस्टमाइज़ पैकेज एकीकृत कुबेक्टल पैकेज की तुलना में तेज़ी से अपडेट किया जाता है (कम से कम कुबेरनेट्स 1.15 रिलीज़ के मामले में यही है)।

पाठक पूछ सकते हैं: "यदि आप फ़ाइलों को सीधे संपादित कर सकते हैं तो इतनी जटिलता क्यों?" बढ़िया सवाल. हमारे उदाहरण में, वास्तव में एक कर सकते हैं फ़ाइलें संशोधित करें deployment.yaml и service.yaml सीधे तौर पर, लेकिन क्या होगा अगर वे किसी और के प्रोजेक्ट का हिस्सा हों? फ़ाइलों को सीधे बदलने से मूल/स्रोत में परिवर्तन किए जाने पर फोर्क को दोबारा आधार बनाना मुश्किल (यदि असंभव नहीं) हो जाता है। कस्टमाइज़ का उपयोग करने से आप इन परिवर्तनों को फ़ाइल में केंद्रीकृत कर सकते हैं kustomization.yaml, मूल फ़ाइलों को बरकरार रखता है और इस प्रकार यदि आवश्यक हो तो मूल फ़ाइलों को फिर से आधार बनाना आसान बनाता है।

अधिक जटिल उपयोग के मामलों में कस्टमाइज़ के लाभ स्पष्ट हो जाते हैं। उपरोक्त उदाहरण में kustomization.yaml और संसाधन एक ही निर्देशिका में हैं। हालाँकि, कस्टमाइज़ उन उपयोग के मामलों का समर्थन करता है जहाँ एक आधार कॉन्फ़िगरेशन और इसके कई प्रकार होते हैं, जिन्हें इसके रूप में भी जाना जाता है ओवरले. उदाहरण के लिए, एक उपयोगकर्ता nginx के लिए परिनियोजन और सेवा लेना चाहता था, जिसे मैंने एक उदाहरण के रूप में उपयोग किया था, और उन फ़ाइलों के विकास, स्टेजिंग और उत्पादन संस्करण (या वेरिएंट) बनाना चाहता था। ऐसा करने के लिए, उसे उपर्युक्त ओवरले और वास्तव में, बुनियादी संसाधनों की आवश्यकता होगी।

ओवरले और अंतर्निहित संसाधनों के विचार को स्पष्ट करने के लिए (आधार संसाधन), आइए मान लें कि निर्देशिकाओं की संरचना निम्नलिखित है:

- base
  - deployment.yaml
  - service.yaml
  - kustomization.yaml
- overlays
  - dev
    - kustomization.yaml
  - staging
    - kustomization.yaml
  - prod
    - kustomization.yaml

फाइल मैं base/kustomization.yaml फ़ील्ड का उपयोग करने वाले उपयोगकर्ता resources बस उन संसाधनों की घोषणा करें जिनमें अनुकूलन शामिल होना चाहिए।

प्रत्येक फ़ाइल में overlays/{dev,staging,prod}/kustomization.yaml उपयोगकर्ता फ़ील्ड में आधार कॉन्फ़िगरेशन का संदर्भ लेते हैं resources, और फिर इसके लिए विशिष्ट परिवर्तन इंगित करें दिया गया वातावरण. उदाहरण के लिए, फ़ाइल 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 . कैटलॉग में overlays/dev, अनुकूलन विकास विकल्प उत्पन्न करेगा। यदि आप दौड़ते हैं kustomize build . कैटलॉग में overlays/prod - आपको उत्पादन का विकल्प मिलता है। और यह सब - मूल में कोई बदलाव किए बिना (आधार) फ़ाइलें, सभी घोषणात्मक और नियतात्मक तरीके से। आप बेस कॉन्फ़िगरेशन और ओवरले निर्देशिकाओं को सीधे संस्करण नियंत्रण के लिए प्रतिबद्ध कर सकते हैं, यह जानते हुए कि इन फ़ाइलों के आधार पर आप किसी भी समय वांछित कॉन्फ़िगरेशन को पुन: उत्पन्न कर सकते हैं।

टिप्पणी। अनुवाद।: अनुकूलन में ओवरले का उपयोग करने पर परियोजना दस्तावेज़ीकरण से चित्रण

अनुकूलित कर सकते हैं अधिक इस लेख में जो बताया गया है उससे कहीं अधिक। हालाँकि, मुझे आशा है कि यह एक अच्छे परिचय के रूप में काम करेगा।

अतिरिक्त संसाधन

कस्टमाइज़ के बारे में कई अच्छे लेख और प्रकाशन हैं। यहाँ कुछ हैं जो मुझे विशेष रूप से उपयोगी लगे:

• Kustomize का उपयोग करके विभिन्न परिवेशों के उत्पाद/परीक्षण के लिए आधार YAML कॉन्फ़िगरेशन बदलें;
• कस्टमाइज़ करें - कुबेरनेट्स में टेम्प्लेटिंग करने का सही तरीका;
• कस्टमाइज़ का उपयोग करके कुबेरनेट्स ऑब्जेक्ट का घोषणात्मक प्रबंधन;
• कस्टमाइज़ के साथ अपस्ट्रीम हेल्म चार्ट को कस्टमाइज़ करना.

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

यदि इस सामग्री को बेहतर बनाने के लिए आपके कोई प्रश्न या सुझाव हैं, तो मैं प्रतिक्रिया के लिए हमेशा तैयार हूं। आप मुझसे यहां संपर्क कर सकते हैं ट्विटर या कुबेरनेट्स स्लैक चैनल. अनुकूलन के साथ अपने मैनिफ़ेस्ट को संशोधित करने का आनंद लें!

अनुवादक से पी.एस

हमारे ब्लॉग पर भी पढ़ें:

• «कुबेरनेट्स पर चलने वाले एप्लिकेशन के डेवलपर्स के लिए उपकरण";
• «कुबेरनेट्स 1.14: मुख्य नवाचारों का अवलोकन";
• «एम्स्टर्डम में हेल्म शिखर सम्मेलन 2019 के पांच मुख्य परिणाम";
• «कुबेरनेट्स के लिए पैकेज मैनेजर का व्यावहारिक परिचय - हेल्म'.

स्रोत: www.habr.com