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

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

Kustomize एउटा उपकरण हो जसले प्रयोगकर्ताहरूलाई "विभिन्न उद्देश्यका लागि सरल, टेम्प्लेट-रहित YAML फाइलहरू अनुकूलन गर्न, मूल YAML लाई अक्षुण्ण र प्रयोगयोग्य छोडेर" (विवरण सीधै बाट उधारो GitHub मा भण्डार अनुकूलन गर्नुहोस्)। Kustomize सिधै चलाउन सकिन्छ वा, Kubernetes 1.14 को रूपमा प्रयोग गरिन्छ kubectl -k यसको कार्यक्षमता पहुँच गर्न (यद्यपि Kubernetes 1.15 को रूपमा, अलग बाइनरी kubectl मा निर्मित क्षमताहरू भन्दा नयाँ छ)। (नोट। अनुवाद।: र भर्खरै रिलीज संग कुबर्नेट १.१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 केवल kustomize समावेश गर्नु पर्ने स्रोतहरू घोषणा गर्नुहोस्।

प्रत्येक फाइलमा 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 मा टेम्प्लेट गर्ने सही तरिका;
• अनुकूलन प्रयोग गरेर Kubernetes वस्तुहरूको घोषणात्मक व्यवस्थापन;
• अनुकूलनको साथ अपस्ट्रीम हेल्म चार्टहरू अनुकूलित गर्दै.

नोट। अनुवाद।: तपाईं पनि प्रकाशित लिङ्कहरूको ब्लक सिफारिस गर्न सक्नुहुन्छ संसाधन उपयोगिताको वेबसाइटमा, त्यसपछि kustomize बारे नवीनतम रिपोर्टहरू सहित भिडियोहरूको संग्रह।

यदि तपाइँसँग यो सामग्री सुधार गर्न प्रश्न वा सुझावहरू छन् भने, म सधैं प्रतिक्रियाको लागि खुला छु। मा सम्पर्क गर्न सक्नुहुन्छ twitter वा Kubernetes Slack च्यानल। kustomize को साथ आफ्नो manifests परिमार्जन गर्न मजा लिनुहोस्!

अनुवादकबाट PS

हाम्रो ब्लगमा पनि पढ्नुहोस्:

• «Kubernetes मा चलिरहेको अनुप्रयोगहरूको विकासकर्ताहरूको लागि उपकरण»;
• «Kubernetes 1.14: मुख्य आविष्कारहरूको सिंहावलोकन»;
• «एम्स्टर्डममा हेल्म समिट 2019 को पाँच मुख्य परिणामहरू»;
• «Kubernetes - Helm को लागि प्याकेज प्रबन्धक को व्यावहारिक परिचय"।

स्रोत: www.habr.com