हेल्म 2 में एक शांत नज़र: "यही वह है ..."

किसी भी अन्य समाधान की तरह, हेल्म - कुबेरनेट्स के लिए पैकेज प्रबंधक - में पेशेवरों, विपक्ष और गुंजाइश है, इसलिए इसका उपयोग करते समय, आपको अपनी उम्मीदों का सही मूल्यांकन करना चाहिए ...


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

इस लेख को लिखने का मुख्य उद्देश्य उपयोगकर्ता को निश्चित निष्कर्ष के बिना हेल्म 2 की मुख्य समस्याओं के एक उद्देश्य मूल्यांकन के साथ-साथ अनुभव और हमारे समाधान साझा करने की इच्छा प्रदान करना है।

[बग] बाहर निकलने के बाद, क्लस्टर में रिलीज़ संसाधनों की स्थिति वर्णित हेलम चार्ट के अनुरूप नहीं है

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

विचार करें कि यह समस्या कैसे प्रकट होती है:

1. चार्ट पर संसाधन टेम्पलेट राज्य X से मेल खाता है।
2. उपयोगकर्ता चार्ट स्थापित करता है (टिलर संसाधन X की स्थिति को बचाता है)।
3. अगला, उपयोगकर्ता मैन्युअल रूप से क्लस्टर में संसाधन बदलता है (राज्य X से Y में बदलता है)।
4. कोई भी बदलाव किए बिना, यह helm upgrade करता है ... और संसाधन अभी भी वाई में है, हालांकि उपयोगकर्ता एक्स की उम्मीद करता है।

और यह सब नहीं है। कुछ बिंदु पर, उपयोगकर्ता चार्ट (नया राज्य डब्ल्यू) पर संसाधन टेम्पलेट बदलता है - फिर हमारे पास helm upgrade बाद दो परिदृश्य हैं:

• XW पैच का अनुप्रयोग गिर रहा है।
• पैच लगाने के बाद, संसाधन राज्य Z में चला जाता है, जो वांछित के अनुरूप नहीं है।

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

यदि यह विकल्प उपयुक्त नहीं है, तो आप रिलीज़ संसाधन राज्यों के सिंक्रनाइज़ेशन की निगरानी कर सकते हैं । मैनुअल तुल्यकालन इस तरह दिख सकता है:

1. हम helm get माध्यम से रिलीज संसाधनों की स्थिति का पता helm get ।
2. Kubectl के माध्यम से kubectl get में संसाधनों की स्थिति का पता लगाएं।
3. यदि संसाधन अलग हैं, तो हम कुबेरनेट्स के साथ हेल्म को सिंक्रनाइज़ करते हैं:
   
   1. एक अलग शाखा बनाएं।
   2. चार्ट मेनिफ़ेस्ट अपडेट करना। टेम्पलेट कुबेरनेट्स में संसाधन राज्यों से मेल खाना चाहिए।
   3. हम तैनाती करते हैं। हम हेल्म रजिस्ट्री और क्लस्टर में राज्य को सिंक्रनाइज़ करते हैं।
   4. उसके बाद, शाखा को हटाया जा सकता है और नियमित काम जारी रख सकता है।

kubectl apply का उपयोग करके पैच लगाने पर, तथाकथित 3-तरफा-मर्ज निष्पादित होता है, अर्थात। अद्यतन संसाधन की वास्तविक स्थिति को ध्यान में रखा जाता है। आप यहां एल्गोरिथ्म कोड देख सकते हैं, और इसके बारे में यहां पढ़ सकते हैं ।

लेखन के समय, हेल्म डेवलपर्स हेल्म 3 में 3-वे-मर्ज को लागू करने के तरीकों की तलाश कर रहे हैं। हेल्म 2 के साथ, चीजें इतनी रसीली नहीं हैं: 3-वे-मर्ज को लागू करने की योजना नहीं है, लेकिन जिस तरह से संसाधन बनाए जाते हैं उसे ठीक करने के लिए एक पीआर है - आप विवरण प्राप्त कर सकते हैं या यहां तक ​​कि भाग भी ले सकते हैं। प्रासंगिक मुद्दे के हिस्से के रूप में।

[बग] त्रुटि: नाम के साथ कोई परिणाम नहीं मिला

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

यदि रोलआउट विफल हो जाता है, तो जारी की गई FAILED रजिस्ट्री में रिलीज़ को सहेजा जाता है, और स्थापना के दौरान Helm नवीनतम DEPLOYED रिलीज़ की स्थिति पर निर्भर करता है, जो इस मामले में नए संसाधनों के बारे में कुछ भी नहीं जानता है। परिणामस्वरूप, हेल्म इन संसाधनों को फिर से बनाने की कोशिश करता है और "NAME के ​​नाम के साथ कोई परिणाम नहीं" त्रुटि के साथ विफल रहता है (त्रुटि इसके विपरीत कहती है, लेकिन यह समस्या है)। समस्या का एक हिस्सा यह है कि हेम पैच बनाते समय क्लस्टर में रिलीज़ संसाधनों की स्थिति को ध्यान में नहीं रखता है, जैसा कि पिछले अनुभाग में वर्णित है।

अभी के लिए, एकमात्र उपाय नए संसाधनों को मैन्युअल रूप से निकालना है।

ऐसी स्थिति से बचने के लिए, कमांड अपग्रेड / रोलबैक में बनाए गए नए संसाधनों को स्वचालित रूप से हटाना संभव है यदि कमांड अंततः विफल हो जाता है। अपग्रेड / रोलबैक कमांड के लिए हेल्म में डेवलपर्स के साथ लंबी चर्चा के बाद, --cleanup-on-fail ऑप्शन जोड़ा गया, जो रोलआउट विफल होने पर स्वचालित सफाई को सक्रिय करता है। हमारे पीआर पर चर्चा चल रही है, सबसे अच्छा समाधान खोज रहे हैं।

हेल्म संस्करण 2.13 के साथ शुरू, - --atomic विकल्प helm install/upgrade --atomic में दिखाई देता है, जो एक असफल इंस्टॉलेशन (अधिक विवरण के लिए, पीआर देखें) के दौरान सफाई और रोलबैक को सक्रिय करता है।

[बग] त्रुटि: घड़ी से पहले बंद घड़ी

समस्या तब हो सकती है जब हेलम हुक को बहुत लंबे समय तक निष्पादित किया जाता है (उदाहरण के लिए, माइग्रेशन के दौरान) - भले ही spec.activeDeadlineSeconds helm install/upgrade के निर्दिष्ट समयबाह्य और संबंधित जॉब के spec.activeDeadlineSeconds अधिक न हों।

यह त्रुटि Kubernetes API सर्वर द्वारा हुक कार्य के पूरा होने की प्रतीक्षा करते समय उत्पन्न होती है। हेलम इस त्रुटि को संभालती नहीं है और प्रतीक्षा अनुरोध को वापस लेने के बजाय तुरंत दुर्घटनाग्रस्त हो जाती है।

समाधान के रूप में, आप एपी-सर्वर में टाइमआउट बढ़ा सकते हैं: --min-request-timeout=xxx फ़ाइल /etc/kubernetes/manifests/kube-apiserver.yaml ।

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

यदि helm install माध्यम से पहली रिलीज़ विफल हो गई, तो बाद वाला helm upgrade एक समान त्रुटि लौटाएगा।

ऐसा लगता है कि समाधान काफी सरल है: आपको पहले असफल स्थापना के बाद मैन्युअल रूप से helm delete --purge लेकिन यह मैनुअल कार्रवाई CI / CD स्वचालन को तोड़ देती है। मैनुअल कमांड्स के निष्पादन को बाधित नहीं करने के लिए, आप रोल-आउट करने के लिए वेयरफ़ सुविधाओं का उपयोग कर सकते हैं। वेयरफ का उपयोग करते समय, समस्याग्रस्त रिलीज को पुन: स्थापित करने पर स्वचालित रूप से फिर से बनाया जाएगा।

इसके अलावा, हेल्म 2.13 से शुरू होकर, हेल्म helm install और helm upgrade --install केवल --atomic ऑप्शन को निर्दिष्ट करें और असफल इंस्टॉलेशन के बाद, रिलीज़ स्वचालित रूप से हटा दी जाएगी (विवरण के लिए पीआर देखें)।

Autorollback

हेलम के पास - --autorollback विकल्प का अभाव है, जो कि --autorollback , वर्तमान सफल संशोधन को याद रखेगा (अंतिम संशोधन सफल नहीं होने पर छोड़ देगा) और, असफल तैनाती के प्रयास के बाद, सहेजे गए संशोधन में रोलबैक होगा।

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

ऑटोरॉलबैक को व्यवस्थित करने के लिए, आप हेल्म-मॉनिटर प्लगइन का उपयोग कर सकते हैं, जो आपको प्रोमेथियस से मैट्रिक्स में रोलबैक को टाई करने की अनुमति देता है। इस दृष्टिकोण का वर्णन करने वाला एक अच्छा लेख यहाँ उपलब्ध है ।

हमारी कुछ परियोजनाओं के लिए, एक काफी सरल दृष्टिकोण का उपयोग किया जाता है:

1. तैनाती से पहले, हम वर्तमान संशोधन को याद करते हैं (हम मानते हैं कि एक सामान्य स्थिति में, यदि रिलीज़ मौजूद है, तो यह आवश्यक रूप से खराब स्थिति में है):
   
   

    export _RELEASE_NAME=myrelease export _LAST_DEPLOYED_RELEASE=$(helm list -adr | \ grep $_RELEASE_NAME | grep DEPLOYED | head -n2 | awk '{print $2}') 

2. इंस्टॉल करें या अपग्रेड करें:
   
   

    helm install/upgrade ... || export _DEPLOY_FAILED=1 

3. हम तैनाती की स्थिति की जाँच करते हैं और सहेजे गए स्थिति में रोलबैक करते हैं:
   
   

    if [ "$_DEPLOY_FAILED" == "1" ] && [ "x$_LAST_DEPLOYED_RELEASE" != "x" ] ; then helm rollback $_RELEASE_NAME $_LAST_DEPLOYED_RELEASE fi 

4. हम एक त्रुटि के साथ पाइपलाइन को समाप्त करते हैं यदि तैनाती असफल रही:
   
   

    if [ "$_DEPLOY_FAILED" == "1" ] ; then exit 1 ; fi 

फिर से, हेल्म संस्करण 2.13 के साथ शुरू, जब helm upgrade --atomic विकल्प निर्दिष्ट करने के लिए पर्याप्त है और एक असफल स्थापना के बाद रोलबैक स्वचालित रूप से किया जाएगा (विवरण के लिए पीआर देखें)।

रोलआउट के समय रिलीज संसाधनों और प्रतिक्रिया की उपलब्धता की प्रतीक्षा है

जैसा कि योजना बनाई गई, - हेल विकल्प का उपयोग करते समय हेल्म को संबंधित लीननेस और तत्परता परीक्षणों के निष्पादन की निगरानी करनी चाहिए:

 --wait if set, will wait until all Pods, PVCs, Services, and minimum number of Pods of a Deployment are in a ready state before marking the release as successful. It will wait for as long as --timeout 

यह फ़ंक्शन अभी ठीक से काम नहीं करता है: सभी संसाधन नहीं और सभी एपीआई संस्करण समर्थित नहीं हैं। और घोषित प्रतीक्षा प्रक्रिया ही हमारी जरूरतों को पूरा नहीं करती है।

kubectl wait साथ, कोई त्वरित प्रतिक्रिया नहीं है और इस व्यवहार को विनियमित करने का कोई तरीका नहीं है। यदि रोलआउट विफल हो जाता है, तो हम इसके बारे में एक टाइमआउट के बाद ही जान पाएंगे। एक समस्याग्रस्त स्थापना के मामले में, रोलआउट प्रक्रिया को जितनी जल्दी हो सके पूरा करना आवश्यक है, सीआई / सीडी पाइपलाइन को फ्लिप करें, कार्य संस्करण में रिलीज को वापस रोल करें और डीबगिंग पर जाएं।

यदि समस्याग्रस्त रिलीज़ को वापस रोल किया जाता है, और हेलम रोलआउट प्रक्रिया के दौरान किसी भी जानकारी को वापस नहीं करता है, तो इसके बारे में क्या डिबगिंग है! kubectl wait के मामले में kubectl wait आप लॉग प्रदर्शित करने के लिए एक अलग प्रक्रिया का आयोजन कर सकते हैं, जिसके लिए रिलीज़ संसाधन नामों की आवश्यकता होगी। एक सरल और काम करने वाले समाधान को कैसे व्यवस्थित किया जाए यह तुरंत स्पष्ट नहीं है। और पॉड लॉग के अलावा, उपयोगी जानकारी रोलआउट प्रक्रिया, संसाधन घटनाओं में निहित हो सकती है ...

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

यह तर्क एक अलग कुबडोग समाधान में बनाया गया है। उपयोगिता का उपयोग करते हुए, आप एक संसाधन की सदस्यता ले सकते हैं और घटनाओं और लॉग प्राप्त कर सकते हैं, साथ ही समय पर असफल रोलआउट के बारे में जान सकते हैं। यानी एक समाधान के रूप में, --वाइट विकल्प के बिना helm install/upgrade बाद, --wait प्रत्येक रिलीज़ संसाधन के लिए कुबेदोग कह सकते हैं।

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

शायद हेल्म 3 में किसी दिन एक समान समाधान दिखाई देगा, लेकिन अभी तक हमारा मुद्दा एक निलंबित स्थिति में है।

डिफ़ॉल्ट रूप से पतवार init का उपयोग करते समय सुरक्षा

डिफ़ॉल्ट रूप से, जब helm init कमांड निष्पादित होती है, तो सर्वर घटक क्लस्टर में सुपरयुसर के समान विशेषाधिकारों के साथ स्थापित किया जाता है, जिससे तीसरे पक्ष द्वारा एक्सेस किए जाने पर अवांछनीय परिणाम हो सकते हैं।

क्लस्टर की सुरक्षा सुनिश्चित करने के लिए, टिलर की क्षमताओं को सीमित करना आवश्यक है, साथ ही कनेक्शन का ध्यान रखना चाहिए - नेटवर्क की सुरक्षा जिसके माध्यम से हेल्म घटकों के बीच संचार होता है।

पहला मानक कुबेरनेट्स आरबीएसी तंत्र के उपयोग के माध्यम से प्राप्त किया जा सकता है, जो टिलर के कार्यों को सीमित करेगा, और दूसरा - एसएसएल सेट करके। हेल्म डॉक्यूमेंटेशन में और पढ़ें: अपने हेल्म इंस्टॉलेशन को सुरक्षित रखें ।

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

मार्टियन गो टेम्प्लेट

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

बॉक्स से बाहर रहस्यों का अभाव

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

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

रहस्यों के साथ काम करते समय, हम अपने स्वयं के समाधान का उपयोग वेयरफ़ ( रहस्यों पर प्रलेखन ) में लागू करते हैं। सुविधाओं में से:

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

निष्कर्ष

हेल्म 2 को एक स्थिर उत्पाद के रूप में तैनात किया गया है, लेकिन एक ही समय में कई कीड़े हैं जो लिम्बो में लटकते हैं (उनमें से कुछ कई सालों तक!)। समाधान के बजाय, या कम से कम पैच, सभी प्रयास हेल्म 3 के विकास के लिए समर्पित हैं।

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

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

पुनश्च

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

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