हेल्म का उपयोग करने से पहले दो बार सोचें।

प्रचार के बिना। सोबर लुक

हेल्म कुबेरनेट्स के लिए एक पैकेज मैनेजर है।

पहली नज़र में, बुरा नहीं है। यह उपकरण रिलीज़ प्रक्रिया को बहुत सरल करता है, लेकिन कभी-कभी यह एक परेशानी हो सकती है, आपने कुछ भी नहीं किया है!

हाल ही में हेल्म को आधिकारिक तौर पर शीर्ष परियोजना @CloudNativeFdn के रूप में मान्यता दी गई थी , यह समुदाय द्वारा व्यापक रूप से उपयोग किया जाता है। यह बहुत कुछ कहता है, लेकिन मैं इस पैकेज मैनेजर से जुड़े अप्रिय क्षणों के बारे में संक्षेप में बात करना चाहूंगा।

हेल्म का सही मूल्य क्या है?

मैं अब भी इस सवाल का जवाब आत्मविश्वास से नहीं दे सकता। हेल्म कोई विशेष सुविधा प्रदान नहीं करता है। टिलर (सर्वर साइड) क्या लाभ लाता है?

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

सरलतम उदाहरण देते हुए हेल्म की प्रशंसा करना पर्याप्त नहीं है। आप बताएंगे कि यह इतना अच्छा क्यों है - विशेष रूप से एक सुरक्षित बहु-किरायेदार कार्य वातावरण के संदर्भ में।

शब्द खाली हैं। मुझे कोड दिखाओ!
-लीनस टोरवाल्ड्स

प्राधिकरण और अभिगम नियंत्रण का एक अतिरिक्त स्तर

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

एक ओवररेटेड टेम्पलेट प्रोसेसिंग टूल?

तथ्य यह है कि गो टेम्प्लेट फ़ाइलों के प्रसंस्करण और स्थैतिक विश्लेषण के लिए, values.yaml फ़ाइल से कॉन्फ़िगरेशन का values.yaml , और फिर संसाधित कुबेरनेट प्रकट होता है जिसका उपयोग कॉन्फ़िगरेशन में संग्रहीत मेटाडेटा के साथ किया जाता है।

और आप कुछ सरल कमांड का उपयोग कर सकते हैं:

 $ # render go-template files using golang or python script $ kubectl apply --dry-run -f . $ kubectl apply -f . 

मैंने देखा कि डेवलपर्स आमतौर पर प्रति पर्यावरण एक values.yaml उपयोग करते थे। या यहां तक ​​कि इसे values.yaml.tmpl से प्राप्त किया। उपयोग करने से पहले।

कुबेरनेट रहस्य के साथ काम करते समय इसका कोई मतलब नहीं है, जो अक्सर एन्क्रिप्ट किए जाते हैं और रिपॉजिटरी में कई संस्करण होते हैं। इस सीमा के आसपास जाने के लिए, आपको हेल्म-सीक्रेट प्लगइन या --set key=value कमांड का उपयोग करना होगा। किसी भी मामले में, जटिलता का एक और स्तर जोड़ा जाता है।

एक बुनियादी ढांचे के जीवन चक्र प्रबंधन उपकरण के रूप में हेलम

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

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

दुर्भाग्य से, Namespace, RBAC, NetworkPolicy, ResourceQuota और PodSecurityPolicy सहित अधिक जटिल और लगातार तैनाती के साथ, Helm सामना नहीं कर सकता।

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

स्टेट हैल्म

टिलर सर्वर Kubernetes के अंदर ConfigMap फ़ाइलों में जानकारी संग्रहीत करता है। उसे अपने डेटाबेस की आवश्यकता नहीं है।

दुर्भाग्य से, विन्यास मानचित्र का आकार 1 एमबी से अधिक नहीं हो सकता है, क्योंकि सीमाएं हैं ।

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

रैंडम क्रैश और एरर हैंडलिंग

मेरे लिए, हेल्म की सबसे बड़ी समस्या इसकी असुरक्षा है।

त्रुटि: UPGRADE विफल: "foo" में कोई रिलीज़ रिलीज़ नहीं है

यह, IMHO, हेल्म की सबसे कष्टप्रद समस्याओं में से एक है।

यदि पहले संस्करण को बनाना संभव नहीं था, तो प्रत्येक बाद का प्रयास एक अज्ञात राज्य से अद्यतन की असंभवता को इंगित करने में त्रुटि के साथ विफल हो जाएगा।

परिवर्तनों को शामिल करने के लिए निम्नलिखित अनुरोध - सुधारों के झंडे को जोड़कर त्रुटि को "ठीक करता है", जो वास्तव में सिर्फ helm delete & helm install —replace कमांड कमांड चलाकर समस्या का helm delete & helm install —replace ।

हालांकि, ज्यादातर मामलों में, आपको रिलीज की पूरी सफाई करनी होगी।

 helm delete --purge $RELEASE_NAME 

त्रुटि: रिलीज फू विफल: हालत के इंतजार में समय समाप्त हो गया

यदि ServiceAccount गायब है या RBAC किसी विशिष्ट संसाधन के निर्माण की अनुमति नहीं देता है, तो Helm निम्नलिखित त्रुटि संदेश लौटाएगा:

 Error: release foo failed: timed out waiting for the condition 

दुर्भाग्य से, इस त्रुटि का मूल कारण नहीं देखा जा सकता है:

 kubectl -n foo get events --sort-by='{.lastTimestamp}' 

 Error creating: pods "foo-5467744958" is forbidden: error looking up service account foo/foo: serviceaccount "foo" not found 

नीले रंग से बाहर असफल

सबसे उन्नत मामलों में, हेल्म बिल्कुल भी कोई कार्रवाई किए बिना एक त्रुटि फेंकता है। उदाहरण के लिए, कभी-कभी यह संसाधन सीमाओं को अद्यतन नहीं करता है।

पतवार init एक प्रति के साथ टिलर चलाता है, हा विन्यास में नहीं

डिफ़ॉल्ट रूप से टिलर उच्च उपलब्धता नहीं है, और संदर्भ द्वारा परिवर्तन को सक्षम करने का अनुरोध अभी भी खुला है।

एक दिन यह नीचे की ओर ले जाएगा ...

हेल्म ३? ऑपरेटर्स? भविष्य?

हेल्म के अगले संस्करण में कुछ आशाजनक विशेषताएं शामिल होंगी:

• क्लाइंट और सर्वर के बीच अलगाव के बिना एकल-सेवा वास्तुकला। कोई और टिलर नहीं;
• अंतर्निहित लुआ स्क्रिप्टिंग इंजन;
• शामिल किए गए अनुरोधों और नए हेल्म नियंत्रक प्रोजेक्ट के आधार पर DevOps वर्कफ़्लो।

अधिक जानकारी के लिए हेल्म 3 प्रोजेक्ट प्रस्ताव देखें।

मुझे वास्तव में टिलर के बिना वास्तुकला का विचार पसंद है, लेकिन लुआ पर आधारित स्क्रिप्ट संदेह में हैं, क्योंकि वे चार्ट को जटिल कर सकते हैं।

मैंने देखा कि हाल ही में ऑपरेटर्स जो हेल्म चार्ट की तुलना में कुबेरनेट्स के लिए अधिक उपयुक्त हैं, ने लोकप्रियता हासिल की है।

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

इसे समझें: यह लेख मेरी निजी राय है, जो मुझे कुबेरनेट्स पर आधारित तैनाती के लिए एक हाइब्रिड क्लाउड प्लेटफॉर्म बनाते समय आया था।