Helm: UPGRADE विफल: "" नाम के साथ कोई संसाधन नहीं

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

तो, अगर यह स्थापित किया गया है: helm install -n my-release

my-thing/
  Chart.yml
  charts/
    depended-upon-thing/

और फिर एक नया चार्ट निर्भरता के रूप में जोड़ा जाता है:

my-thing/
  Chart.yml
  charts/
    depended-upon-thing/
    new-dependency/

जब रिलीज़ को अपग्रेड किया जाता है: helm upgrade my-release my-thing helm निम्नलिखित त्रुटि पैदा करता है:

Error: UPGRADE FAILED: No resource with the name new-dependency found.

@ महादेव मैं इस मुद्दे को मास्टर पर

धन्यवाद!

@elementalvoid मैं मास्टर पर नई निर्भरता त्रुटि को पुन: उत्पन्न करने में भी असमर्थ था। क्या आप अभी भी इस समस्या को देख रहे हैं? हेल्म / टिलर का कौन सा संस्करण चल रहा है?

धन्यवाद।

जब मैं अल्फा 4 पर था उस समय अल्फा 5 और @ देवता के उदाहरण का उपयोग करते हुए मैं भी इस मुद्दे को

ठीक है। मैं इसे अभी के लिए बंद कर दूंगा। यदि आप इनमें से किसी भी समस्या को फिर से देखते हैं, तो समस्या दर्ज करने के लिए स्वतंत्र महसूस करें।

एक बार फिर धन्यवाद।

@michelleN धन्यवाद! क्षमा करें, मेरे पास इस सप्ताह का समय नहीं है कि मैं मास्टर पर एक निंदा का प्रयास करूं। जल्द ही अपग्रेड होने की उम्मीद है!

परमवीर चक्र के लिए एक hostPath परिनियोजन / वॉल्यूम युक्ति को ले जाने पर मेरे लिए समान है।
बग तब लगता है जब अपग्रेड मैनिफेस्ट एक नए (पुराने में "लापता" पर निर्भर करता है?)
संस्करण: 2.7.2

अजीब बात है, मैं एक ही व्यवहार को एक नई भूमिका के साथ 2.7.2 संस्करण में चार्ट को अपग्रेड करने की कोशिश कर रहा हूं। टिलर ने शिकायत की कि यह भूमिका नहीं पा सकता है और तैनाती को विफल करता है, भले ही उसने वास्तव में भूमिका बनाई हो।

मेरी स्थिति यह थी कि मेरे पास एक नया संसाधन था, और मैंने नए संसाधन के साथ हेलम चार्ट के नए संस्करण को तैनात किया। उस परिनियोजन में विफल b / c I वसा ने कुछ यमल उँगलियों को किया। खैर, नई वस्तुओं को कुबेरनेट में बनाया गया था। मैंने yaml को ठीक किया, और अपने चार्ट पर नवीनीकरण को फिर से चलाया, और वोइसला संदेश, जो संसाधन नहीं मिला त्रुटि संदेश प्रकट होता है। मुझे कुबेरनेट्स में जाना पड़ा और असफल तैनाती द्वारा बनाए गए नए संसाधनों (मेरे मामले में एक भूमिका और रोलबाइंडिंग) को हटाना पड़ा। उसके बाद, यह देखने के लिए कि चालू वस्तु मौजूद है, यह देखने के लिए पतवार की जांच (https://github.com/kubernetes/helm/blob/7432bdd716c4bc34ad95a85a76a761c7cec5a74a3/pkg/kube/client.go#L257) सफल नहीं होगी और संसाधन उपलब्ध नहीं होंगे। फिर व। एक बग की तरह लगता है, जहां एक असफल चार्ट के लिए नए संसाधनों का हिसाब होना चाहिए?

उन्नयन के दौरान समान त्रुटि हो रही है:

$ helm upgrade --install bunny ./app --namespace=staging --reuse-values --debug
[debug] Created tunnel using local port: '53859'

[debug] SERVER: "127.0.0.1:53859"

Error: UPGRADE FAILED: no ConfigMap with the name "bunny-proxy-config" found

कॉन्फ़िगरमैप बनाया गया है

$ k get configmap
NAME                 DATA      AGE
bunny-proxy-config   1         7m

मेरा विन्यास:

apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ template "proxy.fullname" . }}-config
  labels:
    app: {{ template "proxy.name" . }}
    chart: {{ template "proxy.chart" . }}
    release: {{ .Release.Name }}
    heritage: {{ .Release.Service }}
data:
  asd: qwe

हमारे पास एक ही मुद्दा है।

मैंने पूरी रिलीज़ हटा दी और फिर से इंस्टॉल हो गई। वर्तमान में यह काम कर रहा है।

$ helm del --purge bunny

मैं भी इस मुद्दे पर चल रहा हूँ

ग्राहक: और संस्करण। वर्जन {सेमीव्यूअर: "v2.8.0", GitCommit: "14af25f1de683222228539259b821949d20069a222", GitTreeState: "क्लीन"}
सर्व

यह हमारे हेल्म के उपयोग के साथ अक्सर होता है और इसके लिए पूर्ण --purge आवश्यकता होती है। यह _not_ एक समाधान है।

यदि आप CI / CD का उपयोग करते हैं तो यह लागू नहीं है।
यदि कोई अपग्रेड विफल हो जाता है और आप रोलिंग अपडेट रणनीति का उपयोग करते हैं तो क्या होता है। क्या मुझे अपनी अभी भी काम कर रही रिलीज को हटाना चाहिए?

मैं एक ही मुद्दा देखता हूं, जब कोई परिनियोजन समस्या या समान है, लेकिन गुप्त / सेमी बनाया गया, लेकिन तब हेल्म इसका ट्रैक खो देता है, आपको बहुत कुछ करने से इनकार करता है।

मैंने इसे देखा है, शायद ही कभी, एक गैर-टूटी हुई रिलीज पर भी होता है (यानी जैसा कि यह देखा गया है) के माध्यम से होता है, लेकिन मुझे अभी तक यह पता लगाना है कि क्या कारण हो सकते हैं।

मौजूदा हेल्म तैनाती में संसाधन जोड़ते समय हम इस मुद्दे (सर्वर v2.8.2) को पुन: पेश करने में भी सक्षम हैं। हर बार एक नया संसाधन जोड़ने के लिए परिनियोजन को हटाने और हटाने के बाद उत्पादन में एक बड़ी समस्या होगी।

हमारे मामले में हम एक चार्ट में एक configmap जोड़ रहे थे और चार्ट के साथ उन्नत होने में विफल रहता है:

त्रुटि: UPGRADE विफल: नाम के साथ कोई संसाधन नहीं "" मिल गया

नोट: हम 2.7.2 का उपयोग कर रहे हैं;

मेरा मानना ​​है कि ऐसा इसलिए होता है क्योंकि जब हेल्म यह निर्धारित करता है कि पुराने रिलीज में नए कॉन्फ़िगरेशन संसाधन के लिए यह क्या बदल गया है, और इसे खोजने में विफल रहता है। कोड के लिए https://github.com/kubernetes/helm/blob/master/pkg/kube/client.go#L276 -L280 देखें जहां यह त्रुटि आती है।

असफल अपग्रेड के लिए टिलर लॉग:

[tiller] 2018/05/03 19:09:14 preparing update for staging-collector
[storage] 2018/05/03 19:09:14 getting deployed release from "staging-collector" history
[tiller] 2018/05/03 19:10:39 getting history for release staging-collector
[storage] 2018/05/03 19:10:39 getting release history for "staging-collector"
[tiller] 2018/05/03 19:10:41 preparing update for staging-collector
[storage] 2018/05/03 19:10:41 getting deployed release from "staging-collector" history
[storage] 2018/05/03 19:10:42 getting last revision of "staging-collector"
[storage] 2018/05/03 19:10:42 getting release history for "staging-collector"
[tiller] 2018/05/03 19:10:44 rendering collector chart using values
[tiller] 2018/05/03 19:10:44 creating updated release for staging-collector
[storage] 2018/05/03 19:10:44 creating release "staging-collector.v858"
[tiller] 2018/05/03 19:10:44 performing update for staging-collector
[tiller] 2018/05/03 19:10:44 executing 0 pre-upgrade hooks for staging-collector
[tiller] 2018/05/03 19:10:44 hooks complete for pre-upgrade staging-collector
[kube] 2018/05/03 19:10:44 building resources from updated manifest
[kube] 2018/05/03 19:10:44 checking 3 resources for changes
[tiller] 2018/05/03 19:10:44 warning: Upgrade "staging-collector" failed: no resource with the name "collector-config" found 
[storage] 2018/05/03 19:10:44 updating release "staging-collector.v857"
[storage] 2018/05/03 19:10:44 updating release "staging-collector.v858" 

एक तैनात सेवा के name लेबल को बदलते समय यह समस्या भी उत्पन्न होती है, शायद अन्य चीजें भी।

मैं एक रिलीज़ में एक सेवा का नाम बदल रहा हूँ और इसके साथ अपग्रेड करने में विफल है:

त्रुटि: UPGRADE विफल: "नई-सेवा-नाम" नाम के साथ कोई सेवा नहीं मिली

मैं इस व्यवहार को ठीक करने के लिए एक पीआर बनाने के लिए तैयार हूं, लेकिन मैं यह जानना चाहूंगा कि इसे संभालने का इरादा या सुझाया तरीका क्या है। यहां तक ​​कि एक CLI ध्वज जो अनुमति देता है - प्रवर्तन पूर्वता लेने के लिए बहुत अच्छा होगा।

महत्व पर सहमत हैं।

यह समस्या अजीब हो सकती है जब आप केवल एक तैनाती को हटा नहीं सकते हैं।

मैंने पाया कि हमारा मुद्दा असफल तैनाती के कारण था।

हेल्म एक असफल तैनाती के बाद सफाई करने का प्रयास नहीं करता है, जिसका अर्थ है कि मैंने जो नया कॉन्फिगरेशन ऊपर जोड़ा है वह निर्मित हो जाता है, लेकिन 'पूर्व' तैनाती में संदर्भ के बिना। इसका मतलब है कि जब अगली तैनाती होती है, तो हेल्म k8 में संसाधन ढूंढता है और उम्मीद करता है कि इसे नवीनतम तैनात संशोधन (या कुछ और; परिवर्तन हैं। यह उस रिलीज़ में नहीं है, इसलिए यह संसाधन नहीं ढूंढ सकता, और विफल रहता है।

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

@krishicks हाँ, यह एक तरीका है इसे

हम इसे भी मार रहे हैं। यह वही मुद्दा है जिसका @krishicks और @jaredallard ने उल्लेख किया है:

1. हमारे पास एक विफल तैनाती है:
   UPGRADE FAILED: the server was unable to return a response in the time allotted, but may still be processing the request (get configmaps)
2. किसी भी बाद के परिवर्तन, अन्य रिलीज के लिए भी, जैसे चेतावनी के साथ विफल
   Error: UPGRADE FAILED: no Service with the name "…" found

मैं पहले मुद्दे को कम करने के लिए helm upgrade --timeout … ध्वज का उपयोग करने की कोशिश करूंगा, लेकिन एक असफल तैनाती सब कुछ को अवरुद्ध करना हमारे लिए काफी एक मुद्दा है। इसके अलावा, helm rollback … का उपयोग करने से यह हल नहीं हुआ।

हमारे उपयोग-मामले में helm upgrade … रूप में स्वचालित रूप से चलता है, --auto-rollback लिए helm upgrade बहुत मददगार होगा, जो विफल परिवर्तनों का बदला लेता है।

चार्ट में नए संसाधन जोड़ते समय v2.7.2 के साथ यह मेरे लिए हो रहा है।
क्या इस बारे में कोई अनुमान लगाया जा सकता है कि इसके लिए एक तय समय कब होगा?

यह # 4146 के साथ तय किया जाना चाहिए।

संपादित करें: नीचे देखें

इसलिए मुझे # 4146 के साथ कुछ कीड़े मिले जो इसे आगे बढ़ने के लिए अवांछनीय पीआर बनाता है। मैंने मास्टर, # 4146, और # 4223 के बीच अपने निष्कर्षों की सूचना दी: https://github.com/kubernetes/helm/pull/4223#issuecomment -397413568

@adamreese और मैं उस अंतर्निहित बग की पहचान करने में कामयाब रहे जो इस विशेष त्रुटि का कारण बनता है, और प्रत्येक प्रस्तावित पीआर के साथ विभिन्न परिदृश्यों और किनारे के मामलों से गुजरता है। अगर कोई और मेरे निष्कर्षों की पुष्टि कर सकता है या अन्य किनारे के मामलों को खोज सकता है, तो यह बहुत सराहना की जाएगी!

ओह, और कुछ मैं उल्लेख करने में विफल रहा: क्योंकि एक असंगत स्थिति में क्लस्टर, यह आसानी से मैन्युअल रूप से हस्तक्षेप करने और संसाधन को हटाने के द्वारा काम किया जा सकता है कि त्रुटि रिपोर्ट "नहीं मिली" के रूप में। उदाहरण के बाद मैंने https://github.com/kubernetes/helm/pull/4223#issuecomment -397413568 में प्रदर्शन किया:

><> helm fetch --untar https://github.com/kubernetes/helm/files/2103643/foo-0.1.0.tar.gz
><> helm install ./foo/
...
><> vim foo/templates/service.yaml
><> kubectl create -f foo/templates/service.yaml
service "foo-bar" created
><> helm upgrade $(helm last) ./foo/
Error: UPGRADE FAILED: no Service with the name "foo-bar" found
><> kubectl delete svc foo-bar
service "foo-bar" deleted
><> helm upgrade $(helm last) ./foo/
Release "riotous-echidna" has been upgraded. Happy Helming!
...
><> kubectl get svc
NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
foo-bar      ClusterIP   10.104.143.52   <none>        80/TCP    3s
kubernetes   ClusterIP   10.96.0.1       <none>        443/TCP   1h

@bacongobbler हमेशा काम नहीं करता है। हमारे पास ऐसी परिस्थितियाँ हैं जहाँ इसे हटाना काम नहीं करता है और कुछ जहाँ ऐसा करने के बाद भी काम नहीं करता है।

यह आसानी से मैन्युअल रूप से हस्तक्षेप करने और संसाधन को हटाने के द्वारा काम किया जा सकता है

@bacongobbler कृपया, यह समझें कि यह संसाधन उत्पादन नामस्थान की सेवा या परिनियोजन ऑब्जेक्ट हो सकता है, जो हमारी सेवा की गारंटी को बाधित कर सकता है (और पहले से ही)।

हां मुझे पता है। मैं सिर्फ बग के व्यवहार को समझा रहा हूं और देख रहा हूं ताकि दूसरों को पता चले कि क्या शामिल है। :)

बस इस मुद्दे को दो बार अलग-अलग समूहों में चलाएं। हर बार configmaps के साथ। संसाधनों को हटाने से समस्या हल नहीं हुई, इसलिए हमें पूरी रिलीज़ को हटाना पड़ा।

मुझे भी। इतना ही नहीं विन्यास मैं एक ServiceAccount के साथ है।

यहां पीवीसी। :)

मूल रूप से हर प्रकार की प्राथमिकता वाली वस्तु इस बग के अधीन है।

क्या इसे ठीक करने के लिए किसी को सौंपा गया है? क्या इसके लिए पहले से कोई पीआर है? क्या मैं कुछ भी मदद कर सकता हूं?

मुझे इस मुद्दे से एक बार से अधिक काट दिया गया है क्योंकि यह अपने आप को प्राप्त करने के लिए एक आसान स्थिति है लेकिन जाहिर है कि इससे बाहर निकलने का कोई आसान तरीका नहीं है। मुझे लगता है कि मेरे मामले में "अच्छा" हिस्सा यह है कि संसाधनों को रिलीज़ पर त्रुटि के साथ भी अपडेट किया जाता है (यह सुनिश्चित नहीं होता है कि क्या मुझे खुश या चिंतित करता है)

मुझे लगता है कि पतवार को या तो उपयोगकर्ता को इस गलत स्थिति में आने से रोकना चाहिए या इसे सही तरीके से संभालना चाहिए।
वहाँ सब कुछ हटाने के लिए इस के लिए कोई वास्तविक सुधार है (जो केवल गैर-उत्पादन उपयोगों के लिए व्यवहार्य है)?

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

@Draiken नहीं, हमने समस्या के कई समाधानों का प्रयास किया है, और उनमें से कोई भी उचित नहीं है जैसा कि वे या तो

a) अपग्रेड नहीं करना है जैसा कि इरादा है, या
बी) नए कीड़े परिचय

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

हम उपयोगकर्ताओं को इस गलत स्थिति में आने से नहीं रोक सकते; हमने समाधानों पर ध्यान दिया है लेकिन फिर से वे सभी समस्याओं का एक अलग सेट पेश करते हैं। एक बार असंगत स्थिति में स्थापित होने के बाद, यह मैन्युअल हस्तक्षेप के बिना इसे "ठीक" करना मुश्किल है। 😢

मेरे लिए काम करने का एक तरीका है असफलता होने से पहले helm rollback ... सही करना। मैं तब पुष्टि करता हूं कि चार्ट helm install -n new-test-release . साथ एक नई रिलीज़ पर काम करता है।

एक बार जब सब कुछ काम करता है, तो मैं रिलीज रिलीज को साफ करता हूं और पुरानी रिलीज के खिलाफ helm upgrade ... चलाता हूं; और सब कुछ काम किया। यह एक कष्टप्रद हल है, लेकिन यह काम करने लगता है।

मुझे नहीं पता कि यह सब मदद करता है, लेकिन मैं सिर्फ इस मुद्दे पर अपने परीक्षण और उत्पादन समूहों दोनों में भाग गया।

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

पतवार चलाते समय मुझे पहली बार यह त्रुटि मिली:

KUBECONFIG=**** helm upgrade --kube-context=mycluster -f helm/project/mycluster.yaml project ./helm/project --install --wait --timeout 1200

Error: UPGRADE FAILED: Deployment.apps "blah-blah" is invalid: spec.template.metadata.labels: Invalid value: map[string]string{"app":"blah-blah", "chart":"blah-3", "name":"blah", "release":"project"}: `selector` does not match template `labels`

जब फिर से पतवार चल रही है, मुझे अब यह त्रुटि बार-बार मिलती है:

KUBECONFIG=**** helm upgrade --kube-context=mycluster -f helm/project/mycluster.yaml project ./helm/project --install --wait --timeout 1200

Error: UPGRADE FAILED: no Service with the name "blah-blah" found

जब मैंने सब कुछ डिलीट कर दिया और फिर से तैयार किया तो निश्चित रूप से हेल्म चार्ट का परीक्षण किया गया। यह वास्तव में हालांकि ठेस के लिए एक विकल्प नहीं है।

@veqryn मैंने इसे बहुत चलाया है, मैं मूल रूप से # 4146 में अपने बिल्ड का उपयोग करता हूं जब भी मैं इस मुद्दे पर चलता हूं और फिर मेनलाइन पर वापस स्वैप करता हूं। हर बार काम करता है। मुझे पता है कि अनुरक्षक इसकी अनुशंसा नहीं कर सकते हैं, लेकिन _it कार्य_ जो कुछ भी नहीं से बेहतर है।

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

@jaredallard हम रुचि रखते हैं। धन्यवाद!

मुझे पता है कि अनुरक्षक इसकी अनुशंसा नहीं कर सकते हैं, लेकिन यह काम करता है जो कुछ भी नहीं से बेहतर है।

@jaredallard हम उस पैच को केवल इसलिए नहीं सुझा सकते क्योंकि यह अपने आप काम नहीं करता (Ref: https://github.com/helm/helm/pull/4223#issuecomment-397413568)। यह त्रुटि को दरकिनार करता है, लेकिन यह संसाधनों को अपग्रेड नहीं करता है, इसलिए पैच वह नहीं करता है जो उपयोगकर्ता मूल रूप से करना चाहता था। यह एक समस्या को ठीक करता है लेकिन मूल मुद्दे को ठीक किए बिना दूसरे का परिचय देता है जो उपयोगकर्ता प्रदर्शन करने का इरादा रखते हैं: एक संसाधन को अपग्रेड करना।

हालाँकि, यह पेचीदा है:

जब भी मैं इस मुद्दे में दौड़ता हूं मैं मूल रूप से # 4146 में अपने बिल्ड का उपयोग करता हूं और फिर मेनलाइन एक पर वापस स्वैप करता हूं।

अगर मैं यह सही पढ़ रहा हूं, तो आप सुझाव दे रहे हैं कि आपने एक वर्कअराउंड ढूंढ लिया है

a) त्रुटि को बायपास करता है
b) संसाधनों को अपग्रेड करने की अनुमति देता है क्योंकि वे मूल रूप से इरादा रखते थे

2 helm upgrade s करके: एक पैच के साथ, और एक बिना? इससे हमें मूल कारण की पहचान करने और इस त्रुटि को ठीक करने में बेहतर तरीके से मदद मिल सकती है।

@bacongobbler मुझे 100% यह सत्यापित करना होगा कि यह व्यवहार है। मैं इस टिप्पणी को अपडेट करूंगा या मेरे पास एक और पोस्ट करूंगा।

मुझे पता है कि अनुरक्षक इसकी अनुशंसा नहीं कर सकते हैं, लेकिन यह काम करता है जो कुछ भी नहीं से बेहतर है।

इसके अलावा, स्पष्ट करने के लिए, मैं वहाँ छाया फेंकने की कोशिश नहीं कर रहा हूँ! यह थोड़ा बुरा शब्द है इसे अब वापस देख रहे हैं, क्षमा करें

मैं अभी भी इस बात पर असमंजस में हूँ कि मेरा हेल्म पहली बार शुरू करने में असफल क्यों रहा।
जब तक मैंने इसे लागू करने का प्रयास नहीं किया, तब तक इसे no X with the name Y त्रुटि नहीं मिली।

@veqryn मैंने इस बात को लिखा कि जिस मुद्दे को मैंने ऊपर जोड़ा है,

आलसी के लिए: https://github.com/helm/helm/pull/4223#issuecomment -3941413568

मैंने वास्तव में वह पढ़ा था, और मेरी समझ यह थी कि यह मुद्दा आपके साथ हुआ था क्योंकि आपने अपनी सेवा का नाम बदल दिया था।

हालाँकि, किसी भी समय मेरी किसी भी सेवा या किसी भी संसाधन ने नाम नहीं बदले।

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

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

यह (बदसूरत) मेरे लिए ठीक काम करता है:

1. मुझे त्रुटि मिल रही है:

helm upgrade az-test-2-prom ./prometheus --namespace monitor --set cluster_name="az-test-2" -f values.yaml
Error: UPGRADE FAILED: no ConfigMap with the name "az-test-2-prom-prometheus-grafana-config" found

1. पिछले नष्ट संशोधनों का पता लगाएं

export TEMPLATE='{{range .items}}{{.metadata.name}}{{"\t"}}{{.metadata.labels.STATUS}}{{"\n"}}{{end}}'
kubectl -nkube-system get cm -l 'OWNER=TILLER' -ogo-template="$TEMPLATE"

az-test-2-prom.v1   SUPERSEDED
az-test-2-prom.v10  SUPERSEDED
az-test-2-prom.v11  SUPERSEDED
az-test-2-prom.v12  SUPERSEDED
az-test-2-prom.v13  SUPERSEDED
az-test-2-prom.v14  SUPERSEDED
az-test-2-prom.v15  SUPERSEDED
az-test-2-prom.v16  SUPERSEDED
az-test-2-prom.v17  DEPLOYED
az-test-2-prom.v18  FAILED
az-test-2-prom.v19  FAILED
az-test-2-prom.v2   SUPERSEDED
az-test-2-prom.v20  FAILED
az-test-2-prom.v21  FAILED
az-test-2-prom.v22  FAILED
az-test-2-prom.v23  FAILED
az-test-2-prom.v24  FAILED
az-test-2-prom.v25  FAILED
az-test-2-prom.v26  FAILED
az-test-2-prom.v27  FAILED
az-test-2-prom.v28  FAILED
az-test-2-prom.v29  FAILED
az-test-2-prom.v3   SUPERSEDED
az-test-2-prom.v30  FAILED
az-test-2-prom.v4   SUPERSEDED
az-test-2-prom.v5   FAILED
az-test-2-prom.v6   SUPERSEDED
az-test-2-prom.v7   SUPERSEDED
az-test-2-prom.v8   SUPERSEDED
az-test-2-prom.v9   FAILED



md5-6d9e4edff5e9111525fecb734bfec15a



for ii in {17..30}
> do
>   kubectl -nkube-system delete cm az-test-2-prom.v${ii}
> done



md5-cf6357e67a21fb9f80abb7b78b9e5b8e



kubectl -nkube-system patch cm az-test-2-prom.v16 -p '{"metadata": {"labels": {"STATUS": "DEPLOYED"}}}'

4. * (महत्वपूर्ण) खोजें सभी संसाधन मौजूदा नए संसाधनों को पिछले तैनात (v16) से जोड़ा गया था और उन्हें हटा दें, उदाहरण के लिए
kubectl -nmonitor delete cm az-test-2-prom-prometheus-grafana-config
kubectl -nmonitor delect svc ...

helm upgrade ... चलाएं और हैप्पी हेमिंग देखें

जैसा कि @ kosta709 ने कहा, अंतिम रूप से जारी रिलीज के लिए, चार्ट या वर्तमान स्थिति (जो भी गलत है) को ठीक करना और एक नया उन्नयन करना, आमतौर पर काम करता है।

हेलम सॉफ्टवेयर का एक बड़ा टुकड़ा है जिसे कुछ स्वचालित वर्कफ़्लोज़ (CI / CD) में छोड़ा जा सकता है यदि कमांड का परिणाम स्थिर नहीं है।

क्या कोई विकल्प है जो ज्ञात समाधानों को अंततः हेल्म में लागू किया जाता है (इस) को अच्छी तरह से ज्ञात (और थोड़ा कष्टप्रद) समस्या को हल करने की कोशिश करें? धन्यवाद।

इसलिए, हाल ही में मैं इसे अक्सर मार रहा हूं, मुझे इस मुद्दे पर काम करने के लिए पर्याप्त है। शुरुआत के लिए, मैंने एक वर्कअराउंड बनाया है (
https://github.com/Nopik/helm/commit/afe6451cc2c6295e71ea2213ccce654ec3f5b686) जो मूल रूप से Tiller को पुराने प्रकट से लिए गए संसाधन के बजाय एक प्रारंभिक बिंदु के रूप में मौजूदा संसाधन प्राप्त करने का कारण बनता है। मेरे लिए एक आकर्षण की तरह काम करता है, हालांकि मुझे विश्वास है कि कोर देवता इसे विलय नहीं करना चाहेंगे, क्योंकि इसमें कठोर-कोडित व्यवहार शामिल है।

एक ही व्यवहार के तहत दो बग छिपे हो सकते हैं, कम से कम एक बार जब यह बग मुझे काटता है तो मुझे बहुत से (> 40) संसाधनों को हटाना पड़ा, जिनमें कुछ पहले से मौजूद 20 सफल संस्करणों के लिए मौजूद थे। लेकिन 99% मामलों में, बस नए सिरे से बनाए गए (और अभी तक अज्ञात के लिए) संसाधनों को हटा देना होगा।

इसलिए, मैं इस बारे में सोच रहा हूं कि इसे कैसे हल किया जाए। मैं इसका वर्णन नीचे कर रहा हूँ। कोर देवता कृपया मुझे यहाँ सुधारे और अगर आप मुझसे सहमत है तो तौलना। यदि हाँ, मैं इस प्रयास का नेतृत्व करने और इसे ठीक करने के लिए पीआर प्रदान करने के लिए तैयार हूं।

आम तौर पर पतवार 'पैच' मोड में काम करती है: यदि उपयोगकर्ता किसी तरह संसाधन को संशोधित करता है, और नया रिलीज़ संस्करण कुछ अन्य मापदंडों को बदलता है, तो हेल्म 2 संशोधनों के बीच पैच की गणना करता है और इसे लागू करता है - मुझे विश्वास है कि यह उपयोगकर्ता परिवर्तनों को बरकरार रखने की कोशिश कर रहा है।

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

मुझे लगता है कि उचित तरीका या तो बेहतर चूक को चुनना होगा (मूल रूप से मेरी शाखा को विलय करना लंबा रास्ता तय करेगा), या उपयोगकर्ता के लिए ध्वज प्रदान करेगा। इस तरह:

• --ignore-old-manifest=never (डिफ़ॉल्ट, वर्तमान व्यवहार)
• --ignore-old-manifest=create-only (इस मामले पर लागू होता है, जब पुराने प्रकटन में संसाधन की कोई धारणा नहीं होती है, लेकिन संसाधन पहले से मौजूद है, हम इसे नए आधार के रूप में ले सकते हैं और बस इसे पैच कर सकते हैं, यदि आवश्यक हो) - मैं इसे नया बनाने की सिफारिश करूंगा चूक। यह भी पतवार को मैन्युअल रूप से निर्मित संसाधनों का स्वामित्व लेना शुरू करने की अनुमति देगा।
• --ignore-old-manifest=always - केवल पूर्णता के लिए, शायद कड़ाई से आवश्यक नहीं। यह हमेशा वर्तमान संसाधन और नवीनतम प्रकट के बीच पैच बनाएगा, मूल रूप से सभी उपयोगकर्ता संशोधनों को हटा देगा।

बेशक आप उल्टे तर्क का उपयोग करने के लिए झंडे का नाम बदल सकते हैं: --use-current-resources=never(currently default)/create-only/always या ऐसा ही कुछ।

बाद में, इस झंडे को संसाधन एनोटेशन से लिया जा सकता है, जैसे कुछ:

annotations:
  helm.io/ignore-old-manifest: always

कौन सा हेल्म प्रति-संसाधन इस रणनीति को पहचान सकता है और लागू कर सकता है। मुझे यकीन नहीं है कि अगर हेल्म देव वहां जाना चाहते हैं, हालांकि;)

तो, आप इस प्रस्ताव के बारे में क्या सोचते हैं?

# 3805 को भी देखें जहां हेम देव 3 तरह के मर्ज पैच पर विचार कर रहे हैं।

एक ही मुद्दा यहाँ।
Google क्लाउड बिल्ड के साथ CD / CI वातावरण सेटअप करने की कोशिश कर रहा है।
Error: UPGRADE FAILED: no Deployment with the name "baobab-sidekiq" found

मजेदार बात यह है कि तैनाती मौजूद है:

kc get deployments
NAME             DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
baobab           3         3         3            2           2d
baobab-ermis     1         1         1            1           23h
baobab-sidekiq   1         1         1            1           23h

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

क्या हेल का इरादा सीआई / सीडी पाइपलाइन में काम करने में सक्षम है?

धन्यवाद

Client: &version.Version{SemVer:"v2.9.1", GitCommit:"20adb27c7c5868466912eebdf6664e7390ebe710", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.9.1", GitCommit:"20adb27c7c5868466912eebdf6664e7390ebe710", GitTreeState:"clean"}

मैं भी इस में चल रहा हूँ, पतवार 0.8.0 को helm 1.0.0 में अपग्रेड करने की कोशिश कर रहा हूँ।

helm version --tls Client: &version.Version{SemVer:"v2.9.1", GitCommit:"20adb27c7c5868466912eebdf6664e7390ebe710", GitTreeState:"clean"} Server: &version.Version{SemVer:"v2.9.1", GitCommit:"20adb27c7c5868466912eebdf6664e7390ebe710", GitTreeState:"clean"}

मैं एक चार्ट की आवश्यकताओं को अपग्रेड करते समय इसमें भी भाग रहा हूं। मैं देख रहा हूं कि इस्तियो इस बग में भाग रहा है, साथ ही उनके स्थापित डॉक helm template का उपयोग करता है। क्या इस मुद्दे के लिए एक समाधान है?

Https://github.com/helm/helm/issues/3805 में हाल की चर्चाओं की जाँच

यह होने के नाते, अभी भी नवीनतम पतवार 2.10 के लिए होता है

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

बहुत सारे गिथब स्टार के साथ बड़ी जिम्मेदारियां आती हैं

@ ब्रेंडन-रिअस आप इस मुद्दे को ठीक करने के लिए कोड का योगदान करने के लिए स्वागत करते हैं, या विचारों के बारे में सोचते हैं। कुछ बिंदुओं के लिए # 3805 और # 4146 देखें।

@ ब्रेंडन-रीस, # 3805 में विशेष रूप से इस बग के बारे में सबसे हालिया चर्चा है। मैं अत्यधिक सुझाव देता हूं कि उस धागे को पढ़ने के लिए एक विचार प्राप्त करें कि हम किस चीज के खिलाफ हैं।

3-मर्ज की रणनीतियों की तुलना में इस मुद्दे से अधिक संबंधित होने के कारण मेरी टिप्पणी को यहां पर दोहराएं:

यदि हेल्म 2.yz में नई तैनाती के लिए तीन तरह से मर्ज व्यवहार्य नहीं है, तो # 1193 कब तय किया जाएगा? बग लगभग दो वर्षों के लिए खुला है जिसमें हेल्म 2.0 के लिए कोई स्पष्ट प्रस्ताव नहीं है।

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

उदाहरण के लिए, @michelleN और मैंने इस सप्ताह की शुरुआत में विचार किया और दो संभावित समाधानों के बारे में सोचा, जिनमें से कोई भी विशेष रूप से शानदार नहीं हैं:

1. जब कोई अपग्रेड विफल होता है, तो हम स्वचालित रूप से उन संसाधनों को वापस लाते हैं और इस रिलीज के दौरान बनाए गए संसाधनों को हटा देते हैं।

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

1. अपग्रेड के दौरान, यदि हम एक नया संसाधन बना रहे हैं और हम देखते हैं कि यह पहले से मौजूद है, हम इसके बजाय मौजूदा संसाधन में उन परिवर्तनों को लागू करते हैं, या इसे हटा / पुनः बनाते हैं।

यह बेहद जोखिम भरा है क्योंकि हेलम उन वस्तुओं को हटा सकता है जो अन्य पैकेजों के माध्यम से या kubectl create माध्यम से स्थापित की गई थीं, जिनमें से कोई भी उपयोगकर्ता नहीं चाहते हैं।

अब तक का सबसे सुरक्षित विकल्प उपयोगकर्ताओं को इस संघर्ष के मामले में मैन्युअल रूप से हस्तक्षेप करने के लिए कहना है, जिसे मैं नीचे प्रदर्शित करूंगा।

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

@bacongobbler , यदि 3-तरफा मर्ज सुविधा के लिए कोई समर्थन की योजना नहीं है, तो हमें वैकल्पिक या वैकल्पिक हल की आवश्यकता है। अन्यथा, # 1193 एक गंभीर रूप से दर्दनाक बोकर है।

समस्या को पुन: हल करने के लिए और साथ ही समाधान:

जब कोई नवीनीकरण जो नए संसाधन स्थापित करता है, विफल हो जाता है, तो रिलीज़ एक विफल स्थिति में चला जाता है और नवीनीकरण प्रक्रिया को रोक देता है। अगली बार जब आप helm upgrade कॉल करते हैं, तो Helm अंतिम DEPLOYED रिलीज़ के विरुद्ध एक अंतर करता है। पिछले DEPLOYED रिलीज़ में, यह ऑब्जेक्ट मौजूद नहीं था, इसलिए यह नए संसाधन बनाने की कोशिश करता है, लेकिन विफल रहता है क्योंकि यह पहले से मौजूद है। त्रुटि संदेश पूरी तरह से भ्रामक है क्योंकि @arturictus बताते हैं।

यह आसानी से मैन्युअल रूप से हस्तक्षेप करके और संसाधन को हटाने के द्वारा काम किया जा सकता है कि त्रुटि रिपोर्ट "नहीं मिली" के रूप में। उदाहरण के बाद मैंने https://github.com/helm/helm/pull/4223#issuecomment -397413568 में प्रदर्शन किया:

><> helm fetch --untar https://github.com/helm/helm/files/2103643/foo-0.1.0.tar.gz
><> helm install ./foo/
...
><> vim foo/templates/service.yaml                    # change the service name from "foo" to "foo-bar"
><> kubectl create -f foo/templates/service.yaml      # create the service
service "foo-bar" created
><> helm upgrade $(helm last) ./foo/
Error: UPGRADE FAILED: no Service with the name "foo-bar" found
><> kubectl delete svc foo-bar
service "foo-bar" deleted
><> helm upgrade $(helm last) ./foo/
Release "riotous-echidna" has been upgraded. Happy Helming!
...
><> kubectl get svc
NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
foo-bar      ClusterIP   10.104.143.52   <none>        80/TCP    3s
kubernetes   ClusterIP   10.96.0.1       <none>        443/TCP   1h

दूसरे शब्दों में, FAILED रिलीज़ के दौरान बनाए गए संसाधनों को हटाना समस्या के आसपास काम करता है।

पहले @bacongobbler , मैं पिछले कुछ हफ्तों में इस मुद्दे पर अधिक विस्तार से विचार करने के लिए धन्यवाद देना चाहता हूं। मुझे पूरी तरह से यकीन नहीं है कि इस मुद्दे को Istio 0.8.0 में Istio 1.0.0 अपग्रेड में

इस्तियो ऑपरेटर समुदाय के साथ बोलने में जिनके पास हेल्म के साथ पूर्व अनुभव है, कुछ ऑपरेटरों ने हमें बताया है कि हेल्म में अप्रबंधित संसाधन बुरी खबर हैं, और अक्सर अपग्रेड विफलताओं का कारण बनते हैं। यदि Istio चार्ट कार्यान्वयन में एक दोष है जो उन्हें Helm 2.yz के साथ अपग्रेड करने में असंगत बनाता है, तो उन असंगतताओं को ठीक करना महान होगा - इसलिए हमारे पास भविष्य में अपग्रेड विफलताएं नहीं हैं।

हम 0.8.0 से 1.0.0 अपग्रेड तक 1 बार हिट करने के लिए तैयार हैं। अगर उन्नयन लगातार परतदार है - एक अलग समस्या है।

मैंने इस्तियो पर एक द्विशताब्दी को अंजाम दिया - 27 जुलाई तक अपग्रेड काम कर रहा था (इस्टियो 1.0.0 रिलीज से 3 दिन पहले) और इस समस्या के लिए प्रतिबद्ध पाया गया: https://github.com/istio/istio/istmit/30161215008128b15069d27ff6d03cdb87420e15b15b15b15

इस पीआर ने अनिवार्य रूप से पोस्ट इंस्टॉल नौकरियों से ऑब्जेक्ट पंजीकरण को हटा दिया। मुझे विश्वास है, लेकिन मैं निश्चित नहीं हूं, हमने 3 दिन के रनअप में पोस्ट-इंस्टॉल्ड जॉब्स के सभी उदाहरणों को हटा दिया है।

क्या आप Istio के विशिष्ट Helm चार्ट पर सलाह दे सकते हैं क्योंकि यह उन्नयन से संबंधित है? क्या ऑब्जेक्ट को पोस्ट इंस्‍टॉल जॉब से बाहर रखने से हमारी अपग्रेड समस्याएं स्‍थायी रूप से हल हो जाएंगी?

मैं वास्तव में किसी भी मजबूत सलाह की पेशकश नहीं कर सकता हूं और न ही इस समस्या को हल करने के लिए प्रस्ताव का उपयोग कर सकता हूं क्योंकि हेल्म के साथ अधिक हाल के अनुभव वाले लोग एक सामान्यीकृत समाधान खोजने में असमर्थ हैं (और समस्या पर एक नज़र रखने की कमी के लिए नहीं)। मुझे नहीं लगता कि मैं बेहतर कर सकता था।

चियर्स
-स्टीव

त्रुटि को बेहतर ढंग से दर्शाने के लिए शीर्षक को अपडेट किया।

हम मुद्दे से भी प्रभावित हैं। हम GKE 10.6 के साथ नवीनतम पतवार 2.10 का उपयोग करते हैं।
मैं कब उम्मीद कर सकता हूं कि इसे ठीक किया जाएगा?
क्या हमारे पास समस्या के लिए कुछ उचित समाधान हैं? --purge विकल्प के साथ संपूर्ण परिनियोजन को हटाना इतना खराब है।

कृपया मेरी पिछली टिप्पणी के लिए स्वतंत्र महसूस करें। हमें वास्तव में यहां कैसे आगे बढ़ना है, इस पर प्रतिक्रिया की जरूरत है।

इस थ्रेड में कई बार वर्कअराउंड दोहराया गया है। कृपया https://github.com/helm/helm/issues/1193#issuecomment -419555433 के माध्यम से पढ़ें।

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

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

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

यहां तक ​​कि इस तथ्य को खारिज करते हुए कि यह इस मुद्दे को ठीक कर सकता है, ऑटो-रोलबैक एक उपयोगी सुविधा होगी और यह सुनिश्चित करने में मदद करेगी कि हेल्म रिलीज स्वभाव में अधिक लेनदेन है। यह स्थिरता और सफल तैनाती को प्राथमिकता देने के सर्वोत्तम प्रयास तैनाती से हेल्म को पिवोट करता है।

@bacongobbler नई तैनाती के लिए निम्नलिखित दृष्टिकोण व्यवहार्य होगा:

• एक ध्वज जोड़ें - -three-way-merge
• केवल उस ध्वज को helm install (नई तैनाती) में उपभोग करने की अनुमति
• एक बार यह ध्वज सक्षम हो जाने के बाद, अपग्रेड हमेशा 3 तरह के मर्ज का उपयोग करेगा
• मौजूदा तैनाती एक प्रवास पथ के बिना अटक जाएगा - मानक वैकल्पिक हल लोग इस बिंदु पर ज़रिये जुड़े हुए हैं है helm delete --purge एक के बाद helm reinstall तो यह रूप में यह पहली बार प्रकट होता अरुचिकर के रूप में नहीं हो सकता।

क्या यह वास्तव में समस्या को हल करेगा?

कुछ व्यक्ति इस हेल्म सीमा के आसपास काम करने के लिए एक ऑपरेटर के कार्यान्वयन पर विचार कर रहे हैं। यह एक गंभीर शर्म की बात होगी। Https://github.com/istio/istio/issues/8841#issue -361871147 देखें

चियर्स
-स्टीव

@Bacongobbler की पिछली टिप्पणी पर वापस जाना:

1. अपग्रेड के दौरान, यदि हम एक नया संसाधन बना रहे हैं और हम देखते हैं कि यह पहले से मौजूद है, हम इसके बजाय मौजूदा संसाधन में उन परिवर्तनों को लागू करते हैं, या इसे हटा / पुनः बनाते हैं।
   यह बेहद जोखिम भरा है क्योंकि हेलम उन वस्तुओं को हटा सकता है जो अन्य पैकेजों के माध्यम से या कुबेटल क्रिएट के माध्यम से स्थापित की गई थीं, जिनमें से कोई भी उपयोगकर्ता नहीं चाह सकता है।

मुझे आश्चर्य है कि क्या हम नए व्यवहार को ऑप्ट-इन करके इस जोखिम को कम कर सकते हैं? एक दिए गए नामस्थान के भीतर मैं आमतौर पर विशेष रूप से पतवार का उपयोग करता हूं, और मुझे संदेह है कि यह कई के लिए मामला है। अगर मैं यह बताने के लिए कि किसी दिए गए नाम स्थान में कुछ भी मौजूद नहीं है, तो मैं हेल्म को इनस्टॉल / अपग्रेड कर सकता हूँ, जो मौजूदा रिलीज़ का हिस्सा नहीं है?

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

जाहिर है कि यह सभी उपयोग के मामलों के लिए समस्या को हल नहीं करता है, लेकिन शायद यह पर्याप्त समाधान है।

@bacongobbler मैं यहाँ से जा सकता हूँ। मैं उन्नयन में इसी तरह के मुद्दों का सामना कर रहा हूं। यह देखते हुए कि इस समस्या को हल करना कितना मुश्किल है, मुझे आश्चर्य है कि अगर कुछ और मूलभूत आवश्यकताओं पर पुनर्विचार किया जाए। जटिलता का एक हिस्सा इस तथ्य के कारण प्रतीत होता है कि हेल्म वास्तविक कॉन्फ़िगरेशन का अपना संस्करण बनाए रखता है, जो वास्तविक स्रोत से अलग है जो कि कुबेरनेट्स है। क्या सिस्टम अधिक विश्वसनीय होगा यदि हेलम केवल इतिहास और रोलबैक के प्रयोजनों के लिए पहले से तैनात हेलम चार्ट की एक प्रति रखता है, लेकिन उन्नयन के दौरान इसका उपयोग नहीं किया। इसके बजाय, हेल्म को कुबेटेल से ही सच्चाई मिलेगी, और फिर हमेशा प्रदर्शन करने के लिए 2-तरीका अलग होता है?

यदि कोई पतवार चार्ट कहता है कि उसके पास संसाधन X होना चाहिए, और kubectl एक मौजूदा संसाधन X देखता है, तो:

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

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

यदि कुबेटेल रिपोर्ट करता है कि उसके पास इस Y चार्ट के नियंत्रण के रूप में संसाधन Y टैग है, और इस helm चार्ट में कोई संसाधन Y नहीं है, तो helm संसाधन को हटा देता है।

इस हेल्म चार्ट द्वारा नियंत्रित नहीं किए जाने वाले किसी भी संसाधन को अपग्रेड करते समय हमेशा हेल्म द्वारा अनदेखा किया जाता है, सिवाय ऊपर बताए मामले में जहां हेल्म चार्ट कहता है कि उसे संसाधन X की आवश्यकता है और X मौजूद है, लेकिन टैग नहीं किया गया है।

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

हम इस समस्या को भी देख रहे हैं। हमारे प्रजनन कदम:

1. helm install एक चार्ट जो सफलतापूर्वक एक तैनाती स्थापित करता है
2. मौजूदा तैनाती के अलावा एक कस्टम संसाधन शामिल करने के लिए चार्ट को अपडेट करें
3. परिनियोजन विफलता की नकल करने के लिए परिनियोजन पॉडसेप की छवि बदलें
4. helm install नया चार्ट। यह परिनियोजन के एक रोलिंग अद्यतन का कारण होगा, जिसे हमने जानबूझकर विफल होने के लिए सेट किया है।
5. हेल्म इंस्टाल फेल होना चाहिए। लेकिन कस्टम संसाधन को k8s etcd में छोड़ दिया जाना चाहिए। ( kubectl का उपयोग करके सत्यापित करें)
6. (इस समय, पतवार खराब स्थिति में है)
7. चार्ट को ठीक करें - परिनियोजन पॉडसेक में एक goot छवि डालें।
8. helm install । हम इस काम के लिए उम्मीद करते हैं, लेकिन यह नहीं है। "___ नाम से कोई संसाधन नहीं" की रिपोर्ट करता है। नाम कस्टम संसाधन का है।
9. पुनर्प्राप्ति: kubectl का उपयोग करके अवशिष्ट कस्टम संसाधन हटाएं। अब helm install काम करेंगे।

ध्यान दें कि चार्ट में एक नए शुरू किए गए कस्टम संसाधन के साथ helm install पहला प्रयास इस अवस्था में आने में विफल होना चाहिए।

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

जैसा कि # 3275 को डुप्लिकेट के रूप में बंद किया गया था: हमारे पास # 3275 में समान स्थिति है

पहले से ही चल रहा है काम my-long-running-job । हम रिलीज को अपग्रेड करने की कोशिश कर रहे हैं:

>helm upgrade --install my-release --namespace my-environment my-chart --timeout 60
Error: UPGRADE FAILED: no Job with the name "my-long-running-job" found

नौकरी मौजूद है:

>kubectl -n=my-environment get jobs
NAME                                DESIRED   SUCCESSFUL   AGE
my-long-running-job                 1         0            16m

उस काम को हटाना:

>kubectl -n=my-environment delete job my-long-running-job
job.batch "my-long-running-job" deleted

उस बाधा को हल करता है:

>helm upgrade --install my-release --namespace my-environment my-chart --timeout 60
Error: UPGRADE FAILED: timed out waiting for the condition

कम से कम संदेश no Job with the name "my-long-running-job" found भ्रामक है, लेकिन मेरी उम्मीद थी, कि नौकरी अपडेट हो जाएगी।

अभी भी इसे v2.9.1 में देखा जा रहा है (वर्तमान में स्थिर संस्करण जारी)

मैं इस बात से असहमत हूं कि अपग्रेड से बाहर जाना "बहुत खतरनाक" है। मुझे लगता है कि ऐसा करना सही उपाय है।

कुबेरनेट्स घोषणात्मक है। स्नैपशॉट उन्नत करने के लिए प्रयास करने से पहले क्लस्टर स्थिति क्या थी।
यदि कोई त्रुटि भाग है, तो स्नैपशॉट पर वापस जाएं।
यदि किसी के पास स्क्रिप्ट हुक है जो ऐसा करते समय खराब स्थिति में क्लस्टर छोड़ देगा, तो यह उनकी अपनी गलती है। (हो सकता है कि रोलबैक हुक के साथ भी हल किया जा सकता है)

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

नमस्ते,

के साथ एक ही मुद्दा था:

ग्राहक: v2.10.0 + g9ad53aa
सर्वर: v2.10.0 + g9ad53aa

सर्विस को डिलीट करना, हेल्मप और सर्विस ही हेल्म को रिलीज़ अपग्रेड करने का एकमात्र तरीका था।

नमस्ते,

हमारे पास @dilumr के समान ही समस्या है ... संस्करण 2.11.0 के साथ:

Client: &version.Version{SemVer:"v2.11.0", GitCommit:"2e55dbe1fdb5fdb96b75ff144a339489417b146b", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.11.0", GitCommit:"2e55dbe1fdb5fdb96b75ff144a339489417b146b", GitTreeState:"clean"}

Error: UPGRADE FAILED: no ConfigMap with the name "xxx" found

इस पर v2.9.1 में भाग गया।

जिस चार्ट अपग्रेड को मैं चला रहा था, उसमें बहुत सारे बदलावों के साथ एक निजी चार्ट पर कुछ प्रमुख संस्करण जंप कर रहे थे, इसलिए मुझे यकीन नहीं है कि वास्तव में आगे बढ़ने में क्या त्रुटि हुई, लेकिन यह कारण मूल रूप से FAILED स्थिति में समाप्त हुआ। यह था कि मेरे पास --wait झंडा था और यह समय समाप्त हो गया था।

हम कई डुप्लिकेट के साथ समाप्त हो गया FAILED में तैनाती helm list लेकिन अंतिम कार्य तैनाती था DEPLOYED । नई तैनाती बनाना No resource with the name x found फेंक दिया।

पिछले संस्करण के लिए helm rollback चलाकर ठीक करने में सक्षम था जो DEPLOYED पर helm list DEPLOYED राज्य में था। उस अपग्रेड के बाद जो त्रुटियों के बिना चलने में सक्षम था।

इसे देखें https://github.com/helm/helm/pull/4871।

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

मैं समझता हूं कि एक असफल हेल्म तैनात से घटकों की स्थापना रद्द करने के लिए यह कैसे मुश्किल और / या अवांछनीय हो सकता है, लेकिन इस तरह की स्थिति के लिए आदर्श हेल्म व्यवहार क्या है?

पहले, मुझे लगता है कि हेलम को नामस्थान और अन्य संसाधनों के साथ ठीक होना चाहिए जो पहले से मौजूद हैं अगर यह उन्हें (पुनः) स्थापित करने की कोशिश कर रहा है। कुबेरनेट्स के बारे में "कॉन्फ़िगरेशन को सही बनाते हैं, और क्यूब को यह पता लगाने देते हैं कि कैसे दुनिया को कॉन्फ़िगरेशन से मेल खाता है।"
दूसरा मुझे लगता है कि हेलम को ऑल-ऑल और कुछ नहीं होना चाहिए। यदि कोई परिनियोजन विफल हो जाता है, तो क्लस्टर उस स्थिति में होना चाहिए, जो परिनियोजन प्रारंभ होने से पहले था।
यदि दो रिलीज़ हैं जो दोनों नामस्थान X बनाना चाहते हैं, तो एक संदर्भ गिनती समस्या है। यदि कोई रिलीज़ है जो नाम स्थान X बनाना चाहता है, लेकिन यह पहले से मौजूद है, तो एक समस्या है। हालांकि, हेलम ऑब्जेक्ट्स पर एनोटेशन का उपयोग करके इसे रिकॉर्ड कर सकता है, और सही काम कर सकता है।

मैं इस मुद्दे को लेटेस्ट हेल्म २.१२.० और कुबेरनेट्स १.१०.११ के साथ ले रहा हूँ, यहाँ तक कि लेटेस्ट गुड रिलीज़ के लिए भी रोल कर रहा हूँ क्योंकि @aguilarm ने सुझाव दिया था कि यह भी काम नहीं करेगा, उन संसाधनों को हटाना जो हेल्म के बारे में शिकायत करते हैं, मदद नहीं करते हैं और अपग्रेड के बाद कमांड विफल रहता है यह उन्हीं संसाधनों को छोड़ देता है जो वास्तव में आंशिक रूप से पुन: निर्मित होते हैं। एक उत्पादों env के लिए बहुत कष्टप्रद ...

मेरे पास बहुत ही समान वातावरण के साथ 2 क्लस्टर हैं, जिनमें से 2 अलग-अलग नोड्स की कुल संख्या है। एक मामले में एक helm delete --purge बाद ताजा helm install काम किया गया, लेकिन दूसरे में ऐसा नहीं हुआ और मुझे अभी तक नवीनतम टेम्पलेट परिवर्तनों को लाने के लिए एक तरीका निकालने की ज़रूरत नहीं है।

क्या इस पर कोई ईटीए है?

मैं helm rollback साथ इसे प्राप्त करने में सक्षम था और सबसे हालिया संशोधन (जो विफल रहा) को निर्दिष्ट करता है

आज भी यही मुद्दा था,
Error: UPGRADE FAILED: no Service with the name "xxx-api" found
kubectl get svc -n stage | grep xxx-api
xxx-api ClusterIP 172.20.149.229 <none> 8300/TCP 19h
helm rollback काम किया।

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

ऊपर मैंने जिस निदान और समाधान को देखा है। मुझे बताना अगर ये आप के लिए काम करता है।

@bacongobbler प्रतिक्रिया के लिए धन्यवाद। यह वास्तव में मेरे साथ आया वर्कअराउंड है और इसे अभी के लिए सहना होगा, लेकिन हम अपने CICD के माध्यम से दिन में दर्जनों बार हेल्म अपग्रेड का उपयोग कर रहे हैं, इसलिए यह फसलें अक्सर सिरदर्द बन जाती हैं। मुझे यकीन नहीं है कि उपरोक्त पूरी कहानी है, क्योंकि नामित संसाधन अक्सर पहले से ही मौजूद हैं, एक सफल तैनाती का हिस्सा है और वर्तमान तैनाती में नहीं बदला जा रहा है - iirc यह हमेशा अंतिम सफल तैनाती में संसाधनों का सबसे हाल का सेट है हालांकि काफी दिलचस्प है।

+1 to @ajcann और धन्यवाद @bacongobbler
मैं ठीक उसी स्थिति में हूं।
हमारी CICD स्वचालित है और अक्सर तैनाती कम वातावरण के लिए सुस्त बॉट द्वारा की जाती है।
जब यह विफल हो जाता है, तो मुझे मैन्युअल रूप से हेल्म रोलबैक और फिर से तैनात करना होगा।
मुद्दा लगातार नहीं बल्कि लगातार है।
मेरे लिए, यह चार्ट / संसाधन की अब तक की दूसरी तैनाती के दौरान ही होता है।
संसाधन हमेशा मौजूद रहते हैं।

हम उसी समस्या का निरीक्षण करते हैं। यदि आपके पास कोई टेम्पलेट है, तो यह होता है:

• एक {{if $condition -}} कथन में
• या एक {{ range $index, $value := $array-}}

@jkroepke ने मुझे बताया कि PR # 5143 इसके लिए एक अच्छा समाधान प्रदान करता है। जब अगले मामूली संस्करण में --atomic झंडा जारी किया जाता है, तो आपको त्रुटि होने पर स्वचालित रूप से शुद्ध या रोलबैक करने के लिए इसका उपयोग करने में सक्षम होना चाहिए।

@bacongobbler दिए गए आप इस पर सबसे आगे और पीछे शामिल हैं, क्या कुछ और है जो इसे पूरी तरह से ठीक करने के लिए किया जा सकता है, या --atomic झंडा पर्याप्त होगा?

मुझे लगता है कि @distorhead उस पर एक नज़र https://github.com/helm/helm/pull/4871 में उठाई है --atomic तरह लग रहा है चिंता को संबोधित करते हुए आपको हमेशा --atomic ध्वज का उपयोग करना चाहिए।

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

• मैन्युअल रूप से क्लस्टर की लाइव स्थिति पर जाएं और इसे वर्कअराउंड के अनुसार ठीक करें
• हेल्म 2.13.0 में अपग्रेड करें और helm upgrade --atomic उपयोग करें

तब मुझे लगता है कि इसे बंद करना सुरक्षित है।

उम्मीद है कि हेलम 2.13.0 इतनी दूर नहीं है।
यह बग CI को तोड़ता है यदि किसी रिलीज पर कहीं एक त्रुटि हुई।

परमाणु समस्या का समाधान नहीं करेगा

उदाहरण चार्ट: https://github.com/distorhead/ex-helm-upgrad-failure

1. मास्टर की जाँच करें, तैनाती चलाएं।

git clone https://github.com/distorhead/ex-helm-upgrade-failure
cd ex-helm-upgrade-failure
helm upgrade --atomic --install --namespace myns myrelease .

चार्ट में 2 तैनाती हैं - myserver1 और myserver2 :

Release "myrelease" does not exist. Installing it now.
NAME:   myrelease
LAST DEPLOYED: Tue Feb  5 23:48:57 2019
NAMESPACE: myns
STATUS: DEPLOYED

RESOURCES:
==> v1beta1/Deployment
NAME       READY  UP-TO-DATE  AVAILABLE  AGE
myserver1  1/1    1           1          5s
myserver2  1/1    1           1          5s

1. ब्रेकिंग बदलाव करें। चार्ट से तैनाती myserver1 हटाएं और उपयोगकर्ता-त्रुटि के साथ तैनाती myserver2 संशोधित करें (उदाहरण के लिए छवि फ़ील्ड हटाएं):

git checkout break-atomic
git diff master

diff --git a/templates/deploy.yaml b/templates/deploy.yaml
index 198516e..64be153 100644
--- a/templates/deploy.yaml
+++ b/templates/deploy.yaml
@@ -1,21 +1,5 @@
 apiVersion: apps/v1beta1
 kind: Deployment
-metadata:
-  name: myserver1
-spec:
-  replicas: 1
-  template:
-    metadata:
-      labels:
-        service: myserver1
-    spec:
-      containers:
-      - name: main
-        command: ["/bin/bash", "-c", "while true ; do date ; sleep 1 ; done"]
-        image: ubuntu:16.04
----
-apiVersion: apps/v1beta1
-kind: Deployment
 metadata:
   name: myserver2
 spec:
@@ -28,4 +12,3 @@ spec:
       containers:
       - name: main
         command: ["/bin/bash", "-c", "while true ; do date ; sleep 1 ; done"]
-        image: ubuntu:16.04

1. रन तैनाती:

git checkout break-atomic
helm upgrade --atomic --install --namespace myns myrelease .

हमारे मित्र को फिर से नमस्कार कहें:

UPGRADE FAILED
ROLLING BACK
Error: Deployment.apps "myserver2" is invalid: spec.template.spec.containers[0].image: Required value
Error: no Deployment with the name "myserver1" found

@bacongobbler @ thomastaylor312 @jkroepke

@distorhead इस परिदृश्य के लिए आपका अपेक्षित व्यवहार क्या था?

रोलबैक के बारे में थोड़ा ऑफटॉप, लेकिन फिर भी।

उन लोगों के लिए, जो रोलबैक का उपयोग करना चाहते हैं, लेकिन कुछ कारणों से --atomic में तैनात होने के तुरंत बाद रोलबैक नहीं चाहते हैं। क्योंकि, उदाहरण के लिए, उपयोगकर्ता के पास असफलता के बाद खराब क्लस्टर स्थिति का मैन्युअल रूप से निरीक्षण करने का कोई रास्ता नहीं है और क्योंकि --wait ध्वज हेल्म का कारण नहीं बनता है जो तैनात किए जा रहे संसाधनों में विफलताओं के बारे में कोई जानकारी नहीं देता है। फिर कुछ रास्ता है: अगले रन पर रोलबैक, उन्नयन से पहले (अधिक जानकारी https://github.com/helm/helm/issues/3149#issuecomment-462271103)

समस्या को पुन: हल करने के लिए और साथ ही समाधान:

जब कोई नवीनीकरण जो नए संसाधन स्थापित करता है, विफल हो जाता है, तो रिलीज़ एक विफल स्थिति में चला जाता है और नवीनीकरण प्रक्रिया को रोक देता है। अगली बार जब आप helm upgrade कॉल करते हैं, तो Helm अंतिम DEPLOYED रिलीज़ के विरुद्ध एक अंतर करता है। पिछले DEPLOYED रिलीज़ में, यह ऑब्जेक्ट मौजूद नहीं था, इसलिए यह नए संसाधन बनाने की कोशिश करता है, लेकिन विफल रहता है क्योंकि यह पहले से मौजूद है। त्रुटि संदेश पूरी तरह से भ्रामक है क्योंकि @arturictus बताते हैं।

यह आसानी से मैन्युअल रूप से हस्तक्षेप करके और संसाधन को हटाने के द्वारा काम किया जा सकता है कि त्रुटि रिपोर्ट "नहीं मिली" के रूप में। उदाहरण के बाद मैंने # 4223 (टिप्पणी) में प्रदर्शन किया:

><> helm fetch --untar https://github.com/helm/helm/files/2103643/foo-0.1.0.tar.gz
><> helm install ./foo/
...
><> vim foo/templates/service.yaml                    # change the service name from "foo" to "foo-bar"
><> kubectl create -f foo/templates/service.yaml      # create the service
service "foo-bar" created
><> helm upgrade $(helm last) ./foo/
Error: UPGRADE FAILED: no Service with the name "foo-bar" found
><> kubectl delete svc foo-bar
service "foo-bar" deleted
><> helm upgrade $(helm last) ./foo/
Release "riotous-echidna" has been upgraded. Happy Helming!
...
><> kubectl get svc
NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
foo-bar      ClusterIP   10.104.143.52   <none>        80/TCP    3s
kubernetes   ClusterIP   10.96.0.1       <none>        443/TCP   1h

दूसरे शब्दों में, FAILED रिलीज़ के दौरान बनाए गए संसाधनों को हटाना समस्या के आसपास काम करता है।

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

आप helm diff समान एक प्लगइन लिख सकते हैं जो अंतिम रिलीज़ में बनाए गए टेम्प्लेट की गणना करेगा। आप सीधे हेल्म से pkg/kube उपभोग भी कर सकते हैं। client.Update में हेल्म के संसाधन ट्रैकिंग / विलोपन के लिए कुछ व्यावसायिक तर्क लिखे गए हैं, जिनका उपयोग टिलर से दो रिलीज प्राप्त करने और तुलना क्रम को उलटने से किया जा सकता है। target.Difference(original) आपको उन सभी संसाधनों का परिणाम देना चाहिए जो पिछली रिलीज़ के बाद से पेश किए गए थे।

@bacongobbler आप किस समाधान के लिए आवेदन को लेने की सिफारिश करेंगे जो रिलीज ए के हिस्से के रूप में तैनात है (उदाहरण के लिए कई अनुप्रयोगों से बना एक बड़ा रिलीज) और इसे रिलीज ए से बाहर तोड़ने के बिना अपने स्वयं के रिलीज (या इसके विपरीत) में किसी भी डाउनटाइम के बिना। (संसाधनों को हटाने के लिए समाधान कुछ डाउनटाइम का कारण होगा) ... इस Github समस्या द्वारा वर्णित त्रुटि में एक भिन्न रिलीज़ परिणाम के माध्यम से संसाधन को अद्यतन करने का प्रयास कर रहा है।

यह इस नए चार्ट की तरह लग रहा है और इसे स्थापित किया गया है और सक्सेफुल की तैनाती से पहले ही पुराने चार्ट को बदल देता है। एक असफल उन्नयन के साथ एक ही बात - स्थापना। यदि चार्ट गलत है तो यह स्थापित नहीं होता है।
त्रुटि पर पिछली स्थिति में रोलबैक करें या सफलता पर टिलर चार्ट अपडेट करें।

यह एक ऐसी प्रक्रिया है जिसका उपयोग मैं इस समस्या से उबरने के लिए करता हूं (अब तक यह हर बार बिना किसी घटना के काम किया है ... लेकिन फिर भी सावधान रहें):

1. helm list चलाएं और प्रभावित चार्ट के लिए नवीनतम संशोधन का पता लगाएं

   NAME        REVISION UPDATED                  STATUS  CHART              NAMESPACE
   fetlife-web 381      Thu Mar 15 19:46:00 2018 FAILED  fetlife-web-0.1.0  default
   

2. वहां से जाएं और DEPLOYED राज्य के साथ नवीनतम संशोधन ढूंढें
   kubectl -n kube-system edit cm fetlife-web.v381 kubectl -n kube-system edit cm fetlife-web.v380 kubectl -n kube-system edit cm fetlife-web.v379 kubectl -n kube-system edit cm fetlife-web.v378
3. एक बार जब आप अंतिम रूप से संशोधित संशोधन पा लेते हैं, तो इसकी स्थिति को DEPLOYED से SUPERSEDED और फ़ाइल को सहेजें
4. helm upgrade फिर से करने की कोशिश करें, अगर यह सफल है तो आप कर रहे हैं!
5. यदि आप इस तरह उन्नयन त्रुटि का सामना करते हैं:
   Error: UPGRADE FAILED: "fetlife-web" has no deployed releases
   तब FAILED से DEPLOYED अंतिम संशोधन के लिए स्थिति संपादित करें
   kubectl -n kube-system edit cm fetlife-web.v381
6. helm upgrade फिर से करने की कोशिश करें, अगर यह फिर से विफल हो जाए तो बस तालिका फ्लिप करें ...

@bacongobbler @michelleN
क्या इस समस्या के लिए त्रुटि संदेश में सुधार करना कठिन है?

मेरा मानना ​​है कि त्रुटि संदेश में कहा जाना चाहिए कि "एक संघर्ष है क्योंकि संसाधन हेल्म द्वारा नहीं बनाया गया था और मैनुअल हस्तक्षेप की आवश्यकता है" और "नहीं मिला"। त्रुटि में केवल इस छोटे से परिवर्तन से उपयोगकर्ता अनुभव में एक अच्छा अंतर आ जाएगा।

@ Selslack मैं त्रुटि संदेश में सुधार के पक्ष में बहुत I होगा

@michelleN मैंने त्रुटि पाठ को बदलने के लिए एक PR तैयार किया है: # 5460।

मैं इस मुद्दे का अनुभव कर रहा हूं और मैं ऐसी स्थिति में हूं जहां मुझे यकीन नहीं है कि इसे कैसे हल किया जाए।

मैंने यहां @reneklacan द्वारा सूचीबद्ध सभी चरणों की कोशिश की: https://github.com/helm/helm/issues/1193#issuecomment -470208910

दुर्भाग्य से यह काम नहीं किया। समस्या हल करने वाली एकमात्र चीज़ त्रुटि संदेश उत्पन्न करने वाले संसाधन को हटाना है, फिर helm upgrade फिर से, जो सफल होगा।

हालांकि, अगला हेल्म अपग्रेड एक ही त्रुटि के साथ विफल हो जाएगा, और मुझे संसाधन को फिर से हटाना होगा और पुन: नवीनीकरण करना होगा ... यह टिकाऊ या अच्छा नहीं है।

मेरे पास दो वातावरण हैं जिन्हें मैं अपने CI प्रक्रिया के भाग के रूप में तैनात करने के लिए पतवार का उपयोग करता हूं: एक क्यूए और एक उत्पादन वातावरण।

क्यूए पर्यावरण का एक ही मुद्दा था इसलिए मैंने helm delete --purge , और फिर helm upgrade - ने समस्या को स्थायी रूप से हल किया।

हालाँकि, मैं इसे प्रोडक्शन के माहौल के लिए नहीं कर सकता - मैं इसे मिटा नहीं सकता और फिर से अपग्रेड कर सकता हूँ, इसलिए वर्तमान में मैं अपनी तैनाती से पहले संसाधन को हटा रहा हूँ। मैं भाग्यशाली हूं कि यह एक आयात संसाधन नहीं है।

@zacharyw इस समय आप किस त्रुटि का सामना कर रहे हैं? No resource with the name ... या "fetlife-web" has no deployed releases ?

क्या आप कोई अतिरिक्त जानकारी साझा कर सकते हैं जो इसे डीबग करने में मदद करेगी?

शायद kubectl -n kube-system describe cm -l NAME=YOUR_RELEASE_NAME | grep -A1 STATUS= का उत्पादन ( YOUR_RELEASE_NAME बदलें)

यदि आप संभावित रूप से असंबंधित डेटा (rene (at) klacan (dot) sk) के साथ इस मुद्दे को स्पैम नहीं करना चाहते हैं तो मुझे अधिक जानकारी के साथ एक ईमेल भेजने के लिए स्वतंत्र महसूस करें।

कृपया संभावित निदान और वर्कअराउंड @zacharyw के लिए https://github.com/helm/helm/issues/1193#issuecomment -419555433 देखें।

@reneklacan यह no resource with the name ... त्रुटि है। हमारे मामले में हमने एक प्रवेश किया, यह प्रतीत होता है कि काम किया है, लेकिन फिर बाद में उन्नयन इस त्रुटि के साथ विफल होना शुरू कर दिया ... भले ही प्रवेश मौजूद था।

मेरी सबसे हालिया रिलीज़ की स्थिति (आपत्तिजनक प्रवेश को हटाने और पतवार को फिर से बनाने के लिए अपग्रेड करने की अनुमति देने के बाद) DEPLOYED :

STATUS=DEPLOYED
VERSION=197

हालांकि, अगर मुझे फिर से अपग्रेड करने की कोशिश की जाती, तो यह विफल हो जाता।

@bacongobbler जब तक मैं गलत नहीं समझ रहा हूं मुझे लगता है कि मैं पहले से ही उस टिप्पणी में वर्कअराउंड कर रहा हूं: मैं संसाधन को हटा देता हूं और इसे पुनः प्राप्त करने देता हूं ... मुद्दा यह है कि मुझे हर बार ऐसा करना होगा।

@reneklacan in https://github.com/helm/helm/issues/1193#issuecomment -470208910 ने मेरी जान बचाई।

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

यह बहुत अच्छा होगा यदि इस तरह की त्रुटि दिखाई देने पर हेल्म ने स्वयं का डेटाबेस अपडेट किया और फिर पुनः प्रयास करें।

मेरा मानना ​​है कि --cleanup-on-fail ध्वज सक्षम होने के साथ, यह त्रुटि मामला दूर हो जाना चाहिए। # 4871 और # 5143 के माध्यम से बंद करने के रूप में।

यदि उन झंडों के बिना आगे कोई समस्या उत्पन्न होती है, तो कृपया एक नया मुद्दा फिर से खोलें। धन्यवाद!

यह मुद्दा बंद हो गया है, मैंने बिना हेल्म रिलीज या चल रही तैनाती को हटाए बिना इस मुद्दे से निपटने के बारे में एक टिप्पणी जोड़ने के बारे में सोचा।

इसलिए, मैंने निम्नलिखित चरणों के साथ समस्या को पुन: प्रस्तुत किया:

1. एक सेवा टेम्पलेट के साथ चार्ट test-chart-failure स्थापित करें।
2. एक सेवा टेम्पलेट के साथ एक सबचर्ट जोड़ें जिसमें सेवा के बंदरगाह में एक स्ट्रिंग (जैसे "परीक्षण") है
3. चार्ट अपग्रेड करें। यह Service in version "v1" cannot be handled as a Service: v1.Service.Spec: v1.ServiceSpec.Ports: []v1.ServicePort: v1.ServicePort.Port: readUint32: unexpected character: ... त्रुटि के साथ विफल हो जाएगा

मैं http://centosquestions.com/helm-how-to-delete-bad-deployment पर सुझाव लागू करके, helm delete चलाने के बिना, पोर्ट को सही करने के बाद अपग्रेड करने में सक्षम था:

1. helm history test-chart-failure साथ विफल संशोधन मिला
2. kubectl delete cm -n kube-system test-chart-failure.v2 साथ विशिष्ट संशोधन के कॉन्फ़िगर किए गए मानचित्र को हटा दिया गया
3. सही चार्ट के साथ helm upgrade