Helm: فشلت الترقية: لم يتم العثور على مورد بالاسم ""

أواجه مشكلة مماثلة حيث لدي مخطط مع التبعيات المجمعة. إذا أضفت تبعية جديدة وقمت بتشغيل 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.

devth لست قادرًا على إعادة إنتاج هذه المشكلة على المستوى الرئيسي. هل مازلت ترى هذه المشكلة؟ ما هو إصدار الدفة / الحارث الذي تستخدمه؟

شكرا!

elementalvoid لم أتمكن أيضًا من إعادة إنتاج خطأ التبعية الجديد على Master. هل مازلت ترى هذه المشكلة؟ ما هو إصدار الدفة / الحارث الذي تستخدمه؟

شكرا لك.

في ذلك الوقت كنت في الإصدار alpha 4. باستخدام مثال alpha 5 و devth ، لم أتمكن أيضًا من إعادة

على ما يرام. سأغلق هذا الآن. لا تتردد في تقديم مشكلة إذا رأيت أيًا من هذه المشاكل مرة أخرى.

شكرا لك مرة أخرى.

michelleN شكرا! آسف لم يكن لدي الوقت هذا الأسبوع لمحاولة إعادة على الماجستير. نتطلع إلى الترقية قريبا!

نفس الشيء بالنسبة لي عند نقل مواصفات حجم / نشر مسار المضيف إلى PVC.
يبدو أن الخطأ يحدث عندما يعتمد بيان الترقية على واحد جديد ("مفقود" في القديم؟)
الإصدار: 2.7.2.2

غريب ، أرى نفس السلوك يحاول ترقية مخطط في الإصدار 2.7.2 بدور جديد. يشكو تيلر من أنه لا يمكنه العثور على الدور ويفشل في عمليات النشر ، على الرغم من أنه أنشأ الدور بالفعل.

كان موقفي هو أن لدي موردًا جديدًا ، وقمت بنشر الإصدار الجديد من مخطط الدفة مع المورد الجديد. فشل هذا النشر ب / ج لقد اصطدمت ببعض اليامل. حسنًا ، تم إنشاء الكائنات الجديدة في kubernetes. لقد أصلحت yaml ، وقمت بتشغيل الترقية على الرسم البياني الخاص بي مرة أخرى ، وفويلا ، تظهر رسالة الخطأ التي تفيد بأن المورد غير موجود. اضطررت للذهاب إلى kubernetes وإزالة الموارد الجديدة (في حالتي دور و rolebinding) التي تم إنشاؤها بواسطة النشر الفاشل. بعد ذلك ، فشل فحص الدفة لمعرفة ما إذا كان الكائن الحالي موجودًا (https://github.com/kubernetes/helm/blob/7432bdd716c4bc34ad95a85a761c7cee50a74ca3/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

تم إنشاء Configmap

$ 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

أواجه هذه المشكلة أيضًا

العميل: & version.Version {SemVer: "v2.8.0"، GitCommit: "14af25f1de6832228539259b821949d20069a222"، GitTreeState: "clean"}
الخادم: & version.Version {SemVer: "v2.8.0"، GitCommit: "14af25f1de6832228539259b821949d20069a222"، GitTreeState: "clean"}

يحدث هذا بشكل متكرر مع استخدامنا للقيادة ويتطلب --purge كاملًا. هذا ليس حلاً.

لا يمكن تطبيقه إذا كنت تستخدم CI / CD.
ماذا يحدث إذا فشلت الترقية واستخدمت إستراتيجية التحديث المتداول. هل يجب علي حذف إصداري الذي لا يزال يعمل؟

أرى نفس المشكلة أيضًا عند وجود مشكلة نشر أو ما شابه ذلك ولكن تم إنشاء السر / سم ولكن بعد ذلك يفقد هيلم مساره ، ويرفض السماح لك بفعل الكثير.

لقد رأيته ، نادرًا ، يحدث حتى في إصدار غير مكسور (أي يُنظر إليه على أنه قد مر) لكنني لم أفهم بعد ما يمكن أن يسبب ذلك.

يمكننا أيضًا إعادة إظهار هذه المشكلة (الخادم v2.8.2) عند إضافة موارد إلى عمليات نشر الدفة الحالية. سيكون الاضطرار إلى حذف النشر وإعادة النشر في كل مرة يجب إضافة مورد جديد مشكلة كبيرة في الإنتاج.

في حالتنا ، كنا نضيف configmap إلى الرسم البياني وفشلت ترقية المخطط بـ:

خطأ: فشل الترقية: لا يوجد مورد بالاسم "" وجدت

ملاحظة: نحن نستخدم 2.7.2 ؛

أعتقد أن هذا يحدث لأنه عندما تحدد helm ما تم تغييره ، فإنها تبحث عن مورد configmap الجديد في الإصدار القديم ، ويفشل في العثور عليه. راجع 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 للخدمة المنتشرة ، وربما أشياء أخرى أيضًا.

إنني أقوم بتغيير اسم خدمة في إصدار وفشلت في الترقية باستخدام:

خطأ: فشلت الترقية: لم يتم العثور على خدمة بالاسم "new-service-name"

سأكون على استعداد لإنشاء علاقات عامة لإصلاح هذا السلوك ، لكني أرغب في معرفة الطريقة المقصودة أو المقترحة للتعامل مع هذا الأمر. حتى علامة CLI التي تسمح - للقوة أن تأخذ الأسبقية ستكون رائعة.

اتفق على الأهمية.

قد تكون هذه المشكلة غريبة عندما لا يمكنك ببساطة حذف النشر.

لقد وجدت أن مشكلتنا كانت بسبب فشل نشر.

لا يحاول Helm التنظيف بعد نشر فاشل ، مما يعني أنه يتم إنشاء أشياء مثل ConfigMap الجديد الذي أضفته أعلاه ولكن بدون مرجع في النشر "المسبق". هذا يعني أنه عند حدوث النشر التالي ، يجد helm المورد في k8s ويتوقع أن تتم الإشارة إليه في أحدث مراجعة تم نشرها (أو شيء من هذا القبيل ؛ لست متأكدًا من المنطق الدقيق الذي يستخدمه للعثور على الإصدار "السابق") للتحقق من ما هناك تغييرات. إنه ليس في هذا الإصدار ، لذلك لا يمكنه العثور على المورد ويفشل.

هذه مشكلة بشكل أساسي عند تطوير مخطط لأن النشر الفاشل يضع k8s في دفة الحالة لا يتتبع بشكل صحيح. عندما اكتشفت أن هذا هو ما كان يحدث ، علمت أنني بحاجة فقط إلى حذف ConfigMap من 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 سيكون مفيدًا للغاية ، مما يؤدي إلى إرجاع التغييرات الفاشلة.

يحدث هذا بالنسبة لي مع الإصدار 2.7.2 عند إضافة موارد جديدة إلى الرسم البياني.
هل هناك تقدير لموعد الإصلاح لهذا؟

يجب إصلاح ذلك بالرقم 4146.

تحرير: انظر أدناه

لذلك وجدت بعض الأخطاء مع # 4146 مما يجعلها علاقات عامة غير مرغوب فيها للمضي قدمًا. لقد أبلغت عن النتائج التي توصلت إليها بين master و # 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. لم يؤد حذف الموارد إلى حل المشكلة ، لذلك اضطررنا إلى إزالة الإصدار بأكمله.

كذلك هنا. ليس فقط Configmaps لدي واحدة مع ServiceAccount.

PVC هنا. :)

في الأساس ، يخضع كل نوع من الكائنات ذات الأولوية لهذا الخطأ.

هل هناك شخص معين لإصلاح هذا؟ هل يوجد علاقات عامة لهذا بالفعل؟ هل يمكنني المساعدة في أي شيء؟

لقد تعرضت للعض من هذه المشكلة أكثر من مرة لأنه من السهل أن تدخل نفسك ولكن يبدو أنه لا توجد طريقة سهلة للخروج منها. أفترض أن الجزء "الجيد" في حالتي هو أنه يتم تحديث الموارد حتى مع وجود خطأ في الإصدار (لست متأكدًا مما إذا كان ذلك يجعلني سعيدًا أو قلقًا)

أعتقد أن الدفة يجب أن تمنع المستخدم من الدخول في هذه الحالة الخاطئة أو التعامل معها بشكل صحيح.
هل هناك أي إصلاحات حقيقية لهذا خارج حذف كل شيء (هذا قابل للتطبيق فقط للاستخدامات غير الإنتاجية)؟

إذا كان بإمكان أي شخص آخر تحديد حالة الحافة الأخرى حيث لم يؤد حذف المورد إلى حل المشكلة ، فسيكون ذلك مفيدًا جدًا في تحديد السبب الجذري لحل هذه المشكلة بالذات. قد تكون هناك مسارات متعددة يمكن أن ينتهي بها الأمر بنفس الخطأ.

Draiken لا ، لقد حاولنا إيجاد حلول متعددة للمشكلة ، ولا يبدو أي منها منطقيًا كما هو أيضًا

أ) لا تجري الترقية على النحو المنشود ، أو
ب) إدخال أخطاء جديدة

لقد كتبت عن هذه الحلول هنا ولماذا لا تعمل. إذا تمكنت من إيجاد حل بديل ، فسيسعدنا إلقاء نظرة عليه.

لا يمكننا منع المستخدمين من الدخول في هذه الحالة الخاطئة أيضًا ؛ لقد بحثنا في الحلول ولكنهم جميعًا يقدمون مجموعة مختلفة من المشكلات. بمجرد أن يكون التثبيت في حالة غير متسقة ، من الصعب "إصلاحه" بدون تدخل يدوي. 😢

الحل الذي نجح بالنسبة لي هو إجراء helm rollback ... إلى اليمين قبل حدوث الفشل. ثم أتحقق من صحة أن الرسم البياني يعمل على إصدار جديد مع helm install -n new-test-release . .

بمجرد أن يعمل كل شيء ، أقوم بتنظيف الإصدار التجريبي وتشغيل helm upgrade ... مقابل الإصدار القديم ؛ وعمل كل شيء. هذا حل مزعج ولكن يبدو أنه يعمل.

لا أعرف ما إذا كان هذا مفيدًا على الإطلاق ، لكنني واجهت هذه المشكلة في كل من مجموعتي الاختبار والإنتاج.

كانت التغييرات التي أجريتها على ملفات دفتري بسيطة جدًا:
كان لدي عملية نشر واحدة ، مع ميزانية مرتبطة بالخدمة و poddisruption ، والتي تُركت دون تغيير.
لقد أضفت نشرًا ثانيًا ، مع الخدمة الخاصة به وميزانية poddisruption.
لقد قمت بزيادة رقم إصدار المخطط.

عند تشغيل الدفة حصلت على هذا الخطأ في المرة الأولى:

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 لقد واجهت هذا كثيرًا ، فأنا أستخدم بشكل أساسي

تحرير : إذا كان أي شخص مهتمًا بتجربته ، فيمكنني دفعه إلى مستودع عام لرسو السفن وتضمين مقتطفًا سريعًا عن كيفية استخدامه.

jaredallard نحن مهتمون. شكرا!

أعلم أن المشرفين قد لا يوصون به ، لكنه يعمل وهو أفضل من لا شيء.

jaredallard لا يمكننا التوصية بهذا التصحيح لمجرد أنه لا يعمل من تلقاء نفسه (المرجع: https://github.com/helm/helm/pull/4223#issuecomment-397413568). إنه يتجاوز الخطأ ، لكنه لا يقوم بترقية الموارد ، لذا فإن التصحيح لا يقوم بما كان المستخدم ينوي القيام به في الأصل. يعمل على إصلاح مشكلة واحدة ولكنه يقدم أخرى دون إصلاح المشكلة الأصلية التي ينوي المستخدمون القيام بها: ترقية مورد.

ومع ذلك ، هذا مثير للاهتمام:

أستخدم بشكل أساسي التصميم الخاص بي في # 4146 كلما واجهت هذه المشكلة ثم أعود إلى الإصدار الرئيسي.

إذا كنت أقرأ هذا بشكل صحيح ، فأنت تقترح أنك وجدت حلاً لذلك

أ) يتجاوز الخطأ
ب) يسمح للمرء بترقية الموارد على النحو المقصود في الأصل

بعمل 2 helm upgrade s: واحد مع التصحيح والآخر بدونه؟ يمكن أن يساعدنا ذلك في تحديد السبب الجذري بشكل أفضل وكيفية إصلاح هذا الخطأ.

bacongobbler ، سأضطر إلى إعادة النظر في هذا حتى تحقق 100٪ من أن هذا هو السلوك. سأقوم بتحديث هذا التعليق أو نشر آخر عندما يكون لدي.

أعلم أن المشرفين قد لا يوصون به ، لكنه يعمل وهو أفضل من لا شيء.

أيضًا ، للتوضيح ، أنا لا أحاول إلقاء الظل هناك! لقد تمت صياغته بشكل سيء قليلاً إذا نظرنا إلى الوراء الآن ، آسف

ما زلت في حيرة من أمري حول سبب فشل دفاعي في المرة الأولى في البداية.
لم يظهر الخطأ no X with the name Y حتى المرة الثانية التي حاولت تطبيقه فيها.

veqryn لقد كتبت عن كيفية ظهور هذه المشكلة في المقام الأول في المشكلة التي ربطتها أعلاه. يرجى قراءة التعليق ؛ يسعدنا المساعدة في توضيح المشكلة بمزيد من التفصيل إذا لم يكن واضحًا.

للكسالى: https://github.com/helm/helm/pull/4223#issuecomment -397413568

لقد قرأت ذلك بالفعل ، وفهمت أن المشكلة حدثت لك لأنك غيرت اسم خدمتك.

ومع ذلك ، لم يغير أي من خدماتي أو أي موارد الأسماء في أي وقت.

وبعد إعادة قراءة تعليقك والتحدث مع طاقمي ، اكتشفنا سبب خطأنا:
لقد اصطدمت بنسخة مخطط دفتري.
تمت الإشارة إلى إصدار المخطط هذا كتسمية من خلال عمليات النشر والخدمات الخاصة بي.
لم يعجب 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. (هام) ابحث عن جميع الموارد التي تمت إضافة الموارد الجديدة الموجودة منذ آخر نشر (الإصدار 16) وقم بحذفها ، على سبيل المثال
kubectl -nmonitor delete cm az-test-2-prom-prometheus-grafana-config
kubectl -nmonitor delect svc ...

قم بتشغيل helm upgrade ... وشاهد Happy Helming

كما قال @ kosta709 ، فإن العودة إلى آخر إصدار تم نشره ، وإصلاح الرسم البياني (يدويًا) أو الحالة الحالية (كل ما هو خطأ) وإجراء ترقية جديدة ، يعمل عادةً.

Helm هو برنامج رائع يمكن التخلص منه في بعض عمليات سير العمل التلقائية (CI / CD) إذا كانت نتيجة الأمر غير مستقرة.

هل هناك خيار يتم تنفيذ الحلول المعروفة في نهاية المطاف في دفة (محاولة) حل هذه المشكلة المعروفة (والمزعجة بعض الشيء)؟ شكرا.

لذا ، في الآونة الأخيرة ، أضرب هذا كثيرًا أيضًا ، وهو ما يكفي لجعلني أعمل على هذه المشكلة بمفردي. بالنسبة للمبتدئين ، لقد قمت بإنشاء حل بديل (
https://github.com/Nopik/helm/commit/afe6451cc2c6295e71ea2213ccce654ec3f5b686) والذي يتسبب بشكل أساسي في حصول Tiller على المورد الحالي كنقطة بداية بدلاً من المورد المأخوذ من البيان القديم. يعمل مثل السحر بالنسبة لي ، على الرغم من أنني أعتقد أن المطورين الأساسيين لن يرغبون في دمجه ، لأنه يحتوي على سلوك مشفر.

قد يكون هناك خطأان مخفيان تحت نفس السلوك ، على سبيل المثال مرة واحدة على الأقل عندما يعضني هذا الخطأ ، اضطررت إلى حذف الكثير (> 40) من الموارد ، بما في ذلك بعض الموارد التي كانت موجودة لأكثر من 20 إصدارًا ناجحًا بالفعل. ولكن في 99٪ من الحالات ، سيؤدي حذف الموارد التي تم إنشاؤها حديثًا (وغير معروف حتى الآن إلى القيادة) إلى حل المشكلة.

لذلك ، كنت أفكر في كيفية حلها بالطريقة الصحيحة. أنا أصفه أدناه. يرجى من المطورين الأساسيين تصحيح لي هنا والوزن إذا كنت تتفق معي. إذا كانت الإجابة بنعم ، فأنا على استعداد لقيادة هذا الجهد وتوفير العلاقات العامة لإصلاحه.

بشكل عام ، يبدو أن الدفة تعمل في وضع "التصحيح": إذا قام المستخدم بتعديل المورد بطريقة ما ، وغيّر الإصدار الجديد بعض المعلمات الأخرى ، فإن الدفة تحسب التصحيح بين مراجعتين وتطبيقها - أعتقد أنها تحاول الحفاظ على تغييرات المستخدم سليمة.

هذا يتركنا للأسف مع مشكلة الدمج ثلاثية الاتجاهات ، حيث لدينا إصدار مورد مأخوذ من البيان القديم ، وإصدار آخر من البيان الجديد ، وإصدار آخر من المورد الحي حاليًا. ويبدو أن الدفة سيئة في حل النزاعات عند نشوئها.

أعتقد أن الطريقة الصحيحة ستكون إما اختيار إعدادات افتراضية أفضل (سيؤدي دمج فرعي بشكل أساسي إلى تحقيق شوط طويل) ، أو توفير إشارة للمستخدم. على سبيل المثال مثل هذا:

• --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

أي قائد يمكنه التعرف على هذه الإستراتيجية وتطبيقها لكل مورد. لست متأكدًا مما إذا كانت شركة helm devs تريد الذهاب إلى هناك ، رغم ذلك ؛)

إذن ، ما رأيك في هذا الاقتراح؟

راجع أيضًا الإصدار رقم 3805 حيث يفكر مطورو Helm في تصحيح الدمج ثلاثي الاتجاهات.

نفس المشكلة هنا.
محاولة إعداد بيئة CD / CI باستخدام google cloud build.
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 هو الحل للتعامل مع تعقيد نشر التطبيقات المعقدة في بيئة CI / CD.

هل نية الدفة أن تكون قادرة على العمل في خط أنابيب CI / CD؟

شكرا

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 إلى 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"}

لقد واجهت هذا أيضًا عند ترقية متطلبات الرسم البياني. أرى أن Istio يواجه هذا الخطأ أيضًا ، يستخدم مستند التثبيت الخاص به helm template . هل هذا حل بديل لهذه المشكلة؟

تحقق من المناقشات الأخيرة في https://github.com/helm/helm/issues/3805

وجود هذا أيضًا ، لا يزال يحدث لأحدث الدفعة 2.10

لقد حان الوقت للنظر بجدية في هذه المشكلة ، فقد مر عامان حتى الآن ، ويبلغ عدد كبير من الأشخاص عن نفس المشكلات بالضبط التي تجعل الدفة غير قابلة للاستخدام تمامًا في الإنتاج ، وهو ألم حقيقي عندما يعتمد نشرك على القيادة.

مع وجود الكثير من نجوم GitHub تأتي مسؤوليات كبيرة

@ brendan-rius فنحن نرحب بك للمساهمة في التعليمات البرمجية لإصلاح هذه المشكلة أو التفكير في الأفكار. انظر # 3805 و # 4146 لبعض المؤشرات.

@ brendan-rius ، يحتوي # 3805 على وجه الخصوص على أحدث المناقشات التي تدور حول هذا الخطأ. أقترح بشدة إعطاء هذا الموضوع قراءة للحصول على فكرة عما نواجهه.

إعادة نشر تعليقي هنا لأنه أكثر ارتباطًا بهذه المشكلة من استراتيجيات الدمج ثلاثية الاتجاهات:

إذا لم يكن الدمج ثلاثي الاتجاهات قابلاً للتطبيق لعمليات النشر الجديدة في Helm 2.yz ، فمتى سيتم إصلاح # 1193؟ تم فتح الخطأ منذ ما يقرب من عامين مع عدم وجود حل واضح مخطط له لبرنامج Helm 2.0.

في هذه المرحلة ، نحن في حيرة من أمرنا بشأن كيفية المضي قدمًا. لقد ناقشنا الخطأ لأسابيع ولن يعمل أي من الحلول المقترحة في جميع الحالات ، إما عن طريق إدخال أخطاء جديدة أو تغيير سلوك ترقية الحارث بشكل كبير.

على سبيل المثال ، قمت أنا و

1. عندما تفشل الترقية ، نقوم تلقائيًا بالتراجع وحذف الموارد التي تم إنشاؤها أثناء هذا الإصدار.

يعد هذا أمرًا

1. أثناء الترقية ، إذا كنا بصدد إنشاء مورد جديد ورأينا أنه موجود بالفعل ، فإننا بدلاً من ذلك نطبق هذه التغييرات على المورد الحالي ، أو نحذفه / نعيد إنشائه.

هذا أمر محفوف بالمخاطر للغاية حيث قد يقوم Helm بحذف العناصر التي تم تثبيتها عبر حزم أخرى أو من خلال kubectl create ، وقد لا يرغب أي من المستخدمين في ذلك.

كان الخيار الأكثر أمانًا حتى الآن هو مطالبة المستخدمين بالتدخل يدويًا في حالة حدوث هذا التعارض ، والذي سأوضحه أدناه.

إذا كان لدى أي شخص اقتراحات / ملاحظات / مقترحات بديلة ، يسعدنا سماع أفكارك.

bacongobbler ، إذا لم يتم التخطيط لدعم ميزة الدمج ثلاثي الاتجاهات ، فنحن بحاجة إلى بديل أو حل بديل. خلاف ذلك ، # 1193 هو خدع مؤلم للغاية.

لإعادة تكرار المشكلة بالإضافة إلى الحل البديل:

عندما تفشل ترقية تقوم بتثبيت موارد جديدة ، ينتقل الإصدار إلى حالة "فشل" ويوقف عملية الترقية. في المرة التالية التي تتصل فيها بـ helm upgrade ، يقوم Helm بمقارنة الإصدار الأخير. في الإصدار الأخير 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 ترقية الذي يسبب المشكلة أو إذا كان يتطابق تماما بيان مشكلتك. تخميني هو أنه قبل حوالي 3 أيام من الإصدار ، تم ترحيل بعض العناصر التي كانت غير مُدارة سابقًا (أي تمت إضافتها في وظيفة ما بعد التثبيت) إلى عدم تثبيتها في وظيفة ما بعد التثبيت.

عند التحدث مع مجتمع مشغلي Istio الذي لديه الكثير من الخبرة السابقة مع Helm ، أخبرنا عدد قليل من المشغلين أن الموارد غير المُدارة في Helm هي أخبار سيئة ، وغالبًا ما تؤدي إلى فشل الترقية. إذا كان تنفيذ مخططات Istio به عيب يجعلها غير متوافقة مع الترقية مع Helm 2.yz ، فسيكون إصلاح أوجه عدم التوافق هذه أمرًا رائعًا - لذلك لن يكون لدينا فشل في الترقية في المستقبل.

نحن على استعداد لأخذ الضربة الأولى من 0.8.0 إلى 1.0.0 ترقية. إذا كانت الترقية ضعيفة باستمرار - فهذه مشكلة مختلفة.

لقد قمت بتنفيذ شطر على Istio - حيث كانت الترقية تعمل حتى 27 يوليو (3 أيام قبل إصدار Istio 1.0.0) ووجدت أن هذا الالتزام يمثل مشكلة: https://github.com/istio/istio/commit/301612af08128b15069d27ff6d03cdb87420e15b

قام هذا PR بشكل أساسي بإزالة تسجيل الكائن من مهام التثبيت اللاحقة. أعتقد ، ولكني لست متأكدًا ، أننا أزلنا جميع حالات وظائف ما بعد التثبيت في 3 أيام من التشغيل إلى Istio 1.0.0.

هل يمكنك تقديم المشورة بشأن مخطط Helm الخاص بـ Istio من حيث صلته بالترقية؟ هل سيؤدي الاحتفاظ بتسجيل الكائن خارج وظائف التثبيت اللاحقة إلى حل مشكلات الترقية لدينا بشكل دائم؟

لا يمكنني حقًا تقديم أي نصيحة قوية أو اقتراح لإصلاح هذه المشكلة على مستوى إدارة المشكلة نظرًا لأن الأشخاص الذين لديهم خبرة أحدث مع Helm لم يتمكنوا من إيجاد حل عام (وليس بسبب عدم إلقاء نظرة على المشكلة). لا أعتقد أنني أستطيع أن أفعل ما هو أفضل.

هتافات
-ستيف

تم تحديث العنوان ليعكس الخطأ بشكل أفضل.

نحن أيضًا نتأثر بهذه المشكلة. نستخدم أحدث إصدار 2.10 مع GKE 10.6.
متى أتوقع أن يتم إصلاح ذلك؟
هل لدينا بعض الحلول المعقولة لهذه المشكلة؟ إزالة النشر بالكامل باستخدام الخيار --purge ضعيف جدًا.

من فضلك لا تتردد في التفكير في تعليقي الأخير. نحتاج حقًا إلى تعليقات حول أفضل طريقة للمضي قدمًا هنا.

تم تكرار حل بديل عدة مرات في مؤشر الترابط هذا. يرجى قراءة https://github.com/helm/helm/issues/1193#issuecomment -419555433.

تعجبني فكرة ميزة التراجع التلقائي للدفة ( الخيار 1 ) لحل هذه المشكلة. نحن نعلم أن الإصدار الأخير من Helm كان يعمل وأن المجموعة كانت في حالة جيدة ، لذا يجب أن تكون آمنة للعودة إليها. إذا كان الأمر محفوفًا بالمخاطر في بعض حالات الاستخدام ، فقد يكون الاشتراك عبر علامة لقيادة الترقية.

يعد هذا أمرًا محفوفًا بالمخاطر نظرًا لأن المجموعة قد تكون في حالة غير معروفة بعد فشل الترقية ، لذلك قد يتعذر على Helm المضي قدمًا بطريقة نظيفة ، مما قد يتسبب في توقف التطبيق.

أعتقد أن الكثير من مستخدمي الدفة يستخدمون الدفة بطريقة آلية عبر قرص مضغوط أو أداة CM ومن الخطورة ترك إصدار الدفة في حالة فشل. قد تؤثر هذه الموارد غير المكتملة في الإصدار الفاشل على الموارد الأخرى بشكل غير متوقع ويمكن أن تتسبب في حد ذاتها في توقف العمل. على سبيل المثال ، إذا احتوت مواصفات البود على إصدار صورة مفقود والذي جعله بطريقة ما في الإنتاج ، فسيكون حمل عملك في حالة ImagePullBackOff لا تعمل. بالنسبة لشركتنا ، الأمر أسوأ من ذلك نظرًا لأن لدينا بعض العملاء المحليين الذين يمكنهم ترقية أنفسهم عبر واجهة المستخدم الخاصة بنا وإذا فشلت ، يتعين علينا الوصول إلى نظامهم لتصحيح الأخطاء.

حتى بغض النظر عن حقيقة أنه يمكن أن يصلح هذه المشكلة ، فإن التراجع التلقائي سيكون ميزة مفيدة وسيساعد في ضمان أن تكون إصدارات Helm أكثر معاملات بطبيعتها. إنها ترتكز على Helm من عمليات النشر ذات الجهد الأفضل إلى إعطاء الأولوية للاستقرار وعمليات النشر الناجحة.

bacongobbler سيكون النهج التالي قابلاً للتطبيق لعمليات النشر الجديدة :

• أضف علم - -three-way-merge
• السماح فقط باستخدام هذه العلامة في helm install (نشر جديد)
• بمجرد تمكين هذه العلامة ، ستستخدم الترقية دائمًا دمجًا ثلاثيًا
• ستتوقف عمليات النشر الحالية بدون مسار الترحيل - يبدو أن الحل البديل القياسي يستخدمه الأشخاص في هذه المرحلة هو helm delete --purge متبوعًا بـ helm reinstall لذلك قد لا يكون هذا غير مستساغ كما يبدو لأول مرة.

هل هذا في الواقع يحل المشكلة؟

يفكر بعض الأفراد في تنفيذ عامل التشغيل للتغلب على قيود "هيلم" هذه. سيكون ذلك عارًا خطيرًا. راجع https://github.com/istio/istio/issues/8841#issue -361871147

هتافات
-ستيف

العودة إلى تعليق @ bacongobbler السابق:

1. أثناء الترقية ، إذا كنا بصدد إنشاء مورد جديد ورأينا أنه موجود بالفعل ، فإننا بدلاً من ذلك نطبق هذه التغييرات على المورد الحالي ، أو نحذفه / نعيد إنشائه.
   هذا أمر محفوف بالمخاطر للغاية حيث قد يقوم Helm بحذف العناصر التي تم تثبيتها عبر حزم أخرى أو من خلال إنشاء kubectl ، والتي قد لا يريدها المستخدمون.

أتساءل عما إذا كان بإمكاننا التخفيف من هذه المخاطر من خلال تمكين السلوك الجديد؟ في نطاق اسم معين ، أستخدم الدفة بشكل حصري ، وأظن أن هذا هو الحال بالنسبة للكثيرين. إذا كان بإمكاني إعطاء علامة تثبيت / ترقية Helm لإخبارها بأن أي شيء في مساحة الاسم المحددة ليس جزءًا من إصدار موجود جيد للحذف / الكتابة فوقه ، فهل يساعد ذلك؟

نظرًا لأنك قلت أيضًا "عبر حزم أخرى" ، أفترض أنك لا تريد أن يضطر Helm إلى فحص الإصدارات الأخرى كجزء من تنفيذ إصدار ، لذلك لن يعمل اقتراحي إلا في نموذج الإصدار الفردي لكل مساحة اسم. للرد على هذا الاعتراض ، أود أن أقول: إذا كنت تريد إدارة حزم متعددة في مساحة اسم وما زلت تحصل على هذا السلوك ، فأنشئ مخططًا شاملاً هدفه الوحيد هو تحديد تبعيات المخطط التي تريدها. ثم استخدم العلم الجديد ("- خاص"؟) عند نشر المخطط الشامل.

من الواضح أن هذا لا يحل المشكلة بالنسبة لجميع حالات الاستخدام ، ولكن ربما يكون حلًا كافيًا.

bacongobbler يمكن أن أكون بعيدًا هنا. أواجه مشكلات مماثلة في الترقية. بالحكم على مدى صعوبة حل هذه المشكلة ، أتساءل عما إذا كان هناك شيء أكثر أهمية يجب إعادة النظر فيه. يبدو أن جزءًا من التعقيد يرجع إلى حقيقة أن Helm تحتفظ بنسختها الخاصة من التكوين المعروف ، منفصلة عن مصدر الحقيقة الفعلي وهو kubernetes. هل سيكون النظام أكثر موثوقية إذا احتفظت Helm فقط بنسخة من مخططات الدفة التي تم نشرها مسبقًا لأغراض السجل والتراجع ، ولكنها لم تستخدمها على الإطلاق أثناء الترقية. بدلاً من ذلك ، سيحصل Helm على الحقيقة من kubectl نفسه ، ومن ثم يكون لديه دائمًا فرق ثنائي الاتجاه لأداءه؟

إذا كان مخطط الدفة ينص على أنه يجب أن يحتوي على المورد X ، ورأى kubectl موردًا موجودًا X ، فعندئذٍ:

• إذا تم وضع علامة على المورد الحالي على أنه خاضع لسيطرة Helm ، فسيقوم Helm بإجراء الترقية المطلوبة
• إذا لم يتم وضع علامة على المورد الحالي على أنه خاضع لسيطرة Helm ، فإن Helm يفشل في ظهور رسالة خطأ نظيفة (أو يمكن استخدام بعض علامات سطر الأوامر لفرض الترقية والتسبب في حصول Helm على ملكية المورد X الحالي).

إذا كان مخطط الدفة ينص على أنه يجب أن يحتوي على المورد X ولا يوجد واحد وفقًا لـ kubectl ، فإن Helm يقوم بإنشائه.

إذا أبلغت kubectl عن وجود مورد Y تم وضع علامة عليه على أنه يتم التحكم فيه بواسطة مخطط الدفة هذا ، ولا يوجد مورد Y في مخطط الدفة هذا ، فإن الدفة تحذف المورد.

يتم دائمًا تجاهل أي موارد لم يتم وضع علامة عليها على أنها خاضعة للتحكم بواسطة مخطط الدفة هذا من قِبل الدفة عند إجراء الترقية ، باستثناء الحالة المذكورة أعلاه حيث يشير مخطط الدفة إلى أنه يحتاج إلى المورد X و X ولكن لم يتم وضع علامة عليه.

إذا حدث وفشل طرح مخطط الدفة لسبب ما ، ولم يتم طرح سوى نصف الموارد فقط ، فسيستخدم خلال فترة التراجع ملفات التكوين المخزنة من النشر الناجح السابق وتشغيل نفس الخوارزمية أو الأشياء بالضبط يمكن تركها في حالة معطلة بالنسبة إلى بعض علم سطر أوامر الدفة. إذا حاول المستخدم الترقية مرة أخرى ، نظرًا لاستخدام kubernetes كمصدر للحقيقة وليس آخر نشر ناجح معروف ، فيجب أن يظل فرقًا بسيطًا ثنائي الاتجاه بين مخطط الدفة الجديد والحالة الحالية للنظام.

نحن نرى هذه المشكلة أيضًا. خطوات إعادة الإنتاج لدينا:

1. helm install رسم بياني يثبت عملية النشر بنجاح
2. حدِّث الرسم البياني ليشمل موردًا مخصصًا بالإضافة إلى النشر الحالي
3. قم بتغيير صورة podspec النشر لتقليد فشل النشر
4. رسم بياني جديد helm install . سيؤدي هذا إلى فشل تحديث متجدد للنشر ، والذي قمنا بإعداده عمدًا للفشل.
5. يجب أن يفشل تثبيت الدفة. ولكن يجب ترك المورد المخصص في k8s وما إلى ذلك. (تحقق باستخدام kubectl )
6. (في هذه المرحلة ، الدفة في حالة سيئة)
7. أصلح الرسم البياني - ضع صورة goot في podspec النشر.
8. helm install . نتوقع أن ينجح هذا ، لكنه لا يعمل. يُبلغ عن "لا يوجد مورد باسم ___". الاسم هو اسم المورد المخصص.
9. الاسترداد: حذف المورد المخصص المتبقي باستخدام kubectl . الآن سيعمل helm install .

لاحظ أن المحاولة الأولى عند helm install باستخدام مورد مخصص تم إدخاله حديثًا في المخطط يجب أن تفشل في الوصول إلى هذه الحالة.

@ rbair23 لقد جربنا ذلك سابقًا ولم ينجح ذلك. هناك مجموعة عمل التطبيق التي تتطلع إلى تحسين حالة إدارة الكائنات التصريحية عن طريق تثبيت تطبيق kubectl ، ونقل المنطق من العميل إلى الخادم ، ولكن هذا لا يزال في مراحله الأولى. يحتاج كل من Kubectl (و الحارث) إلى الاحتفاظ بنسخة من آخر تكوين تم تطبيقه لإجراء فرق. لا يمكنك الاختلاف مقابل الحالة الحية للكتلة دون تنفيذ استراتيجية تصحيح دمج ثلاثية الاتجاه ، والعودة إلى هذه البطاقة.

نظرًا لأنه تم إغلاق # 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 مضللة ، لكن توقعت أنه سيتم تحديث الوظيفة أيضًا.

ما زلت أرى هذا في الإصدار 2.9.1 (الإصدار الثابت الذي تم إصداره حاليًا)

لا أوافق على أنه من "الخطير جدًا" التراجع عن الترقية. أعتقد أن القيام بذلك هو الحل الصحيح.

Kubernetes هو تعريف. أخذ لقطة لحالة الكتلة قبل محاولة الترقية.
إذا كان هناك خطأ جزئيًا ، فارجع إلى اللقطة.
إذا كان لدى شخص ما خطافات نصية من شأنها أن تترك المجموعة في حالة سيئة عند القيام بذلك ، فهذا خطأه الخاص. (ربما يمكن حل ذلك باستخدام خطافات التراجع أيضًا)

بالطبع ، سيكون أمرًا رائعًا إذا كانت الترقية قد تم إجراؤها مسبقًا ولم يتم تقديمها في المقام الأول قدر الإمكان.
يجب أن يكون من الممكن التحقق من الأخطاء في مخططات التبعية التي تم إنشاؤها بواسطة القيم أو وسيطات المجموعة قبل محاولة تغيير أي شيء ، على سبيل المثال. أشياء مثل نسيان رفع رقم الإصدار يمكن أيضًا أن تكون جاهزة للطائرة لتجنب إجراء تغييرات عندما لا تعمل.

أهلا،

واجهت نفس المشكلة مع:

العميل: v2.10.0 + g9ad53aa
الخادم: v2.10.0 + g9ad53aa

كان حذف serviceAccount و configMap والخدمة هي الطريقة الوحيدة لجعل Helm يقوم بترقية الإصدار.

أهلا،

لدينا نفس المشكلة كما وصفها @ 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 state هو أن لديّ علامة --wait وانتهت المهلة.

انتهى بنا الأمر بعدة عمليات نشر مكررة لـ FAILED في helm list لكن آخر نشر عمل كان DEPLOYED . أدى إنشاء عمليات نشر جديدة إلى طرح No resource with the name x found .

كان قادرًا على الإصلاح عن طريق تشغيل helm rollback إلى الإصدار الأخير الذي كان في حالة DEPLOYED على helm list . بعد تلك الترقية التي كانت قادرة على العمل دون أخطاء.

تحقق من ذلك https://github.com/helm/helm/pull/4871.

مثل الآخرين من مظهر الأشياء ، يبدو أن هذا الخطأ يحدث بشكل متكرر (لست متأكدًا منه دائمًا) بالنسبة لي عندما فشل النشر الأخير ، وتركت الأصول الجديدة من هذا النشر مثبتة.

أفهم كيف يمكن أن يكون من الصعب و / أو غير المرغوب فيه إلغاء تثبيت المكونات من نشر Helm الفاشل ، ولكن ما هو سلوك Helm المثالي لهذا النوع من المواقف؟

أولاً ، أعتقد أن Helm يجب أن يكون جيدًا مع مساحات الأسماء والموارد الأخرى الموجودة بالفعل إذا كانت تحاول (إعادة) تثبيتها. Kubernetes هو كل شيء عن "جعل التكوين صحيحًا ، ودع kube يكتشف كيفية جعل العالم يطابق التكوين."
ثانيًا ، أعتقد أن هيلم يجب أن يكون كل شيء أو لا شيء. إذا فشل النشر ، يجب أن تكون المجموعة في الحالة التي كانت عليها قبل بدء النشر.
إذا كان هناك إصداران يريد كلاهما إنشاء مساحة الاسم X ، فهناك مشكلة في حساب المرجع. إذا كان هناك إصدار يريد إنشاء مساحة اسم X ، ولكنه موجود بالفعل ، فهناك مشكلة في المصدر. ومع ذلك ، يمكن للدفة تسجيل ذلك باستخدام التعليقات التوضيحية على الكائنات ، والقيام بالشيء الصحيح.

أنا أواجه هذه المشكلة أيضًا مع أحدث إصدار 2.12.0 و kubernetes 1.10.11 ، حتى أن الرجوع إلى أحدث إصدار جيد حيث اقترح aguilarm لم ينجح ، كما أن حذف الموارد التي يشكو دفة بشأنها لا يساعد ، وبعد الترقية فشل الأمر ، فإنه يترك نفس الموارد التي تم إعادة إنشائها جزئيًا. مزعج جدا لمحول ...

لدي مجموعتان مع بيئة متشابهة جدًا ، والاختلاف الرئيسي بين المجموعتين هو العدد الإجمالي للعقد. في إحدى الحالات ، نجح helm delete --purge متبوعًا بـ helm install جديدًا ولكن في حالة أخرى لم ينجح ذلك ، وما زلت بحاجة إلى اكتشاف طريقة لإدخال ذلك في أحدث تغييرات القالب.

هل هناك أي ETA على هذا؟

تمكنت من حل هذا الأمر باستخدام 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 الخاص بنا ، لذا فإن هذا يؤدي في كثير من الأحيان إلى حدوث صداع. لست متأكدًا مما ورد أعلاه هو القصة الكاملة ، على الرغم من أن الموارد المذكورة غالبًا ما تكون موجودة بالفعل ، فهي جزء من عملية نشر ناجحة ولا يتم تغييرها في النشر الحالي - فهي دائمًا ما تكون أحدث مجموعة من الموارد في آخر عملية نشر ناجحة على الرغم من المثير للاهتمام بما فيه الكفاية.

+1 إلى ajcann وشكرًا @ bacongobbler
أنا في نفس الموقف تماما.
CICD الخاص بنا مؤتمت وغالبًا ما تتم عمليات النشر بواسطة روبوت Slack للبيئات الأقل.
عندما يفشل ، يجب أن أقوم يدويًا بالتراجع عن الدفة ونشرها مرة أخرى.
المشكلة ليست متسقة على الإطلاق ولكنها متكررة.
بالنسبة لي ، يحدث ذلك فقط أثناء النشر الثاني للمخطط / المورد حتى الآن.
المورد موجود دائما.

نلاحظ نفس المشكلة. يحدث ذلك إذا كان لديك قالب ، وهو إما:

• في كشف حساب {{if $condition -}}
• أو في {{ range $index, $value := $array-}}

jkroepke أوضحت لي للتو أن PR # 5143 يوفر حلاً جيدًا لهذا. عندما يتم تحرير العلم --atomic في الإصدار الثانوي التالي ، يجب أن تكون قادرًا على استخدامه للمسح أو التراجع تلقائيًا عند حدوث خطأ.

bacongobbler نظرًا لأنك شاركت في معظم عمليات --atomic ستكون كافية؟

أعتقد أن distorhead قد يرغب في إلقاء نظرة على ذلك ومعرفة ما إذا كان يحل مخاوفه التي أثارها في https://github.com/helm/helm/pull/4871. بخلاف ذلك ، يبدو أن --atomic يجب أن يعالج المشكلة على افتراض أنك تستخدم دائمًا علامة --atomic .

لا أعتقد أن هناك أي حلول مقترحة لمعالجة المشكلة عندما تدخل في هذه الحالة بالذات ، لكن قد أكون مخطئًا. إذا كانت استراتيجية التخفيف لهذه المشكلة

• انتقل يدويًا إلى الحالة الحية للمجموعة وقم بإصلاحها وفقًا للحل البديل
• قم بالترقية إلى Helm 2.13.0 واستخدم helm upgrade --atomic فصاعدًا

ثم أعتقد أن هذا آمن للإغلاق.

نأمل أن Helm 2.13.0 ليس بعيدًا جدًا.
هذا الخطأ يكسر CI إذا حدث خطأ في مكان ما في الإصدار.

أتوميك لن يحل المشكلة

مثال على الرسم البياني: https://github.com/distorhead/ex-helm-upgrade-failure

1. تحقق من سيد ، قم بتشغيل النشر.

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

يحتوي المخطط على عمليتي نشر - 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 @ thomastaylor312jkroepke

distorhead ما كان سلوكك المتوقع لهذا السيناريو؟

قليلا offtop حول التراجع ، ولكن على أي حال.

بالنسبة لهؤلاء الأشخاص ، الذين يرغبون في استخدام التراجع ، ولكنهم أيضًا لا يريدون حدوث التراجع فورًا بعد النشر كما هو الحال في --atomic لبعض الأسباب. لأنه ، على سبيل المثال ، لا توجد طريقة للمستخدم لفحص حالة الكتلة السيئة يدويًا بعد الفشل ولأن علامة --wait لا تتسبب في قيام القائد بتسجيل أي معلومات حول حالات الفشل في الموارد التي يتم نشرها. ثم هناك طريقة ما: التراجع عن التشغيل التالي ، قبل الترقية (مزيد من المعلومات https://github.com/helm/helm/issues/3149#issuecomment-462271103)

لإعادة تكرار المشكلة بالإضافة إلى الحل البديل:

عندما تفشل ترقية تقوم بتثبيت موارد جديدة ، ينتقل الإصدار إلى حالة "فشل" ويوقف عملية الترقية. في المرة التالية التي تتصل فيها بـ helm upgrade ، يقوم Helm بمقارنة الإصدار الأخير. في الإصدار الأخير 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 - إنه في الأساس ما توصلنا إليه كعملية أيضًا. إحدى المشكلات المؤلمة هنا هي أثناء الترقيات المعقدة ، قد تجد العديد من الموارد الجديدة - في بعض الأحيان بعض مستويات التبعيات العميقة - نفسها في هذه الحالة. لم أجد حتى الآن طريقة لتعداد هذه الحالات بشكل كامل بطريقة تلقائية تؤدي إلى مواقف يحتاج فيها المرء إلى الفشل بشكل متكرر في الترقية إلى "البحث" عن جميع الموارد ذات الصلة. على سبيل المثال ، في الآونة الأخيرة ، كانت التبعية المضافة نفسها تعتمد على مخطط postgresql. لحل هذه المشكلة ، كان من الضروري حذف خريطة سرية ، وخريطة تكوين ، وخدمة ، ونشر ، و PVC - كل منها وجد طريقه الطويل.

يمكنك كتابة مكون إضافي مشابه لـ helm diff والذي من شأنه تعداد القوالب التي تم إنشاؤها في الإصدار الأخير. يمكنك حتى أن تستهلك pkg/kube مباشرة من Helm. client.Update على بعض منطق الأعمال المكتوب لتتبع / حذف موارد الدفة والتي يمكن إعادة استخدامها عن طريق جلب الإصدارين من Tiller وعكس ترتيب المقارنة. يجب أن يمنحك target.Difference(original) نتيجة لجميع الموارد التي تم تقديمها منذ الإصدار السابق.

bacongobbler ما الحل الذي توصي به لأخذ تطبيق تم نشره كجزء من الإصدار A (على سبيل المثال ، إصدار أكبر يتكون من عدة تطبيقات) وتقسيمه من الإصدار A إلى إصداره الخاص (أو العكس) دون تكبد أي توقف (قد يتسبب الحل البديل لحذف الموارد في بعض الوقت الضائع) ... محاولة تحديث مورد عبر إصدار مختلف يؤدي إلى الخطأ الموضح بواسطة مشكلة 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 state
   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 ، قم بتغيير حالتها من 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 مرة أخرى ، إذا فشلت مرة أخرى ، فقط اقلب الطاولة ...

تضمين التغريدة
هل هناك أي شيء يجعل من الصعب تحسين رسالة الخطأ لهذه المشكلة؟

أعتقد أن رسالة الخطأ يجب أن تنص على أن "هناك تعارض لأنه لم يتم إنشاء المورد بواسطة القيادة والتدخل اليدوي مطلوب" وليس "غير موجود". سيؤدي هذا التغيير البسيط في الخطأ فقط إلى تحسين تجربة المستخدم بهامش جيد.

selslack سأؤيد بشدة تحسين رسالة الخطأ 👍

michelleN لقد أعددت العلاقات العامة لتغيير نص الخطأ: # 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).

يرجى الاطلاع على https://github.com/helm/helm/issues/1193#issuecomment -419555433 للحصول على تشخيص محتمل وحل بديل ،zacharyw.

reneklacan إنه no resource with the name ... . في حالتنا ، أضفنا إدخالًا ، يبدو أنه نجح ، ولكن بعد ذلك بدأت الترقيات اللاحقة بالفشل مع هذا الخطأ ... على الرغم من وجود الإدخال بالفعل.

حالة أحدث إصدار لي (بعد حذف الإدخال المخالف والسماح بترقية الدفة لإعادة إنشائه) هي DEPLOYED :

STATUS=DEPLOYED
VERSION=197

ومع ذلك ، إذا حاولت الترقية مرة أخرى ، فسوف تفشل.

bacongobbler ما لم أكن أسيء الفهم ، أعتقد أنني أقوم بالفعل وأتركه يُعاد إنشاؤه ... المشكلة هي أنني يجب أن أفعل هذا في كل مرة.

reneklacan في 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: ...

تمكنت من الترقية بعد تصحيح المنفذ إلى رقم ، بدون تشغيل helm delete ، من خلال تطبيق الاقتراح على http://centosquestions.com/helm-how-to-delete-bad-deployment :

1. تم العثور على المراجعة الفاشلة مع helm history test-chart-failure
2. حذف خريطة التكوين للمراجعة المحددة بـ kubectl delete cm -n kube-system test-chart-failure.v2
3. تم تنفيذ helm upgrade بالرسم البياني المصحح