प्रस्तुत है हेल्म 3

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

15 अक्टूबर, 2015 को परियोजना का जन्म हुआ, जिसे अब हेल्म के नाम से जाना जाता है। इसकी स्थापना के ठीक एक साल बाद, हेल्म समुदाय कुबेरनेट्स में शामिल हो गया, जबकि सक्रिय रूप से हेल्म 2 पर काम कर रहा था। जून 2018 में, हेल्म एक ऊष्मायन परियोजना के रूप में सीएनसीएफ में शामिल हो गया । वर्तमान में तेजी से आगे - और अब नए हेल्म 3 की पहली अल्फा रिलीज रास्ते में है (यह रिलीज पहले से ही मई के मध्य में हुई - लगभग अनुवाद।) ।

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

सारांश:

• हेल्म के निर्माण का इतिहास;
• टिलर को कोमल विदाई;
• चार्ट रिपॉजिटरी;
• रिलीज प्रबंधन;
• चार्ट निर्भरता में परिवर्तन;
• पुस्तकालय चार्ट;
• आगे क्या है?

हेल्म का इतिहास

जन्म

हेल ​​1 एक डेस द्वारा बनाई गई एक ओपन सोर्स परियोजना के रूप में शुरू हुई। हम 2017 के वसंत में Microsoft द्वारा अवशोषित एक छोटा स्टार्टअप थे। हमारे अन्य ओपन सोर्स प्रोजेक्ट, जिसे deisctl भी कहा जाता है, में एक deisctl टूल था, जिसका उपयोग फ्लीट क्लस्टर में डीआईएस प्लेटफॉर्म को स्थापित करने और संचालित करने के लिए किया गया था। फ्लीट उस समय कंटेनर ऑर्केस्ट्रेशन के लिए पहले प्लेटफार्मों में से एक था।

2015 के मध्य में, हमने पाठ्यक्रम बदलने का फैसला किया और फ्लीस से कुबेरनेट्स में डेस (उस समय का नाम बदलकर डेस वर्कफ़्लो) कर दिया। deisctl इंस्टॉलेशन deisctl को रीडिज़ाइन करने वाले पहले में से एक। हमने इसका इस्तेमाल फ्लीट क्लस्टर में डेस वर्कफ़्लो को स्थापित करने और प्रबंधित करने के लिए किया था।

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

हेल्म के साथ हमारे पहले प्रयास ने काम किया, लेकिन गंभीर प्रतिबंध थे। उन्होंने कुबेरनेट्स मेनिफेस्टों का एक सेट लिया, जनरेटर के साथ सुगंधित, सामने के मामले के रूप में * YAML ब्लॉक, और परिणामों को कुबेरनेट्स पर अपलोड किया।

* नोट ट्रांस। : हेल्म के पहले संस्करण से, कुबेरनेट्स संसाधनों का वर्णन करने के लिए YAML सिंटैक्स चुना गया था, और कॉन्फ़िगरेशन लिखते समय जिनजा टेम्प्लेट और पायथन स्क्रिप्ट का समर्थन किया गया था। हमने इस बारे में और हेल्म के पहले संस्करण के उपकरण के बारे में इस सामग्री के "ए ब्रीफ हिस्ट्री ऑफ हेल्म" अध्याय में लिखा है।

उदाहरण के लिए, एक YAML फ़ाइल में फ़ील्ड को बदलने के लिए, आपको निम्न निर्माण को प्रकट में जोड़ना होगा:

 #helm:generate sed -i -es|ubuntu-debootstrap|fluffy-bunny| my/pod.yaml 

यह अच्छा है कि आज टेम्पलेट इंजन हैं, है ना?

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

पिछली गलतियों के अनुभव के आधार पर, हमने हेल्म 2 को विकसित करना शुरू कर दिया।

सृजन हेल्म २

2015 के अंत में, Google टीम ने हमसे संपर्क किया। उन्होंने कुबेरनेट्स के लिए एक समान उपकरण पर काम किया। कुबेरनेट्स के लिए परिनियोजन प्रबंधक मौजूदा उपकरण का पोर्ट था जो Google क्लाउड प्लेटफ़ॉर्म के लिए उपयोग किया गया था। "क्या हम करेंगे," उन्होंने पूछा, "कुछ दिनों की समानता और मतभेदों पर चर्चा करते हुए?"

जनवरी 2016 में, हेल्म और तैनाती प्रबंधक टीमों ने सिएटल में विचारों के आदान-प्रदान के लिए मुलाकात की। वार्ता एक महत्वाकांक्षी योजना के साथ समाप्त हुई: हेल्म बनाने के लिए दोनों परियोजनाओं को संयोजित करने के लिए 2. डेस और गूगल के साथ मिलकर, स्किप्पबॉक्स (अब बिटनामी का हिस्सा - लगभग।) से लोग विकास टीम में शामिल हुए, और हमने हेल्म 2 में काम करना शुरू कर दिया।

हम हेल्म के उपयोग की आसानी बनाए रखना चाहते थे, लेकिन निम्नलिखित जोड़ सकते हैं:

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

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

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

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

टिलर को कोमल की विदाई

हेल्म 2 के विकास के दौरान, हमने टिलर को Google के परिनियोजन प्रबंधक के साथ हमारे एकीकरण के भाग के रूप में पेश किया। टिलर ने एक सामान्य क्लस्टर के भीतर काम करने वाली टीमों के लिए एक महत्वपूर्ण भूमिका निभाई: इसने विभिन्न विशेषज्ञों को रिलीज के एक ही सेट के साथ बुनियादी ढांचे का संचालन करने की अनुमति दी।

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

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

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

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

चार्ट रिपोजिटरी

उच्च स्तर पर, चार्ट रिपॉजिटरी एक ऐसी जगह है जहां आप चार्ट को स्टोर और साझा कर सकते हैं। हेलम क्लाइंट पैक करता है और चार्ट को रिपॉजिटरी में भेजता है। सीधे शब्दों में कहें, चार्ट रिपॉजिटरी एक आदिम HTTP सर्वर है जिसमें एक index.yaml फ़ाइल और कुछ पैक्ड चार्ट होते हैं।

हालांकि इसमें कुछ फायदे हैं कि चार्ट रिपॉजिटरी एपीआई रिपॉजिटरी के लिए सबसे बुनियादी आवश्यकताओं को पूरा करता है, इसके कई नुकसान भी हैं:

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

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

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

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

हेलम-चार्ट रिपॉजिटरी में आने वाले कुछ परिवर्तनों का अधिक विस्तृत विवरण यहां उपलब्ध है ।

रिलीज प्रबंधन

हेल्म 3 में, एक अनुप्रयोग की स्थिति को क्लस्टर के भीतर कुछ वस्तुओं द्वारा मॉनिटर किया जाता है:

• रिलीज़ ऑब्जेक्ट - एप्लिकेशन के एक उदाहरण का प्रतिनिधित्व करता है;
• रिलीज़ संस्करण गुप्त - समय में एक विशेष बिंदु पर आवेदन की वांछित स्थिति का प्रतिनिधित्व करता है (उदाहरण के लिए, एक नया संस्करण की रिहाई)।

helm install कॉल helm install से रिलीज़ ऑब्जेक्ट और रिलीज़ संस्करण गुप्त हो जाता है। helm upgrade को कॉल helm upgrade लिए एक रिलीज़ ऑब्जेक्ट (जो इसे बदल सकता है) की आवश्यकता होती है और एक नया रिलीज़ संस्करण गुप्त बनाता है जिसमें नए मान और एक तैयार मैनिफ़ेस्ट होता है।

रिलीज़ ऑब्जेक्ट में रिलीज़ जानकारी होती है, जहाँ रिलीज़ एक नामित चार्ट और मानों की एक विशिष्ट स्थापना होती है। यह ऑब्जेक्ट रिलीज़ के बारे में शीर्ष-स्तरीय मेटाडेटा का वर्णन करता है। रिलीज़ ऑब्जेक्ट को एप्लिकेशन के पूरे जीवन चक्र में संरक्षित किया जाता है और सभी रिलीज़ संस्करण रहस्यों के मालिक के रूप में कार्य करता है, साथ ही सभी ऑब्जेक्ट्स जो सीधे हेल्म चार्ट द्वारा बनाए जाते हैं।

रिलीज़ संस्करण गुप्त रीलीज़ को संशोधन (इंस्टॉलेशन, अपडेट, रोलबैक, अनइंस्टॉलमेंट) की एक श्रृंखला के साथ जोड़ता है।

हेल्म 2 में, संशोधन बेहद सुसंगत थे। helm install कॉल बनाई गई v1, बाद में अपग्रेड वी 2 और इसी तरह। रिलीज़ और रिलीज़ संस्करण रहस्य एक ही ऑब्जेक्ट में ढह गए थे, जिसे संशोधन के रूप में जाना जाता है। संशोधन को टिलर के समान नामस्थान में संग्रहीत किया गया था, जिसका अर्थ था कि प्रत्येक रिलीज़ नामस्थान के संदर्भ में "वैश्विक" थी; नतीजतन, नाम का केवल एक उदाहरण इस्तेमाल किया जा सकता है।

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

टिलर को छोड़ने के बाद, हेल्म 3 ने रिलीज के साथ एकल नाम स्थान में डेटा जारी किया। ऐसा परिवर्तन आपको एक अलग नामस्थान में एक ही रिलीज़ नाम के साथ एक चार्ट स्थापित करने की अनुमति देता है, और डेटा को क्लस्टर में अपडेट / रिबूट के बीच सहेजा जाता है। उदाहरण के लिए, आप नामस्थान "फू" में Wordpress स्थापित कर सकते हैं और फिर नामस्थान "बार" में, और दोनों रिलीज को "वर्डप्रेस" कहा जा सकता है।

चार्ट निर्भरता परिवर्तन

Helm 2 के साथ उपयोग के लिए पैक किए गए चार्ट ( helm package उपयोग) Helm 3 के साथ स्थापित किया जा सकता है, लेकिन चार्ट विकास वर्कफ़्लो को पूरी तरह से संशोधित किया गया है, इसलिए Helm 3 के साथ विकासशील चार्ट जारी रखने के लिए कुछ बदलाव किए जाने की आवश्यकता है। विशेष रूप से, प्रबंधन प्रणाली को बदल दिया गया है चार्ट निर्भरताएँ।

चार्ट निर्भरता प्रबंधन प्रणाली requirements.lock से Chart.yaml Chart.lock । Chart.yaml और requirements.lock से। इसका मतलब है कि helm dependency कमांड का उपयोग करने वाले चार्ट को हेल्म 3 में काम करने के लिए कुछ कॉन्फ़िगरेशन की आवश्यकता होती है।

आइए एक उदाहरण देखें। Helm 2 में चार्ट पर निर्भरता जोड़ें और देखें कि जब आप Helm 3 पर जाते हैं तो क्या परिवर्तन होते हैं।

Helm 2 requirements.yaml इस तरह देखा:

 dependencies: - name: mariadb version: 5.xx repository: https://kubernetes-charts.storage.googleapis.com/ condition: mariadb.enabled tags: - database 

हेल्म 3 में, एक ही निर्भरता आपके Chart.yaml में दिखाई Chart.yaml ।

 dependencies: - name: mariadb version: 5.xx repository: https://kubernetes-charts.storage.googleapis.com/ condition: mariadb.enabled tags: - database 

charts/ अभी भी लोड किए गए हैं और charts/ निर्देशिका में रखे गए हैं, इसलिए charts/ निर्देशिका में सबचर्स बिना बदलाव के काम करना जारी रखेंगे।

पेश है लाइब्रेरी चार्ट्स

हेल्म 3 एक चार्ट क्लास का समर्थन करता है जिसे लाइब्रेरी चार्ट कहा जाता है । इस चार्ट का उपयोग अन्य चार्ट द्वारा किया जाता है, लेकिन यह अपने आप कोई रिलीज़ कलाकृतियों का निर्माण नहीं करता है। लाइब्रेरी चार्ट टेम्प्लेट केवल define तत्वों define घोषित कर सकते हैं। अन्य सामग्री को केवल अनदेखा किया जाता है। यह उपयोगकर्ताओं को कोड के टुकड़ों का पुन: उपयोग करने और साझा करने की अनुमति देता है जो कई चार्ट पर उपयोग किए जा सकते हैं, जिससे नकल और DRY सिद्धांत का पालन करने से बचा जा सकता है।

लाइब्रेरी चार्ट Chart.yaml फ़ाइल की dependencies अनुभाग में घोषित किए जाते हैं। उनकी स्थापना और प्रबंधन अन्य चार्ट से अलग नहीं है।

 dependencies: - name: mylib version: 1.xx repository: quay.io 

हम उन उपयोग मामलों के लिए तत्पर हैं जो यह घटक चार्ट डेवलपर्स के लिए खुलेगा, साथ ही साथ पुस्तकालय चार्ट से उत्पन्न होने वाले सर्वोत्तम अभ्यास भी।

आगे क्या है?

Helm 3.0.0-alp.1 - वह आधार जिसके आधार पर हम Helm का नया संस्करण बनाना शुरू कर रहे हैं। लेख में मैंने हेल्म 3 की कुछ दिलचस्प विशेषताओं का वर्णन किया है। उनमें से कई अभी भी विकास के प्रारंभिक चरण में हैं और यह सामान्य है; अल्फा रिलीज का सार विचार का परीक्षण करना है, पहले उपयोगकर्ताओं से प्रतिक्रिया एकत्र करना और हमारी मान्यताओं की पुष्टि करना है।

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

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

यदि आपको लगता है कि हमने कुछ याद किया है, तो हम आपके विचारों को सुनकर प्रसन्न होंगे!

हमारे सुस्त चैनलों में चर्चा में शामिल हों:

• सवालों के लिए #helm-users और समुदाय के साथ आसान संचार;
• #helm-dev पुल अनुरोध, कोड और बग पर चर्चा करने के लिए।

आप 19:30 MSK पर गुरुवार को हमारे साप्ताहिक पब्लिक डेवलपर कॉल में भी चैट कर सकते हैं। बैठक उन कार्यों पर चर्चा करने के लिए समर्पित है जो प्रमुख डेवलपर्स और समुदाय काम कर रहे हैं, साथ ही साथ सप्ताह के लिए चर्चा के विषय भी। कोई भी शामिल हो सकता है और बैठक में भाग ले सकता है। लिंक #helm-dev स्लैक चैनल में उपलब्ध है।

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

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

• " कुबेरनेट्स के लिए पैकेज मैनेजर - हेल्म: अतीत, वर्तमान, भविष्य ";
• " हेल्म 2 में एक शांत नज़र:" यही वह है ... " ";
• " कुबेरनेट्स के लिए पैकेज मैनेजर का एक व्यावहारिक परिचय - हेल्म ";
• " कुबेरनेट्स टिप्स एंड ट्रिक्स: एक क्लस्टर में संसाधनों को हेल्म 2 में स्थानांतरित करना ";
• “ डैप के साथ अभ्यास करें। भाग 2. हेल्म के साथ कुबेरनेट्स में डॉकटर छवियों को तैनात करना । "