إزالة التحرير تمامًا من Helm عبر أعمال helm delete release ، لكنه ليس حلاً قابلاً للتطبيق.

لماذا لا يستطيع Helm الكتابة فوق كل ما هو مثبت حاليًا؟ ألا نعيش في عالم تصريحي مع Kubernetes؟

لقد حصلت للتو على نفس الشيء ... جديد تمامًا بالنسبة لي ، يبدو أنه مشكلة جديدة. حذف المورد سوف يصلحه.
v2.7.2 مع Kubernetes 1.7.7.
جميلة عملت من قبل ...

كانت لدي هذه المشكلة - كان ذلك بسبب PersistentVolume الذي قمت بإنشائه. لحل المشكلة ، قمت بحذف PV و PVC. Ran helm upgrade XXX XXX وعملت بشكل جيد. ربما لا يزال هناك شيء يجب التحقيق فيه لأن PV موجود بالفعل.

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

جربت للتو 2.7.1 بدون حظ ...

[رئيسي] 2017/12/21 15:30:48 بدء Tiller v2.7.1 (tls = false)
[رئيسي] 2017/12/21 15:30:48 GRPC يستمع على: 44134
[رئيسي] 2017/12/21 15:30:48 تحقيقات تستمع: 44135
[main] 2017/12/21 15:30:48 برنامج تشغيل التخزين هو ConfigMap
[main] 2017/12/21 15:30:48 الحد الأقصى للسجل لكل إصدار هو 0
[الحارث] 2017/12/21 15:30:55 يتم تحضير التحديث لـ xxx
[تخزين] 2017/12/21 15:30:55 الحصول على إصدار منشور من سجل "xxx"
[الحارث] 2017/12/21 15:30:56 نسخ القيم من xxx (v65) إلى الإصدار الجديد.
[التخزين] 2017/12/21 15:30:56 الحصول على آخر نسخة من "xxx"
[تخزين] 2017/12/21 15:30:56 جارٍ الحصول على سجل إصدار لـ "xxx"
[الحارث] 2017/12/21 15:30:59 عرض مخطط helm-xxx باستخدام القيم
2017/12/21 15:30:59 معلومات: البيان "helm-xxx / Templates / Scheduler-publish.yaml" فارغ. التخطي.
2017/12/21 15:30:59 معلومات: البيان "helm-xxx / Templates / recomposer -loy.yaml" فارغ. التخطي.
2017/12/21 15:31:00 المعلومات: البيان "helm-xxx / Templates / recomposer-pvc.yaml" فارغ. التخطي.
2017/12/21 15:31:00 المعلومات: البيان "helm-xxx / Templates / Scheduler-pvc.yaml" فارغ. التخطي.
2017/12/21 15:31:00 المعلومات: البيان "helm-xxx / Templates / Scheduler-secret.yaml" فارغ. التخطي.
2017/12/21 15:31:00 المعلومات: البيان "helm-xxx / Templates / recomposer-secret.yaml" فارغ. التخطي.
[الحارث] 2017/12/21 15:31:09 إنشاء إصدار محدث لـ xxx
[التخزين] 2017/12/21 15:31:09 إنشاء الإصدار "xxx.v80"
[الحارث] 2017/12/21 15:31:09 إجراء تحديث لـ xxx
[الحارث] 2017/12/21 15:31:09 تنفيذ 0 خطافات ما قبل الترقية لـ xxx
[الحارث] 2017/12/21 15:31:09 الخطافات كاملة للترقية المسبقة xxx
[الحارث] 2017/12/21 15:31:11 يتم تحضير التحديث لـ xxx
[تخزين] 2017/12/21 15:31:11 الحصول على إصدار منشور من سجل "xxx"
[التخزين] 2017/12/21 15:31:11 الحصول على آخر نسخة من "xxx"
[تخزين] 2017/12/21 15:31:11 جارٍ الحصول على سجل إصدار لـ "xxx"
[الحارث] 2017/12/21 15:31:18 عرض مخطط helm-xxx باستخدام القيم
2017/12/21 15:31:18 معلومات: البيان "helm-xxx / Templates / Scheduler-secret.yaml" فارغ. التخطي.
2017/12/21 15:31:18 معلومات: البيان "helm-xxx / Templates / Scheduler-pvc.yaml" فارغ. التخطي.
2017/12/21 15:31:19 معلومات: البيان "helm-xxx / Templates / Scheduler-publish.yaml" فارغ. التخطي.
[kube] 2017/12/21 15:31:28 بناء الموارد من المانيفست المحدث
[الحارث] 2017/12/21 15:31:46 إنشاء إصدار محدث لـ xxx
[التخزين] 2017/12/21 15:31:46 إنشاء الإصدار "xxx.v81"
[الحارث] 2017/12/21 15:31:47 إجراء تحديث لـ xxx
[الحارث] 2017/12/21 15:31:47 تنفيذ 0 خطافات ما قبل الترقية لـ xxx
[الحارث] 2017/12/21 15:31:47 الخطافات كاملة للترقية المسبقة xxx
[kube] 2017/12/21 15:31:49 التحقق من 7 موارد للتغييرات
[kube] 2017/12/21 15:31:49 يبدو أنه لا توجد تغييرات على "xxx-helm-xxx-nginx-secret"
[kube] 2017/12/21 15:31:50 يبدو أنه لا توجد تغييرات على "xxx-application-secret" السرية
[kube] 2017/12/21 15:31:50 يبدو أنه لا توجد تغييرات على Secret "azure-secret"
[kube] 2017/12/21 15:31:51 يبدو أنه لا توجد تغييرات في ConfigMap "xxx-helm-xxx-nginx-config"
[kube] 2017/12/21 15:31:51 يبدو أنه لا توجد تغييرات في ConfigMap "xxx-application-config"
[kube] 2017/12/21 15:31:51 يبدو أنه لا توجد تغييرات على الخدمة "xxx-application-svc"
[kube] 2017/12/21 15:31:51 يبدو أنه لا توجد تغييرات في StatefulSet "xxx-application"
[الحارث] 2017/12/21 15:31:51 تنفيذ 0 خطافات ما بعد الترقية لـ xxx
[الحارث] 2017/12/21 15:31:51 الخطافات كاملة لما بعد الترقية xxx
[تخزين] 2017/12/21 15:31:51 تحديث الإصدار "xxx.v65"
[الحارث] 2017/12/21 15:31:51 تحديث الحالة للإصدار المحدث لـ xxx
[التخزين] 2017/12/21 15:31:51 تحديث الإصدار "xxx.v80"
[kube] 2017/12/21 15:31:57 بناء الموارد من البيان المحدث
[kube] 2017/12/21 15:32:10 التحقق من 11 موردًا للتغييرات
[kube] 2017/12/21 15:32:10 يبدو أنه لا توجد تغييرات على Secret "xxx-helm-xxx-nginx-secret"
[الحارث] تحذير 2017/12/21 15:32:10: فشلت ترقية "xxx": لم يتم العثور على مورد بالاسم "xxx-recomposer-secret"
[تخزين] 2017/12/21 15:32:10 تحديث الإصدار "xxx.v65"
[تخزين] 2017/12/21 15:32:10 تحديث الإصدار "xxx.v81"

يبدو أنه مرتبك عند القيام بالإفراج في نفس الوقت ...

فقط أعاد تطبيق نفس التكوين مرتين ...

[الحارث] 2017/12/21 15:50:46 يتم تحضير التحديث لـ xxx
[تخزين] 2017/12/21 15:50:46 الحصول على إصدار منشور من سجل "xxx"
[التخزين] 2017/12/21 15:50:46 الحصول على آخر نسخة من "xxx"
[تخزين] 2017/12/21 15:50:46 جارٍ الحصول على سجل إصدار لـ "xxx"
[الحارث] 2017/12/21 15:50:50 عرض مخطط helm-xxx باستخدام القيم
2017/12/21 15:50:50 معلومات: البيان "helm-xxx / Templates / Scheduler-pvc.yaml" فارغ. التخطي.
2017/12/21 15:50:50 معلومات: البيان "helm-xxx / Templates / recomposer -loy.yaml" فارغ. التخطي.
2017/12/21 15:50:50 معلومات: البيان "helm-xxx / Templates / Scheduler-secret.yaml" فارغ. التخطي.
2017/12/21 15:50:50 معلومات: البيان "helm-xxx / Templates / Scheduler-publish.yaml" فارغ. التخطي.
2017/12/21 15:50:50 معلومات: البيان "helm-xxx / Templates / recomposer-secret.yaml" فارغ. التخطي.
2017/12/21 15:50:50 معلومات: البيان "helm-xxx / Templates / recomposer-pvc.yaml" فارغ. التخطي.
[الحارث] 2017/12/21 15:50:58 إنشاء إصدار محدث لـ xxx
[التخزين] 2017/12/21 15:50:58 إنشاء الإصدار "xxx.v85"
[الحارث] 2017/12/21 15:50:59 إجراء تحديث لـ xxx
[الحارث] 2017/12/21 15:50:59 تنفيذ 0 خطافات ما قبل الترقية لـ xxx
[الحارث] 2017/12/21 15:50:59 الخطافات كاملة للترقية المسبقة xxx
[kube] 2017/12/21 15:51:13 بناء الموارد من البيان المحدث
[kube] 2017/12/21 15:51:22 التحقق من 7 موارد للتغييرات
[kube] 2017/12/21 15:51:22 يبدو أنه لا توجد تغييرات على "xxx-helm-xxx-nginx-secret"
[kube] 2017/12/21 15:51:23 يبدو أنه لا توجد تغييرات على "xxx-application-secret" السرية
[kube] 2017/12/21 15:51:23 يبدو أنه لا توجد تغييرات على Secret "azure-secret"
[kube] 2017/12/21 15:51:23 يبدو أنه لا توجد تغييرات في ConfigMap "xxx-helm-xxx-nginx-config"
[kube] 2017/12/21 15:51:23 يبدو أنه لا توجد تغييرات في ConfigMap "xxx-application-config"
[kube] 2017/12/21 15:51:24 يبدو أنه لا توجد تغييرات على الخدمة "xxx-application-svc"
[kube] 2017/12/21 15:51:24 يتم حذف "xxx-recomposer-secret" في xxx ...
[kube] 2017/12/21 15:51:24 فشل حذف "xxx-recomposer-secret" ، يخطئ: الأسرار "xxx-recomposer-secret" غير موجودة
[kube] 2017/12/21 15:51:24 يتم حذف "xxx-recomposer-config" في xxx ...
[kube] 2017/12/21 15:51:24 فشل حذف "xxx-recomposer-config" ، والخطأ: configmaps "xxx-recomposer-config" غير موجود
[kube] 2017/12/21 15:51:24 يتم حذف "xxx-recomposer-pv" في ...
[kube] 2017/12/21 15:51:24 فشل حذف "xxx-recomposer-pv" ، يخطئ: persistentvolumes "xxx-recomposer-pv" غير موجود
[kube] 2017/12/21 15:51:24 يتم حذف "xxx-recomposer-pvc" في xxx ...
[kube] 2017/12/21 15:51:24 فشل حذف "xxx-recomposer-pvc" ، يخطئ: persistentvolumeclaims "xxx-recomposer-pvc" غير موجود
[kube] 2017/12/21 15:51:24 يتم حذف "xxx-recomposer" في xxx ...
[kube] 2017/12/21 15:51:24 استخدام آلة حصادة لحذف "xxx-recomposer"
[kube] 2017/12/21 15:51:24 فشل حذف "xxx-recomposer" ، خطأ: لم يتم العثور على النشرات "xxx-recomposer"
[الحارث] 2017/12/21 15:51:24 تنفيذ 0 خطافات ما بعد الترقية لـ xxx
[الحارث] 2017/12/21 15:51:24 الخطافات كاملة لما بعد الترقية xxx
[التخزين] 2017/12/21 15:51:24 تحديث الإصدار "xxx.v68"
[الحارث] 2017/12/21 15:51:24 تحديث الحالة للإصدار المحدث لـ xxx
[التخزين] 2017/12/21 15:51:24 تحديث الإصدار "xxx.v85"
[التخزين] 2017/12/21 15:51:25 الحصول على آخر نسخة من "xxx"
[تخزين] 2017/12/21 15:51:25 جارٍ الحصول على سجل إصدار لـ "xxx"
[kube] 2017/12/21 15:51:38 القيام بالكشف عن السر: "xxx-helm-xxx-nginx-secret"
[kube] 2017/12/21 15:51:39 الحصول على مجموعة علاقة الكائن: xxx / Secret / xxx-helm-xxx-nginx-secret
[kube] 2017/12/21 15:51:39 القيام بالكشف عن السر: "xxx-application-secret"
[kube] 2017/12/21 15:51:39 الحصول على مجموعة علاقة الكائن: xxx / Secret / xxx-application-secret
[kube] 2017/12/21 15:51:39 القيام بالكشف عن السر: "azure-secret"
[kube] 2017/12/21 15:51:39 الحصول على مجموعة علاقة الكائن: xxx / Secret / azure-secret
[kube] 2017/12/21 15:51:39 إجراء الحصول على ConfigMap: "xxx-helm-xxx-nginx-config"
[kube] 2017/12/21 15:51:39 الحصول على مجموعة علاقة الكائن: xxx / ConfigMap / xxx-helm-xxx-nginx-config
[kube] 2017/12/21 15:51:39 إجراء الحصول على ConfigMap: "xxx-application-config"
[kube] 2017/12/21 15:51:39 الحصول على مجموعة علاقة الكائن: xxx / ConfigMap / xxx-application-config
[kube] 2017/12/21 15:51:39 جارٍ الحصول على الخدمة: "xxx-application-svc"
[kube] 2017/12/21 15:51:39 الحصول على مجموعة علاقة الكائن: xxx / Service / xxx-application-svc
[kube] 2017/12/21 15:51:39 Do get for StateSet: "xxx-application"
[kube] 2017/12/21 15:51:39 الحصول على مجموعة علاقة الكائن: xxx / StatefulSet / xxx-application

قد تكون مرتبطة بـ # 2941

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

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

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

نفس المشكلة. كان كل شيء على ما يرام أمس وقمت بترقيات متعددة. لقد أضفت اليوم لتوي yaml جديدًا مع service و deployment كتلة مفصولة بـ --- وفشلت الترقية.

الشيء المثير للاهتمام هو أن helm أنشأ service ثم اشتكى منه (ولم يفعل النشر).
لقد علقت على service وقمت بإجراء الترقية باستخدام كتلة deployment - لقد نجحت. ومع ذلك ، لم يحذف helm الخدمة - التي يجب أن تكون موجودة عند إزالتها من ملف yaml.

تحديث : قمت بحذف service يدويًا ، وقمت بإلغاء التعليق عليه من yaml وقمت بتشغيل الترقية - هذه المرة عملت مثل السحر!

كنت أواجه هذا الخطأ بالضبط. يبدو أن المشكلة تتعلق بالقوالب التي تحتوي على كائنات متعددة لواجهة برمجة التطبيقات مشابهة لما رآه

{{ if .Values.enabled }}
---
...

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

إضافة نقطة بيانات أخرى: يبدو أنني أواجه نفس المشكلة تمامًا مثلawwithro. نحن نستخدم حلقة jinja لإنشاء عدة cronjobs عبر قالب ، وعندما تسببت ترقية جديدة في أن تملأ هذه الحلقة وظيفة cronjob إضافية ، واجهنا الخطأ. يبدو أنه يؤدي إلى تشغيل # 2941 أيضًا (أو ربما يتسبب خطأ واحد في حدوث الآخر) ، كما يؤدي حذف خرائط التكوين الزومبي إلى إصلاحه.

فقط حوصر في هذا حتى بدون استخدام أي خرائط التكوين

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

يبدو أن هذا يتماشى مع دليل الآخرين على أن الحذف هو الطريقة الوحيدة لحل الآن right

يعمل أيضًا عبر هذا = \

كنت بحاجة أيضًا إلى حذف الموارد المتأثرة. ليست جيدة لبيئة الإنتاج = _ (

أرى شيئًا أعتقد أنه مشابه. وتظهر مشكلة أن يكون أن helm upgrade لا --reuse القيم من نشر السابق. إذا قمت بتحديد نفس مجموعة القيم في سطر الأوامر كما فعل التثبيت الأولي ، فعندئذٍ يعمل helm upgrade . دونو إذا كان هذا يساعد (أو يمكن لأي شخص آخر تأكيد ذلك).

مثل amritb ، بعد أن حذفت يدويًا الكائن الذي فشل helm في البداية ، نجح بعد الترقية التالية. لم أواجه # 2941.

نفس المشكلة باستخدام helm 2.8.0 . إصدارات Kubernetes client=v1.8.6 و server=v1.8.5-gke.0 .

$ helm upgrade bunny ./app --debug
[debug] Created tunnel using local port: '54274'

[debug] SERVER: "127.0.0.1:54274"

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

لكن خريطة التكوين موجودة في $ kubectl get configmap . إذا قمت بحذف خريطة التكوين يدويًا ، فستعمل ، ولكن في المرة التالية تفشل مرة أخرى.

هنا هو configmap:

apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ template "proxy.fullname" . }}-config
  # namespace: {{ .Release.Namespace }} # I've tried adding and removing it
  labels: # labels are the same as labels from $ kubectl describe configmap bunny-proxy-config
    app: {{ template "proxy.name" . }}
    chart: {{ template "proxy.chart" . }}
    release: {{ .Release.Name }}
    heritage: {{ .Release.Service }}
data:
  asd: qwe

لقد حذفت الإصدار وأعدت التثبيت مرة أخرى. أيضًا ، كنت أستخدم إصدار api extensions/v1beta للنشر ، لقد غيرت إلى apiVersion: apps/v1beta2 ، لا أعرف ما إذا كان هذا مفيدًا أم لا.
حاليًا أنا أقوم بتشغيل tiller محليًا.

في الوقت الحالي يبدو أن كل شيء يعمل.

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

مثلما لدينا مورد 1 و مورد 2 ، يعتمد المورد 2 على أولاً. عندما نقوم بترقية الإصدار ، يتم إنشاء المورد 1 (على سبيل المثال PV & PVC) ، ولكن يفشل المورد 2. بعد هذا الحذف فقط للمورد 1 يساعد ، حيث أن الدفة تبلغ دائمًا عن مشكلة في الترقية (PersistentVolume بالاسم ... غير موجود)

كانت لدينا نفس المشكلة (المصدر الذي حصلنا عليه هو الأسرار). إزالة الأسرار الجديدة وإعادة نشرها وإصلاحه.

لاحظ أنه بسبب الإخفاقات ، لدينا الآن 11 إصدارًا مختلفًا عندما نقوم بعمل helm list ، 10 إصدارات فاشلة و 1 DEPLOYED. هذا غير متوقع ، أليس كذلك؟ نفس المشكلة كما يبدو هنا: https://github.com/kubernetes/helm/issues/2941

لقد جعل هذا الدفة إلى حد كبير غير قابلة للاستخدام في عمليات نشر الإنتاج المنتظمة بالنسبة لنا: ، لست متأكدًا مما نفعله بشكل خاطئ :(

بعد تفصيل سجلات الحارث ، وجدت أن الحارث كان يحاول تحديث إصدار قديم في نفس الوقت:

[storage] 2018/02/14 18:25:40 updating release "s2osf.v10"
[storage] 2018/02/14 18:25:40 updating release "s2osf.v44"

حذف ملف configmap القديم لـ s2osf.v10 ثم عمل الترقية.

Client: &version.Version{SemVer:"v2.7.2", GitCommit:"8478fb4fc723885b155c924d1c8c410b7a9444e6", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.7.2", GitCommit:"8478fb4fc723885b155c924d1c8c410b7a9444e6", GitTreeState:"clean"}

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

[storage] 2018/02/15 10:20:50 updating release "control.v136"
[storage] 2018/02/15 10:20:50 updating release "control.v226"

تسبب في مشاكل غريبة مع UPGRADE FAILED: no Secret with the name "foobar" found .
حتى أنني حاولت حذف هذا السر الذي تسبب بعد ذلك في حدوث أخطاء في بعض ملفات configmap بدلاً من ذلك ، وفي المرة الثالثة اشتكت مرة أخرى من السر السابق.

قد يكون هذا قد تم تشغيله بعد الترقية من 2.7.x إلى 2.8.1.

Client: &version.Version{SemVer:"v2.8.1", GitCommit:"6af75a8fd72e2aa18a2b278cfe5c7a1c5feca7f2", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.8.1", GitCommit:"6af75a8fd72e2aa18a2b278cfe5c7a1c5feca7f2", GitTreeState:"clean"}

إذا كان الملاذ الأخير يتعلق بحذف الإصدار القديم ، فقد يكون هناك عمل أقل تدميراً مثل تعليقي https://github.com/kubernetes/helm/issues/3513#issuecomment -366918019

العثور بشكل أساسي على تلك المراجعة القديمة في السجلات وتحرير configmap يدويًا حيث يخزن الحارث الحالة المنشورة. يجب ألا يكون هناك مراجعتان مع وضع DEPLOYED afaik.

وجدت حلا جديدا لهذه المشكلة.

kubectl -n kube-system edit cm name_of_your_release.v2 ، حيث v2 هو أحدث رقم مراجعة تم تمييزه على أنه FAILED في helm list . قد ترغب أيضًا في تحرير أحد الإصدارات DEPLOYED وتغيير الحالة إلى SUPERSEDED ، حتى لا يكون لدينا إصداران تم نشرهما في نفس الوقت.

zuzzas هذا ما أشرت إليه. عملت من أجلي كذلك

balboah ، المشكلة هي أن لدينا عملية نشر واحدة فقط في حالة DEPLOYED ، ولكن إذا لم تكن من أحدث النشرات (التي تم وضع علامة عليها كـ FAILED ، في معظم السيناريوهات) ، فستظل تتعطل. يبدو أن المشكلة لا علاقة لها بعمليتي نشر أو أكثر في حالة DEPLOYED في معظم حالاتنا.

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

إذا كانت واحدة فقط ، فكم عدد حالات الفشل لديك حتى الإصدار المنشور؟ كيف تحققت من نشر واحد فقط؟

نعتقد أنه تم إصلاح هذا (المضي قدمًا) عبر # 3539. يرجى إعادة الفتح إذا حدث خطأ. :)

شكرا لكم جميعا لعملكم على هذا!

لاحظ أنه لم يتم إصلاح ذلك للمخططات الموجودة في هذه الحالة ؛ ستظل بحاجة إلى إزالة الإصدارات القديمة التي تم نشرها حتى تعمل الأشياء مرة أخرى. balboah منعت للتو الحالة التي يمكنك من خلالها الدخول في حالة "الإصدارات المتعددة التي تم وضع علامة عليها كـ DEPLOYED". :)

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

لدي القليل من مخطط الدفة الكبير مع التبعيات المتداخلة ؛ قد يكون ذلك؟

أرى نفس المشكلة مع الربط العنقودي. لقد أضفت المورد الجديد إلى الرسم البياني الخاص بي و upgrade بالإضافة إلى upgrade --install سيفشل مع Error: UPGRADE FAILED: no ClusterRoleBinding with the name "test-clusterrolebinding" found

أواجه نفس المشكلة مثل ramyala مع ClusterRole. يوجد ClusterRole ، ولكن فشل إنشاء RoleBinding مع هذا الخطأ.

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

helm upgrade --install --namespace my-namespace my-stack stack
Error: UPGRADE FAILED: no ConfigMap with the name "my-stack-my-app" found

بينما أرى هذا ConfigMap على الكتلة الخاصة بي.

أواجه هذه المشكلة إذا كان لدي موارد متعددة مع خطافات في ملف واحد

+1 ، هذا يحدث مرة أخرى مع 2.9.1. يرجى إعادة الفتح.

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

تضمين التغريدة

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

لقد قمت بالفعل بنشر مخطط الدفة stable/nginx-ingress حتى تكون وحدة التحكم موجودة. يبدو أن الخطأ يشير إلى أنه يحاول العثور على الخطأ الذي أحاول إنشاؤه. هذا هو الأمر الذي أقوم بتشغيله:

helm upgrade some-existing-release-name -i --set imageTag=$TAG-$BUILD_NUMBER --namespace=default ./deploy/helm حيث يحتوي deploy/helm على بيانات الرسم البياني الخاص بي.

Error: UPGRADE FAILED: no Ingress with the name "my-ingress" found

يامل:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: my-ingress
  labels:
    app: my-app
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/ssl-redirect: "false"
spec:
  rules:
  - host: {{ $.Values.appDomain }}
    http:
      paths:
      - path: /*
        backend:
          serviceName: web-app
          servicePort: 80
      - path: /api/*
        backend:
          serviceName: api
          servicePort: 8080

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

أهلا،
فيما يلي الخطوات التي قدمت المشكلة في حسابي:

1. كان لدي مخطط دفة تم نشره وترقيته عدة مرات.
2. إنشاء كائن CronJob جديد في الرسم البياني وترقيته مرة أخرى - تم إنشاء وظيفة cron بنجاح.
3. فشلت جميع الترقيات التالية بسبب الخطأ الذي تم الإبلاغ عنه "خطأ: فشل الترقية: لم يتم العثور على CronJob بالاسم" cronjob-name ""

أرى أيضًا المشكلة عندما أضفت سرًا لم يكن موجودًا من قبل. حاولت إضافة "بيانات اعتماد db"
السر الذي أدى إلى:

Error: UPGRADE FAILED: no Secret with the name "db-credentials" found

الإصلاح المحتمل أن يكون ذا صلة: # 4146

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

لا يمكنني تأكيد 100٪ ما إذا كان هذا سيتكاثر دائمًا ، لكنني لاحظت أن هذا يحدث في الموقف التالي:

1. أقوم بترقية مخطط Helm ، بما في ذلك مورد جديد
2. فشلت هذه الترقية ، ولكن تم إنشاء المورد كجزء من الترقية الفاشلة
3. جميع الترقيات اللاحقة تفشل

إذا قمت بإجراء عملية نشر helm rollback لآخر عملية نشر ناجحة ثم حاولت إعادة الترقية ، يبدو أنها تعمل.

يبدو من السهل جدًا إعادة إنتاجه يدويًا ، دون محاولة ترقية مخطط مع تغييرات ضارة (على سبيل المثال ، تعديل كائنات مهمة غير قابلة للتغيير):

1. خذ بعض المخططات وانشرها (لكن احذف موردًا واحدًا ، دعنا نقول خدمة)
2. أضف المورد المحذوف يدويًا (على سبيل المثال ، باستخدام "kubectl create") ، ولكن بالاسم المقابل للإصدار
3. أضف المورد المحذوف مرة أخرى إلى المخطط ثم حاول ترقيته ، يجب على القائد الإبلاغ عن "فشل الترقية: لابالاسموجدت"

الخطوات مختلفة ولكن لا يزال السبب الأساسي هو نفسه. صححني إذا كنت مخطئًا في الافتراض ، ولكن يبدو لي أن النسخة المنقحة الأخيرة لإصدار DEPLOYED لا تحتوي على معلومات حول المورد المعين ، إما لأنه تمت إضافته "خارج" Helm (يدويًا على سبيل المثال) أو فشل التحديث الأخير في بعض الخطوات (دعنا نقول عن ترقية وظيفة غير قابلة للتغيير) ، في نفس الوقت نشر كائنات أخرى ثم تسجيلها في مراجعة FAILED (ولكن لا يزال بدون أي مسار في المراجعة DEPLOYED ما هو متوقع ، وإلا فإنه سيعني تغيير السجل) . في التشغيل التالي ، يرى عميل kube لـ Tiller الموارد الموجودة في المجموعة ، مما يعني أنه يجب نشرها بالفعل وبالتالي تسجيلها ، فإنه يتحقق من أحدث مراجعة DEPLOYED (يبدو أنه لم يتم الاتصال بالمراجعة الفاشلة على الإطلاق) ولا يراها مدرجة هناك لذلك يبلغ عن خطأ.

bacongobbler لقد اختبرت # 4146 باستخدام صورة أصلحت هذه المشكلة! بالنسبة للآخرين الذين يبحثون عن حل ، يمكنك تطبيق التصحيح في المشكلة على الرئيسي الحالي وتجميع:

make bootstrap build docker-build

سيكون عليك تحميل صورة الحارث إلى الريبو الخاص بك وإعادة تثبيت الحارث على مجموعتك. تمكنت من التخلص من إعادة تعيين القوة وإعادة التثبيت دون تدمير الإصدارات الحالية.

$GO_HOME/src/k8s.io/helm/bin/helm init -i gcr.io/my-repo/tiller:1 --service-account tiller

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

لذلك وجدت بعض الأخطاء مع # 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

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

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

selector:
    app: {{ template "mything.name" . }}

ل

selector:
    app: mything

ربما هناك مشكلة ما في استخدام متغير في هذا السياق؟

جرب helm delete RELEASE_NAME --purge
وتثبيته مرة أخرى.

أنا أضرب هذه القضية أيضا. حاولت إضافة مخطط فرعي مع نشر في الرسم البياني الخاص بي ، وقد نجح ذلك عند الترقية بـ helm upgrade chart chart-1.0.1.tgz للمرة الأولى فقط ، وبعد ذلك عندما حاولت helm upgrade chart chart-1.0.1.tgz فشل مع الخطأ Error: UPGRADE FAILED: no Deployment with name "subchart-deployment" found

Client: &version.Version{SemVer:"v2.12.0", GitCommit:"d325d2a9c179b33af1a024cdb5a4472b6288016a", GitTreeState:"clean"} Server: &version.Version{SemVer:"v2.12.0", GitCommit:"d325d2a9c179b33af1a024cdb5a4472b6288016a", GitTreeState:"clean"}

تسجل أداة الحرث الدفة نفس الخطأ فقط. أي شخص يعاني من هذا أيضا؟

نفس المشكلة. كان كل شيء على ما يرام أمس وقمت بترقيات متعددة. لقد أضفت اليوم لتوي yaml جديدًا مع service و deployment كتلة مفصولة بـ --- وفشلت الترقية.

الشيء المثير للاهتمام هو أن helm أنشأ service ثم اشتكى منه (ولم يفعل النشر).
لقد علقت على service وقمت بإجراء الترقية باستخدام كتلة deployment - لقد نجحت. ومع ذلك ، لم يحذف helm الخدمة - التي يجب أن تكون موجودة عند إزالتها من ملف yaml.

تحديث : قمت بحذف service يدويًا ، وقمت بإلغاء التعليق عليه من yaml وقمت بتشغيل الترقية - هذه المرة عملت مثل السحر!

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

راجع https://github.com/helm/helm/issues/1193#issuecomment -419555433.

فقط أؤكد أنني أشهد نفس المشكلة والسبب أيضًا كما هو موضح سابقًا.

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

أظهرت قائمة الأسرار أنه تم إنشاؤه. تم حذف السر يدويًا وتمت الترقية بنجاح.

نفس الشيء ،thedumbtechguy. أواجه هذه المشكلة بشكل روتيني. إنه أمر ممتع بشكل خاص عندما يقرر Helm أنك بحاجة إلى حذف _جميع_ أسرارك ، وخرائط التكوين ، والأدوار ، وما إلى ذلك. تصبح الترقية لعبة wack-a-mole مع قائمة متزايدة من الوسائط إلى kubectl delete . كان يجب أن ألقي بالمنشفة في هذه المهمة العبثية منذ أشهر ، لكن فات الأوان لذلك الآن. نأمل بالتأكيد أن يتم إصلاح هذا والعشرات من المشكلات المماثلة!

لقد كنت أستخدم الدفة لمدة أسبوع وواجهت بالفعل كل ما تم تحديده
هنا https://medium.com/@7mind_dev/the -problems-with-helm-72a48c50cb45

يحتاج الكثير إلى الإصلاح هنا.

في الجمعة ، 15 مارس 2019 ، 10:49 مساءً كتب Tom Davis [email protected] :

نفس الشيء ، thedumbtechguy https://github.com/thedumbtechguy . واجهت
هذه المسألة بشكل روتيني. إنه أمر ممتع بشكل خاص عندما يقرر هيلم أنك بحاجة إلى ذلك
احذف جميع أسرارك وخرائط التكوين والأدوار وما إلى ذلك
لعبة wack-a-mole مع قائمة متزايدة من الحجج لـ kubectl
حذف. كان يجب أن ألقي بالمنشفة في هذه المهمة الشاقة
في الماضي ، ولكن الوقت قد فات الآن. بالتأكيد نأمل هذا والعشرات من
يمكن إصلاح مشكلات مماثلة!

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/helm/helm/issues/3275#issuecomment-473464809 ، أو كتم الصوت
الخيط
https://github.com/notifications/unsubscribe-auth/AA4XZU4KMQePtZKcir8S5kWulkbYg-8Uks5vXCNggaJpZM4RGz7W
.

لقد جربت نفس الشيء مع Helm v2.10. لقد قمت بالفعل بنشر مخطط ، أضفت configMap آخر إلى المخطط. ذكرت أن النشر فشل لأنه لم يتمكن من العثور على configMap "blah". فعلت

helm upgrade <NAME> chart --debug --dryrun 

للتحقق من أن configMap قد تم تقديمه بالفعل ، فقد كان. فحصت configMaps في المجموعة ، ووجدتها هناك. حذف ملف configMap ، وأعد تشغيل الترقية ، لقد نجح.

يجب أن يوضح https://github.com/helm/helm/pull/5460 رسالة الخطأ بشكل أفضل من الآن فصاعدًا.

نقطة عادلة.

$ helm upgrade linting-unicorn testrail                                                                                                                                                                                        
Error: UPGRADE FAILED: no ConfigMap with the name "linting-unicorn-testrail-php-config" found

استمروا في قيادة فريق العمل الجيد.

في حال كانت هذه مشكلة كبيرة لأي شخص آخر ، أعتقد أنني سأشير إلى أن https://github.com/helm/helm/pull/4871 يجب أن يصلح هذه المشكلات.

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

تواجه نفس المشكلة والحل الوحيد يبدو أنه helm delete --purge release وقم بالتثبيت مرة أخرى!

واجهتني نفس المشكلة. fbcbarbosa يبدو أنه تم دمجه منذ أسبوعين. نأمل أن يكون جزءًا من الإصدار التالي 2.14.0 .

تواجه نفس المشكلة والحل الوحيد يبدو أنه helm delete --purge release وقم بالتثبيت مرة أخرى!

الخيار الأقل تدميراً هو إجراء helm rollback للإصدار / الحالي / (أي 0 خطوات). لا أستطيع أن أضمن النجاح ، لكن بالنسبة لنا حتى الآن ، فقد نجح هذا الأمر دائمًا في فك تثبيت الأشياء.

هل هناك فكرة عما إذا كان هذا سيكون في الإصدار التالي ، وإذا كان سيحدث عندما يأتي؟

تم دمج 5460 منذ شهرين ، مما يعني أنه يجب أن يكون في دفة 2.14.0.

أصلحت المشكلة عن طريق

1. حذف تلك الموارد التي اشتكت من خلال "ترقية الدفة". (تقول لم يتم العثور عليها ولكن في الواقع يمكن العثور عليها). لا تحذف الإصدار بالكامل ، وإلا إذا كنت ستفشل تمامًا في الإنتاج.
2. إعادة ترقية الدفة. الآن هذه المرة يجب أن يظهر "هيلمينج سعيد". :)

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

helm rollback <some revision that's acceptable>
helm upgrade <desired version>

بالنسبة لنا ، كان التراجع البسيط إلى المراجعة الحالية ناجحًا دائمًا:

helm ls
helm rollback <NAME> <current REVISION>

tobypeschel هل لديك فكرة عن كيفية عمل الإصلاح الخاص بك؟