<p>हेल्म अपग्रेड --इंस्टॉल अब काम नहीं करता</p>

मुझे लगा कि मैं उसी समस्या का सामना कर रहा हूं, लेकिन यह पता चला कि मेरे पास एक पुराना डिलीट (लेकिन पर्ज नहीं) था, रिलीज चारों ओर लटका हुआ था। हेलम लिस्ट -ए चेक करें, और अगर आपकी रिलीज है, तो हेल्म डिलीट - पर्ज रिलीजनाम। helm upgrade -i मेरे लिए 2.7.2 पर सफलतापूर्वक काम कर रहा है।

यह रिलीज़ को अपग्रेड करने से संबंधित समस्याओं को ठीक करने का एक साइड-इफ़ेक्ट है जो खराब स्थिति में थे। https://github.com/kubernetes/helm/pull/3097 वह पीआर था जिसने इस मुद्दे को ठीक किया। क्या यहां कोई बढ़त का मामला है जिसे पकड़ने में हम असफल रहे?

चेक helm list -a जैसा कि @tcolgate ने उल्लेख किया है, शायद यह भी समझाते हुए कि इसे कैसे पुन: पेश किया जाए, यह निर्धारित करने में भी मददगार होगा कि यह एक अनकैप्ड एज केस है या बग।

डुप्लिकेट रिलीज़ नामों के साथ भी यही समस्या है:

$>helm ls -a|grep ingress
nginx-ingress               9           Thu Nov 30 11:33:06 2017    FAILED      nginx-ingress-0.8.2         kube-ingress
nginx-ingress               11          Thu Nov 30 11:37:58 2017    FAILED      nginx-ingress-0.8.2         kube-ingress
nginx-ingress               12          Thu Nov 30 11:38:50 2017    FAILED      nginx-ingress-0.8.2         kube-ingress
nginx-ingress               8           Thu Nov 30 11:31:27 2017    FAILED      nginx-ingress-0.8.2         kube-ingress
nginx-ingress               10          Thu Nov 30 11:33:53 2017    FAILED      nginx-ingress-0.8.2         kube-ingress
$>helm diff nginx-ingress ./nginx-ingress
Error: "nginx-ingress" has no deployed releases

जब आप अपग्रेड कर रहे थे, तो कौन सा संदेश प्रदर्शित किया गया था?

उपरोक्त अंतर के समान त्रुटि, लेकिन एक इंस्टॉल कहेगा कि यह पहले से ही स्थापित था।

मेरा मतलब पिछले अपग्रेड प्रयासों से है जो एक FAILED स्थिति में समाप्त हुए। मैं जानना चाहता हूं कि हम उस स्थिति में कैसे आते हैं जहां सभी रिलीज विफल स्थिति में हैं।

ओह, डुप्लिकेट रिलीज़ नाम परिनियोजन? मुझे यकीन नहीं है, मैं इसे बहुत बार प्राप्त करता हूं। कभी-कभी वे सभी DEPLOYED अवस्था में होते हैं, कभी-कभी FAILED और DEPLOYED का मिश्रण। हम एक CI/CD जेनकिंस सर्वर का उपयोग करते हैं जो हर पीआर मर्ज को लगातार अपडेट करता है इसलिए हम कई helm upgrade 'एक दिन में करते हैं, आमतौर पर केवल एक नया कंटेनर टैग होता है। आम तौर पर डुप्लिकेट केवल परेशान होते हैं जब तैनात किए गए कार्यों को देखते हुए, यह पहली बार था जब हमें उनके साथ एक कठिन समस्या थी, और आम तौर पर हम इस मामले में प्रवेश नियंत्रक को अपग्रेड नहीं करते थे।

मुझे लगता है कि कुछ इसी तरह के साथ समाप्त हो गया है, मुझे मेरी रिलीज सूचियों में कुछ डुप्लीकेट दिखाई देते हैं:

$ helm ls
NAME                      REVISION    UPDATED                     STATUS      CHART                           NAMESPACE
.....
front-prod                180         Tue Dec  5 17:28:22 2017    DEPLOYED    front-1                         prod
front-prod                90          Wed Sep 13 14:36:06 2017    DEPLOYED    front-1                         prod 
...

वे सभी एक नियोजित स्थिति में प्रतीत होते हैं, लेकिन यह अच्छी तरह से हो सकता है कि पिछला अपग्रेड किसी बिंदु पर विफल हो गया, क्योंकि मैंने उस बग को कई बार मारा है। मैं अभी भी K8S 1.7 पर हूं, इसलिए अभी तक 2.7 को अद्यतन नहीं किया है।

एक ही समस्या, FAILED परिनियोजन पर अपग्रेड नहीं किया जा सकता

2.7.2 का उपयोग करके यहां वही। रिलीज का पहला प्रयास विफल रहा। फिर जब मैंने अपग्रेड करने की कोशिश की --इंस्टॉल मुझे त्रुटि मिली है "त्रुटि: अपग्रेड विफल: "$ {रिलीज}" में कोई तैनात रिलीज नहीं है"।

2.7.2 के साथ यहाँ भी यही समस्या है, helm upgrade --install साथ विफल रहता है:

Error: UPGRADE FAILED: "APPNAME" has no deployed releases

यदि रिलीज़ पूरी तरह से helm del --purge APPNAME से शुद्ध हो जाती है तो बाद में upgrade --install ठीक काम करता है।

मैं एक ही समस्या का सामना कर रहा हूँ। #3134 के साथ संयुक्त, जो कुछ स्क्रिप्टिंग के बिना वर्कअराउंड के लिए स्वचालित निष्क्रिय तैनाती के लिए कोई विकल्प नहीं छोड़ता है।

@winjer ने --purge के साथ हटाने की कोशिश की और मेरे लिए यह काम नहीं किया, हालांकि त्रुटि बदल गई
/ # हेल्म अपग्रेड फू /चार्ट्स/फू/-आई --वेट
त्रुटि: अपग्रेड विफल: "foo" में कोई परिनियोजित रिलीज़ नहीं है
/ # हेल्म डिलीट --पर्ज फू
रिलीज "फू" हटा दिया गया
/ # हेल्म अपग्रेड फू /चार्ट्स/फू/-आई --वेट
रिलीज "फू" मौजूद नहीं है। इसे अभी स्थापित कर रहे हैं।
त्रुटि: रिलीज फू विफल: परिनियोजन। एक्सटेंशन "फू-फू-कुछ-सेवा-नाम" पहले से मौजूद है

@prein ऐसा इसलिए है क्योंकि आपके पास ऐसी सेवा है जो "मालिक" नहीं है, लेकिन क्लस्टर में पहले से मौजूद है। आप जिस व्यवहार का अनुभव कर रहे हैं वह मुझे सही लगता है। परिनियोजन सफल नहीं हो सकता क्योंकि पतवार को एक एपीआई ऑब्जेक्ट का "स्वामित्व लेना" होगा जो पहले उसके पास नहीं था।

यदि नया मेनिफेस्ट वास्तव में सही है और क्लस्टर में किसी अन्य संसाधन से संतुष्ट नहीं है, तो FAILED रिलीज़ को अपग्रेड करने में सक्षम होना समझ में आता है।

मैं इस व्यवहार को content नामक रिलीज पर भी देख रहा हूं:

helm upgrade --install --wait --timeout 300 -f ./helm/env/staging.yaml --set image.tag=xxx --namespace=content content ./helm/content
Error: UPGRADE FAILED: no resource with the name "content-content" found
helm list | grep content
content                         60          Mon Dec 25 06:02:38 2017    DEPLOYED    content-0.1.0                   content           
content                         12          Tue Oct 10 00:02:24 2017    DEPLOYED    content-0.1.0                   content           
content                         37          Tue Dec 12 00:42:42 2017    DEPLOYED    content-0.1.0                   content           
content                         4           Sun Oct  8 05:58:44 2017    DEPLOYED    k8s-0.1.0                       content           
content                         1           Sat Oct  7 22:29:24 2017    DEPLOYED    k8s-0.1.0                       content           
content                         61          Mon Jan  1 06:39:21 2018    FAILED      content-0.1.0                   content           
content                         62          Mon Jan  1 06:50:41 2018    FAILED      content-0.1.0                   content           
content                         63          Tue Jan  2 17:05:22 2018    FAILED      content-0.1.0                   content           

तैनाती जारी रखने में सक्षम होने के लिए मुझे इसे हटाना होगा, मुझे बताएं कि क्या ऐसा कुछ है जो मैं इसे डीबग करने में मदद के लिए कर सकता हूं।
(मुझे लगता है कि हमें इस मुद्दे का नाम बदलना चाहिए, क्योंकि यह डुप्लिकेट के बारे में अधिक है?)
(हम 2.7.2 भी चलाते हैं)

मेरे पास वास्तव में मेरे क्लस्टर पर एक और डुप्लिकेट रिलीज है, अगर आपके पास डीबग करने में मदद के लिए मेरे लिए चलाने के लिए कोई आदेश है? मुझे बताओ!

अभी टिलर 2.7.2 में अपग्रेड किया गया है और हम वही देख रहे हैं। helm delete RELEASE_NAME बाद helm upgrade RELEASE_NAME . साथ विफल रहता है Error: UPGRADE FAILED: "RELEASE_NAME" has no deployed releases । upgrade हटाए गए (लेकिन शुद्ध नहीं) रिलीज को पुनर्स्थापित करने का इच्छित तरीका है, सही?

ऐसा लगता है कि आप हटाए गए संस्करण पर वापस रोल करके रिलीज़ को पुनर्स्थापित कर सकते हैं।

v2.7.2 साथ एक ही समस्या को देखते हुए, विफल हो जाता है जब कोई पिछली सफलतापूर्वक परिनियोजित रिलीज़ नहीं होती है

इस मुद्दे के दो संभावित संस्करण भी देख रहे हैं:

सीआई में:

+ helm upgrade --install --wait api-feature-persistent-data . --values -
+ cat
WARNING: Namespace doesn't match with previous. Release will be deployed to default
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
Error: UPGRADE FAILED: "api-feature-persistent-data" has no deployed releases

मेरी स्थानीय मशीन पर:

(दोनों मेरे OSX बैश में और gcloud/kubectl कंटेनर में)

+ helm upgrade --install --wait api-feature-persistent-data . --values -
+ cat
WARNING: Namespace doesn't match with previous. Release will be deployed to default
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
Error: UPGRADE FAILED: no PersistentVolumeClaim with the name "api-feature-persistent-data-db" found

हमारे चार्ट के लिए चेतावनियां सामान्य हैं।
त्रुटियां दिलचस्प हैं क्योंकि हमारे एक सबचार्ट में pvc.yaml है।

helm del --purge <release> समस्या को कम करता है।
इससे हमारी सीआई पाइपलाइन को अपग्रेड करना मुश्किल हो जाता है।

@adamreese इस मुद्दे का अंतिम समाधान क्या है? हम 2.8 पर हैं और हम अभी भी पहले की FAILED रिलीज़ को helm list में परिवर्तन के साथ अपग्रेड नहीं कर सकते हैं।

विशेष रूप से, हम निम्न प्रकार की समस्याओं का सामना कर रहे हैं:

• एक रिलीज तैनात करें, ठीक है
• upgrade --install --wait , लेकिन हो सकता है कि एक छोटी सी बग हो और --wait सफल न हो (उदाहरण के लिए, जीवंतता जांच इसे कभी नहीं बनाती है)
• चार्ट को ठीक करने के बाद, upgrade --install --wait xxx has no deployed releases साथ विफल हो जाता है

हटाना/शुद्ध करना यहां वांछनीय या स्वीकार्य नहीं है: रिलीज में कई संसाधन (पॉड्स, लोड बैलेंसर्स) हो सकते हैं जो एक संसाधन से प्रभावित नहीं होते हैं जो ऊपर नहीं जाएंगे। पिछले हेल्म संस्करणों में, upgrade --install ने हमें केवल उस परिवर्तन को पैच करने की अनुमति दी जिसने सभी संसाधनों को हटाए बिना पूर्ण रिलीज़ को तोड़ दिया।

हेल्म यहां हर समय शामिल सभी संसाधनों का स्वामी है -- संसाधन को केवल FAILED रूप में चिह्नित किया गया है क्योंकि --wait सभी संसाधनों के अच्छी स्थिति में होने की प्रतीक्षा करने में सफल नहीं हुआ। मुझे लगता है कि ऐसा ही होगा यदि एक पॉड शुरू करने के लिए थोड़ा धीमा है और इसी तरह के कई मामलों में।

अनुवर्ती चर्चा के लिए @peay #3353 देखें।

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

यह तब भी होता है जब इंस्टॉलेशन विफल हो जाता है।
आपको शुद्ध करने और पुनः प्रयास करने की आवश्यकता है।

UPGRADE FAILED: "API" has no deployed releases
तो आपको मैन्युअल रूप से शुद्ध करने की आवश्यकता है
helm delete --purge API
और यह काम करेगा।

हेलम 2.9 के रूप में आप helm upgrade --install --force भी प्रदर्शन कर सकते हैं,

helm delete API
helm install --replace --name API ./mychart

@bacongobbler मैं अभी भी इस व्यवहार के बारे में उलझन में हूँ।
क्या आपके पास समय होने पर https://github.com/kubernetes/helm/pull/3597#issuecomment -382843932 का उत्तर देने में सक्षम होंगे?

इस पर आपके काम के लिए धन्यवाद।

ज़रूर। मैं इस समय AFK हूं लेकिन मैं आज शाम को उत्तर दे सकता हूं। भ्रम को पूरी तरह से समझें और मैं आपके प्रश्नों का यथासंभव उत्तर देने का प्रयास करूंगा। यह कार्यालय में KubeCon EU के लिए अन्य सामान तैयार करने के लिए पागल है। :)

मैं इस पर हैक करने और/या दस्तावेज़ों को बेहतर बनाने में मदद करने के लिए तैयार हूं, जब हम वहां हों।
आइए निश्चित रूप से मिलते हैं: +1:

@bacongobbler इस पते को #3353 करता है और मेरे द्वारा #4004 के हिस्से के रूप में लिखे गए कोड के समूह को नकारता है?

मेरे मामले में helm upgrade --install --force ने delete --purge और उसके बाद एक इंस्टॉल किया।

क्या यह अपेक्षित व्यवहार है? इस वजह से मेरा लगभग 2 महीने का काम छूट गया है। force का अर्थ delete कब हुआ?

^ मैंने क्यूबकॉन के लोगों के साथ कुछ बातचीत की और पाया कि इस व्यवहार परिवर्तन के कारण कुछ टीमों को v2.7.0 पर पिन किया गया है।

मैं सहमत हूं कि upgrade install कभी भी विनाशकारी नहीं होना चाहिए, भले ही --force का कभी भी मतलब हो।

@bacongobbler , क्षमा करें, जब हम सीपीएच में थे तब मैं नहीं मिल पाया।
क्या विफल रिलीज़ को अपग्रेड करने की अनुमति न देने के व्यवहार को बदलने के औचित्य के पीछे कोई दस्तावेज़ है?
पुराना व्यवहार अब हमारे पास की तुलना में कहीं अधिक वांछनीय लगता है।

पृष्ठभूमि संदर्भ के लिए https://github.com/kubernetes/helm/issues/3353 में दूसरी टिप्पणी देखें कि हमें यह परिवर्तन क्यों करना पड़ा

मैं वास्तव में यह जानने के लिए उत्सुक हूं कि प्रस्तावित मार्ग क्या है। #3353 में प्रदर्शित समस्याओं के कारण हम #3097 से पीछे नहीं हट सकते, इसलिए मुझे यह सुनना अच्छा लगेगा कि इस मुद्दे को ठीक करने के लिए समुदाय क्या सोचता है कि आगे बढ़ने का सही रास्ता क्या है। हम #3597 वापस ले सकते हैं लेकिन मैंने जो सुना है उससे helm upgrade --install समस्या को ठीक करने के लिए कोई अच्छा समाधान नहीं है। :निराश:

मुझे पता है कि हम हेल्म 3 के लिए लागू तर्क को फिर से काम करने पर काम कर रहे हैं, लेकिन यह एक लंबा रास्ता तय करना है

उस @bacongobbler को जोड़ने के लिए धन्यवाद :)
आपका सुझाव यहाँ एक उचित दृष्टिकोण की तरह लगता है:

जब कोई सफल रिलीज़ तैनात नहीं किया गया हो, तो अंतर नहीं करना मूल्यवान हो सकता है। अनुभव वैसा ही होगा जैसे कि उपयोगकर्ता ने पहली बार इस अर्थ में हेल्म इंस्टाल चलाया कि इसके खिलाफ कोई "वर्तमान" रिलीज़ नहीं होगा। हालांकि मैं कुछ किनारे के मामलों के बारे में थोड़ा चिंतित हूं। @adamreese क्या इस पर आपकी कोई राय है?

यह हमें #3597 से पीछे हटने की अनुमति देगा क्योंकि एकमात्र विफलता मामले (इसके खिलाफ कुछ भी भिन्न नहीं) को संबोधित किया जाएगा।
यह upgrade --install को फिर से विनाशकारी और kubectl apply समान बनाता है।

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

मैंने चर्चाओं के माध्यम से पढ़ा है, लेकिन मैं अभी भी स्पष्ट नहीं हूं कि कैसे एक बेवकूफ upgrade --install कमांड (या आदेशों का अनुक्रम) है।

वर्तमान स्थिर संस्करण के साथ, मैं इसे स्वचालित स्क्रिप्ट में कैसे प्राप्त कर सकता हूं? मुझे delete --purge का उपयोग किए बिना गैर-अंतःक्रियात्मक रूप से तैनात करने में सक्षम होना चाहिए, भले ही पिछला प्रयास विफल हो गया हो।

भविष्य की योजनाओं के लिए, यह वह व्यवहार है जिसकी मुझे मूल रूप से upgrade --install से उम्मीद

• अगर कोई पिछली स्थापना नहीं की गई थी तो स्थापित करें
• पहले से सफल इंस्टॉलेशन को अपग्रेड करें
• पहले विफल इंस्टालेशन को बदलें
• यदि स्थापना विफल हो जाती है, तो पुराने संसाधन अभी भी यथावत होने चाहिए, जहाँ संभव हो, बिना किसी डाउनटाइम के
• कोई विनाशकारी ऑप्स नहीं (जैसे कि ऊपर वर्णित स्वचालित delete --purge )

मेरी व्यक्तिगत राय में, इस व्यवहार के लिए किसी अतिरिक्त झंडे की आवश्यकता नहीं होनी चाहिए। इस प्रकार पैकेज प्रबंधक आमतौर पर व्यवहार करते हैं। जब तक मैं आवश्यकताओं को गलत नहीं समझता, मुझे नहीं लगता कि --force ध्वज, उदाहरण के लिए, आवश्यक है।

क्या इस संबंध में कोई अपडेट आया है? अगर कुछ विफल हो जाता है, तो बिना पर्ज चलाए मौजूदा इंस्टॉलेशन पर मज़बूती से अपग्रेड चलाने का सही तरीका क्या है?

@MythicManiac FWIW:
इस व्यवहार के कारण मैंने अभी भी हमारी टीमों को v2.7.0 पर पिन किया है।
ऐसा लगता है कि संसाधनों को अपग्रेड करने और हटाने में हमें कोई समस्या नहीं है जब उन्हें इस संस्करण के साथ helm upgrade --install का उपयोग करना चाहिए।

हमें भी यह समस्या है। यह बहुत कष्टप्रद है कि मुझे K8s सेवाओं और संबंधित AWS ELBs को हटाने की आवश्यकता है क्योंकि हेल्म has no deployed releases । पैकेज मैनेजर बहुत अच्छा है लेकिन इस समस्या से प्रोडक्शन डाउनटाइम हो जाता है जो अच्छा नहीं है।

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

शुक्र, 5 अक्टूबर 2018 को, 18:13 यूजीन ग्लोतोव, नोटिफिकेशन @github.com ने लिखा:

हमें भी यह समस्या है। यह बहुत कष्टप्रद है कि मुझे K8s को हटाना होगा
services और संबंधित AWS ELBs क्योंकि हेलम के पास कोई परिनियोजित रिलीज़ नहीं है।
पैकेज मैनेजर बहुत अच्छा है लेकिन यह समस्या उत्पादन डाउनटाइम की ओर ले जाती है जो
यह अच्छा नहीं है क्या।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/helm/helm/issues/3208#issuecomment-427436187 , या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/AAEo8_pISzHFAuOz6Lsv5EjrFaEo_HkYks5uh5M7gaJpZM4Qtexz
.

@tcolgate , धन्यवाद! मैंने आपके समाधान के साथ एक और समस्या (https://github.com/helm/helm/issues/2426#issuecomment-427388715) को ठीक किया है और जब मैं अगले सप्ताह मौजूदा संसाधनों पर एक नया चार्ट तैनात कर रहा हूं, तो मौजूदा ईएलबी के लिए इसका परीक्षण करने का प्रयास करूंगा। .

मूल विफल रिलीज़ में रोलबैक करना काम कर सकता है।

@tcolgate , मैंने अभी परीक्षण किया है और नहीं, यह पहली तैनाती के मामले में काम नहीं करता है।

$ helm upgrade --wait --timeout 900 --install myproject charts/myproject/myproject-1.1.1.tgz
14:53:18 Release "myproject" does not exist. Installing it now.
14:53:18 Error: release myproject failed: deployments.apps "myproject" already exists

$ helm list
NAME            REVISION    UPDATED                     STATUS      CHART               APP VERSION NAMESPACE
myproject       1           Mon Oct  8 11:53:18 2018    FAILED      myproject-1.1.1                 default

$ helm rollback myproject 1
Error: "myproject" has no deployed releases

मैं उत्सुक हूं, अगर हेल्म मौजूदा संसाधनों पर चार्ट को तैनात नहीं कर सकता है तो क्यों helm delete इन संसाधनों को हटाने का कारण बनता है?

@ thomastaylor312 , हमने इस मुद्दे का सामना किया ~ साथ ही साथ https://github.com/helm/helm/issues/2426~ (ऊपर: मुझे 2426 के लिए वास्तविक मूल कारण मिला) पतवार 2.11.0 के साथ। क्या आपको लगता है कि उन्हें फिर से खोलना चाहिए?

मुझे यह धागा Error: UPGRADE FAILED: "xxx-service" has no deployed releases बाद मिला
जबकि यह एक पतवार ls -a से दिखाई दे रहा था।

मैंने यह देखने का फैसला किया कि क्या यह गलत --सेट मान के कारण एक मुद्दा था, और --debug --dry-run --force वास्तव में अभी भी मेरे चल रहे पॉड को हटा दिया गया था ... मेरी अपेक्षा थी कि एक सूखी रन कार्रवाई कभी भी संशोधित नहीं होगी क्लस्टर संसाधन।

हालांकि इसने काम किया, और सेवा को बाद में फिर से तैनात किया जा सकता था, लेकिन हमने डाउनटाइम का अनुभव किया।

मेरी अपेक्षा यह थी कि ड्राई रन एक्शन कभी भी क्लस्टर संसाधनों को संशोधित नहीं करेगा।

यह एक उचित अपेक्षा है -- हमें ऐसा करना चाहिए... ऐसा न हो

मेरा मानना ​​​​है कि https://github.com/helm/helm/pull/4402 में पैच किया गया था, लेकिन यह अच्छा होगा अगर कोई जाँच करे। उसके लिए माफ़ करना!

2.11.0 . में अपग्रेड करने के बाद भी यही समस्या

क्रॉस पोस्ट:
https://github.com/reactiveops/reckoner/issues/48#issuecomment -453411283

यह बंद क्यों है? क्या अब हमारे पास इसे संभालने का कोई उचित तरीका है?

@gerbsen , हेल्म के वर्तमान संस्करणों के साथ इसके आसपास कोई रास्ता नहीं है जो विनाशकारी है।
हम अभी भी अपने संगठन में हर चीज के लिए हेल्म 2.7.0 का उपयोग करते हैं। यह एक बहुत पुराना संस्करण है जिसमें अन्य बग हैं, लेकिन इसमें यह समस्या नहीं है।

बस helm upgrade --install --force एक delete --purge और मुझे बताए बिना (रीसाइक्लिंग पर) मेरे पीवीसी/पीवी को नष्ट कर दिया। कई असफल रिलीज़ थे, इसलिए यह एक राज्य में था जो कुबेरनेट्स में चल रहा था, लेकिन हेल्म ने सोचा कि कोई रिलीज़ रिलीज़ नहीं थी। समय बिल्कुल भी अच्छा नहीं है।

@notque सभी ग्राफाना डैशबोर्ड को दो बार खोने के बाद मैंने किसी भी तरह के अपग्रेड करने से पहले बैकअप करना शुरू कर दिया है, इस तरह का जोखिम होने से पतवार का उपयोग करने के सभी लाभ दूर हो जाते हैं

जो लोग मदद मांग रहे हैं, उनके लिए हेलम को v.2.15.2 . में अपग्रेड करने के बाद यह समस्या मेरे लिए दूर हो गई थी

अभी भी इस मुद्दे को 2.16.0 पर देख रहे हैं

यह अभी भी बंद क्यों है? 2.16.1 अभी भी प्रभावित है

@ nick4fake मुझे लगता है कि यह https://github.com/helm/helm/issues/5595 का डुप्लिकेट है