हाय - क्या आप कुछ और विवरण दे सकते हैं कि आप कैसे तैनात कर रहे हैं? क्या आप किसी भी संयोग से helm upgrade --install का उपयोग कर रहे हैं? और यदि आप करते हैं, तो टूटने पर ( helm ls ) परिनियोजन की स्थिति क्या है - संभवतः यह Failed ?

यदि यह मामला है, एक helm delete --purge <deployment> चाल करना चाहिए।

reschex 18 अप्रैल 2019

👍15 👎8 ❤2

नमस्ते, गुम जानकारी के लिए खेद है।
हाँ, मैं helm upgrade --install का उपयोग कर रहा हूँ
और हाँ, तैनाती Failed हमेशा के लिए रहती है।
दुर्भाग्य से helm delete --purge <deployment> यहाँ एक विकल्प नहीं है। मैं सिर्फ इसलिए कि उत्पादन सेवाओं को हटा नहीं सकता :)

सवाल यह है कि हेल्म लगातार 3 विफलताओं के बाद ठीक क्यों नहीं हो सकता है।

sta-szek 18 अप्रैल 2019

👍2

छांटने का एकमात्र तरीका है कि रिलीज को हटाए बिना --force

rimusz 18 अप्रैल 2019

👍2

--force क्या? helm upgrade --install ?
और यदि हाँ, तो इसका मतलब है कि उपरोक्त मुद्दा वास्तव में अपेक्षित विशेषता है और हमें हर तैनाती के साथ --force उपयोग करना चाहिए? - यदि हाँ, तो इसका मतलब है कि वह जबरन टूटी हुई विज्ञप्ति को तैनात करेगा?

sta-szek 18 अप्रैल 2019

👍6 ❤1

हां, बिल्कुल helm upgrade --install :) का
और हाँ आपको हर तैनाती के साथ --force उपयोग करना चाहिए

rimusz 18 अप्रैल 2019

👍2

क्या इसका मतलब यह है कि --force टूटी हुई रिलीज़ को जबरन जारी करेंगे? - मेरा मतलब है, अगर फली टूट जाएगी और हर समय फिर से चालू हो जाएगी, तो क्या यह पुरानी फली को हटा देगा और नए शेड्यूल करेगा?
--force force resource update through delete/recreate if needed
delete स्थिति क्या है? क्या आप यह बता सकते हैं कि यह कैसे काम करता है? इस तरह के महत्वपूर्ण झंडे के लिए वर्णन निश्चित रूप से बहुत छोटा है - मुझे उम्मीद है कि यह हूड के तहत हजारों चीजें करता है।

BTW मैं वास्तव में हटाए गए उत्पादन सेवाओं के साथ समाप्त नहीं करना चाहता हूं, इसलिए --force ध्वज मेरे लिए एक विकल्प नहीं है।

और क्या आप वास्तव में सोचते हैं कि यह कोई मुद्दा नहीं है?
यहां तक कि त्रुटि संदेश गलत है:
app-name has no deployed releases
जिसमें कहा गया है कि कोई भी जारी विज्ञप्ति नहीं है
जबकि वहाँ है, लेकिन राज्य के साथ Failed और पतवार भी इसे ठीक करने की कोशिश नहीं करता है :( - फिक्सिंग से मेरा मतलब है कि कृपया इसे शुरू करने के बजाय, इसे तैनात करने का प्रयास करें।

sta-szek 18 अप्रैल 2019

👍23

Https://github.com/helm/helm/issues/3208 देखें

AmazingTurtle 14 मई 2019

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

bappr 8 नव॰ 2019

👍36 😕2 👀1

यह "स्थिति" को हटाकर तय किया जा सकता है: "तैनात", भंडारण में

देखें: https://github.com/helm/helm/pull/6933/commits/638229c3d3646e78d0fd5157309f8aeadfd01af1

जब मेरे पास समय होगा तो मैं अनुरोध को ठीक कर दूंगा।

johannges 12 नव॰ 2019

👎2 👀1 👍1

मूल रूप से कोड सही था। हेल्म के साथ नवीनतम परिणामों को खोजने के लिए status: deployed को हटाकर, अपग्रेड करने के लिए नवीनतम रिलीज़ ढूंढने की, भले ही यह वर्तमान में जिस राज्य में अनपेक्षित परिणाम हो सकता है। यह समस्या को अस्थायी रूप से दूर करता है, लेकिन यह सड़क के नीचे बहुत बड़े मुद्दों का परिचय देता है।

यदि आप इस बग को हिट करते समय helm history का आउटपुट प्रदान कर सकते हैं, तो यह उपयोगी होगा। यह निर्धारित करने के लिए अधिक उपयोगी है कि कोई ऐसे मामले में कैसे समाप्त होता है जहां रिलीज लेज़र की "तैनात" स्थिति में कोई रिलीज़ नहीं है।

bacongobbler 12 नव॰ 2019

जब मैं पहली बार किसी नए क्लस्टर के लिए परिनियोजित कर रहा हूं तो यह समस्या आ रही है। क्या मुझे --force भी उपयोग करना चाहिए?

bastoche 19 नव॰ 2019

मुझे इस मुद्दे का सामना करना पड़ा जब मैंने --purge विकल्प का उपयोग किए बिना पिछली रिलीज़ को हटा दिया।

helm delete --purge <release-name>

हेल्म संस्करण

Client: &version.Version{SemVer:"v2.15.X"}
Server: &version.Version{SemVer:"v2.15.X"}

japzio 25 नव॰ 2019

👍1

मैं इस मुद्दे का सामना भी कर रहा हूं।

tomaustin700 26 नव॰ 2019

@bacongobbler
मैंने यह हेल्म 3 से मारा। ऐसा होने पर इतिहास पूरी तरह से खाली है, हालांकि प्रयास 1 के बाद से टूटे हुए k8 संसाधन हैं।

प्रजनन वास्तव में आसान लगता है:

पतवार उन्नयन - "एक फली के साथ कुछ है जिसमें एक कंटेनर है जो त्रुटि के साथ बाहर निकलता है"
सही क्या कंटेनर के बाहर निकलने का कारण है, जैसे कंटेनर के अंदर निष्पादन योग्य के लिए अमान्य arg के साथ मान, और फिर से प्रयास करें
-> त्रुटि: UPGRADE विफल: "फू" में कोई भी रिलीज़ रिलीज़ नहीं है

henrikb123 2 दिस॰ 2019

👍9

लगता है - परमाणु ध्वज मेरे (CI / CD) परिदृश्य में आगे का रास्ता हो सकता है। चूंकि यह प्रारंभिक असफलता को पूरी तरह से बाहर निकाल देता है, जैसे कि यह कभी नहीं हुआ, मैं अगले प्रयास में इस मुद्दे को नहीं मारता।

henrikb123 3 दिस॰ 2019

👍5

यहाँ, मैं नहीं देखता कि कैसे delete या --force का उपयोग करने की सलाह दी जा सकती है, विशेष रूप से जब लगातार मात्राएँ होती हैं, तो मैंने पहले से ही सभी ग्राफ्टाना डैशबोर्ड खो दिए हैं, क्योंकि एक बार ऐसा नहीं करना यह फिर से :)

अपडेट: मेरे मामले में btw क्योंकि रिलीज विफल हो रही है:

Upgrade "grafana" failed: cannot patch "grafana" with kind PersistentVolumeClaim: PersistentVolumeClaim "grafana" is invalid: spec: Forbidden: is immutable after creation except resources.requests for bound claims

भले ही मैंने ग्राफ्टाना मूल्यों में कुछ भी नहीं बदला है

alex88 10 दिस॰ 2019

@ alex88 क्या आप helm history से आउटपुट प्रदान कर सकते हैं? मुझे यह जानने की जरूरत है कि अन्य लोग इस मामले को किस तरह से मार रहे हैं, इसलिए हम मूल कारण को खत्म करने और इसका समाधान खोजने की कोशिश कर सकते हैं।

bacongobbler 10 दिस॰ 2019

@bacongobbler यकीन है कि मैं वास्तव में इस निश्चित रूप से देखना पसंद करूंगा क्योंकि मैं एक दो बार लगातार संस्करणों को खो देने के कारण पतवार का उपयोग करने के लिए वास्तव में सतर्क हूं (शायद मेरी गलती थी)

REVISION    UPDATED                     STATUS  CHART           APP VERSION DESCRIPTION
4           Wed Dec  4 02:45:59 2019    failed  grafana-4.1.0   6.5.0       Upgrade "grafana" failed: cannot patch "grafana" with kind PersistentVolumeClaim: PersistentVolumeClaim "grafana" is invalid: spec: Forbidden: is immutable after creation except resources.requests for bound claims
5           Mon Dec  9 12:27:22 2019    failed  grafana-4.1.0   6.5.0       Upgrade "grafana" failed: cannot patch "grafana" with kind PersistentVolumeClaim: PersistentVolumeClaim "grafana" is invalid: spec: Forbidden: is immutable after creation except resources.requests for bound claims
6           Mon Dec  9 12:33:54 2019    failed  grafana-4.1.0   6.5.0       Upgrade "grafana" failed: cannot patch "grafana" with kind PersistentVolumeClaim: PersistentVolumeClaim "grafana" is invalid: spec: Forbidden: is immutable after creation except resources.requests for bound claims
7           Mon Dec  9 12:36:02 2019    failed  grafana-4.1.0   6.5.0       Upgrade "grafana" failed: cannot patch "grafana" with kind PersistentVolumeClaim: PersistentVolumeClaim "grafana" is invalid: spec: Forbidden: is immutable after creation except resources.requests for bound claims
8           Mon Dec  9 13:06:55 2019    failed  grafana-4.1.0   6.5.0       Upgrade "grafana" failed: cannot patch "grafana" with kind PersistentVolumeClaim: PersistentVolumeClaim "grafana" is invalid: spec: Forbidden: is immutable after creation except resources.requests for bound claims
9           Mon Dec  9 13:38:19 2019    failed  grafana-4.1.0   6.5.0       Upgrade "grafana" failed: cannot patch "grafana" with kind PersistentVolumeClaim: PersistentVolumeClaim "grafana" is invalid: spec: Forbidden: is immutable after creation except resources.requests for bound claims
10          Mon Dec  9 13:38:51 2019    failed  grafana-4.1.0   6.5.0       Upgrade "grafana" failed: cannot patch "grafana" with kind PersistentVolumeClaim: PersistentVolumeClaim "grafana" is invalid: spec: Forbidden: is immutable after creation except resources.requests for bound claims
11          Mon Dec  9 13:41:30 2019    failed  grafana-4.1.0   6.5.0       Upgrade "grafana" failed: cannot patch "grafana" with kind PersistentVolumeClaim: PersistentVolumeClaim "grafana" is invalid: spec: Forbidden: is immutable after creation except resources.requests for bound claims
12          Mon Dec  9 13:56:01 2019    failed  grafana-4.1.0   6.5.0       Upgrade "grafana" failed: cannot patch "grafana" with kind PersistentVolumeClaim: PersistentVolumeClaim "grafana" is invalid: spec: Forbidden: is immutable after creation except resources.requests for bound claims
13          Mon Dec  9 15:15:05 2019    failed  grafana-4.1.0   6.5.0       Upgrade "grafana" failed: cannot patch "grafana" with kind PersistentVolumeClaim: PersistentVolumeClaim "grafana" is invalid: spec: Forbidden: is immutable after creation except resources.requests for bound claims

मूल रूप से मैंने कुछ env वैरिएबल्स को बदलने के लिए अपग्रेड को चलाने के लिए कई बार कोशिश की है और जब से वहाँ पर तैनाती की त्रुटि हुई तब तक env वैरिएबल वैसे भी बदलते रहे जब तक मैं ऐसा नहीं कर पाया वह त्रुटि को अनदेखा करता रहा

alex88 10 दिस॰ 2019

आप उस राज्य में कैसे गए जहां हर रिलीज़ विफल रही है? 1, 2, और 3 की रिलीज़ कहां है?

bacongobbler 10 दिस॰ 2019

आप उस राज्य में कैसे गए जहां हर रिलीज़ विफल रही है? 1, 2, और 3 की रिलीज़ कहां है?

बदलते एनवी चर (कई बदलाव करने थे) और हर बार अपग्रेड को चलाने के दौरान, यह एनवी वैरिएबल्स को बदल रहा था, लेकिन मुझे इस बात का कोई पता नहीं था कि लगातार वॉल्यूम की त्रुटि को कैसे ठीक किया जाए

अद्यतन: btw मैं उपयोग कर रहा हूँ

version.BuildInfo{Version:"v3.0.0", GitCommit:"e29ce2a54e96cd02ccfce88bee4f58bb6e2a28b6", GitTreeState:"clean", GoVersion:"go1.13.4"}

पिछले रिलीज के बारे में शायद पतवार उनमें से केवल 10 रखता है

alex88 10 दिस॰ 2019

Helm3: मैं istio को अपग्रेड करते समय इसी तरह की समस्या आ रही है, रिलीज़ विफल रही, अब मैं इसे फिर से तैयार नहीं कर सकता, भले ही टेम्प्लेट में एक छोटी सी त्रुटि तय हो। मैं प्रोडक्शन रिलीज़ को नहीं हटा सकता क्योंकि यह भी संबंधित ईएलबी को आईएसटीओ-इनग्रेस सेवा से हटा देगा।

ajitchahal 16 दिस॰ 2019

क्या कोई भविष्य का काम तर्क को बदलने के लिए है जब प्रारंभिक रिलीज विफल स्थिति में समाप्त हो जाती है?

HamzaZo 17 दिस॰ 2019

👍17

अगर डाउनटाइम स्वीकार नहीं किया जाता है तो मुझे क्या करना होगा?

% helm upgrade prometheus-thanos --namespace metrics -f values.yaml . 
Error: UPGRADE FAILED: "prometheus-thanos" has no deployed releases
% helm install --atomic prometheus-thanos --namespace metrics -f values.yaml .                                                                                                               
Error: cannot re-use a name that is still in use
% helm version
version.BuildInfo{Version:"v3.0.1", GitCommit:"7c22ef9ce89e0ebeb7125ba2ebf7d421f3e82ffa", GitTreeState:"clean", GoVersion:"go1.13.4"}

com30n 2 जन॰ 2020

अगर डाउनटाइम स्वीकार नहीं किया जाता है तो मुझे क्या करना होगा?

अभी के लिए मैं सिर्फ टेम्पलेट्स बनाने के लिए पतवार का उपयोग करता हूं और मैं स्वयं उन्हें स्थानीय रूप से सहेजता हूं और लागू करता हूं

alex88 3 जन॰ 2020

लगता है - परमाणु ध्वज मेरे (CI / CD) परिदृश्य में आगे का रास्ता हो सकता है। चूंकि यह प्रारंभिक असफलता को पूरी तरह से बाहर निकाल देता है, जैसे कि यह कभी नहीं हुआ, मैं अगले प्रयास में इस मुद्दे को नहीं मारता।

@ henrikb123 ऊपर काम करता है केवल यदि आप allways इस्तेमाल किया --atomic झंडा। अन्यथा यह काम नहीं करेगा। उदाहरण के लिए: इसके बिना एक टूटे चार्ट को स्थापित करने का प्रयास करें और वे --atomic ध्वज के साथ एक ही कमांड चलाते हैं। यह टूट जाएगा। FYI करें मैं नवीनतम Helm संस्करण का उपयोग कर रहा हूं -> 3.0.2

@ alex88 क्या आप पतवार इतिहास से आउटपुट प्रदान कर सकते हैं? मुझे यह जानने की जरूरत है कि अन्य लोग इस मामले को किस तरह से मार रहे हैं, इसलिए हम मूल कारण को खत्म करने और इसका समाधान खोजने की कोशिश कर सकते हैं।

@bacongobbler @ henrikb123 ने समस्या का अनुकरण करने के लिए यहाँ क्या क्यों नहीं किया? जैसा कि @ henrikb123 ने बताया, इतिहास पूरी तरह से खाली है । मैं इसकी पुष्टि कर सकता हूं। कृपया देख लें:

$ helm upgrade --install --cleanup-on-fail --reset-values --force --namespace teleport --values values.test.yaml teleport ./
Release "teleport" does not exist. Installing it now.
Error: Secret "teleport-secrets" is invalid: metadata.labels: Invalid value: "helm.sh/chart:teleport-1.0.0app.kubernetes.io/managed-by": a qualified name must consist of alphanumeric characters, '-', '_' or '.', and must start and end with an alphanumeric character (e.g. 'MyName',  or 'my.name',  or '123-abc', regex used for validation is '([A-Za-z0-9][-A-Za-z0-9_.]*)?[A-Za-z0-9]') with an optional DNS subdomain prefix and '/' (e.g. 'example.com/MyName')

$ helm history teleport
Error: release: not found

$ helm upgrade --install --cleanup-on-fail --reset-values --force --namespace teleport --values values.test.yaml teleport ./
Error: UPGRADE FAILED: "teleport" has no deployed releases

galindro 14 जन॰ 2020

👍3

मैं भी इस्तियो के साथ इस में भाग गया।

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

(यह है कि आप एक सर्व-विफल रिलीज़ स्थिति में कैसे आ सकते हैं, क्योंकि उस बारे में एक सवाल था।)

REVISION    UPDATED                     STATUS  CHART       APP VERSION DESCRIPTION                                                                                                                                                                                                         
10          Tue Jan 14 09:17:00 2020    failed  istio-1.4.3 1.4.3       Upgrade "istio" failed: post-upgrade hooks failed: timed out waiting for the condition
11          Tue Jan 14 09:22:21 2020    failed  istio-1.4.3 1.4.3       Upgrade "istio" failed: post-upgrade hooks failed: warning: Hook post-upgrade istio/charts/security/templates/create-custom-resources-job.yaml failed: jobs.batch "istio-security-post-install-1.4.3" already exists
12          Tue Jan 14 09:23:10 2020    failed  istio-1.4.3 1.4.3       Upgrade "istio" failed: post-upgrade hooks failed: warning: Hook post-upgrade istio/charts/security/templates/create-custom-resources-job.yaml failed: jobs.batch "istio-security-post-install-1.4.3" already exists
13          Tue Jan 14 09:25:58 2020    failed  istio-1.4.3 1.4.3       Upgrade "istio" failed: post-upgrade hooks failed: timed out waiting for the condition 
14          Tue Jan 14 09:35:21 2020    failed  istio-1.4.3 1.4.3       Upgrade "istio" failed: post-upgrade hooks failed: warning: Hook post-upgrade istio/charts/security/templates/create-custom-resources-job.yaml failed: jobs.batch "istio-security-post-install-1.4.3" already exists
15          Tue Jan 14 09:38:08 2020    failed  istio-1.4.3 1.4.3       Upgrade "istio" failed: post-upgrade hooks failed: timed out waiting for the condition 
16          Tue Jan 14 14:02:47 2020    failed  istio-1.4.3 1.4.3       Upgrade "istio" failed: post-upgrade hooks failed: timed out waiting for the condition
17          Tue Jan 14 14:19:44 2020    failed  istio-1.4.3 1.4.3       Upgrade "istio" failed: post-upgrade hooks failed: timed out waiting for the condition
18          Tue Jan 14 14:33:36 2020    failed  istio-1.4.3 1.4.3       Upgrade "istio" failed: post-upgrade hooks failed: warning: Hook post-upgrade istio/charts/security/templates/create-custom-resources-job.yaml failed: jobs.batch "istio-security-post-install-1.4.3" already exists
19          Tue Jan 14 14:36:59 2020    failed  istio-1.4.3 1.4.3       Upgrade "istio" failed: post-upgrade hooks failed: timed out waiting for the condition

यह हेल्म 3.0.2 के साथ है।

tillig 15 जन॰ 2020

IMO यह एक महत्वपूर्ण समस्या है जिसे ठीक करने की आवश्यकता है। मैंने कई अन्य समान मुद्दों को देखा जो कि संस्करण 2 के बाद से इसी समस्या के लिए खुले थे और अब लगता है कि इसे ठीक नहीं किया गया है।

मैं सिर्फ डेवलपर्स से इस समस्या का अनुकरण करने के लिए उनकी टिप्पणी पर @ henrikb123 ने ठीक वही करने के लिए कहा है। इसका अनुकरण करने का एक बहुत ही सरल तरीका है। आप इसे किसी भी हेल्म संस्करण (2.xx और 3.xx) के साथ जांच सकते हैं। मुझे लगभग यकीन है कि यह उन सभी के साथ घटित होगा।

शायद --atomic एक कठिन आवश्यकता होनी चाहिए (कमांड लाइन तर्क नहीं)। यह --cleanup-on-fail रूप में भी काफी बेमानी है। अंतर यह है कि --cleanup-on-fail ने इस समस्या को --atomic तरह ठीक नहीं किया है।

galindro 15 जन॰ 2020

👍10

हमने उत्पादन में भी इसका सामना किया है और डाउनटाइम एक विकल्प नहीं है। हमने केवल नवीनतम FAILED कॉन्फ़िगरमैप को पैच करके एक वर्कअराउंड पाया इसके बजाय एक कमांड का उपयोग करके STATUS: DEPLOYED ।

kubectl -n kube-system patch configmap app-name.v123 --type=merge -p '{"metadata":{"labels":{"STATUS":"DEPLOYED"}}}'

हमारे मामले में, हमें यकीन था कि अंतिम विफल संशोधन वास्तव में kubernetes द्वारा सफलतापूर्वक तैनात किया गया था।

हम इस अवस्था में कैसे आए?

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

विशेष रूप से, हम हेल्म 2 का उपयोग कर रहे हैं और हम टिलर-परिनियोजन पर TILLER_HISTORY_MAX=20 सेट करते हैं। हम अपने सभी रोलिंग अपग्रेड के लिए helm upgrade --wait --timeout 1080 का उपयोग कर रहे थे जो समय के साथ अधिक समय ले रहे थे। तब हेल्म अपग्रेड टाइम-आउट होने लगे लेकिन किसी को भी चिंता नहीं हुई (सिर्फ नाराज थे) क्योंकि कुबेरनेट्स अभी भी सफलतापूर्वक संशोधन कर रहे थे। 20 अपग्रेड के बाद (आज) समय समाप्त हो गया, तो हम चिंतित थे क्योंकि हम अब तैनात नहीं कर सकते थे क्योंकि इसके बजाय हम app-name has no deployed releases देख रहे थे।

पैच काम क्यों करता है?

हमें पता चला कि हमें विन्यास में STATUS लेबल को पैच करने की आवश्यकता है क्योंकि हमें एहसास हुआ कि हेल्म शायद एक समान अनुरोध का उपयोग करके कॉन्फ़िगरमैप का अनुरोध कर रहा था ...

kubectl -n kube-system get configmap -l NAME=app-name,STATUS=DEPLOYED

सुराग तब मिला जब हमने configmap yaml देखा और निम्नलिखित लेबल देखे ...

$ kubectl -n kube-system describe configmap app-name.v123
Name:         app-name.v123
Namespace:    kube-system
Labels:       MODIFIED_AT=1579154404
              NAME=app-name
              OWNER=TILLER
              STATUS=FAILED
              VERSION=123
Annotations:  <none>
Data
====
release:
----
H4sIAAAAAAAC...snipped...

और यह https://github.com/helm/helm/issues/5595#issuecomment -55543436 के अनुरूप है

carlosdoordash 16 जन॰ 2020

👍7

@bacongobbler यह सोचने के बजाय कि आप एक विफल स्थिति में कैसे

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

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

आपको क्वेरी से status: deployed निकालने का विचार पसंद नहीं आया। तो क्या एक नया लेबल जोड़ने के बारे में जो वास्तव में नवीनतम रिलीज को चिह्नित करता है, भले ही इसकी स्थिति तैनात या विफल रही हो? यह वास्तव में समझ में आता है। क्योंकि यही आप करना चाहते हैं, आप नवीनतम रिलीज को अपग्रेड से प्राप्त करना चाहते हैं। और अगर कोई नहीं है, तो आपको शायद इसके बजाय विफल रिलीज़ के लिए जांच करनी चाहिए। या बस एक नए लेबल का उपयोग करें जो सीधे नवीनतम को चिह्नित करता है।

इस पर आपकी राय सुनने के लिए मैं उत्साहित हूं ।_

AmazingTurtle 16 जन॰ 2020

👍1

परफेक्ट कॉलेक्शन @AmazingTurtle।

galindro 19 जन॰ 2020

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

मेरा मानना है कि इस मामले में सीएलआई उपयोगकर्ताओं के लिए केवल वर्कअराउंड रहस्य ड्राइवर का उपयोग करने पर रिलीज़ ट्रैकिंग रहस्य को हटाना है, साथ ही साथ सभी संसाधन जो अंतिम रिलीज़ (हेलम के संसाधन स्वामित्व जांच में चलने से बचने के लिए) बनाए गए थे।

यह एक उपकरण से एक वास्तविक कार्य है जिसे मैंने आंतरिक रूप से इस मुद्दे को संभालने के लिए लिखा है जब यह फसल करता है:

package foo

import (
    "helm.sh/helm/v3/pkg/action"
    "helm.sh/helm/v3/pkg/release"
    "helm.sh/helm/v3/pkg/storage/driver"
)

// DangerouslyApplyRelease allows installing or upgrading any release from a failed state,
// but does not enforce Helm's standard resource ownership checks.
func DangerouslyApplyRelease(cfg *action.Configuration, rel *release.Release) error {
    // Forcibly mark the last release as successful and increment the version
    rel.Info = &release.Info{
        Status: release.StatusDeployed,
    }
    rel.Version++

    var err error

    // Attempt to create the release
    err = cfg.Releases.Create(rel)

    // If release already exists, update it
    if err == driver.ErrReleaseExists {
        err = cfg.Releases.Update(rel)
    }

    return err
}

jlegrone 23 जन॰ 2020

👍1

@jlegrone helm delete --purge (v2) या helm uninstall (v3) भी काम करेंगे, क्योंकि वे सभी विफल रिलीज़ हैं?

hickeyma 24 जन॰ 2020

@Jlegrone ने जो बताया वह सच है।
@ हिक्कीमा आपका प्रस्ताव एक समाधान है जो काम कर सकता है। लेकिन, मुझे एक निश्चित समाधान चाहिए।

galindro 24 जन॰ 2020

यह पिछले 2 साल के लिए हार्मफुल बग है और पतवार इसे ठीक करने वाली नहीं है
अधिकांश उत्पादन मामलों में helm delete स्वीकार्य नहीं है
helm3 के साथ हम kubectl edit secret sh.helm.release.... नहीं कर सकते क्योंकि यह एन्क्रिप्टेड है
helm rollback <latest-successful> केवल सही समाधान है

इसलिए यदि आपके पास डिफ़ॉल्ट HISTORY_MAX = 10 है और आपने काम करने के लिए 10 बार कोशिश की है - आप पूरी तरह से खो गए हैं ...

और अगर आपके पास इंस्टॉल बनाम अपग्रेड पर कुछ तर्क हैं, तो आप sh.helm.release ..... v * रहस्य नहीं हटा सकते

पतवार को मरना चाहिए या इसे ठीक करना चाहिए

kosta709 30 जन॰ 2020

👍4

वर्कअराउंड मिला
helm3 अपने रहस्यों पर लेबल सेट करता है:
kubectl get secrets --show-labels | grep sh.helm.release.v1

....
sh.helm.release.v1.helm-must-die.v34                 helm.sh/release.v1                    1         13h       modifiedAt=1580326073,name=helm-must-die,owner=helm,status=failed,version=34
sh.helm.release.v1.helm-must-die.v35                 helm.sh/release.v1                    1         13h       modifiedAt=1580326228,name=helm-must-die,owner=helm,status=failed,version=35
sh.helm.release.v1.helm-must-die.v36                 helm.sh/release.v1                    1         1h        modifiedAt=1580370043,name=helm-must-die,owner=helm,status=failed,version=36
...

इसलिए नवीनतम kubectl edit secret sh.helm.release.v1.helm-must-die.v36 और सेट लेबल स्थिति = परिनियोजित करें
और इससे पहले रिलीज़ होने के लिए (v35) लेबल की स्थिति निर्धारित करें

अगले helm upgrade --install ... काम करेंगे

kosta709 30 जन॰ 2020

👍9 ❤1

@ kosta709 हेल्म 2 के लिए मेरी खोज के समान है, जो सभी कैपस वाले लेबल के साथ क्यूब-सिस्टम नेमस्पेस में कॉन्फिगरमैप के रूप में रिलीज़ करता है, हेल्म 3 अब उन एप्लिकेशन के नेमस्पेस में सीक्रेट्स के रूप में रिलीज़ करता है जो सभी लोअरकेस हैं।

तो Helm3 के लिए, आप बस थोड़ा अलग kubectl पैच कमांड का उपयोग कर सकते हैं ...

kubectl -n app-namespace patch secret app-name.v123 --type=merge -p '{"metadata":{"labels":{"status":"deployed"}}}'

carlosdoordash 30 जन॰ 2020

👍4

काश, हमें इन वर्कअराउंड पर चर्चा नहीं करनी होती। उत्पाद में इसे ठीक करना सर्वोच्च प्राथमिकता होनी चाहिए। यह कितना बुरा है इसकी याद दिलाते हैं (वर्कअराउंड की उपेक्षा):

यदि कोई रिलीज़ पहली बार परिनियोजित की गई थी, या यदि पर्याप्त रिलीज़ इतिहास से अंतिम सफलता को घुमाने में विफल रही, तो मैन्युअल नियमन के बिना रिलीज़ को ठीक नहीं किया जा सकता है।

निरंतर तैनाती पाइपलाइन से हेल्म का उपयोग संभवतः एक सामान्य पैटर्न है या कम से कम एक वांछित है, यह व्यावहारिक नहीं है।

henrikb123 31 जन॰ 2020

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

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

carlosdoordash 31 जन॰ 2020

👍3

यह पतवार के पुराने संस्करणों पर मेरे लिए कोई समस्या नहीं थी, और कोई भी निष्फल तैनाती नहीं है, कुबेकलेट चल रही सेवाओं को दिखा रहा है और सब कुछ काम कर रहा है।

अब मैं बस helm upgrade -f app.yaml --namespace prometheus prometheus prometheus चलाने की कोशिश कर रहा हूं और मुझे बस त्रुटि मिलती है: Error: UPGRADE FAILED: "prometheus" has no deployed releases लेकिन मैं आसपास के किसी भी काम की कोशिश नहीं कर सकता क्योंकि यह उत्पादों में है ...

zrsm 3 फ़र॰ 2020

@zrsm अब हम जो कुछ भी कर रहे हैं वह yml फ़ाइलों को helm का उपयोग करके और kubectl diff / dry-run का उपयोग करके मैन्युअल रूप से लागू करने से पहले परिवर्तनों का पूर्वावलोकन करने के लिए उत्पन्न कर रहा है।

alex88 3 फ़र॰ 2020

👍1

@zrsm अब हम जो कुछ भी कर रहे हैं वह yml फ़ाइलों को helm का उपयोग करके और kubectl diff / dry-run का उपयोग करके मैन्युअल रूप से लागू करने से पहले परिवर्तनों का पूर्वावलोकन करने के लिए उत्पन्न कर रहा है।

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

zrsm 5 फ़र॰ 2020

नमस्ते वहाँ, इसलिए मैंने इसे बाहर का परीक्षण किया ... और मेरी पिछली ~ / .helm को हटाने के बाद निम्न कमांड का प्रदर्शन करने की तरह लगता है / इसे हल किया ...

helm init --service-account tiller --override spec.selector.matchLabels.'name'='tiller',spec.selector.matchLabels.'app'='helm' --output yaml | sed 's<strong i="6">@apiVersion</strong>: extensions/v1beta1<strong i="7">@apiVersion</strong>: apps/v1@' | kubectl apply -f -

मैं सोच रहा हूं कि यदि आप एक नया हेलम संस्करण स्थापित करते हैं और आपका सर्विसकाउंट सामान नहीं है (मैंने अपने लैपटॉप को मिटा दिया और कुछ बिंदु पर बहाल किया) तो ऐसा होता है और यह ठीक था। मुझे आशा है कि यह आपके लिए भी काम करता है।

zrsm 6 फ़र॰ 2020

यह बग हेल्म 3 में चल रहा है, क्या कोई नियोजित फिक्स है?

dudicoco 9 फ़र॰ 2020

👍33 👀6

टाइमआउट के कारण एक ताजा क्लस्टर और एक नई तैनाती के साथ इस मुद्दे में चल रहा है। मुझे इसे ठीक करने के लिए मैन्युअल रूप से हमारे क्लस्टर से कनेक्ट करना पसंद नहीं है, लेकिन मुझे लगता है कि अब यह एकमात्र विकल्प है।

क्या हम यह सुनिश्चित कर सकते हैं कि यह मुद्दा सुलझ जाए?

devedse 18 फ़र॰ 2020

यह मुद्दा इतना निराशाजनक है कि यह helm पूरी तरह से बंद करने का एक कारण है।

gretel 20 फ़र॰ 2020

😕4 👍2

मैं सहमत हूं। यह मुझे पागल कर देता है। मैं इसे ठीक करने पर काम करने जा रहा हूं। मुझे शुभकामनाएँ दें।

yinzara 21 फ़र॰ 2020

👍16 ❤11

मैं सहमत हूं। यह मुझे पागल कर देता है। मैं इसे ठीक करने पर काम करने जा रहा हूं। मुझे शुभकामनाएँ दें।

धन्यवाद और शुभकामनाएँ!

gretel 21 फ़र॰ 2020

मैं पीआर # 7653 को देखने के लिए आप में से कुछ पाने के लिए बुरा नहीं मानूंगा।

मुझे विश्वास है कि यह ऊपर वर्णित मुद्दों को हल करेगा।

yinzara 21 फ़र॰ 2020

विश्वास नहीं कर सकता कि यह अभी भी अनुरक्षकों से कोई प्रतिक्रिया के साथ खुला है

yarax 24 फ़र॰ 2020

👍8

cc @bacongobbler @mattfarina

HamzaZo 24 फ़र॰ 2020

क्या हेल्म डिलीट - अपर्ज (v2) या हेल्म अनइंस्टॉल (v3) का उपयोग करने से भी काम चलेगा, क्योंकि वे सभी रिलीज में विफल हैं?

@ हिक्की हमेशा नहीं; यह भी हेल्म रिलीज मेटाडाटा भ्रष्टाचार का परिणाम हो सकता है इसलिए कुछ मामलों में स्थापना रद्द करने से लोड के तहत संसाधनों को नष्ट किया जा सकता है।

jlegrone 26 फ़र॰ 2020

कभी-कभी रिलीज़ विफल नहीं होता है, लेकिन टाइमआउट और हेल्म इसे विफल करने के रूप में लेबल करता है, और अगली बार यह दिखाता है कि कोई तैनात रिलीज़ नहीं है, लेकिन ऐप वास्तव में पूरी तरह कार्यात्मक है, यह मेरे लिए कई बार हुआ, इसलिए मुझे रिलीज़ को बदलना पड़ा deployed एक पर लेबल। यह हमेशा helm delete --purge (v2) or helm uninstall (v3) करने का विकल्प नहीं है

rimusz 26 फ़र॰ 2020

👎2

@rimusz आप रिलीज़ लेबल कैसे बदल रहे हैं?

dudicoco 26 फ़र॰ 2020

हेल्म v3 नवीनतम रिलीज रहस्य को मैन्युअल रूप से संपादित करके @dudicoco , आप इसे स्वचालित कर सकते हैं और kubectl patch उपयोग कर सकते हैं

rimusz 26 फ़र॰ 2020

https://github.com/k14s/kapp पर चले गए हैं जो एक आकर्षण की तरह काम करता है।

gretel 26 फ़र॰ 2020

@rimusz यही मैंने सोचा है, धन्यवाद।

dudicoco 26 फ़र॰ 2020

मैंने भी अपने फिक्स को # 7668 में 2 के लिए ठीक कर दिया, लेकिन मुझे अभी भी # 7653 पर प्रतिक्रिया का इंतजार है

yinzara 26 फ़र॰ 2020

😕3

एक ही मुद्दा यहाँ,

--wait साथ तैनात रिलीज़ ने समय समाप्त कर दिया, और अंत में ऊपर और चल रहा है। यह अभी भी विफल के रूप में चिह्नित है।
और इसलिए, बाद में तैनाती भी विफल हो रही है।

इसका मतलब है कि रिलीज की स्थिति एक विश्वसनीय जानकारी नहीं है।

linkdd 3 मार्च 2020

हम उत्पादन में कई सेवाओं के लिए हमारी कंपनी में k8s का उपयोग करते हैं।
एक महीने में कुछ समय के लिए, हमें विभिन्न अनुप्रयोगों पर पतवार के साथ एक ही समस्या है (" * कोई तैनात रिलीज नहीं है।")।
हमने हेल्म के विभिन्न संस्करणों (2.7 से 3.0.3 तक) का उपयोग किया।
समस्या ठीक नहीं हुई है।
यह हमारे उपयोगकर्ताओं (क्लस्टर में एप्लिकेशन को लागू करने वाले डेवलपर्स) के लिए बहुत असुविधा का कारण बनता है
हर बार, जब हम इसे मारते हैं, तो हम केवल नवीनतम रिलीज़ सीक्रेट (तैनात करने की स्थिति) को पैच करते हैं।
क्या कोई व्यवहार जोड़ने की योजना है जो पिछली रिलीज़ स्थिति को अनदेखा करता है और नई रिलीज़ स्थापित करता है?

yuripastushenko 5 मार्च 2020

👍6

--history-max 10 (डिफ़ॉल्ट मान) पर सेट होने के बाद, पहली रिलीज़ सफल रही।
उसके बाद, अगले 10 रिलीज़ असफल रहे:
Error: UPGRADE FAILED: timed out waiting for the condition (यह नकली था, इस प्रकार अपेक्षित)।
उसके बाद, अगली (11 वीं असफल) रिलीज़ विफल रही:
Error: UPGRADE FAILED: "app" has no deployed releases (यही समस्या है!)

क्या यह संभव होगा कि हेल्म हमेशा 10 सबसे हालिया (जो भी उनकी स्थिति है) के अलावा, इतिहास में नवीनतम सफल रिलीज को संरक्षित करता है?

zkovac-devops 10 मार्च 2020

👍2

मुझे आइडिया पसंद है। भंडारण कार्यक्षमता को संशोधित करने की आवश्यकता होगी, लेकिन मुझे लगता है कि यह किया जा सकता है।

yinzara 10 मार्च 2020

https://github.com/helm/helm/pull/4978 Helm 2 के लिए विलय कर दिया गया था। शायद यह Helm 3 पर पोर्ट नहीं किया गया था। अगर किसी के पास समय है और वह इसे पोर्ट करना चाहता है, तो कृपया बेझिझक।

bacongobbler 10 मार्च 2020

मैंने # 7806 के साथ इसे हेल्म 3 में पोर्ट करने के लिए अपना हाथ आजमाया, और इसे ASAP में विलय करना पसंद करेगा। धन्यवाद, @ultimateboy!

yurrriq 25 मार्च 2020

👍2

उन रिलीज के बारे में क्या जो _first_ पर विफल होती हैं, अर्थात पिछले कोई सफल रिलीज नहीं हुई हैं?
हम हेल्म रिलीज की बेकार तैनाती के लिए upgrade --install का उपयोग कर रहे हैं और जब पहली रिलीज विफल हो जाती है, तो upgrade --install असफलता के सभी बाद के आक्रमणों में "कोई तैनात रिलीज" त्रुटि (यह मुद्दा) नहीं है।

krylovsk 25 मार्च 2020

👍18 👀1

"पहली रिलीज़ विफल होना" परिदृश्य कम से कम अधिक प्रबंधनीय है, क्योंकि आप आमतौर पर इसे मैन्युअल रूप से चलाते हैं या इसकी निगरानी करते हैं (और फिर एक फ़िक्स लागू कर सकते हैं) - जैसे कि एक CI / CD सिस्टम द्वारा हेल्म रन होने का विरोध किया गया है जो अभी एक को विफल करना शुरू करता है दिन और कोड ठीक करने के बाद भी ठीक नहीं होता है।

यह अभी भी निश्चित होना चाहिए।

केवल इस बग के कारण ही अंतिम सफल रिलीज़ को संरक्षित करने में भी मूल्य है। जैसे मान फ़ाइल, आदि के साथ डिबगिंग समस्याएँ

peterholak 25 मार्च 2020

👍1

@peterholak "पहली रिलीज़ असफल" परिदृश्य कभी-कभी CI / CD के साथ भी किया जाता है और उदाहरण के लिए - हमारे पास हमारे क्लस्टर तक पहुँच प्रतिबंधित है और हम "helm ls" भी नहीं बना सकते हैं, तो हम इसे "कैसे प्रबंधित करें"?

son4etyyy 1 अप्रैल 2020

👍4

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

javonclarke 7 अप्रैल 2020

👍2

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

एक स्वचालित तैनाती पाइपलाइन में पहली तैनाती लगभग हमेशा विफल हो जाएगी। इसके बाद की तैनाती को पहले प्रयास से अलग तरीके से ट्रिगर नहीं किया जाना चाहिए।

कृपया इस मुद्दे की प्राथमिकता को बढ़ाने पर विचार करें।

nemoo 7 अप्रैल 2020

👍9

अनुभव soooooooo बुरा है, हम बस पूरी रिलीज को हटा नहीं सकते, क्योंकि यह उत्पादन में है! यह सर्वर डाउनटाइम का कारण होगा! हम अंत में इस मुद्दे से कैसे निपट सकते हैं?

thetruechar 10 अप्रैल 2020

👍9 😄1

इसके अलावा, क्या कोई प्रश्न / समर्थन लेबल हटा सकता है? यह मुद्दा लापता प्रलेखन के बारे में नहीं है, बल्कि हेल्म के वर्तमान व्यवहार के बारे में है जो स्वचालित तैनाती पाइपलाइनों में उपयोग के लिए बहुत सहायक नहीं है।

nemoo 12 अप्रैल 2020

👍5

# 7806 PR को मास्टर में मर्ज कर दिया गया है। यह 3.2 में रिलीज होगी। मैं इस मुद्दे को तदनुसार बंद कर रहा हूं।

technosophos 14 अप्रैल 2020

🎉3 👍3

वाह् भई वाह! यह हेलम के साथ हमारे अधिकांश मुद्दों को हल करता है।

यदि पहली रिलीज़ विफल हो जाती है (तो अभी तक कोई भी रिलीज़ नहीं हुई है) वर्तमान व्यवहार क्या है?

Https://github.com/helm/helm/issues/3353 था जिसे https://github.com/helm/helm/pull/3597 द्वारा संबोधित किया गया था, लेकिन केवल जब --force का उपयोग किया जाता है।

--force पास हेल्म 3 में कुछ मुद्दे हैं (हालांकि https://github.com/helm/helm/issues/6378), इसे संबोधित करने के प्रस्ताव के साथ (https://github.com/helm/helm/ मुद्दों / 7082), साथ ही इस धागे में अन्य टिप्पणियों के रूप में, --force का उपयोग करना वैसे भी हमेशा उपयुक्त नहीं है। इसलिए पूरी स्थिति अभी भी कुछ स्पष्ट नहीं है।

peterholak 14 अप्रैल 2020

👍1

@technosophos फिक्स के लिए धन्यवाद। उत्सुक, जब 3.2 होगा। स्थापित करने के लिए उपलब्ध रिलीज? किसी मौजूदा विफल रिलीज़ पर app-name has no deployed releases त्रुटि प्राप्त करते रहें। और यह CI / CD पाइपलाइनों में अवरोधक है।

nareshnayini 14 अप्रैल 2020

@peterholak # 7913 देखें।

bacongobbler 14 अप्रैल 2020

👍1

3.2 16 अप्रैल को सार्वजनिक देव कॉल पर चर्चा की जाएगी। मैंने इसे केवल उन लोगों तक सीमित कर दिया है जो वर्तमान में दिखते हैं जैसे वे अभी तक लपेटे जा सकते हैं। फिर हम बीटा रिलीज़ प्रक्रिया शुरू करेंगे (यह सुनिश्चित करते हुए कि कॉल पर सभी सहमत हैं कल)।

technosophos 16 अप्रैल 2020

👍1

मैं कमांड का पालन करते हुए उल्लेखित मुद्दे को ठीक करने के लिए AKS के समाधान पर समान समस्या का सामना कर रहा था:

helm version : 3.1.2
मैं कमांड के साथ k8s क्लस्टर से पैकेज हटाता हूं
helm delete <release-name>

और समस्या को ठीक करने के लिए परिनियोजन चक्र चलाएँ

sachinmishra007 6 मई 2020

मुद्दा अभी भी 3.2.0 संस्करण में है

deimosfr 6 मई 2020

😕3

@deimosfr यह # 7653 में तय किया गया है जो 3.2.1 रिलीज में होगा। यह अभी तक जारी नहीं हुआ है, लेकिन यदि आप मास्टर बनाना चाहते हैं, तो आप इसे ठीक कर सकते हैं।

hickeyma 6 मई 2020

🎉2

मैं 3.2.1 पर हूं और यह अभी भी हो रहा है

VengefulAncient 22 मई 2020

👍1

अभी भी कारण हैं कि यह त्रुटि हो सकती है। 3.2.1 बस त्रुटि को दूर नहीं किया। इसने कुछ कारणों को दूर किया। यदि आप अभी भी इसका अनुभव कर रहे हैं, तो आपकी समस्या समस्या को ठीक करने के अलावा कुछ और है।

yinzara 22 मई 2020

@yzzara मैं एक ताजा क्लस्टर पर मूल विवरण से "पथ बी" का एक क्लासिक मामला है जिसमें कोई समस्या नहीं है। मैं इस त्रुटि को किसी अन्य क्लस्टर में भी पुन: उत्पन्न कर सकता हूं जहां Helm v2 ठीक काम करता है। हम निश्चित रूप से क्लासिक कर सकते हैं "यह कुछ और के कारण होता है, एक नया मुद्दा खोलें" नृत्य, लेकिन मुझे लगता है कि यह तेज होगा यदि यह बस मान्यता है कि यह वास्तव में तय नहीं है।

VengefulAncient 22 मई 2020

helm list का आउटपुट क्या है? पूर्व में जारी असफलता की "स्थिति" क्या है? हेल्म 2 में यह समस्या है और इसे बिल्कुल भी ठीक नहीं किया गया है इसलिए मुझे अभी भी लगता है कि आपका मुद्दा वह नहीं है जो आप सोचते हैं।

yinzara 22 मई 2020

अभी भी संस्करण 3.2.1 पर होता है।

यदि प्रारंभिक तैनाती 3 बार विफल हो जाती है तो यह सब अटक जाता है ... यदि आप चार्ट को नहीं हटाते हैं और एक अच्छा तैनात करते हैं तो इसे ठीक करने का कोई तरीका नहीं है।

विवरण:

helm history t3-mac -n t3                                                                                                                                                                 REVISION        UPDATED                         STATUS          CHART           APP VERSION     DESCRIPTION
1               Fri May 22 18:55:11 2020        failed          t3-mac-2.13.0   2.13.0          Release "t3-mac" failed: timed out waiting for the condition
2               Fri May 22 19:33:44 2020        failed          t3-mac-2.13.0   2.13.0          Upgrade "t3-mac" failed: timed out waiting for the condition
3               Fri May 22 19:57:51 2020        pending-upgrade t3-mac-2.13.0   2.13.0          Preparing upgrade

helm.exe upgrade --namespace t3b --install --force --wait t3b-mac t3b-mac-2.13.0.tgz
2020-05-22T18:14:01.7103689Z Error: UPGRADE FAILED: "t3b-mac" has no deployed releases

zodraz 22 मई 2020

😕3

मैं तैनात चार्ट पर एक ही मुद्दा है और फली ठीक चल रहा है

vm-victoria-metrics-single-server-0                    1/1     Running     0          2d18h

लेकिन मैं इसे अपग्रेड नहीं कर सकता।

$ helm version
version.BuildInfo{Version:"v3.1.2", GitCommit:"d878d4d45863e42fd5cff6743294a11d28a9abce", GitTreeState:"clean", GoVersion:"go1.13.8"}

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.0", GitCommit:"9e991415386e4cf155a24b1da15becaa390438d8", GitTreeState:"clean", BuildDate:"2020-03-26T06:16:15Z", GoVersion:"go1.14", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.8", GitCommit:"ec6eb119b81be488b030e849b9e64fda4caaf33c", GitTreeState:"clean", BuildDate:"2020-03-12T20:52:22Z", GoVersion:"go1.13.8", Compiler:"gc", Platform:"linux/amd64"}


ismail ~ $ helm list
NAME    NAMESPACE   REVISION    UPDATED                                 STATUS      CHART                                   APP VERSION    
vm      default     1           2020-05-23 16:20:35.243505 +0300 +03    deployed    victoria-metrics-single-0.5.3           1.35.6         

$ helm upgrade vm vm/victoria-metrics-single --set "-selfScrapeInterval=10" 
Error: UPGRADE FAILED: "vm" has no deployed releases


ismail ~ $ helm upgrade --install vm vm/victoria-metrics-single --set "-selfScrapeInterval=10" 
Release "vm" does not exist. Installing it now.
Error: rendered manifests contain a resource that already exists. Unable to continue with install: existing resource conflict: namespace: , name: vm-victoria-metrics-single, existing_kind: policy/v1beta1, Kind=PodSecurityPolicy, new_kind: policy/v1beta1, Kind=PodSecurityPolicy

ismailyenigul 26 मई 2020

मैं पुष्टि करता हूं कि यह मेरी तरफ से भी हुआ

deimosfr 26 मई 2020

@zodraz आपकी पतवार की स्थिति आपकी त्रुटि का कारण बताती है। सबसे हालिया रिलीज़ असफल नहीं दिख रही है, यह "लंबित इंस्टॉल" के रूप में दिखाई दे रही है। इसका अर्थ यह होगा कि अंतिम अपग्रेड को प्रबंधित करने की प्रक्रिया को कृत्रिम रूप से पूरा होने से पहले ही समाप्त कर दिया गया था (यानी इससे पहले कि यह गलत है या सफल था)।

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

मेरा सुझाव है कि आप यह पता लगाने की कोशिश करें कि आपके हेल्म अपग्रेड को खत्म करने से पहले क्यों रद्द किया जा रहा है। यह एक परिहार्य स्थिति होनी चाहिए।

yinzara 26 मई 2020

मैं तैनात चार्ट पर एक ही मुद्दा है और फली ठीक चल रहा है

vm-victoria-metrics-single-server-0                    1/1     Running     0          2d18h

लेकिन मैं इसे अपग्रेड नहीं कर सकता।

$ helm version
version.BuildInfo{Version:"v3.1.2", GitCommit:"d878d4d45863e42fd5cff6743294a11d28a9abce", GitTreeState:"clean", GoVersion:"go1.13.8"}

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.0", GitCommit:"9e991415386e4cf155a24b1da15becaa390438d8", GitTreeState:"clean", BuildDate:"2020-03-26T06:16:15Z", GoVersion:"go1.14", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.8", GitCommit:"ec6eb119b81be488b030e849b9e64fda4caaf33c", GitTreeState:"clean", BuildDate:"2020-03-12T20:52:22Z", GoVersion:"go1.13.8", Compiler:"gc", Platform:"linux/amd64"}


ismail ~ $ helm list
NAME  NAMESPACE   REVISION    UPDATED                                 STATUS      CHART                                   APP VERSION    
vm    default     1           2020-05-23 16:20:35.243505 +0300 +03    deployed    victoria-metrics-single-0.5.3           1.35.6         

$ helm upgrade vm vm/victoria-metrics-single --set "-selfScrapeInterval=10" 
Error: UPGRADE FAILED: "vm" has no deployed releases


ismail ~ $ helm upgrade --install vm vm/victoria-metrics-single --set "-selfScrapeInterval=10" 
Release "vm" does not exist. Installing it now.
Error: rendered manifests contain a resource that already exists. Unable to continue with install: existing resource conflict: namespace: , name: vm-victoria-metrics-single, existing_kind: policy/v1beta1, Kind=PodSecurityPolicy, new_kind: policy/v1beta1, Kind=PodSecurityPolicy

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

yinzara 26 मई 2020

हाय @ यंजारा ,

बात यह है कि मैंने इसे रद्द नहीं किया ... जहाँ तक मैंने अपने द्वारा शुरू किए गए थ्रिलर समय को समझा (और मिटाया ... क्योंकि मुझे इसे विफल करने के लिए तैनाती में त्रुटियां थीं) ने इसे "भ्रष्ट राज्य" तक पहुँचने के लिए बनाया। ।

यह स्थिति पुनर्प्राप्त करने योग्य नहीं है ... इसलिए इसे ठीक करने का एकमात्र तरीका चार्ट को हटाना है ... मेरा काम करने के लिए परमाणु ध्वज का उपयोग करने से बचने के लिए हमेशा रोलबैक और इस "भ्रष्ट राज्य" तक कभी नहीं पहुंचें ...

मैं अनुचर के निर्णय को समझता हूं ... लेकिन इससे भ्रम पैदा होता है, (यदि चार्ट को नहीं हटाया जा रहा है) तो कोई भी संभव समाधान नहीं है और ठीक है, जैसे मैंने कहा कि यह स्थिति तब थी जब 3 त्रुटियां हुईं ... इसे रद्द किए बिना .. ।

वैसे भी सबक सीखा और परमाणु ध्वज के माध्यम से रोलबैक बनाना।

zodraz 26 मई 2020

हाय @ यंजारा

मुझे इसका कारण पता चला कि यह विफल क्यों है।

मैंने गलत पैरामीटर सेट किया -selfScrapeInterval=10 यह सर्वर होना चाहिए।

तो पैरामीटर में - की समस्या।
शायद इस प्रकार की परिवर्तनशील त्रुटि के लिए हेलम त्रुटि सार्थक नहीं थी?

एक असफल:

ismail sf $ helm upgrade vm vm/victoria-metrics-single --set "-selfScrapeInterval=10" 
Error: UPGRADE FAILED: "vm" has no deployed releases

सफलता:

ismail sf $ helm upgrade vm vm/victoria-metrics-single --set "server.extraArgs.selfScrapeInterval=10" 
Release "vm" has been upgraded. Happy Helming!
NAME: vm
LAST DEPLOYED: Tue May 26 22:35:15 2020
NAMESPACE: default
STATUS: deployed
REVISION: 3
TEST SUITE: None
NOTES:
TBD

यह भी काम करता है:

ismail sf $ helm upgrade vm vm/victoria-metrics-single --set "selfScrapeInterval=10" 
Release "vm" has been upgraded. Happy Helming!
NAME: vm
LAST DEPLOYED: Tue May 26 22:37:43 2020
NAMESPACE: default
STATUS: deployed
REVISION: 4
TEST SUITE: None
NOTES:
TBD

ismailyenigul 26 मई 2020

मेरे पास एक ही समस्या है: '(और मैं पर्स का उपयोग नहीं कर सकता क्योंकि मैं डेटा खो दूंगा और मैं ऐसा नहीं कर सकता, मुझे पता है कि यह मुद्दा बंद है लेकिन केवल मैं अपना दर्द व्यक्त कर रहा हूं।

GloriaPG 8 जून 2020

जब हम महत्वपूर्ण कार्यभार तैनात करते हैं, तब भी हमें हेल्म रिलीज को खोदना पड़ता है, यहां तक कि इस कारण के लिए इस्तिओ डॉक्ट्स हेल्मेट का आईटियोक्टेल भी होता है (मुझे लगता है)। हम helm टेम्पलेट का उपयोग करते हैं kubctl -f - इस समस्या से बचने के लिए, लेकिन इस-कोर्स के कारण हटाए गए संसाधनों के बारे में याद रखना समस्या पैदा करता है।

ajitchahal 9 जून 2020

👍2

@ GloriaPG आप अधिक जानकारी साझा कर सकते हैं? आप एक ही समस्या का सामना कैसे कर रहे हैं? जैसा कि @yzzara ने पहले उल्लेख किया था, आप एक ऐसे मामले का अनुभव कर रहे होंगे जो # 7652 ठीक नहीं करता है। हालाँकि, इससे पहले कि हम उस निष्कर्ष पर आ सकें, हमें मदद करने के लिए और अधिक जानकारी चाहिए।

bacongobbler 15 जून 2020

हाय @ बबोंगबॉबलर

हम helm upgrade --install और --force झंडों के साथ उपयोग कर रहे हैं:

helm upgrade --install ${PROJECT_NAME} ${CHART_NAME} \
   --namespace $NAMESPACE_NAME \
   --values ${SECRETS} \
   --values ${CONFIG_VALUES} \
   --force \
   --wait \
   --timeout ${MAX_WAIT_SECONDS} || rollback

दुर्भाग्य से जब रिलीज विफल स्थिति में है:

$ helm list
NAME                    NAMESPACE   REVISION    UPDATED                                 STATUS      CHART           APP VERSION
PROJECT_NAME                CHART_NAME      136         2020-07-09 14:13:09.192381483 +0000 UTC failed      CHART_NAME-0.1.0

इसका परिणाम है:

Error: UPGRADE FAILED: "PROJECT_NAME" has no deployed releases
Error: failed to replace object: Deployment.apps "PROJECT_NAME" is invalid: spec.selector: Invalid value: v1.LabelSelector{MatchLabels:map[string]string{"app":"PROJECT_NAME"}, MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: field is immutable

इसे कैसे हल किया जा सकता है? ऐसा लगता है कि --force --install ध्वज के साथ काम नहीं कर रहा है

जैसा कि यह उत्पादन है, मैं सिर्फ पर्ज रिलीज करने में सक्षम नहीं हूं और इसे खरोंच से बना सकता हूं :(

किसी भी सुझाव के लिए धन्यवाद

sebarys 9 जुल॰ 2020

आपको त्रुटि https://github.com/kubernetes/client-go/issues/508 से संबंधित लगती है
आप चयनकर्ता को परिनियोजन में नहीं बदल सकते। आपको पूर्ववत् करना होगा और फिर से तैयार करना होगा।

yinzara 9 जुल॰ 2020

@yinzara मजेदार बात यह है कि मैं अपनी तैनाती पर चयनकर्ता को नहीं बदल रहा हूं, सब कुछ 9/10 पर काम कर रहा है। एक तैनाती के दौरान sth गलत हो गया, रिलीज़ विफल स्थिति में है और मैं किसी भी तरह से इससे उबर नहीं पा रहा हूं - परिनियोजन स्वयं काम कर रहा है, पॉड्स चल रहे हैं, लेकिन मैं इसे संशोधित करने में सक्षम नहीं हूं।

यह थोड़ा उल्टा है कि रिहाई के बाद विफल स्थिति में है, मैं इसे अब पतवार का उपयोग करने के लिए बदलने में सक्षम नहीं हूं। मुझे उम्मीद है कि झंडा --force मुझे पूरी तैनाती को बदलने या बल लागू करने की अनुमति देगा लेकिन मुझे मौजूदा रिलीज़ को ठीक करने और इसके साथ काम करने का कोई तरीका नहीं मिला।

sebarys 9 जुल॰ 2020

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

yinzara 9 जुल॰ 2020

👎5

मैंने पिछले संस्करण में रोलबैक की कोशिश की है, रिलीज़ अब deployed स्थिति में है। दुर्भाग्य से यह कुछ भी नहीं बदलता है इसलिए मुझे लगता है कि दुर्भाग्य से फिर से हटाने और तैनात करने का एकमात्र तरीका है।

sebarys 10 जुल॰ 2020

इसलिए, इसके साथ मेरा विशेष मुद्दा पुन: पेश करना आसान है।

हेल्म 3 ( --atomic और --cleanup-on-fail ) के साथ कुछ की तैनाती शुरू करें, और ctrl + c प्रक्रिया के बाद यह संसाधन बनाना शुरू कर देता है। कुछ भी वापस लुढ़का नहीं है, संसाधन अभी भी मौजूद हैं, और बाद में "कोई तैनाती नहीं हुई है" त्रुटि में install --upgrade परिणाम चलाने का कोई भी प्रयास।

यह ctrl + c एक ऐसी चीज है, जो तब होता है जब कोई हमारे सीआई सिस्टम में एक शाखा के लिए एक नई कमिट को धकेलता है, जबकि पहले से ही एक बिल्ड रनिंग है - हेल्म अपग्रेड रद्द हो जाएगा, और फिर यह पूरी तरह से टूटी हुई स्थिति में है।

क्या इस बिंदु के बाद हम इसे ठीक करने के लिए कुछ कर सकते हैं? इस धागे में कई अन्य लोगों के साथ, विलोपन एक विकल्प नहीं है।

संपादित करें: एक बार यह टूट जाने के बाद, helm ls रिलीज नहीं दिखाती है, helm history इसे लंबित-स्थापित स्थिति में दिखाती है।

AirbornePorcine 21 जुल॰ 2020

👍5

वास्तव में - कभी नहीं। इससे प्रभावित लोगों के लिए, एक समाधान है: मैन्युअल रूप से कुबेरनेट्स से इतिहास रिकॉर्ड को हटा दें। यह एक रहस्य के रूप में संग्रहीत है। अगर मैं अपमानजनक pending-install राज्य प्रविष्टि को हटाता हूं, तो मैं upgrade --install फिर से सफलतापूर्वक चला सकता हूं!

AirbornePorcine 21 जुल॰ 2020

❤2

@ एयरबोर्नपोरिसिन - क्या आप लंबित-स्थापित प्रविष्टियों को हटाने के लिए कुबेरनेट में आवश्यक परिवर्तनों पर विस्तार से बता सकते हैं।

tarunnarang0201 30 जुल॰ 2020

@ tarunnarang0201 हेल्म प्रत्येक तैनाती के लिए एक कुबेरनेट गुप्त बनाता है, उसी नामस्थान पर जिसे आपने तैनात किया था, आप देखेंगे कि वह 'helm.sh/release.v1' प्रकार का है, और 'sh' .helm.release.v1.release जैसा कुछ नाम दिया है -name.v1 '। आपको बस सबसे हालिया रहस्य को हटाना होगा (उदाहरण में 'v1' प्रत्यय को देखें, यह प्रत्येक तैनाती के लिए बढ़ा हुआ है), और यह मेरे लिए चीजों को अनब्लॉक करने के लिए लग रहा था।

AirbornePorcine 30 जुल॰ 2020

👍3 🚀1 🎉1

@ एयरबोर्न धन्यवाद!

ninja- 13 अग॰ 2020

@AirbornePorcine @ tarunnarang0201 @ निंजा- आप केवल स्टेटस लेबल को पैच कर सकते हैं ... विशेष रूप से, यदि आपके पास कोई पिछला रिलीज़ रिलीज़ नहीं है।

हेल्म 3 के लिए, मेरी टिप्पणी https://github.com/helm/helm/issues/5595#issuecomment -580449247 पर

हेल्म 2 के अधिक विवरण और निर्देशों के लिए, मेरी टिप्पणी https://github.com/helm/helm/issues/5595#issuecomment -575024277 पर

carlosdoordash 13 अग॰ 2020

यह वार्तालाप बहुत लंबा है ... और प्रत्येक टिप्पणी का एक समाधान है .... निष्कर्ष क्या है?
हम पुराने हेल्म 2.12 का उपयोग कर रहे हैं और हमारे पास कभी भी समस्या नहीं थी, लेकिन अब v3.2.4 के साथ इस त्रुटि के साथ पहले से विफल तैनाती विफल हो जाती है।

हम जिस तरह से और नवीनतम हेल्म प्रदाता द्वारा टेराफॉर्म का उपयोग कर रहे हैं। तो क्या हमें --force या --replace उपयोग करना चाहिए

xbmono 1 सित॰ 2020

@xbmono बातचीत लंबी है क्योंकि वहाँ हैं

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

यदि आप "कोई तैनात न होने वाली रिलीज़" त्रुटि पर हैं, तो मुझे यकीन नहीं है कि मैं install --replace और न ही upgrade --install --force स्वयं ही आपकी सहायता करूंगा।

एक समझदार सुझाव शायद केवल दिया जा सकता है

यदि आप रिलीज़ के लिए helm history आपूर्ति करते हैं तो लोग देख सकते हैं कि क्या हुआ है
यदि आप विफलता के मूल कारण को साझा करते हैं / आपने वहां पहुंचने के लिए क्या किया - और क्या आपको लगता है कि मूल समस्या का समाधान किया गया है

संभावित विकल्पों का मेरा सारांश

यदि आप मौजूदा k8s संसाधनों के बारे में सभी या डाउनटाइम पर परवाह नहीं करते हैं, तो helm uninstall && helm install एक विकल्प हो सकता है
यदि यह पहली बार चार्ट स्थापित है जो विफल हो गया है, तो आप शायद रिलीज़ गुप्त मेटाडेटा और helm install फिर से हटा सकते हैं। हो सकता है कि अगर आप --atomic आदि का उपयोग करते हैं, तो विफलता के कारण cruft से आगे निकल जाने पर k8 के संसाधनों को मैन्युअल रूप से साफ़ करना होगा।
यदि आपने --wait ed का हिस्सा स्थापित किया है तो helm history अंतिम शो दिखाता है pending-install आप सबसे हालिया रिलीज़ गुप्त मेटाडेटा को रिलीज़ स्थिति को पैच कर सकते हैं
परिदृश्यों के कुछ अन्य संयोजनों में, एक या अधिक रिलीज़ रहस्यों की रिलीज़ स्थिति को हो सकता है और देखें कि क्या बाद में upgrade आगे बढ़ सकते हैं, हालांकि मेरे ज्ञान में, इनमें से अधिकांश मामलों को संबोधित किया गया था # 7653 (यह सुनिश्चित करने के लिए कि इतिहास में कहीं न कहीं deployed रिलीज हो) इसलिए मुझे आश्चर्य होगा कि क्या यह अब उपयोगी था।

चूंकि यह एक बंद मुद्दा है, मुझे संदेह है कि एक मूल कारण है जो किसी भी तरह से अलग, अधिक विशिष्ट टिकट में डिबग और दस्तावेज़ करना अच्छा होगा।

chadlwilson 1 सित॰ 2020

@chadlwilson आपकी प्रतिक्रिया के लिए धन्यवाद।

helm history रिटर्न कोई पंक्तियाँ नहीं!

Error: release: not found

लेकिन helm list असफल तैनाती देता है

M:\>helm3 list -n cluster171
NAME            NAMESPACE       REVISION        UPDATED                                 STATUS  CHART                           APP VERSION
cluster171      cluster171      1               2020-09-01 04:45:26.108606381 +0000 UTC failed    mychart-prod-0.2.0-alpha.10    1.0

हम टेराफॉर्म का उपयोग कर रहे हैं और हमारे वातावरण जेनकींस द्वारा हर घंटे स्वचालित रूप से तैनात हो जाते हैं। टेराफॉर्म के साथ मैं helm upgrade उपयोग नहीं कर सकता, यह है कि हेल्म प्रदाता क्या कर रहा है

टेररफॉर्म कोड में मैंने force_update true , कोई भाग्य नहीं सेट किया है और मैंने replace से true , फिर से कोई भाग्य सेट नहीं किया है

resource "helm_release" "productStack" {
  name = "${var.namespace}"
  namespace = "${var.namespace}"
  chart = "${var.product_stack}"
  force_update = true//"${var.helm_force_update}"
  max_history = 10
  replace = true

  wait = true
  timeout = "${var.timeout_in_seconds}"

}

तो मुझे आश्चर्य है कि क्या यह wait=true ? तो पिछली तैनाती विफल होने का कारण यह था कि क्लस्टर डॉक रिपॉजिटरी के साथ संवाद करने में सक्षम नहीं था और इसलिए timeout पहुंच गया और स्टेटस failed लेकिन हमने इश्यू और pods तय किया helm delete काम करता है, लेकिन अगर मैं ऐसा हर बार करता हूं तो मेरे प्रबंधक और न ही डेवलपर्स खुश होंगे।

हेल्म v2 के साथ यदि तैनाती विफल हो जाती है और डेवलपर्स इसे ठीक कर देते हैं, तो अगली तैनाती विफल तैनाती को अपग्रेड कर देगी।

xbmono 1 सित॰ 2020

👍1

M:\>helm3 list -n cluster171
NAME            NAMESPACE       REVISION        UPDATED                                 STATUS  CHART                           APP VERSION
cluster171      cluster171      1               2020-09-01 04:45:26.108606381 +0000 UTC failed    mychart-prod-0.2.0-alpha.10    1.0

helm history विफलता अजीब लगती है (टाइपो! गलत नाम याद किया हुआ गलत संस्करण?), लेकिन इसे देखते हुए 1 list ऊपर लगता है, ऐसा लगता है कि आप पहली बार करने की कोशिश कर रहे हैं? नए चार्ट की समय स्थापना और पहली बार स्थापना विफल रही है। यदि आप उन चीज़ों को अनब्लॉक करने का प्रयास कर रहे हैं, तो आप संभवतः रिलीज़ गुप्त मेटाडेटा को ऊपर या उसकी स्थिति पैच के रूप में हटा सकते हैं, और पुनः प्रयास कर सकते हैं। यह संकेत दे सकता है कि मेटाडेटा हेल्म या हेल्म टेराफ़ॉर्म प्रोवाइडर के दृष्टिकोण से खराब स्थिति में है, लेकिन यह नहीं है कि यह वहां कैसे पहुंचा।

किसी भी मामले में, मेरे पास upgrade करने वाले मुद्दे नहीं हैं, # 7653 के विलय के बाद से Helm 3.2.1 साथ पहली बार विफल रहे हैं। आप उस विशिष्ट Helm संस्करण को दोबारा जांचना चाहेंगे जो प्रदाता वास्तव में उपयोग कर रहा है? यह भी संभव है कि install विफलता के बाद जिस तरह से हेल्म टेराफ़ॉर्म प्रदाता ने आंकड़े जारी किए हैं, उससे यह हो सकता है। मुझे उस प्रदाता के साथ कोई अनुभव नहीं है, और व्यक्तिगत रूप से टीएफ जैसे एक और घोषणात्मक अमूर्त के साथ हेल्म को लपेटने के पक्ष में नहीं हूं क्योंकि मुझे लगता है कि यह और भी अपारदर्शी है जब चीजें गलत हो जाती हैं, लेकिन आप आगे भी खुदाई करना चाहते हैं। ।

किसी भी मामले में, जैसा कि मैंने ऊपर कहा, अगर आप जिस त्रुटि पर फंस गए हैं, वह has no deployed releases पहली बार की गई तैनाती के बाद, मुझे नहीं लगता कि replace force कुछ अन्य हस्तक्षेप के बिना स्थिति को फिर से जीवित करने में आपकी मदद करने की संभावना है और इसे आगे डिबग करना सबसे अच्छा होगा और किसी भी अन्य वार्तालाप को करना होगा, क्योंकि 51 प्रतिभागियों के साथ इस पुराने बंद टिकट पर सभी संबंधितों के लिए इतना उत्पादक नहीं लगता है।

chadlwilson 2 सित॰ 2020

नहीं, कोई टाइपो नहीं था। इसके अलावा, यह पहले तैनाती या बाद में होने की परवाह किए बिना होता है।

जैसा कि मैंने उल्लेख किया है कि हम जेनकिंस में तैनाती के लिए प्रतीक्षा करने के लिए --wait विकल्प का उपयोग कर रहे हैं और फिर यह सूचित करने के लिए कि तैनाती विफल हुई या नहीं।

ऐसा लगता है, यदि समय समाप्त हो गया है और तैनाती सफल नहीं है, तो helm ने failed रूप में परिनियोजन को चिह्नित किया और उस रिलीज़ को मैन्युअल रूप से हटाने के अलावा अन्य पुनर्प्राप्त करने का कोई तरीका नहीं है। और हम रिलीज़ को स्वचालित रूप से हटाना नहीं चाहते क्योंकि यह डरावना है।

इसलिए यदि हम --wait विकल्प को हटाते हैं, तो helm की तैनाती को successful रूप में चिन्हित करेगा।

वर्कअराउंड:

अब मुझे एक और उपाय सूझा। जो लोग एक ही समस्या है और चाहते हैं कि उनका स्वचालन अच्छी तरह से काम करे क्योंकि यह पहले काम करता था, यहाँ मेरा काम है:

helm परिनियोजन से --wait विकल्प निकालें
उस नामस्थान के लिए परिनियोजन की सूची प्राप्त करने के लिए इस कमांड का उपयोग करें जिसे आप के विरुद्ध तैनात कर रहे हैं: kubectl get deployments -n ${namespace} -o jsonpath='{range .items[*].metadata}{.name}{","}{end}'
एक सरणी में ऊपर कॉमा से अलग की गई सूची को चालू करने के लिए आप split का उपयोग कर सकते हैं
तब आप समानांतर में कई कमांड चला सकते हैं (हम जेनकिन्स का उपयोग करते हैं इसलिए ऐसा करना आसान है) kubectl rollout status deployment ${deploymentName} --watch=true --timeout=${timeout} -n ${namespace}
यदि timeout , उदाहरण के लिए 7m अर्थ है 7 मिनट, परिनियोजन अभी भी सफल नहीं है, तो कमांड त्रुटि के साथ बाहर निकल जाती है
समस्या हल हो गई।

xbmono 3 सित॰ 2020

वास्तव में - कभी नहीं। इससे प्रभावित लोगों के लिए, एक समाधान है: मैन्युअल रूप से कुबेरनेट्स से इतिहास रिकॉर्ड को हटा दें। यह एक रहस्य के रूप में संग्रहीत है। अगर मैं अपमानजनक pending-install राज्य प्रविष्टि को हटाता हूं, तो मैं upgrade --install फिर से सफलतापूर्वक चला सकता हूं!

वैकल्पिक रूप से, इसने मेरे लिए काम किया:

helm uninstall {{release name}} -n {{namespace}}

LasTshaMAN 16 सित॰ 2020

kubectl -n $namespace delete secret -lstatus=pending-upgrade द्वारा तय किया गया
अब पतवार चलाओ।

abdennour 29 सित॰ 2020

👍5 🚀4 ❤3 😄3 🎉2 👀1

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

क्या किसी ने केवल एक ध्वज जोड़ने के बारे में सोचा है कि यह पहली रिलीज़ है इसलिए इसे स्वचालित रूप से हटा देना सुरक्षित होना चाहिए? या "--फोर्स-डिलीट-ऑन-फेल" जैसा कुछ जोड़ना? समस्या को नजरअंदाज करने से मदद नहीं मिलने वाली है।

nick4fake 8 अक्तू॰ 2020

👍4

@ nic4fake AFIK यह PR # 7653 द्वारा बंद किया गया था। @yzzara अधिक जानकारी प्रदान करने में सक्षम हो सकता है।

hickeyma 8 अक्तू॰ 2020

यह अनुरक्षकों द्वारा लंबित-अपग्रेड रिलीज को ओवरराइटिंग की अनुमति नहीं देने का निर्णय था। लेकिन आपका यह कथन कि सभी कार्य आस-पास के कार्य हैं जो CI / CD पाइपलाइन में काम नहीं करते हैं, सत्य नहीं हैं। आपके सुझाए गए अपग्रेड को चलाने से पहले अंतिम सुझाए गए काम को बिल्ड स्टेप के रूप में जोड़ा जा सकता है (मैं किसी CI / CD पिप्पलीलाइन में --force का उपयोग नहीं करूंगा)। इसका वही असर होता है जो आपने सुझाया है, सिवाय इसके कि यह रिलीज को डिलीट करे, इससे पहले कि आप अगली रिलीज को तुरंत इंस्टॉल करें, इसके तुरंत बाद आपको असफलता के कारण को डिबग करना होगा।

yinzara 8 अक्तू॰ 2020

मैंने अपनी अपग्रेड कमांड चलाने से पहले किसी भी "लंबित" रिलीज़ को अनइंस्टॉल करने के लिए अपने स्वचालित बिल्ड में निम्नलिखित का उपयोग किया है (NS_NAME पर्यावरण चर को आपके द्वारा तैनात नामस्थान पर सेट करना सुनिश्चित करें):
`` `बाश

/ usr / bin / env बैश

RELEASES = $ (helm list --namespace $ NS_NAME --pending --output json। J -r '। [] | Select (.status == "लंबित-स्थापित")) .name' |
अगर [[ ! -z "$ नियम"]]; तब फिर
हेल्म डिलीट --namespace $ NS_NAME $ RELEASES
फाई

yinzara 8 अक्तू॰ 2020

👍1

@yinzara स्निपेट के लिए धन्यवाद, यह धागा खोजने वालों के लिए बहुत मददगार है।

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

मेरा मतलब है, बस इस चर्चा धागे की जांच करें, लोग अभी भी इस मुद्दे का सामना करते हैं। आप संभवतः इस थ्रेड के लिंक के साथ हेल्म त्रुटि संदेश में कुछ अतिरिक्त जानकारी जोड़ने के बारे में क्या सोचते हैं + क्या करना है पर कुछ सुझाव?

nick4fake 10 अक्तू॰ 2020

@ nick4fake मुझे लगता है कि आप "लंबित-इंस्टॉल" के साथ "असफल" मिश्रण कर रहे हैं।

लाइब्रेरी के अनुचर आपको असफल रिलीज़ से सहमत हैं, इसीलिए उन्होंने मेरे PR को स्वीकार किया।

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

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

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

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

yinzara 10 अक्तू॰ 2020

👍1

यह कहा जा रहा है, मैं आपके कथन से सहमत नहीं हूं कि आपकी बात अभी भी मान्य है। मेरा सुझाव लंबित रिलीज़ को हटा सकता है, हालाँकि आपके ठीक पहले

yinzara 10 अक्तू॰ 2020

आप संभवतः इस थ्रेड के लिंक के साथ हेल्म त्रुटि संदेश में कुछ अतिरिक्त जानकारी जोड़ने के बारे में क्या सोचते हैं + क्या करना है पर कुछ सुझाव?

इसके लिए +1। हमें इस थ्रेड को खोजने के लिए अभी भी चारों ओर Google है, यह समझने के लिए कि pending-install रिलीज़ क्या है, इसलिए हम इस त्रुटि संदेश के बारे में तर्क करना शुरू कर सकते हैं।

omnibs 13 अक्तू॰ 2020

मेरे पास helm upgrade साथ मुद्दे थे और यह मुझे यहां ले जाता है। इसे -n <namespace> जोड़कर हल किया गया था। शायद यह किसी को वहाँ से बाहर निकलने में मदद करेगा।

sajtrus 20 अक्तू॰ 2020

Helm3 के लिए, पैच के माध्यम से हल किया जा सकता है
kubectl -n <namespace> patch secret <release-name>.<version> --type=merge -p '{"metadata":{"labels":{"status":"deployed"}}}'

release-name और version - kubectl get secrets -n <namespace> | grep helm से देखे जा सकते हैं

Jenishk56 27 अक्तू॰ 2020

👍6 🎉5

Helm: ऐप-नाम में कोई भी रिलीज़ रिलीज़ नहीं है

सबसे उपयोगी टिप्पणी

सभी 120 टिप्पणियाँ

वर्कअराउंड:

/ usr / bin / env बैश

संबंधित मुद्दों