एक और कुबेरनेट्स टेंपलेटिंग टूल लिखना

यदि आप कुबेरनेट्स के वातावरण के साथ काम कर रहे हैं, तो आप शायद कई मौजूदा टेम्प्लेटिंग टूल का उपयोग करते हैं, उनमें से कुछ पैकेज प्रबंधकों जैसे कि हेल्म या कॉन्सनेट , या सिर्फ टेम्प्लेटिंग लैंग्वेज (जिन्जा 2, गो टेम्प्लेट आदि) का हिस्सा बनते हैं। उन सभी की अपनी कमियां होने के साथ-साथ फायदे भी हैं और हम उनके माध्यम से जा रहे हैं और अपने स्वयं के टूल को लिखने जा रहे हैं जो सर्वोत्तम विशेषताओं को संयोजित करने का प्रयास करेंगे।

तो, हेल्म क्यों नहीं?

हेल्म की आलोचना करने वाले कई लेख हैं (उदाहरण के लिए उनमें से केवल एक: हेल्म का उपयोग करने से पहले दो बार सोचें )। हेल्म के साथ मुख्य मुद्दा यह है कि यह स्ट्रिंग प्रतिनिधित्व के साथ काम करता है और कुबेरनेट्स मैनिफेस्ट्स ( जसन ) ऑब्जेक्ट हैं । हेलम चार्ट डेवलपर के लिए असली नरक तब शुरू होता है जब उसे एक yaml प्रकट के लिए इंडेंट की गणना करने की आवश्यकता होती है, कभी-कभी ऐसा दिखता है (यह मेरे चार्ट से वास्तविक उदाहरण है):

 spec: jobTemplate: spec: template: spec: containers: - name: my-awesome-container resources: {{ toYaml .Values.resources | indent 14 }} 

लेकिन हेल्म आज कुबेरनेट्स अनुप्रयोगों की पैकेजिंग के लिए मानक है। हेल्म का मुख्य लाभ बड़े समुदाय और चार्ट के साथ सार्वजनिक रिपॉजिटरी की एक बड़ी संख्या है। और हाल ही में हेल्म डेवलपर्स ने हेल्म हब की घोषणा की है। इसलिए हेल्म आज डॉकटर की तरह है - यह केवल एक ही नहीं है, बल्कि इसमें समुदाय और समर्थन है।

हेल्म 3 रिलीज के साथ आने वाले बदलाव हो रहे हैं, लेकिन किसी को नहीं पता कि यह कब हो सकता है।

समाप्त करने के लिए, हेल्म लाभ:

• बड़े समुदाय और कई सार्वजनिक चार्ट
• (अपेक्षाकृत) मानव-अनुकूल वाक्य-विन्यास। कम से कम यह yaml + go टेम्पलेट;)

कमियां:

• तार और वस्तुओं के साथ काम करना
• आप उपयोग कर सकते हैं ऑपरेटरों और कार्यों की सीमित संख्या

ठीक है, तो शायद Ksonnet?

यदि आप हेल्स की तुलना Ksonnet से कर रहे हैं तो उत्तरार्द्ध का एक बड़ा लाभ है, अर्थात् यह वस्तुओं के साथ काम करता है। Ksonnet JSON टेम्प्लेटिंग लैंग्वेज Jsonnet पर आधारित एक टूल है। Ksonnet के बारे में एक और अच्छी विशेषता यह है कि इसमें Kubernetes-API-संगत Jsonnet लाइब्रेरी है जिसे आप अपने टेम्पलेट में आयात कर सकते हैं और किसी भी OOP भाषा की तरह Kubernetes ऑब्जेक्ट के साथ काम कर सकते हैं:

 local k = import "k.libsonnet"; local deployment = k.apps.v1beta1.deployment; local appDeployment = deployment .new( params.name, params.replicas, container .new(params.name, params.image) .withPorts(containerPort.new(targetPort)), labels); 

प्रभावशाली लगता है, है ना?
जब आप एपीआई वस्तुओं के साथ नहीं, बल्कि yaml / json फ़ाइल से आयातित सिर्फ yaml वस्तुओं के साथ काम कर रहे हों तो यह थोड़ा कम साफ-सुथरा होता है:

 { global: {}, components: { "deployment-nginx-deployment-dkecx"+: { spec+: { replicas: 10, template+: { spec+: { containers+: [ { name: "nginx", image: "nginx:latest", ports: [ { containerPort: 80, }, ], }, ], }, }, }, }, }, } 

लेकिन फिर भी यह कुछ है और यह हेल्म में तार के साथ काम करने से बेहतर है। Ksonnet का नुकसान यह है कि इसमें Helm की तुलना में छोटे समुदाय और कम पैकेज होते हैं (हालांकि आप अपने Ksonnet प्रोजेक्ट में Helm चार्ट आयात कर सकते हैं, लेकिन आप उनके साथ jsonnet- लाइब्रेरी ऑब्जेक्ट के रूप में नहीं, बल्कि json ऑब्जेक्ट के रूप में काम करेंगे)। और एक छोटे समुदाय और योगदान के परिणामस्वरूप कुछ विशेषताओं का अभाव है जब आप अपना चार्ट लिखने की कोशिश कर रहे हैं। उनमें से एक जो मैंने स्वयं अनुभव किया है: आप जानते हैं कि हेल्म में आप एक निर्देशिका से एक विन्यास ConfigMap बना सकते हैं जिसमें इस तरह की कई विन्यास फाइल होती हैं:

 apiVersion: v1 kind: ConfigMap metadata: name: conf data: {{- (.Files.Glob "foo/*").AsConfig | nindent 2 }} 

आप मेरी हताशा की कल्पना कर सकते हैं जब मुझे पता चला कि Ksonnet में ऐसी कोई सुविधा नहीं है। हालांकि वर्कअराउंड हैं। लेकिन मुद्दा यह है कि यह सिर्फ उस स्थिति का उदाहरण है जब आप ख़ुशी से अपना चार्ट लिख रहे होते हैं और फिर अचानक किसी विशेषता की कमी आपको आधे रास्ते पर रोक देती है।
कुल मिलाकर, Ksonnet के लाभ:

• वस्तुओं के साथ काम करना
• कुबेरनेट्स-एपीआई-संगत जोंसनेट लाइब्रेरी
• हेलम चार्ट आयात समर्थन करता है

कमियां:

• छोटे समुदाय और Ksonnet- देशी पैकेजों की कम संख्या
• कुछ कार्यक्षमता का अभाव आप हेल्म में उपयोग कर सकते हैं
• नया सिंटैक्स => सीखने का समय => बढ़ा हुआ बस-कारक
• सिंटैक्स कभी-कभी बदसूरत और कम मानव-पठनीय हो सकता है (विशेषकर जब अभाव सुविधाओं के लिए वर्कआर्स बनाते हैं)

आइए एक आदर्श टेम्प्लेटिंग टूल के बारे में सोचें

यहाँ "आदर्श" अस्थायी उपकरण के कुछ मानदंड हैं:

• यह वस्तुओं के साथ काम करना चाहिए, तार नहीं
• इसमें कुबेरनेट्स-एपीआई-संगत वस्तुओं के साथ काम करने की क्षमता होनी चाहिए
• इसमें स्ट्रिंग्स के साथ काम करने के लिए कार्यों का एक सभ्य सेट होना चाहिए
• यह अच्छी तरह से json और yaml प्रारूपों के साथ काम करना चाहिए
• यह मानव के अनुकूल होना चाहिए
• यह सरल होना चाहिए
• इसमें मौजूदा हेलम चार्ट को आयात करने की क्षमता होनी चाहिए (क्योंकि यह वास्तविकता है और हम हेल्म समुदाय का उपयोग करना चाहते हैं)

अभी के लिए इतना ही काफी है। मैं अपने सिर में इस सूची के माध्यम से चला गया और अपने आप से सोचा: ठीक है, क्यों पायथन की कोशिश नहीं की? आइए देखें कि क्या यह हमारे मानदंडों में फिट बैठता है:

• वस्तुओं के साथ काम करें, तार नहीं । हां, हम उसके लिए dict और list प्रकारों का उपयोग कर सकते हैं।
• कुबेरनेट्स-एपीआई-संगत वस्तुओं के साथ काम करने की क्षमता है । हाँ, from kubernetes import client
• तार के साथ काम करने के लिए कार्यों का एक सभ्य सेट है । खूब!
• Json और yaml स्वरूपों के साथ अच्छी तरह से काम करें । बहुत अच्छी तरह से।
• मानव के अनुकूल है। कोई गंदगी नहीं।
• सरल। हां।
• मौजूदा हेलम चार्ट आयात करने की क्षमता । कि, हम खुद को जोड़ने जा रहे हैं।

ठीक है, होनहार लग रहा है। मैंने कुबेरनेट्स के लिए आधिकारिक पायथन क्लाइंट लाइब्रेरी के सरल टेंपलेटिंग टूल को लिखने का फैसला किया और अब मैं आपको दिखाता हूं कि इससे क्या हुआ।

करवले से मिलते हैं

इस उपकरण के बारे में कुछ भी विशेष या जटिल नहीं है। मैंने सिर्फ कुबेरनेट्स पुस्तकालय (जो मुझे कुबेरनेट वस्तुओं के साथ काम करने की क्षमता देता है) लिया और मौजूदा हेल्म चार्ट के लिए कुछ बुनियादी कार्यक्षमता लिखी (ताकि कोई उन्हें प्राप्त कर सके और अपने स्वयं के चार्ट में जोड़ सके)। तो, चलो एक दौरा है।
सबसे पहले, यह उपकरण जीथब रेपो में सुलभ है और आप वहां उदाहरण के साथ एक निर्देशिका पा सकते हैं।

डॉकर छवि के साथ त्वरित शुरुआत

यदि आप इसे आज़माना चाहते हैं, तो सबसे आसान तरीका है इस डॉकटर छवि का उपयोग करना:

 $ docker run greegorey/karavel -h usage: karavelcli.py [-h] subcommand ... optional arguments: -h, --help show this help message and exit list of subcommands: subcommand template generates manifests from template ensure ensure helm dependencies 

बेशक, यदि आप चार्ट चार्ट बनाना चाहते हैं, तो आपको अपने चार्ट की निर्देशिका को माउंट करने की आवश्यकता है:

 $ cd example $ docker run -v $PWD:/chart greegorey/karavel template . 

तो, चलो चार्ट संरचना पर एक नजर डालते हैं। यह हेल्म में से एक के समान है:

 $ cd example $ tree . . ├── dependencies ├── prod.yaml ├── requirements.yaml ├── templates │  ├── custom-resource.py │  ├── deployment.py │  └── service-helm.py └── values.yaml 2 directories, 6 files 

हेल्म की तरह, इसमें requirements.yaml । एक ही लेआउट के साथ श्याम फ़ाइल:

 dependencies: - name: mysql version: 0.13.1 repository: https://kubernetes-charts.storage.googleapis.com/ 

यहां आप अपने हेल्म निर्भरता को सूचीबद्ध करते हैं जिसे आप अपने चार्ट में आयात करना चाहते हैं। निर्भरताएँ dependencies निर्देशिका पर जाती हैं। उन्हें ensure करने या अपडेट करने के लिए ensure कमांड का उपयोग ensure :

 $ karavel ensure . 

उसके बाद आपकी dependencies निर्देशिका इस तरह दिखाई देगी:

 $ tree dependencies dependencies └── mysql-0.13.1 └── mysql ├── Chart.yaml ├── README.md ├── templates │  ├── NOTES.txt │  ├── _helpers.tpl │  ├── configurationFiles-configmap.yaml │  ├── deployment.yaml │  ├── initializationFiles-configmap.yaml │  ├── pvc.yaml │  ├── secrets.yaml │  ├── svc.yaml │  └── tests │  ├── test-configmap.yaml │  └── test.yaml └── values.yaml 4 directories, 13 files 

अब हमने अपनी निर्भरता सुनिश्चित करने के बाद आइए टेम्प्लेट पर एक नजर डालते हैं। सबसे पहले, हम एक सरल nginx परिनियोजन बनाते हैं:

 from kubernetes import client from karavel.helpers import Values def template(): values = Values().values # Configure Pod template container container = client.V1Container( name='nginx', image='{}:{}'.format(values.nginx.image.repository, values.nginx.image.tag), ports=[client.V1ContainerPort(container_port=80)]) # Create and configurate a spec section template = client.V1PodTemplateSpec( metadata=client.V1ObjectMeta(labels={'app': 'nginx'}), spec=client.V1PodSpec(containers=[container])) # Create the specification of deployment spec = client.ExtensionsV1beta1DeploymentSpec( replicas=3, template=template) # Instantiate the deployment object deployment = client.ExtensionsV1beta1Deployment( api_version='extensions/v1beta1', kind='Deployment', metadata=client.V1ObjectMeta(name='nginx-deployment'), spec=spec) return deployment # [deployment], (deployment, deployment) are valid 

इसलिए, टेम्पलेट के वैध होने के लिए आपको template() फ़ंक्शन की आवश्यकता होती है जो एकल कुबेरनेट्स ऑब्जेक्ट या उनकी list / tuple देता है। आप पायथन क्लाइंट के लिए एपीआई वस्तुओं की सूची यहां पा सकते हैं।
जैसा कि आप देख सकते हैं, कोड साफ, सरल, पठनीय है। आप आश्चर्य कर सकते हैं कि values.nginx.image.repository कहां से है। values.nginx.image.repository आती है? यह उस मान फ़ाइलों से मान प्राप्त करता है जिसे आप चार्ट को karavel template -f one.yaml --values two.yaml करते समय पास करते हैं, ठीक उसी तरह जैसे हेल्म में: karavel template -f one.yaml --values two.yaml । हम बाद में उन पर एक नजर डालेंगे।

ठीक है, हेल्म चार्ट के बारे में क्या?

अब, हमने अपनी तैनाती बनाई। लेकिन क्या होगा अगर हम हेल्म चार्ट या चार्ट के एक हिस्से को आयात करना चाहते हैं? आइए templates/service-helm.py पर एक नज़र डालें:

 from kubernetes import client from karavel.helm import HelmChart from karavel.helpers import Values def template(): values = Values().values # Initialize the chart (== helm template --values) chart = HelmChart(name='mysql', version='0.13.1', values=values.mysql.helm) # Get the desired object from chart service = chart.get(name='svc', obj_class=client.V1Service) # Create custom objects to add custom_ports = [ client.V1ServicePort( name='my-custom-port', protocol=values.mysql.protocol, port=values.mysql.port, target_port=39000, ) ] # Add custom objects to the service service.spec['ports'] = custom_ports # Change Helm-generated label service.metadata['labels']['release'] += '-suffix' # Delete Helm-generated label `heritage: Tiller` del service.metadata['labels']['heritage'] return service # [service], (service, service) are valid 

सरल, हुह? इस पंक्ति पर ध्यान दें: service = chart.get(name='svc', obj_class=client.V1Service) - हमने कक्षा V1Service प्रपत्र Helm yaml फ़ाइल का ऑब्जेक्ट बनाया। यदि आप ऐसा नहीं करना चाहते / चाहते हैं - तो आप हमेशा सिर्फ dict काम ले सकते हैं।

यदि मैं कस्टम संसाधन बनाना चाहता हूं तो क्या होगा?

खैर, इसके साथ एक छोटी सी बात है। Kubernetes API /openapi/v2 json परिभाषा में CRD ऑब्जेक्ट नहीं जोड़ता है, और /openapi/v2 क्लाइंट ऑब्जेक्ट इस परिभाषा पर निर्मित होते हैं। लेकिन आप अभी भी आसानी से dict वस्तुओं के साथ काम कर सकते हैं। इस तरह:

 from kubernetes import client def template(): resource = { 'apiVersion': 'stable.example.com/v1', 'kind': 'Whale', 'metadata': client.V1ObjectMeta( name='my-object', ), 'spec': { 'image': 'my-whale-image:0.0.1', 'tail': 1, 'fins': 4, } } return resource # [resource], (resource, resource) are valid 

अभी भी अच्छा लग रहा है, है ना?

क्या मेरे पास विभिन्न वातावरणों के लिए मान हो सकते हैं, जैसे देव / ठेस?

हाँ, आप कर सकते हैं!
आइए values.yaml को values.yaml सबसे पहले:

 nginx: image: repository: nginx tag: 1.15-alpine mysql: port: 3307 protocol: TCP helm: releaseName: my-release namespace: prod imageTag: '5.7.14' service: type: NodePort 

mysql अंदर helm कुंजी को नोट करें: हमने इसका उपयोग तब किया था जब helm चार्ट chart = HelmChart(name='mysql', version='0.13.1', values=values.mysql.helm) . chart = HelmChart(name='mysql', version='0.13.1', values=values.mysql.helm) लिए मान निर्दिष्ट करते हुए। कुछ हेल्म चार्ट को releaseName लिए आवेदन नामकरण और namespace लिए releaseName आवश्यकता releaseName । इन दो मानों को helm template में - --namespace और NAME तर्कों के रूप में Helm को दिया जाता है।

अब, आप prod env के लिए अतिरिक्त फ़ाइल निर्दिष्ट कर सकते हैं, और हमारे सभी उदाहरणों को टेम्पलेट कर सकते हैं:

 $ karavel template -f values.yaml -f prod.yaml . --- # Source: templates/custom-resource.py apiVersion: stable.example.com/v1 kind: Whale metadata: name: my-object spec: fins: 4 image: my-whale-image:0.0.1 tail: 1 --- # Source: templates/deployment.py apiVersion: extensions/v1beta1 kind: Deployment metadata: name: nginx-deployment spec: replicas: 3 template: metadata: labels: app: nginx spec: containers: - image: nginx:1.14-alpine name: nginx ports: - containerPort: 80 --- # Source: templates/service-helm.py apiVersion: v1 kind: Service metadata: annotations: null labels: app: prod-release-mysql chart: mysql-0.13.1 release: prod-release-suffix name: prod-release-mysql spec: ports: - name: my-custom-port port: 3308 protocol: TCP targetPort: 39000 selector: app: prod-release-mysql type: NodePort 

उसके बाद आप इन वस्तुओं को क्लस्टर में kubeclt apply कर सकते हैं।

कूल! एन्कोडिंग और base64 के बारे में क्या?

import base64

रहस्यों के लिए तिजोरी का उपयोग करने के बारे में क्या?

import hvac

उरोज लाना?

import importlib

सुरक्षित हैश कार्य?

import Crypto

आपको मिल गया। अजगर के साथ आप अपने कुबेरनेट्स मेनिफेस्टों के साथ बहुत सी चीजें कर सकते हैं।

क्या यह NIH सिंड्रोम है?

नहीं :)
मैं हूं खुशी से मेरी वर्तमान परियोजनाओं में हेल्म का उपयोग करना। ऐसी चीजें हैं जो मुझे याद आती हैं। मैंने अपने कुछ प्रोजेक्ट्स में Ksonnet का भी इस्तेमाल किया।
मैं इस टूल को एक प्रूफ-ऑफ-कॉन्सेप्ट के रूप में सोचना चाहता हूं कि हमारे पास अस्थायी उपकरण हेल्म से बेहतर हो सकते हैं और पायथन का उपयोग करके उन्हें विकसित करना बहुत मुश्किल नहीं है। अगर इस तरह के उपकरण में सामुदायिक रुचि / आवश्यकता है तो हम इसे विकसित करना जारी रख सकते हैं। या हम हेल्म 3 के रिलीज होने का इंतजार कर सकते हैं;)

निष्कर्ष

मैंने आपको कुबेरनेट्स के लिए पायथन-आधारित टेंपलेटिंग टूल दिखाया है, जिसमें कुबेरनेट्स-एपीआई-संगत ऑब्जेक्ट्स का समर्थन और हेलम चार्ट आयात करने के लिए समर्थन है। किसी भी टिप्पणी और समुदाय से चर्चा का स्वागत है, और फिर से रेपो में आपका स्वागत है।

इसे पढ़ने के लिए धन्यवाद और आपका दिन शुभ हो!

संदर्भ

• कुबेरनेट्स के लिए आधिकारिक पायथन क्लाइंट लाइब्रेरी
• पतवार
• Ksonnet
• यह लेख मध्यम पर