مرحبًا - هل يمكنك تقديم مزيد من التفاصيل حول كيفية النشر؟ هل تستخدم helm upgrade --install بأي فرصة؟ وإذا قمت بذلك ، فما حالة النشر عند تعطله ( helm ls ) - من المفترض أنه Failed ؟

إذا كانت هذه هي الحالة ، فيجب أن يؤدي helm delete --purge <deployment> المهمة.

مرحبًا ، آسف على المعلومات المفقودة.
نعم أنا أستخدم helm upgrade --install
ونعم ، يبقى النشر في Failed إلى الأبد.
لسوء الحظ ، فإن helm delete --purge <deployment> ليس خيارًا هنا على الإطلاق. لا يمكنني حذف خدمات الإنتاج فقط بسبب ذلك :)

السؤال هو لماذا لا تستطيع الدفة التعافي بعد 3 حالات فشل متتالية.

الطريقة الوحيدة لفرز ذلك بدون حذف الإصدار أضف --force

--force على ماذا؟ إلى helm upgrade --install ؟
وإذا كانت الإجابة بنعم ، فهذا يعني أن المشكلة المذكورة أعلاه هي بالفعل ميزة متوقعة ويجب علينا استخدام --force مع كل عملية نشر؟ - إذا كانت الإجابة بنعم ، فهذا يعني أنها ستنشر عمليات تحرير معطلة بالقوة؟

نعم ، بالطبع إلى helm upgrade --install :)
ونعم يجب عليك استخدام --force مع كل عملية نشر

هل هذا يعني أن --force سينشر إصدارات معطلة بالقوة أيضًا؟ - أعني ، إذا تم كسر البود وإعادة تشغيله طوال الوقت ، فهل سيتم حذف البودات القديمة وجدولة أخرى جديدة؟
--force force resource update through delete/recreate if needed
ما هو شرط delete ؟ هل يمكنك توضيح كيفية عملها بالضبط؟ الوصف قصير جدًا بالتأكيد لمثل هذا العلم الناقد - أتوقع أنه يقوم بآلاف الأشياء تحت الغطاء.

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

وهل تعتقد حقًا أنها ليست مشكلة؟
حتى رسالة الخطأ خاطئة:
app-name has no deployed releases
التي تنص على عدم وجود إصدارات منتشرة
في حين أن هناك ولكن مع حالة Failed ورأس لا بل محاولة لاصلاحها :( - عن طريق تحديد أعني فقط يرجى محاولة نشرها، بدلا من التخلي عن البداية

راجع https://github.com/helm/helm/issues/3208

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

يمكن إصلاحه بإزالة "الحالة": "تم النشر" ، في storage.go: 136

انظر: https://github.com/helm/helm/pull/6933/commits/638229c3d3646e78d0fd5157309f8aeadfd01af1

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

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

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

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

واجهت هذه المشكلة عندما حذفت الإصدار السابق بدون استخدام الخيار --purge .

helm delete --purge <release-name>

إصدار هيلم

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

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

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

يبدو التكاثر سهلاً حقًا:

1. ترقية الدفة - تثبيت "شيء به حجرة بها حاوية تخرج بها خطأ"
2. صحح سبب خروج الحاوية ، على سبيل المثال القيمة ذات الوسيطة غير الصالحة للحاوية الداخلية القابلة للتنفيذ ، وحاول مرة أخرى
   -> خطأ: فشلت الترقية: ليس لـ "foo" إصدارات منتشرة

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

نفس الشيء هنا ، لا أرى كيف يمكن نصح باستخدام delete أو --force خاصةً عند وجود مجلدات ثابتة في مكانها ، لقد فقدت بالفعل جميع لوحات معلومات grafana بسبب هذا مرة واحدة ، ولم أفعل ذلك مرة أخرى :)

تحديث: راجع للشغل في حالتي فشل الإصدار بسبب:

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

حتى لو لم أغير أي شيء في قيم grafana

@ alex88 هل يمكنك توفير الناتج من helm history ؟ أحتاج إلى معرفة كيف يتعامل الآخرون مع هذه الحالة حتى نتمكن من محاولة تحديد السبب الجذري وإيجاد حل.

bacongobbler متأكد من أنني أرغب حقًا في رؤية هذا ثابتًا لأنني حذر حقًا من استخدام الدفة بسبب فقد مجلدات ثابتة عدة مرات (ربما خطأي)

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

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

كيف وصلت إلى حالة فشل فيها كل إطلاق؟ أين الإصدار 1 و 2 و 3؟

كيف وصلت إلى حالة فشل فيها كل إطلاق؟ أين الإصدار 1 و 2 و 3؟

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

تحديث: راجع للشغل أنا أستخدم

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

فيما يتعلق بالإصدار السابق ربما تحتفظ الدفة بعشرة منهم فقط

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

هل هناك أي عمل مستقبلي لتغيير المنطق عندما ينتهي الإصدار الأولي في حالة فاشلة؟

ماذا علي أن أفعل إذا لم يتم قبول التوقف؟

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

ماذا علي أن أفعل إذا لم يتم قبول التوقف؟

في الوقت الحالي ، أستخدم فقط helm لإنشاء القوالب وأقوم بحفظها يدويًا محليًا والتقدم بطلب

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

@ henrikb123 يعمل أعلاه فقط إذا كنت تستخدم لل Allways --atomic العلم. وإلا فإنه لن ينجح. على سبيل المثال: حاول تثبيت مخطط معطل بدونه ويقومون بتشغيل نفس الأمر بعلامة --atomic . سوف ينكسر. لمعلوماتك أنا أستخدم أحدث إصدار من Helm -> 3.0.2

@ alex88 هل يمكنك تقديم الإخراج من سجل الدفة؟ أحتاج إلى معرفة كيف يتعامل الآخرون مع هذه الحالة حتى نتمكن من محاولة تحديد السبب الجذري وإيجاد حل.

bacongobbler لماذا لا تفعل ما قاله @ henrikb123 هنا لمحاكاة المشكلة؟ كما أشار @ henrikb123 ، فإن السجل فارغ تمامًا . استطيع ان اؤكد ذلك ايضا الق نظرة من فضلك:

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

$ helm history teleport
Error: release: not found

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

واجهت هذا أيضًا مع Istio.

هناك مشكلة Istio مع 1.4.3 حيث ستفشل إحدى المهام التي يتم تشغيل التثبيت فيها إذا لم تتمكن من الوصول إلى خادم Kubernetes API. ثم يترك وظيفة وراءه وإذا حاولت إعادة تشغيل أمر Helm فإنه يفشل لأن الوظيفة موجودة بالفعل. حاولت حذف الوظيفة ، وتعديل الأشياء ، وإعادة تشغيل الترقية ولكني لم تنجح أبدًا ... والآن أنا عالق.

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

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

هذا مع Helm 3.0.2.

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

أنا فقط أطلب من المطورين أن يفعلوا بالضبط ما قاله @ henrikb123 في تعليقه لمحاكاة هذه المشكلة. إنها طريقة بسيطة للغاية لمحاكاتها. يمكنك اختباره بأي إصدار من إصدارات Helm (2.xx و 3.xx). أنا على يقين من أنه سيحدث مع كل منهم.

ربما يجب أن يكون --atomic متطلبًا صعبًا (وليس وسيطة سطر أوامر). حتى أنها زائدة عن الحاجة مثل --cleanup-on-fail . الفرق هو أن --cleanup-on-fail لم يصلح هذه المشكلة كما فعل --atomic .

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

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

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

كيف وصلنا إلى هذه الحالة؟

في الأساس ، تجاهل فريق التطوير لدينا الترقيات الفاشلة لأن Kubernetes كان لا يزال يُجري التعديلات بعد انتهاء مهلة القيادة.

على وجه التحديد ، نحن نستخدم Helm 2 وقمنا بتعيين TILLER_HISTORY_MAX=20 على نشر الحراثة. كنا نستخدم helm upgrade --wait --timeout 1080 لجميع ترقيات RollingUpdate التي كانت تستغرق وقتًا أطول بمرور الوقت. ثم بدأت مهلة ترقيات الدفة ولكن لم ينزعج أحد (فقط منزعج) لأن Kubernetes كان لا يزال يُجري التعديلات بنجاح. بعد انتهاء مهلة 20 ترقية (اليوم) ، شعرنا بالقلق لأننا لم نعد قادرين على النشر لأننا بدلاً من ذلك رأينا app-name has no deployed releases .

لماذا يعمل التصحيح؟

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

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

تم العثور على الدليل عندما شاهدنا configmap yaml ولاحظنا التسميات التالية ...

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

وهذا يتوافق مع https://github.com/helm/helm/issues/5595#issuecomment -552743196

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

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

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

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

_ أنا متحمس لسماع رأيك في هذا ._

تجميع مثاليAmazingTurtle.

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

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

هذه وظيفة حقيقية من أداة قمت بكتابتها داخليًا للتعامل مع هذه المشكلة عند ظهورها:

package foo

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

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

    var err error

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

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

    return err
}

jlegrone هل يعمل استخدام helm delete --purge (v2) أو helm uninstall (v3) أيضًا ، حيث إنها كلها إصدارات فاشلة؟

ما أشار إليه jlegrone صحيح.
hickeyma اقتراحك هو حل بديل يمكن أن ينجح. لكني أحتاج إلى حل نهائي.

إنه خطأ ضار خلال العامين الماضيين ولن يقوم القائد بإصلاحه
helm delete غير مقبول في معظم حالات الإنتاج
مع helm3 لا يمكننا kubectl edit secret sh.helm.release.... لأنه مشفر
helm rollback <latest-successful> هو الحل الصحيح فقط

لذلك إذا كان لديك HISTORY_MAX = 10 افتراضيًا وحاولت 10 مرات للحصول على شيء يعمل - فقد فقدت تمامًا ...

وإذا كان لديك بعض المنطق حول التثبيت مقابل الترقية ، فلا يمكنك حذف sh.helm.release ..... v * secrets

يجب أن تموت الدفة أو تصلحها

وجدت الحل
يضع helm3 ملصقات على أسراره:
kubectl get secrets --show-labels | grep sh.helm.release.v1

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

وكذلك الحال بالنسبة لآخر kubectl edit secret sh.helm.release.v1.helm-must-die.v36 وتعيين حالة التسمية = تم النشر
وللإصدار قبل ذلك (الإصدار 35) ، قم بتعيين حالة التسمية = تم الإلغاء

التالي helm upgrade --install ... سوف يعمل

@ kosta709 على غرار ما وجدته لـ Helm2 ، الذي يخزن الإصدارات كـ ConfigMaps في مساحة اسم نظام kube مع تسميات كلها CAPS ، يخزن Helm3 الآن الإصدارات كأسرار في مساحة اسم التطبيق مع تسميات كلها أحرف صغيرة.

لذلك بالنسبة إلى Helm3 ، يمكنك فقط استخدام أمر تصحيح kubectl مختلف قليلاً ...

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

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

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

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

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

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

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

الآن أحاول ببساطة تشغيل helm upgrade -f app.yaml --namespace prometheus prometheus prometheus وقد تلقيت الخطأ: Error: UPGRADE FAILED: "prometheus" has no deployed releases لكن لا يمكنني تجربة أي من الأعمال المجاورة لأن هذا قيد الإنتاج ...

zrsm ما نقوم به الآن هو إنشاء ملفات yaml باستخدام helm واستخدام kubectl diff / dry-run لمعاينة التغييرات قبل تطبيقها يدويًا

zrsm ما نقوم به الآن هو إنشاء ملفات yaml باستخدام helm واستخدام kubectl diff / dry-run لمعاينة التغييرات قبل تطبيقها يدويًا

شكرًا على الرد ، لقد خفضت تصنيفي إلى 2.15.1 ولكنني واجهت مشكلات مماثلة ، ومع ذلك ، حاولت شيئًا مثل حذف ~ /. . سأحاول اختبار هذا باستخدام helm 3 في وقت لاحق اليوم والرد عليه بإصلاح. لدي شعور أن هذا قد يكون هو المشكلة.

مرحبًا ، لقد اختبرت ذلك ... ويبدو أنني قمت بتنفيذ الأمر التالي بعد حذف ~ / .helm / السابق الخاص بي ...

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

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

هذا الخطأ مستمر في Helm 3 ، فهل هناك مخطط لإصلاحه؟

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

هل يمكننا التأكد من حل هذه المشكلة في أسرع وقت ممكن؟

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

أنا موافق. هذا يقودني للجنون سأعمل على إصلاحه. تمنى لي الحظ.

أنا موافق. هذا يقودني للجنون سأعمل على إصلاحه. تمنى لي الحظ.

شكرا لك وحظا سعيدا!

لا أمانع في جعل القليل منكم ينظرون إلى PR # 7653.

أعتقد أن هذا سيحل المشكلات الموضحة أعلاه.

لا أصدق أنه لا يزال مفتوحًا بدون أي رد فعل من المشرفين

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

هل سيعمل استخدام helm delete --purge (v2) أو helm uninstall (v3) أيضًا ، حيث إنها كلها إصدارات فاشلة؟

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

في بعض الأحيان لا يفشل الإصدار ولكن المهلة وتصنفه على أنه الإصدار الفاشل ، وفي المرة التالية يظهر أنه لا يوجد إصدار منشور ، ولكن التطبيق يعمل بكامل طاقته بالفعل ، لقد حدث هذا لي عدة مرات ، لذلك اضطررت إلى تغيير الإصدار التسمية إلى deployed one. ليس دائمًا خيارًا للقيام بـ helm delete --purge (v2) or helm uninstall (v3)

rimusz كيف يتم تغيير تسمية الإصدار؟

dudicoco بالتحرير اليدوي لأحدث سر إصدار helm v3 ، يمكنك أتمتة ذلك واستخدام kubectl patch

انتقلت إلى https://github.com/k14s/kapp الذي يعمل مثل السحر.

rimusz هذا ما

لقد قمت أيضًا بإعادة توجيه الإصلاح الخاص بي إلى الدفة 2 في # 7668 ولكن ما زلت في انتظار التعليقات على # 7653

نفس المشكلة هنا ،

الإصدار الذي تم نشره --wait انتهى وقته ، وأخيرًا أصبح قيد التشغيل. لا يزال يتم وضع علامة عليه على أنه فاشل.
وهكذا ، فشلت عمليات النشر اللاحقة أيضًا.

هذا يعني أن حالة الإصدار ليست معلومات موثوقة.

نستخدم k8s في شركتنا للعديد من الخدمات في الإنتاج.
لبضع مرات في الشهر ، نواجه نفس المشكلات مع الدفة في تطبيقات مختلفة (" * لا توجد إصدارات منتشرة.").
استخدمنا إصدارات مختلفة من الدفة (من 2.7 حتى 3.0.3).
لم يتم حل المشكلة.
هذا يسبب الكثير من الانزعاج لمستخدمينا (المطورين الذين ينشرون التطبيقات في الكتلة)
في كل مرة ، عندما نضغط عليها ، نقوم فقط بتصحيح أحدث أسرار الإصدار (الحالة قيد النشر).
هل هناك أي خطة لإضافة سلوك يتجاهل حالة الإصدارات الأخيرة ويقوم بتثبيت الإصدارات الجديدة؟

بعد تعيين --history-max على 10 (القيمة الافتراضية) ، نجح الإصدار الأول.
بعد ذلك ، فشلت الإصدارات العشرة التالية في:
Error: UPGRADE FAILED: timed out waiting for the condition (تمت محاكاته ، وبالتالي كان متوقعًا).
بعد ذلك ، فشل الإصدار الحادي عشر التالي في:
Error: UPGRADE FAILED: "app" has no deployed releases (هذه هي المشكلة!)

هل من الممكن أن تحتفظ helm دائمًا بأحدث إصدار أحدث 10 إصدارات (مهما كانت حالتها)؟

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

تم دمج https://github.com/helm/helm/pull/4978 مع Helm 2. ربما لم يتم نقله إلى Helm 3. إذا كان لدى شخص ما الوقت وأراد نقله ، فلا تتردد.

لقد جربت يدي في نقل هذا إلى Helm 3 بالرقم # 7806 ، وأحب أن أراه مدمجًا في أسرع وقت ممكن. شكراultimateboy!

ماذا عن الإصدارات التي تفشل في التثبيت الأول ، أي ليس لها إصدارات سابقة ناجحة؟
نحن نستخدم upgrade --install للنشر غير الفعال لإصدارات الدفة وعندما يفشل الإصدار الأول ، تفشل جميع الاستدعاءات اللاحقة لـ upgrade --install مع ظهور الخطأ "ليس له إصدارات منشورة" (هذه المشكلة).

يعتبر سيناريو "فشل الإصدار الأول" أكثر قابلية للإدارة على الأقل ، لأنك عادةً ما تقوم بتشغيله أو مراقبته يدويًا (ويمكنك تطبيق الإصلاح في ذلك الوقت وهناك) - على عكس تشغيل الدفة بواسطة نظام CI / CD الذي يبدأ بفشل أحدهما اليوم ولا يتعافى حتى بعد إصلاح الكود.

يجب أن يتم إصلاحه بالطبع.

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

peterholak أحيانًا يتم تنفيذ سيناريو "فشل الإصدار الأول" باستخدام CI / CD ، وعلى سبيل المثال - قمنا بتقييد الوصول إلى المجموعة الخاصة بنا ولا يمكننا حتى إنشاء "helm ls" كيف يفترض بنا "إدارة هذا"؟

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

نحن نستخدم أيضًا الترقية - التثبيت للنشر غير

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

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

التجربة سيئة للغاية ، لا يمكننا ببساطة حذف الإصدار بالكامل ، لأنه قيد الإنتاج! سيؤدي ذلك إلى تعطل الخادم! فكيف نتعامل مع هذه القضية في النهاية؟

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

تم دمج # 7806 PR في Master. سيتم إصداره في 3.2. أنا أغلق هذه المسألة وفقا لذلك.

رائعة! هذا يحل معظم مشكلاتنا مع Helm.

ما هو السلوك الحالي إذا فشل الإصدار الأول بالرغم من ذلك (لم يتم نشر إصدارات بعد)؟

كان هناك https://github.com/helm/helm/issues/3353 والذي تمت معالجته بواسطة https://github.com/helm/helm/pull/3597 ولكن فقط عند استخدام --force .

يواجه --force بعض المشكلات في Helm 3 رغم ذلك (https://github.com/helm/helm/issues/6378) ، مع اقتراح لمعالجتها (https://github.com/helm/helm/ القضايا / 7082) ، بالإضافة إلى التعليقات الأخرى في هذا الموضوع ، فإن استخدام --force ليس مناسبًا دائمًا على أي حال. لذا فإن الوضع برمته لا يزال غير واضح إلى حد ما.

technosophos شكرا على الإصلاح. فضولي ، متى 3.2. الإصدار المتاح للتثبيت؟ استمر في تلقي خطأ app-name has no deployed releases في إصدار حالي فاشل. وهو نوع مانع في خطوط أنابيب CI / CD.

@ peterholak انظر # 7913.

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

كنت أواجه نفس المشكلة على حل AKS لإصلاح المشكلة المذكورة باتباع الأمر:

helm version : 3.1.2
أنا فقط أحذف الحزمة من مجموعة k8s باستخدام الأمر
helm delete <release-name>

وقم بتشغيل دورة النشر لإصلاح المشكلة

المشكلة لا تزال موجودة في الإصدار 3.2.0

deimosfr تم إصلاح هذا في # 7653 والذي سيكون في الإصدار 3.2.1. لم يتم إصداره بعد ولكن يمكنك الحصول على الإصلاح إذا كنت تريد إنشاء نسخة رئيسية.

أنا في 3.2.1 وما زال هذا يحدث

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

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

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

لا يزال يحدث في الإصدار 3.2.1.

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

تفاصيل:

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

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

لدي نفس المشكلة على الرسم البياني المنشور والجراب يعمل بشكل جيد

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

لكن لا يمكنني ترقيته.

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

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


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

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


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

أؤكد أنه حدث من جانبي أيضًا

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

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

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

لدي نفس المشكلة على الرسم البياني المنشور والجراب يعمل بشكل جيد

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

لكن لا يمكنني ترقيته.

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

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


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

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


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

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

مرحبًا yinzara ،

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

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

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

على أي حال الدرس المستفاد وإجراء التراجع من خلال العلم الذري.

مرحبا yinzara

لقد وجدت سبب فشلها.

لقد قمت بتعيين المعلمة الخاطئة -selfScrapeInterval=10 يجب أن تكون server.extraArgs.selfScrapeInterval = 10

لذا فإن المشكلة مع - في المعلمة.
ربما لم يكن خطأ الدفة ذا مغزى لهذا النوع من الخطأ المتغير؟

فشل واحد:

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

نجاح:

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

يعمل هذا أيضًا:

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

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

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

GloriaPG هل يمكنك مشاركة المزيد من المعلومات؟ كيف تواجه نفس المشكلة؟ كما ذكر yinzara سابقًا في الموضوع ، ربما تواجه حالة لم يتم إصلاحها # 7652. نحن بحاجة إلى مزيد من المعلومات للمساعدة قبل أن نتمكن من التوصل إلى هذا الاستنتاج ، مع ذلك.

مرحبًا @ bacongobbler

نحن نستخدم helm upgrade مع علامات --install و --force :

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

للأسف عندما يكون الإصدار في حالة فشل:

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

ينتج عنه:

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

كيف يمكن حلها؟ يبدو أن --force مع العلم --install لا يعمل

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

شكرا على أي اقتراحات

يبدو أن الخطأ مرتبط بـ https://github.com/kubernetes/client-go/issues/508
لا يمكنك تغيير المحدد في عملية النشر. سيكون عليك إلغاء النشر وإعادة النشر.

الشيء المضحك في yinzara هو أنني لا أغير المحدد في النشر الخاص بي ، كل شيء يعمل في 9/10. حدث خطأ أثناء النشر ، وكان الإصدار في حالة فشل ولم أتمكن من التعافي منه بأي شكل من الأشكال - النشر نفسه يعمل ، تعمل Pods ولكنني لم أعد قادرًا على تعديلها.

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

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

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

لذلك ، من السهل إعادة إنتاج مشكلتي الخاصة مع هذا.

ابدأ في نشر شيء باستخدام helm3 (باستخدام --atomic و --cleanup-on-fail ) ، و ctrl + c العملية بعد أن تبدأ في إنشاء الموارد. لم يتم التراجع عن أي شيء ، ولا تزال الموارد موجودة ، وأية محاولات لاحقة لتشغيل install --upgrade تؤدي إلى ظهور الخطأ "ليس به إصدارات منشورة".

هذا ctrl + c هو شيء يحدث في جوهره عندما يدفع شخص ما التزامًا جديدًا إلى فرع في نظام CI الخاص بنا بينما يكون هناك بالفعل بناء قيد التشغيل - سيتم إلغاء ترقية الدفة ، ثم تكون في حالة معطلة تمامًا.

هل هناك شيء يمكننا القيام به لإصلاحه بعد هذه النقطة؟ كما هو الحال مع العديد من الآخرين في هذا الموضوع ، الحذف ليس خيارًا.

تحرير: بمجرد كسر هذا، helm ls لا تظهر الإفراج عنهم، helm history يظهر ذلك في انتظار تثبيت الدولة.

في الواقع - فما باللك. بالنسبة لأولئك المتأثرين بهذا ، هناك حل واحد: حذف سجل المحفوظات من kubernetes يدويًا. يتم تخزينها على أنها سر. إذا قمت بحذف إدخال حالة pending-install المخالف ، فيمكنني تشغيل upgrade --install مرة أخرى بنجاح!

AirbornePorcine - هل يمكنك توضيح التغييرات المطلوبة في kubernetes لحذف إدخالات التثبيت المعلقة.

@ tarunnarang0201 ينشئ Helm سر kubernetes لكل عملية نشر ، في نفس مساحة الاسم التي قمت بالنشر بها ، سترى أنه من النوع 'helm.sh/release.v1' ، وسمي شيئًا مثل 'sh.helm.release.v1.release -name.v1 '. عليك فقط حذف أحدث سر (انظر إلى لاحقة "v1" في المثال ، يتم زيادتها لكل عملية نشر) ، ويبدو أن ذلك أدى إلى إلغاء حظر الأشياء بالنسبة لي.

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

AirbornePorcine @ tarunnarang0201 @ ninja - يمكنك أيضًا تصحيح ملصق الحالة ... خاصة إذا لم يكن لديك أي إصدارات سابقة.

بالنسبة إلى Helm 3 ، راجع تعليقي على https://github.com/helm/helm/issues/5595#issuecomment -580449247

لمزيد من التفاصيل والإرشادات حول Helm 2 ، راجع تعليقي على https://github.com/helm/helm/issues/5595#issuecomment -575024277

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

نحن نستخدم Terraform بالمناسبة وأحدث مزود دفة. لذلك يجب علينا استخدام --force أو --replace

xbmono المحادثة طويلة لأن هناك

• هناك عدد كبير من الأسباب التي تجعل إطلاق سراحك يدخل في هذه الحالة
• كان هذا ممكنًا في Helm 2 أيضًا ، والحلول التي نجحت هناك وعلى Helm 3 مختلفة.
• هناك مسارات مختلفة اتخذها المستخدمون للوصول إلى هناك
• هناك خيارات مختلفة بناءً على ما تحاول القيام به ، وما إذا كنت على استعداد للمخاطرة / تحمل فقدان الـ PVC ومجموعات مختلفة من فترات التوقف عن العمل.

إذا كنت في الخطأ "ليس لديه إصدارات منتشرة" ، فأنا لست متأكدًا من أن install --replace ولا upgrade --install --force سيساعدك بمفرده.

ربما لا يمكن تقديم اقتراح معقول إلا

• إذا قمت بتوفير helm history للإصدار حتى يتمكن الأشخاص من رؤية ما حدث
• إذا كنت تشارك السبب الأصلي للفشل / ما فعلته للوصول إلى هناك - وما إذا كنت تشعر أن المشكلة الأصلية قد تمت معالجتها

ملخصي للخيارات الممكنة

• إذا كنت لا تهتم بموارد k8s الحالية على الإطلاق أو التوقف ، فقد يكون helm uninstall && helm install خيارًا
• إذا كانت هذه هي المرة الأولى التي فشل فيها تثبيت المخطط ، فيمكنك على الأرجح حذف البيانات الوصفية السرية للإصدار و helm install مرة أخرى. ربما ستحتاج إلى تنظيف موارد k8s يدويًا إذا تم ترك cruft وراءه بسبب الفشل ، اعتمادًا على ما إذا كنت تستخدم --atomic إلخ.
• إذا تخلت عن تثبيت --wait ed جزئيًا وظهر helm history الإصدار الأخير في pending-install يمكنك حذف أحدث بيانات وصفية سرية للإصدار أو تصحيح حالة الإصدار
• في مجموعات معينة أخرى من السيناريوهات ، قد يكون من الممكن أيضًا تصحيح حالة الإصدار لواحد أو أكثر من أسرار الإصدار ومعرفة ما إذا كان يمكن متابعة upgrade اللاحق ، ومع ذلك ، على حد علمي ، تمت معالجة معظم هذه الحالات بواسطة # 7653 (لضمان وجود إصدار deployed في مكان ما في التاريخ للعودة إليه) لذلك سأفاجأ إذا كان هذا مفيدًا الآن.

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

chadlwilson شكرا لاستجابتك.

لا يُرجع helm history أي صفوف!

Error: release: not found

لكن helm list تُرجع عملية النشر الفاشلة

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

نحن نستخدم Terraform ويتم نشر بيئاتنا كل ساعة تلقائيًا بواسطة Jenkins. مع terraform لا يمكنني استخدام helm upgrade ، هذا ما يفعله مزود الدفة

في رمز التضاريس ، قمت بتعيين force_update إلى true ، لم يحالفني الحظ وقمت بتعيين replace إلى true ، مرة أخرى لا حظ

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

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

}

لذا أتساءل عما إذا كان الأمر يتعلق بـ wait=true ؟ لذا ، فإن سبب فشل النشر السابق هو أن المجموعة لم تكن قادرة على الاتصال بمستودع عامل الإرساء ، وبالتالي تم الوصول إلى timeout والحالة هي failed لكننا أصلحنا المشكلة و pods إعادة تشغيل helm delete يعمل ولكن إذا كنت سأفعل ذلك في كل مرة سيكون مديري أو المطورين سعداء.

باستخدام helm v2 في حالة فشل النشر وقام المطورون بإصلاحه ، فإن النشر التالي سيؤدي إلى ترقية النشر الفاشل.

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

يبدو الفشل helm history غريبًا (خطأ إملائي؟ مفقود مساحة الاسم؟ إصدار خاطئ للقيادة؟) ، ولكن نظرًا للمراجعة 1 في list أعلاه ، يبدو أنك تحاول القيام بأول وقت التثبيت لمخطط جديد وفشل التثبيت لأول مرة. إذا كنت تحاول إلغاء حظر الأشياء ، يمكنك على الأرجح حذف البيانات الوصفية السرية للإصدار على النحو الوارد أعلاه أو تصحيح حالتها ، والمحاولة مرة أخرى. قد يشير ذلك إلى أن البيانات الوصفية في حالة سيئة من منظور Helm أو Helm Terraform Provider ، ولكن ليس كيف وصلت إلى هناك.

في أي حال، ليس لدي القضايا القيام upgrade فشل عبر تنشر لأول مرة مع هيلم 3.2.1 منذ تم دمج # 7653. قد ترغب في التحقق مرة أخرى من إصدار Helm المحدد الذي يستخدمه الموفر بالفعل؟ من الممكن أيضًا أن يكون الأمر متعلقًا بالطريقة التي يكتشف بها مزود Helm Terraform حالة الإصدار بعد فشل install . ليس لدي أي خبرة مع هذا المزود ، وأنا شخصياً لا أؤيد تغليف Helm بتجريد تصريحي آخر مثل TF لأنني أجده أكثر غموضًا عندما تسوء الأمور ، ولكن قد ترغب في البحث أكثر هناك بنفس الطريقة .

على أي حال ، كما قلت أعلاه ، إذا كان الخطأ الذي علقت فيه هو has no deployed releases بعد نشر فاشل لأول مرة ، لا أعتقد أن replace ولا force من المحتمل أن تساعدك على إحياء الموقف دون تدخل آخر ، وسيكون من الأفضل تصحيحه بشكل أكبر وإجراء أي محادثة في مكان آخر ، لأن الانتقال ذهابًا وإيابًا على هذه التذكرة القديمة المغلقة مع 51 مشاركًا لا يبدو مثمرًا لجميع المعنيين.

لا لم يكن هناك خطأ مطبعي. أيضًا ، يحدث هذا بغض النظر عن كونه أول عملية نشر أو لاحقًا.

كما ذكرت ، نحن نستخدم الخيار --wait لانتظار النشر في Jenkins ثم إخطار ما إذا كان النشر قد فشل أم لا.

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

لذلك إذا قمنا بإزالة الخيار --wait ، فإن helm سيضع علامة على النشر كـ successful بغض النظر.

الحل:

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

• إزالة --wait الخيار من helm نشر
• استخدام هذا الأمر لاسترداد قائمة نشرها لأن مساحة الاسم الذي كنت بصدد نشر ضد: kubectl get deployments -n ${namespace} -o jsonpath='{range .items[*].metadata}{.name}{","}{end}'
• يمكنك استخدام split لتحويل القائمة المفصولة بفواصل أعلاه إلى مصفوفة
• ثم يمكنك تشغيل أوامر متعددة بالتوازي (نستخدم Jenkins لذلك من السهل القيام بذلك) مثل kubectl rollout status deployment ${deploymentName} --watch=true --timeout=${timeout} -n ${namespace}
• إذا كان بعد timeout ، على سبيل المثال ، 7m يعني 7 دقائق ، فإن النشر لا يزال غير ناجح ، يتم إنهاء الأمر مع وجود خطأ
• تم حل المشكلة.

في الواقع - فما باللك. بالنسبة لأولئك المتأثرين بهذا ، هناك حل واحد: حذف سجل المحفوظات من kubernetes يدويًا. يتم تخزينها على أنها سر. إذا قمت بحذف إدخال حالة pending-install المخالف ، فيمكنني تشغيل upgrade --install مرة أخرى بنجاح!

بدلاً من ذلك ، نجح هذا بالنسبة لي:

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

تم إصلاحه بواسطة kubectl -n $namespace delete secret -lstatus=pending-upgrade
تشغيل الآن دفة مرة أخرى.

لست متأكدًا من سبب إغلاق هذا ، لقد ضربته للتو مع العلامة التجارية الجديدة Helm 3.3.4. في حالة فشل التثبيت الأولي ، لا تزال ترقية القائد الثاني - install --force تظهر نفس الخطأ. تعمل جميع هذه الحلول ، ولكنها يدوية ، فهي لا تساعد عندما تريد ، CI / CD تلقائي بنسبة 100٪ حيث يمكنك ببساطة دفع الإصلاح لتشغيل عملية نشر أخرى دون القيام بالتنظيف يدويًا.

هل فكر أي شخص ببساطة في إضافة علامة على أن هذا هو الإصدار الأول ، لذا من الآمن حذفه تلقائيًا؟ أو إضافة شيء مثل "- force-delete-on-failure"؟ تجاهل المشكلة لن يساعد.

@ nick4fake AFIK تم إغلاقه بواسطة PR # 7653. قد يكون yinzara قادرًا على تقديم المزيد من التفاصيل.

كان قرارًا من قبل المشرفين بعدم السماح بالكتابة فوق إصدار ترقية معلق. لكن تصريحك بأن جميع الحلول عبارة عن حلول لا تعمل في خط أنابيب CI / CD ليس صحيحًا. يمكن إضافة آخر عمل مقترح كخطوة بناء قبل تشغيل ترقية الدفة (أنا أيضًا لن أستخدم --force في خط أنابيب CI / CD). له نفس تأثير ما اقترحته باستثناء أنه يحذف الإصدار مباشرة قبل تثبيت الإصدار التالي بدلاً من بعد ذلك مباشرة مما يسمح لك بتصحيح سبب الفشل.

لقد استخدمت أيضًا ما يلي في بنائي الآلي لإلغاء تثبيت أي إصدارات "معلقة" قبل أن أقوم بتشغيل أمر الترقية (تأكد من تعيين متغير البيئة NS_NAME على مساحة الاسم التي تنشر فيها):
"" باش

! / usr / bin / env bash

RELEASES = $ (قائمة القيادة - مساحة الاسم $ NS_NAME - معلق - إخراج json | jq -r '. [] | حدد (.status == "معلق التثبيت") | .name')
إذا [[ ! -z "إصدارات $"]] ؛ ومن بعد
حذف الدفة - مساحة الاسم $ NS_NAME $ RELEASES
فاي

yinzara شكرًا لك على المقتطف ، إنه مفيد جدًا لأولئك الذين

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

أعني ، فقط تحقق من سلسلة المناقشة هذه ، لا يزال الناس يواجهون المشكلة. ما رأيك في إمكانية إضافة بعض المعلومات الإضافية إلى رسالة خطأ Helm مع ارتباط إلى هذا الموضوع + بعض الاقتراحات حول ما يجب فعله؟

@ nick4fake أعتقد أنك تخلط بين "فشل" و "معلق التثبيت".

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

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

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

إذا وجدت إصداراتك في هذه الحالة ، فقد ترغب في إعادة النظر في تكوين النشر الخاص بك. يجب ألا يحدث هذا أبدًا في خط أنابيب CI / CD تم تكوينه بشكل صحيح. يجب أن تفشل أو تنجح. تشير كلمة "معلقة" إلى أن التثبيت قد تم إلغاؤه بينما كان لا يزال قيد المعالجة.

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

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

ما رأيك في إمكانية إضافة بعض المعلومات الإضافية إلى رسالة خطأ Helm مع ارتباط إلى هذا الموضوع + بعض الاقتراحات حول ما يجب فعله؟

+1 لهذا. لا يزال يتعين علينا البحث في موقع Google ، للعثور على هذا الموضوع ، لفهم ما هو إصدار pending-install ، حتى نتمكن من البدء في التفكير في رسالة الخطأ هذه.

كان لدي مشاكل مع helm upgrade وهذا يقودني إلى هنا. تم حلها عن طريق إضافة -n <namespace> . ربما سيساعد شخص ما هناك.

بالنسبة إلى Helm3 ، يمكن حلها من خلال التصحيح
kubectl -n <namespace> patch secret <release-name>.<version> --type=merge -p '{"metadata":{"labels":{"status":"deployed"}}}'

release-name و version - يمكن رؤيته من kubectl get secrets -n <namespace> | grep helm