🚷 🚶🏾 🕰️ कुबेरनेट्स के लिए पैकेज मैनेजर - हेल्म: अतीत, वर्तमान, भविष्य ⛰️ 😚 🚣

लगभग। ट्रांस। : इस लेख के साथ हम कुबेरनेट्स के पैकेज मैनेजर के बारे में प्रकाशनों की एक श्रृंखला खोलते हैं, जिसे हम सक्रिय रूप से रोजमर्रा के काम में उपयोग करते हैं, - हेल्म। मैटेर कसाई का मूल लेखक है मैट बुचर, जो हेल्म प्रोजेक्ट के संस्थापकों में से एक है, माइक्रोसॉफ्ट में ओपन सोर्स प्रोजेक्ट्स पर काम कर रहा है और 8 तकनीकी किताबें लिख रहा है (विशेष रूप से, "गो इन प्रैक्टिस")। हालांकि, लेख हमारे (कभी-कभी व्यापक) टिप्पणियों द्वारा पूरक है, और जल्द ही अधिक व्यावहारिक ध्यान के साथ हेल्म पर नए नोटों के साथ आगे बढ़ाया जाएगा। अद्यतन (09/03/2018): अगली कड़ी सामने आई - " कुबेरनेट्स के लिए पैकेज मैनेजर के साथ व्यावहारिक परिचय - हेल्म "।

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

ए ब्रीफ हिस्ट्री ऑफ हेल्म

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

लगभग। ट्रांस।: पहले संस्करण से, जिसे डीएम (तैनाती प्रबंधक) कहा जाता था, कुबेरनेट्स संसाधनों का वर्णन करने के लिए YAML सिंटैक्स चुना गया था, और कॉन्फ़िगरेशन लिखते समय जिनजा टेम्प्लेट और पायथन स्क्रिप्ट का समर्थन किया गया था।

एक साधारण वेब एप्लीकेशन टेम्प्लेट इस तरह दिख सकता है:

YAML

resources: - name: frontend type: github.com/kubernetes/application-dm-templates/common/replicatedservice:v1 properties: service_port: 80 container_port: 80 external_service: true replicas: 3 image: gcr.io/google_containers/example-guestbook-php-redis:v3 - name: redis type: github.com/kubernetes/application-dm-templates/storage/redis:v1 properties: null

रोल आउट एप्लिकेशन के घटकों का वर्णन करते समय, नाम, उपयोग किए गए टेम्पलेट, और इस टेम्पलेट के आवश्यक पैरामीटर भी इंगित किए जाते हैं। ऊपर के उदाहरण में, frontend और redis आधिकारिक रिपॉजिटरी से टेम्पलेट्स का उपयोग करते हैं।

पहले से ही इस संस्करण में, आप सामान्य ज्ञान आधार से संसाधनों का उपयोग कर सकते हैं, अपने स्वयं के टेम्पलेट रिपॉजिटरी बना सकते हैं और टेम्पलेट्स के मापदंडों और घोंसले के कारण जटिल अनुप्रयोगों का निर्माण कर सकते हैं।

हेल्म 1 वास्तुकला में तीन घटक होते हैं। निम्नलिखित चित्र उनके बीच के संबंध को दर्शाता है:

Manager एक वेब सर्वर का कार्य करता है (क्लाइंट के साथ REST API के माध्यम से संचार होता है), कुबेरनेट क्लस्टर में तैनाती का प्रबंधन करता है और इसका उपयोग डेटा वेयरहाउस के रूप में किया जाता है।
expandybird घटक उपयोगकर्ता कॉन्फ़िगरेशन को एक फ्लैट रूप में लाता है, अर्थात। जिन्जा टेम्प्लेट लागू करता है और पायथन स्क्रिप्ट को निष्पादित करता है।
एक फ्लैट कॉन्फ़िगरेशन प्राप्त करने के बाद, resourcifier , kubectl को आवश्यक कॉल करता है और manager को स्थिति और त्रुटि संदेश देता है, यदि कोई हो।

हेल्म के पहले संस्करण की क्षमताओं को समझने के लिए, मैं dm कमांड पर मदद दूंगा :

डीएम से आउटपुट में मदद करें

 Usage: ./dm [<flags>] <command> [(<template-name> | <deployment-name> | (<configuration> [<import1>...<importN>]))] Commands: expand Expands the supplied configuration(s) deploy Deploys the named template or the supplied configuration(s) list Lists the deployments in the cluster get Retrieves the supplied deployment manifest Lists manifests for deployment or retrieves the supplied manifest in the form (deployment[/manifest]) delete Deletes the supplied deployment update Updates a deployment using the supplied configuration(s) deployed-types Lists the types deployed in the cluster deployed-instances Lists the instances of the named type deployed in the cluster templates Lists the templates in a given template registry (specified with --registry) registries Lists the registries available describe Describes the named template in a given template registry getcredential Gets the named credential used by a registry setcredential Sets a credential used by a registry createregistry Creates a registry that holds charts Flags: -apitoken string Github api token that overrides GITHUB_API_TOKEN environment variable -binary string Path to template expansion binary (default "../expandybird/expansion/expansion.py") -httptest.serve string if non-empty, httptest.NewServer serves on this address and blocks -name string Name of deployment, used for deploy and update commands (defaults to template name) -password string Github password that overrides GITHUB_PASSWORD environment variable -properties string Properties to use when deploying a template (eg, --properties k1=v1,k2=v2) -regex string Regular expression to filter the templates listed in a template registry -registry string Registry name (default "application-dm-templates") -registryfile string File containing registry specification -service string URL for deployment manager (default "http://localhost:8001/api/v1/proxy/namespaces/dm/services/manager-service:manager") -serviceaccount string Service account file containing JWT token -stdin Reads a configuration from the standard input -timeout int Time in seconds to wait for response (default 20) -username string Github user name that overrides GITHUB_USERNAME environment variable --stdin requires a file name and either the file contents or a tar archive containing the named file. a tar archive may include any additional files referenced directly or indirectly by the named file.

और अब वापस मूल पाठ में हेल्म के इतिहास के बारे में ...

कुछ महीने बाद, हम Google से कुबेरनेट्स परिनियोजन प्रबंधक टीम के साथ सेना में शामिल हो गए और हेल्म 2 पर काम करना शुरू कर दिया। लक्ष्य यह था कि निम्नलिखित जोड़कर हेल्म का उपयोग आसान रखा जाए:

चार्ट टेम्प्लेट ("चार्ट" - हेल्म इकोसिस्टम में एक पैकेज का एक एनालॉग - अनुकूलन के लिए लगभग अनुवाद। ) ;
टीमों के लिए क्लस्टर प्रबंधन;
पूर्ण चार्ट रिपॉजिटरी;
स्थिर और हस्ताक्षरित पैकेज प्रारूप;
सिमेंटिक संस्करण के लिए मजबूत प्रतिबद्धता और संस्करण से संस्करण तक पिछड़े संगतता को बनाए रखना।

इन लक्ष्यों को प्राप्त करने के लिए, हेल्म पारिस्थितिकी तंत्र में एक दूसरा घटक जोड़ा गया है। यह टिलर क्लस्टर के अंदर बन गया, जिसने हेल्म चार्ट और उनके प्रबंधन की स्थापना प्रदान की।

लगभग। perev।: इस प्रकार, हेल्म के दूसरे संस्करण में, क्लस्टर में शेष एकमात्र घटक स्थापना जीवन चक्र ( रिलीज ) के लिए जिम्मेदार है, और कॉन्फ़िगरेशन तैयारी हेल्म क्लाइंट को प्रस्तुत की जाती है।

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

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

इसलिए हम हेल्म 3 पर आ गए। आगे मैं प्रोजेक्ट रोडमैप पर चित्रित कुछ नवाचारों के बारे में बात करूंगा।

बधाई लुआ

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

गो टेम्प्लेट के चार फायदे थे:

पुस्तकालय को गो में बनाया गया है ;
टेम्पलेट्स को कड़ाई से सीमित सैंडबॉक्स पर्यावरण में निष्पादित किया जाता है;
हम इंजन में मनमाने कार्यों और वस्तुओं को सम्मिलित कर सकते हैं;
उन्होंने YAML के साथ अच्छा काम किया।

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

और हमें उनकी निराशाओं के बारे में पता चला:

सिंटैक्स को पढ़ना मुश्किल है और खराब तरीके से प्रलेखित है।
भाषा के मुद्दे, जैसे कि अपरिवर्तनीय चर, जटिल डेटा प्रकार, और प्रतिबंधात्मक दृश्यता नियम, ने सरल चीजों को जटिल बना दिया है।
टेम्पलेट्स के भीतर कार्यों को परिभाषित करने में असमर्थता ने पुन: प्रयोज्य पुस्तकालयों के निर्माण को और भी कठिन बना दिया।

सबसे महत्वपूर्ण बात, टेम्प्लेट भाषा का उपयोग करते हुए, हम कुबेरनेट्स वस्तुओं को "पंक्तिबद्ध" करते हैं। (दूसरे शब्दों में, टेम्प्लेट डेवलपर्स को कुबेरनेट्स संसाधनों को यिम्ल प्रारूप में पाठ दस्तावेजों के रूप में प्रबंधित करना था।)

वस्तुओं पर काम करें, यम के टुकड़े नहीं

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

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

1993 में, ब्राजील के आईटी इंजीनियरों के एक समूह ने अपने टूल में एम्बेड करने के लिए एक हल्की स्क्रिप्टिंग भाषा बनाई। लुआ में एक सरल वाक्यविन्यास है, यह व्यापक रूप से समर्थित है और लंबे समय तक शीर्ष 20 भाषाओं की सूची में चित्रित किया गया है। यह आईडीई और पाठ संपादकों द्वारा समर्थित है, कई मैनुअल और ट्यूटोरियल हैं। इस तरह के मौजूदा पारिस्थितिकी तंत्र पर, हम अपना समाधान विकसित करना चाहेंगे।

हेल्म लुआ पर हमारा काम अभी भी वैचारिक प्रमाण चरण में है, और हम सिंटैक्स की उम्मीद करते हैं जो परिचित और लचीला दोनों है। पुराने और नए दृष्टिकोणों की तुलना में, आप देख सकते हैं कि हम कहाँ जा रहे हैं।

यहाँ हेल्म 2 में अल्पाइन के साथ चूल्हा टेम्पलेट का एक उदाहरण दिया गया है:

 apiVersion: v1 kind: Pod metadata: name: {{ template "alpine.fullname" . }} labels: heritage: {{ .Release.Service }} release: {{ .Release.Name }} chart: {{ .Chart.Name }}-{{ .Chart.Version }} app: {{ template "alpine.name" . }} spec: restartPolicy: {{ .Values.restartPolicy }} containers: - name: waiter image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}" imagePullPolicy: {{ .Values.image.pullPolicy }} command: ["/bin/sleep", "9000"]

इस सीधे टेम्पलेट में, आप तुरंत सभी अंतर्निहित टेम्पलेट निर्देश देख सकते हैं, जैसे कि {{ .Chart.Name }} ।

और यहाँ Lua कोड के प्रारंभिक संस्करण में उसी चूल्हा की परिभाषा है:

 unction create_alpine_pod(_) local pod = { apiVersion = "v1", kind = "Pod", metadata = { name = alpine_fullname(_), labels = { heritage = _.Release.Service or "helm", release = _.Release.Name, chart = _.Chart.Name .. "-" .. _.Chart.Version, app = alpine_name(_) } }, spec = { restartPolicy = _.Values.restartPolicy, containers = { { name = waiter, image = _.Values.image.repository .. ":" .. _.Values.image.tag, imagePullPolicy = _.Values.image.pullPolicy, command = { "/bin/sleep", "9000" } } } } } _.resources.add(pod) end

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

आइए इस कोड को छोटा करें

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

 local pods = require("mylib.pods"); function create_alpine_pod(_) myPod = pods.new("alpine:3.7", _) myPod.spec.restartPolicy = "Always" -- set any other properties _.Manifests.add(myPod) end

इस उदाहरण में, हम किसी संसाधन की परिभाषा के साथ एक ऑब्जेक्ट के रूप में काम करने की क्षमता का उपयोग करते हैं, जो कोड निर्धारित करने और पठनीयता को बनाए रखते हुए, गुणों को सेट करना आसान है।

टेम्प्लेट ... लुआ ... सब एक साथ क्यों नहीं?

हालांकि सभी कार्यों के लिए टेम्प्लेट इतने अद्भुत नहीं हैं, फिर भी उनके कुछ फायदे हैं। Go में टेम्प्लेट एक स्थिर तकनीक है जिसमें एक स्थापित उपयोगकर्ता आधार और कई मौजूदा चार्ट हैं। कई चार्ट डेवलपर लेखन टेम्प्लेट को पसंद करने का दावा करते हैं। इसलिए, हम टेम्पलेट समर्थन को हटाने नहीं जा रहे हैं।

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

हम लुआ पर लिपियों के समर्थन से बहुत प्रोत्साहित हैं, लेकिन साथ ही हम हेल्मोन के महत्वपूर्ण हिस्से से छुटकारा पा रहे हैं ...

टिलर को अलविदा कहना

हेल्म 2 के विकास के दौरान, हमने टिलर को तैनाती प्रबंधक के साथ एकीकरण घटक के रूप में पेश किया। टिलर ने एक ही क्लस्टर पर काम करने वाली टीमों के लिए एक महत्वपूर्ण भूमिका निभाई: कई अलग-अलग प्रशासकों के लिए रिलीज़ के एक ही सेट के साथ बातचीत करना संभव बना दिया।

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

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

टिलर का मुख्य लक्ष्य बिना टिलर के ही हासिल किया जा सकता है। इसलिए, हेल्म 3 योजना चरण के दौरान किए गए पहले निर्णयों में से एक था, टिलर को पूरी तरह से छोड़ देना।

सुरक्षा में सुधार

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

रिलीज़, रिलीज़विर्स और स्टेट स्टोरेज

टिलर की अनुपस्थिति में, क्लस्टर के भीतर विभिन्न रिलीज की स्थिति को बनाए रखने के लिए, हमें सभी क्लाइंट्स के साथ बातचीत करने (इंटरव्यू पर) के लिए एक नया तरीका चाहिए।

ऐसा करने के लिए, हमने दो नई प्रविष्टियाँ प्रस्तुत कीं:

Release - एक विशेष चार्ट की एक विशिष्ट स्थापना के लिए। अगर हम helm install my-wordpress stable/wordpress रन करते हैं तो helm install my-wordpress stable/wordpress नामक एक रिलीज बनाई जाएगी और इस वर्डप्रेस इंस्टॉलेशन के जीवन भर बनाए रखी जाएगी।
ReleaseVersion - हर बार जब आप हेल्म चार्ट को अपडेट करते हैं, तो आपको यह विचार करना होगा कि क्या बदल गया है और क्या बदलाव सफल रहा है। ReleaseVersion एक रिलीज़ ReleaseVersion जुड़ा हुआ है और केवल अद्यतन, रोलिंग बैक और हटाने के बारे में जानकारी के साथ रिकॉर्ड संग्रहीत करता है। जब हम helm upgrade my-wordpress stable/wordpress , तो मूल Release ऑब्जेक्ट समान रहता है, लेकिन अपडेट ऑपरेशन के बारे में जानकारी के साथ एक चाइल्ड ReleaseVersion ऑब्जेक्ट ReleaseVersion ।

चार्ट ऑब्जेक्ट्स के रूप में Releases और ReleaseVersions समान नामस्थानों में संग्रहीत किए जाएंगे।

इन सुविधाओं के साथ, हेल्म उपयोगकर्ता टीम, टिलर की आवश्यकता के बिना क्लस्टर में हेल्म प्रतिष्ठानों के रिकॉर्ड को ट्रैक करने में सक्षम होगी।

लेकिन रुको, यह सब नहीं है!

इस लेख में मैंने हेल्म 3 में कुछ बड़े बदलावों के बारे में बात करने की कोशिश की। हालांकि, यह सूची पूरी तरह से नहीं है। हेल्म 3 योजना में अन्य परिवर्तन भी शामिल हैं, जैसे चार्ट प्रारूप में सुधार, चार्ट रिपॉजिटरी के लिए प्रदर्शन में सुधार, और एक नया ईवेंट सिस्टम जो चार्ट डेवलपर्स उपयोग कर सकते हैं। हम कोड बेस को साफ करके और पिछले तीन वर्षों में प्रासंगिकता खो चुके घटकों को अपडेट करके एरिक रेमंड नामक कोड पुरातत्व भी बना रहे हैं।

लगभग। ट्रांस। : यह एक विरोधाभास है, लेकिन install या upgrade होने पर हेल्म 2 पैकेज मैनेजर, अर्थात्। success स्थिति में रिलीज़ होने की गारंटी नहीं है कि अनुप्रयोग संसाधन सफलतापूर्वक रोल आउट हो गए हैं (उदाहरण के लिए, ImagePullError जैसी कोई त्रुटि नहीं है)। शायद नया ईवेंट मॉडल आपको संसाधनों के लिए अतिरिक्त हुक जोड़ने और रोलआउट प्रक्रिया को बेहतर ढंग से नियंत्रित करने की अनुमति देगा - हम जल्द ही पता लगाएंगे।

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

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

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

" कुबेरनेट्स के लिए पैकेज मैनेजर का एक व्यावहारिक परिचय - हेल्म ";
“ डैप के साथ अभ्यास करें। भाग 2. हेल्म का उपयोग करते हुए कुबेरनेट्स में डॉकर छवियों की तैनाती ";
" डब और GitLab CI का उपयोग करके कुबेरनेट्स में एप्लिकेशन बनाएं और स्थापित करें ";
" कुबेरनेट्स और गिटलैब के साथ सर्वश्रेष्ठ सीआई / सीडी अभ्यास " (समीक्षा और वीडियो रिपोर्ट) ;
" छोटी परियोजनाओं में कुबेरनेट्स के साथ हमारा अनुभव " (वीडियो रिपोर्ट, जिसमें कुबेरनेट्स तकनीकी उपकरण का परिचय शामिल है)।

कुबेरनेट्स के लिए पैकेज मैनेजर - हेल्म: अतीत, वर्तमान, भविष्य