<p>ترقية الدفة - التثبيت لم يعد يعمل</p>

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

يعد هذا أحد الآثار الجانبية لإصلاح المشكلات المتعلقة بترقية الإصدارات التي كانت في حالة سيئة. https://github.com/kubernetes/helm/pull/3097 كانت العلاقات العامة التي أصلحت هذه المشكلة. هل هناك قضية متطرفة هنا فشلنا في اكتشافها؟

تحقق من helm list -a كما ذكر tcolgate ، وربما يكون شرح كيفية إعادة إنتاجه مفيدًا أيضًا لتحديد ما إذا كانت حالة غير معلومة أو خطأ.

توجد أيضًا نفس المشكلة ، جنبًا إلى جنب مع أسماء الإصدارات المكررة:

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

عندما كنت تقوم بالترقية ، ما هي الرسالة التي تم عرضها؟

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

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

أوه ، نشر اسم الإصدار المكرر؟ لست متأكدًا ، فأنا أحصل عليه كثيرًا. في بعض الأحيان يكونون جميعًا في حالة نشر ، وأحيانًا يكونون مزيجًا من فاشلة وموزعة. نحن نستخدم خادم CI / CD Jenkins الذي يقوم باستمرار بتحديث كل عملية دمج للعلاقات العامة ، لذلك نقوم بالعديد من helm upgrade اليوم ، وعادة ما يكون لدينا فقط علامة حاوية جديدة. عادةً ما تكون النسخ المكررة مزعجة عند النظر إلى ما تم نشره ، وكانت هذه هي المرة الأولى التي نواجه فيها مشكلة صعبة معهم ، وعادةً لا نقوم بترقية وحدة التحكم في الدخول كما كنا في هذه الحالة.

يبدو أنني انتهيت بشيء مشابه ، أرى بعض التكرارات في قوائم إصداراتي:

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

يبدو أن كل منهم في حالة DEPLOYED ، ولكن من المحتمل أن تكون الترقية السابقة قد فشلت في مرحلة ما ، لأنني قد أصبت بهذا الخطأ عدة مرات. ما زلت على K8S 1.7 ، لذلك لم يتم التحديث إلى helm 2.7 حتى الآن.

نفس المشكلة ، لا يمكن الترقية فوق نشر FAILED

نفس الشيء هنا باستخدام 2.7.2. فشلت المحاولة الأولى للإفراج. ثم عندما حاولت ترقية - تثبيت ، ظهر لي الخطأ "خطأ: فشلت الترقية:" $ {RELEASE} "ليس له إصدارات منتشرة".

نفس المشكلة هنا مع 2.7.2 ، فشل helm upgrade --install مع:

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

إذا تمت إزالة الإصدار بالكامل باستخدام helm del --purge APPNAME فعندئذٍ يعمل upgrade --install اللاحق بشكل جيد.

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

winjer فقط حاول الحذف باستخدام --purge ولم ينجح بالنسبة لي بالرغم من تغيير الخطأ
/ # helm Upgrade foo / charts / foo / -i --wait
خطأ: فشلت الترقية: ليس لـ "foo" إصدارات منتشرة
/ # helm delete --purge foo
الافراج عن "foo" المحذوفة
/ # helm Upgrade foo / charts / foo / -i --wait
الإصدار "foo" غير موجود. تثبيته الآن.
خطأ: فشل الإصدار foo: عمليات النشر "foo-foo-some-service-name" موجودة بالفعل

prein هذا لأن لديك خدمة ليست "المالك" من قِبل الدفة ، ولكنها موجودة بالفعل في المجموعة. يبدو أن السلوك الذي تواجهه صحيح بالنسبة لي. لا يمكن أن ينجح النشر لأنه سيتعين على الدفة "الحصول على ملكية" كائن API لم يكن يمتلكه من قبل.

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

أرى أيضًا هذا السلوك في إصدار يسمى content :

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

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

لدي بالفعل إصدار مكرر آخر على الكتلة الخاصة بي ، إذا كان لديك أي أمر لي لتشغيله للمساعدة في تصحيح ذلك؟ دعني أعلم!

مجرد الترقية إلى الحارث 2.7.2 ونرى نفس الشيء. helm delete RELEASE_NAME متبوعًا بـ helm upgrade RELEASE_NAME . فشل مع Error: UPGRADE FAILED: "RELEASE_NAME" has no deployed releases . upgrade هي الطريقة المقصودة لاستعادة إصدار محذوف (لكن لم يتم حذفه) ، أليس كذلك؟

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

رؤية نفس المشكلة مع v2.7.2 ، فشل في حالة عدم وجود إصدارات سابقة تم نشرها بنجاح

تظهر أيضًا نسختين محتملتين من هذه المشكلة:

في CI:

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

على جهازي المحلي:

(في كل من OSX bash الخاص بي وفي حاوية gcloud / kubectl)

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

التحذيرات طبيعية لمخططنا.
الأخطاء مثيرة للاهتمام لأن أحد مخططاتنا الفرعية يحتوي على pvc.yaml فيه.

helm del --purge <release> يخفف من المشكلة.
هذا يجعل من الصعب ترقية خط أنابيب CI الخاص بنا.

adamreese ما هو الحل النهائي لهذه المشكلة؟ نحن في الإصدار 2.8 وما زلنا لا نستطيع ترقية إصدار سابق FAILED بالتغيير إلى helm list .

على وجه الخصوص ، نحن نواجه النوع التالي من المشكلات:

• نشر إصدار ، حسنًا
• upgrade --install --wait ، ولكن ربما يكون هناك خطأ صغير و --wait لا تنجح (على سبيل المثال ، تحقيقات الحياة لا تصنعها أبدًا)
• بعد إصلاح المخطط ، فشل upgrade --install --wait مع xxx has no deployed releases

الحذف / التطهير غير مرغوب فيه أو مقبول هنا: قد يحتوي الإصدار على موارد متعددة (القرون ، موازنات التحميل) التي لا تتأثر بالمورد الوحيد الذي لن يزداد. في إصدارات Helm السابقة ، سمح لنا upgrade --install بتصحيح التغيير الذي كسر الإصدار الكامل فقط دون الحاجة إلى إزالة جميع الموارد.

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

peay انظر # 3353 لمتابعة المناقشة.

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

لا يزال هذا يحدث إذا فشل التثبيت.
أنت بحاجة للتطهير والمحاولة مرة أخرى.

UPGRADE FAILED: "API" has no deployed releases
فأنت بحاجة إلى التطهير يدويًا
helm delete --purge API
وسوف تعمل.

اعتبارًا من helm 2.9 ، يمكنك أيضًا أداء helm upgrade --install --force لذلك ليست هناك حاجة للتطهير. للإصدارات السابقة:

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

bacongobbler ما زلت في حيرة من
هل ستتمكن من الإجابة على https://github.com/kubernetes/helm/pull/3597#issuecomment -382843932 عندما يكون لديك وقت؟

شكرا لعملك في هذا.

بالتأكيد. أنا AFK في الوقت الحالي ولكن يمكنني الإجابة لاحقًا هذا المساء. افهم تمامًا الالتباس وسأحاول الإجابة على أسئلتك بأفضل ما يمكنني. لقد انتهى الأمر تمامًا في المكتب أثناء الاستعداد لأشياء أخرى لـ KubeCon EU. :)

أنا منفتح للمساعدة في اختراق هذا و / أو تحسين المستندات عندما نكون هناك.
دعنا نتقابل بالتأكيد: +1:

bacongobbler هل هذا العنوان # 3353 وينفي مجموعة التعليمات البرمجية التي كتبتها كجزء من # 4004؟

في حالتي ، قام helm upgrade --install --force بتنفيذ delete --purge وبعد ذلك تم التثبيت.

هل هذا هو السلوك المتوقع؟ لقد فقدت شهرين من العمل تقريبًا بسبب هذا. متى بدأ force يعني delete ؟

^ لقد أجريت بعض المحادثات مع الأشخاص في kubecon ووجدت أن عددًا قليلاً جدًا من الفرق مثبتة على v2.7.0 بسبب هذا التغيير في السلوك.

أوافق على أن upgrade install يجب ألا يكون مدمرًا أبدًا ، حتى مع ما يمكن أن يعنيه --force .

bacongobbler ، آسف لأنني لم أتمكن من اللقاء عندما كنا بالخارج في CPH.
هل هناك وثائق وراء الأساس المنطقي لتغيير السلوك لعدم السماح بترقية إصدار فاشل؟
يبدو أن السلوك القديم مرغوب فيه أكثر مما لدينا الآن.

راجع التعليق الثاني في https://github.com/kubernetes/helm/issues/3353 للحصول على سياق الخلفية حول سبب إجراء هذا التغيير

أشعر بالفضول حقًا لسماع ما هو المسار المقترح للمضي قدمًا. لا يمكننا التراجع عن # 3097 بسبب المشكلات الموضحة في # 3353 ، لذلك أود أن أسمع ما يعتقده المجتمع أنه المسار الصحيح للمضي قدمًا لإصلاح هذه المشكلة. يمكننا التراجع عن # 3597 ولكن مما سمعته لا يوجد حل جيد للمضي قدمًا لإصلاح مشكلة helm upgrade --install . :خائب الامل:

أعلم أننا نعمل على إعادة العمل بالمنطق التطبيقي لـ Helm 3 ولكن هذا طريق طويل

شكرا لربط ذلك bacongobbler :)
يبدو اقتراحك هنا وكأنه نهج معقول:

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

سيسمح لنا هذا بالتراجع عن # 3597 نظرًا لأنه سيتم معالجة حالة الفشل الوحيدة (لا يوجد شيء يختلف ضده).
هذا يجعل upgrade --install غير مدمر مرة أخرى وأكثر شبهاً بـ kubectl apply .

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

لقد قرأت خلال المناقشات ، لكنني ما زلت غير واضح بشأن كيفية الحصول على أمر upgrade --install (أو تسلسل الأوامر).

باستخدام الإصدار الثابت الحالي ، كيف يمكنني تحقيق ذلك في نص آلي؟ أحتاج إلى أن أكون قادرًا على النشر غير التفاعلي دون استخدام delete --purge ، حتى لو فشلت محاولة سابقة.

بالنسبة للخطط المستقبلية ، هذا هو السلوك الذي توقعته في الأصل من upgrade --install :

• قم بالتثبيت في حالة عدم إجراء عمليات تثبيت سابقة
• قم بترقية تثبيت ناجح سابقًا
• استبدال التثبيت الفاشل سابقا
• في حالة فشل التثبيت ، يجب أن تظل الموارد القديمة في مكانها ، مع عدم وجود وقت تعطل حيثما كان ذلك ممكنًا
• لا توجد عمليات مدمرة (مثل delete --purge التلقائي المذكور أعلاه)

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

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

MythicManiac FWIW:
لا يزال لدي فرقنا مثبتة على v2.7.0 بسبب هذا السلوك.
يبدو أننا لا نواجه أية مشكلات تتعلق بترقية الموارد وحذفها عندما يُفترض أن تستخدم helm upgrade --install مع هذا الإصدار.

لدينا هذه المشكلة أيضًا. إنه أمر مزعج للغاية أنني بحاجة إلى حذف خدمات K8s وما يرتبط بها من خدمات AWS ELB لأن helm has no deployed releases . مدير الحزم رائع ولكن هذه المشكلة تؤدي إلى توقف الإنتاج وهو أمر غير جيد.

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

في الجمعة ، 5 أكتوبر 2018 ، الساعة 18:13 ، كتب يوجين جلوتوف ، [email protected] :

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

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

tcolgate ، شكرا لك! لقد أصلحت للتو مشكلة أخرى (https://github.com/helm/helm/issues/2426#issuecomment-427388715) مع الحل البديل الخاص بك وسأحاول اختباره بحثًا عن ELBs الموجودة عندما أنشر مخططًا جديدًا الأسبوع المقبل على الموارد الحالية .

يمكن أن يعمل التراجع عن الإصدار الأصلي الفاشل.

tcolgate ، لقد اختبرت للتو ولا ، لا يعمل في حالة

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

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

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

لدي فضول ، إذا لم يتمكن Helm من نشر مخطط على الموارد الحالية فلماذا يتسبب helm delete حذف هذه الموارد بالضبط؟

@ thomastaylor312 ، واجهنا هذه المشكلة ~ وكذلك https://github.com/helm/helm/issues/2426~ (لأعلى: لقد وجدت السبب الجذري الحقيقي لـ 2426) مع helm 2.11.0. هل تعتقد أنه يجب إعادة فتحها؟

لقد وجدت هذا الموضوع بعد Error: UPGRADE FAILED: "xxx-service" has no deployed releases
بينما كان مرئيًا من دفة ls -a.

قررت أن أرى ما إذا كانت مشكلة بسبب خطأ - ضبط القيمة ، و --debug --dry-run - فرض في الواقع ما زال يحذف الكبسولة قيد التشغيل ... كان توقعي أن إجراء التشغيل الجاف لن يعدل أبدًا موارد الكتلة.

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

كان توقعي أن إجراء التشغيل الجاف لن يؤدي أبدًا إلى تعديل موارد المجموعة.

هذا توقع عادل - يجب أن نجعل ذلك ... لا يحدث

أعتقد أنه تم تصحيح ذلك في https://github.com/helm/helm/pull/4402 ولكن سيكون من الجيد أن يقوم شخص ما بالتحقق. اسف بشأن ذلك!

نفس المشكلة بعد الترقية إلى 2.11.0

عبر آخر:
https://github.com/reactiveops/reckoner/issues/48#issuecomment -453411283

لماذا هذا مغلق؟ هل لدينا طريقة مناسبة للتعامل مع هذا الآن؟

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

كان للتو helm upgrade --install --force عمل delete --purge وقم بتدمير PVC / PV الخاص بي دون إخباري (عند إعادة التدوير). كان لديه العديد من الإصدارات الفاشلة ، لذلك كان في حالة كان يعمل في kubernetes ، لكن هيلم اعتقد أنه لا توجد إصدارات قيد التشغيل. ليست أوقات جيدة على الإطلاق.

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

بالنسبة لأولئك الذين يبحثون عن المساعدة ، فقد اختفت المشكلة بالنسبة لي بعد ترقية الدفة إلى الإصدار 2.15.2

ما زلت ترى هذه المشكلة على 2.16.0

لماذا لا يزال مغلقًا؟ 2.16.1 لا يزال يتأثر

@ nick4fake أعتقد أنها نسخة مكررة من https://github.com/helm/helm/issues/5595