Kustomize चा संक्षिप्त परिचय

नोंद. अनुवाद: लेख स्कॉट लोव यांनी लिहिला आहे, जो IT मध्ये व्यापक अनुभव असलेले अभियंता आहे, जो सात छापील पुस्तकांचे लेखक/सह-लेखक आहे (मुख्यतः VMware vSphere वर). तो आता त्याच्या VMware उपकंपनी Heptio (2016 मध्ये विकत घेतले), क्लाउड कंप्युटिंग आणि Kubernetes मध्ये विशेष काम करतो. मजकूर स्वतःच तंत्रज्ञानाचा वापर करून कुबर्नेट्ससाठी कॉन्फिगरेशन व्यवस्थापनाचा संक्षिप्त आणि समजण्यास सुलभ परिचय म्हणून काम करतो सानुकूल करा, जे अलीकडे K8s चा भाग बनले आहे.

Kustomize हे एक साधन आहे जे वापरकर्त्यांना "वेगवेगळ्या उद्देशांसाठी साध्या, टेम्पलेट-मुक्त YAML फायली सानुकूलित करण्याची परवानगी देते, मूळ YAML अखंड आणि वापरण्यायोग्य सोडून" (वर्णन थेट कडून घेतलेले GitHub वर रिपॉजिटरी कस्टमाइझ करा). Kustomize थेट चालवले जाऊ शकते किंवा, Kubernetes 1.14 नुसार, वापरले जाऊ शकते kubectl -k त्याच्या कार्यक्षमतेमध्ये प्रवेश करण्यासाठी (जरी Kubernetes 1.15 नुसार, स्वतंत्र बायनरी कुबेक्टलमध्ये तयार केलेल्या क्षमतांपेक्षा नवीन आहे). (नोंद. अनुवाद: आणि अलीकडील रिलीझ सह कुबर्नेट्स 1.16 सानुकूलित करा द्वारे समर्थित kubeadm युटिलिटीमध्ये देखील.) या पोस्टमध्ये, मी वाचकांना kustomize च्या मूलभूत गोष्टींचा परिचय करून देऊ इच्छितो.

त्याच्या सर्वात सोप्या फॉर्म/अॅप्लिकेशनमध्ये, kustomize हा फक्त संसाधनांचा संग्रह आहे (YAML फाइल्स ज्या Kubernetes ऑब्जेक्ट्स: डिप्लॉयमेंट्स, सर्व्हिसेस इ. परिभाषित करतात) तसेच त्या संसाधनांमध्ये करावयाच्या बदलांसाठी सूचनांची सूची आहे. ज्याप्रमाणे मेकमध्ये समाविष्ट असलेल्या सूचना संचाचा वापर केला जातो Makefile, आणि डॉकर कडील सूचनांवर आधारित कंटेनर तयार करतो 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 विशिष्ट उपसर्ग जोडण्यासाठी kustomize सूचना देते (या प्रकरणात - dev-) विशेषता name क्षेत्रात परिभाषित सर्व संसाधने resources. अशा प्रकारे, उपयोजन असल्यास name अर्थासह nginx-deployment, सानुकूलित करेल dev-nginx-deployment.
• फील्ड namespace सर्व संसाधनांमध्ये दिलेले नेमस्पेस जोडण्यासाठी kustomize सूचना देते. या प्रकरणात, उपयोजन आणि सेवा नेमस्पेसमध्ये येतील development.
• शेवटी, फील्ड commonLabels लेबलांचा संच आहे जो सर्व संसाधनांमध्ये जोडला जाईल. आमच्या उदाहरणात, kustomize नावासह संसाधनांना लेबल नियुक्त करेल environment आणि अर्थ development.

जर वापरकर्ता करतो kustomize build . फाइलसह निर्देशिकेत kustomization.yaml आणि आवश्यक संसाधने (उदा. फाइल्स deployment.yaml и service.yaml), नंतर आउटपुटवर त्यात निर्दिष्ट केलेल्या बदलांसह एक मजकूर प्राप्त होईल kustomization.yaml.

नोंद. अनुवाद: kustomize च्या “साध्या” वापरावरील प्रकल्प दस्तऐवजीकरणातील उदाहरण

बदल करणे आवश्यक असल्यास आउटपुट पुनर्निर्देशित केले जाऊ शकते:

kustomize build . > custom-config.yaml

आउटपुट डेटा निर्धारक आहे (समान इनपुट डेटा समान आउटपुट परिणाम देईल), त्यामुळे तुम्हाला निकाल फाइलमध्ये सेव्ह करण्याची गरज नाही. त्याऐवजी, ते थेट दुसर्‍या कमांडवर पास केले जाऊ शकते:

kustomize build . | kubectl apply -f -

कस्टमाइझ वैशिष्ट्यांद्वारे देखील प्रवेश केला जाऊ शकतो kubectl -k (Kubernetes आवृत्ती 1.14 पासून). तथापि, लक्षात ठेवा की स्टँडअलोन kustomize पॅकेज एकात्मिक kubectl पॅकेजपेक्षा अधिक जलद अपडेट केले जाते (किमान हे Kubernetes 1.15 प्रकाशनाच्या बाबतीत आहे).

वाचक विचारू शकतात: "जर तुम्ही फाइल्स थेट संपादित करू शकत असाल तर ही सर्व गुंतागुंत का?" छान प्रश्न. आमच्या उदाहरणात, खरंच करू शकता फाइल्स सुधारित करा deployment.yaml и service.yaml थेट, पण ते दुसऱ्याच्या प्रकल्पाचे काटे असतील तर? फायली बदलल्याने मूळ/स्रोतामध्ये बदल केले जातात तेव्हा फॉर्क रिबेस करणे कठीण होते (अशक्य नसल्यास). kustomize वापरल्याने तुम्हाला हे बदल एका फाईलमध्ये केंद्रीकृत करण्याची परवानगी मिळते 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 कस्टमाइझमध्ये समाविष्ट असले पाहिजेत अशी संसाधने फक्त घोषित करा.

प्रत्येक फायलीमध्ये 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 विकास पर्याय निर्माण करेल. आपण धावत असल्यास kustomize build . कॅटलॉगमध्ये overlays/prod - तुम्हाला उत्पादन पर्याय मिळेल. आणि हे सर्व - मूळमध्ये कोणतेही बदल न करता (पाया) फायली, सर्व घोषणात्मक आणि निर्धारवादी मार्गाने. तुम्ही बेस कॉन्फिगरेशन आणि आच्छादित निर्देशिका थेट आवृत्ती नियंत्रणासाठी कमिट करू शकता, या फायलींवर आधारित तुम्ही कधीही इच्छित कॉन्फिगरेशनचे पुनरुत्पादन करू शकता.

नोंद. अनुवाद: kustomize मध्ये आच्छादन वापरण्यावर प्रकल्प दस्तऐवजीकरणातील उदाहरण

सानुकूल करू शकता खूप या लेखात जे समाविष्ट आहे त्यापेक्षा जास्त. तथापि, मला आशा आहे की तो एक चांगला परिचय म्हणून काम करेल.

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

kustomize बद्दल बरेच चांगले लेख आणि प्रकाशने आहेत. येथे काही आहेत जे मला विशेषतः उपयुक्त वाटले:

• Kustomize वापरून वेगवेगळ्या वातावरणातील उत्पादन/चाचणीसाठी बेस YAML कॉन्फिगरेशन बदला;
• Kustomize — Kubernetes मध्ये टेम्प्लेटिंग करण्याचा योग्य मार्ग;
• सानुकूलित वापरून कुबर्नेट्स ऑब्जेक्ट्सचे घोषणात्मक व्यवस्थापन;
• सानुकूलित सह अपस्ट्रीम हेल्म चार्ट सानुकूलित करणे.

नोंद. अनुवाद: तुम्ही प्रकाशित केलेल्या लिंक्सच्या ब्लॉकची शिफारस देखील करू शकता साधनसंपत्ती युटिलिटीच्या वेबसाइटवर, त्यानंतर kustomize बद्दल नवीनतम अहवालांसह व्हिडिओंचा संग्रह.

ही सामग्री सुधारण्यासाठी आपल्याकडे प्रश्न किंवा सूचना असल्यास, मी नेहमी अभिप्रायासाठी तयार आहे. तुम्ही माझ्याशी येथे संपर्क साधू शकता Twitter किंवा कुबर्नेट्स स्लॅक चॅनेल. कस्टमाइझसह तुमचे मॅनिफेस्ट सुधारण्यात मजा करा!

अनुवादकाकडून पुनश्च

आमच्या ब्लॉगवर देखील वाचा:

• «Kubernetes वर चालणार्‍या ऍप्लिकेशन्सच्या विकसकांसाठी साधने";
• «कुबर्नेट्स 1.14: मुख्य नवकल्पनांचे विहंगावलोकन";
• «अॅमस्टरडॅममधील हेल्म समिट 2019 चे पाच मुख्य निकाल";
• «कुबर्नेट्स - हेल्मसाठी पॅकेज मॅनेजरचा व्यावहारिक परिचय».

स्त्रोत: www.habr.com