Hai - dapatkah Anda memberikan detail lebih lanjut tentang cara Anda menerapkan? apakah Anda kebetulan menggunakan helm upgrade --install ? Dan jika Anda melakukannya, bagaimana status penerapan saat rusak ( helm ls ) - mungkin Failed ?

Jika ini masalahnya, helm delete --purge <deployment> cukup.

hai, maaf atas info yang hilang.
Ya, saya menggunakan helm upgrade --install
Dan ya, penerapan tetap di Failed selamanya.
Sayangnya helm delete --purge <deployment> sama sekali bukan pilihan. Saya tidak bisa begitu saja menghapus layanan produksi karena itu :)

Pertanyaannya adalah mengapa helm tidak bisa pulih setelah 3 kali kegagalan berturut-turut.

satu-satunya cara untuk mengurutkan itu tanpa menghapus rilis tambahkan --force

--force untuk apa? menjadi helm upgrade --install ?
dan jika ya, berarti masalah di atas sebenarnya adalah fitur yang diharapkan dan kita harus menggunakan --force dengan setiap penerapan? - jika ya, maka itu berarti akan menyebarkan rilis yang rusak secara paksa?

ya, tentu saja menjadi helm upgrade --install :)
dan ya, Anda harus menggunakan --force dengan setiap penerapan

apakah itu berarti bahwa --force akan menyebarkan rilis yang rusak secara paksa juga? - Maksud saya, jika pod akan rusak dan selalu aktif ulang, apakah akan menghapus pod lama dan menjadwalkan yang baru?
--force force resource update through delete/recreate if needed
apa kondisi delete ? dapatkah Anda menjelaskan cara kerjanya dengan tepat? deskripsinya pasti terlalu pendek untuk bendera yang begitu kritis - saya berharap itu melakukan ribuan hal di balik terpal.

BTW Saya benar-benar tidak ingin berakhir dengan layanan produksi yang dihapus, jadi bendera --force bukanlah pilihan bagi saya.

dan apakah Anda benar-benar berpikir bahwa itu bukan masalah?
bahkan pesan kesalahannya salah:
app-name has no deployed releases
yang menyatakan bahwa tidak ada rilis yang diterapkan
sementara ada tetapi dengan negara Failed dan helm bahkan tidak mencoba untuk memperbaikinya :( - dengan memperbaiki maksud saya coba gunakan saja, daripada menyerah dari awal

Lihat https://github.com/helm/helm/issues/3208

Sangat setuju. Produksi kami mengalami kesalahan yang sama. Jadi menghapus bagan bukanlah suatu pilihan, dan memaksa penginstalan tampaknya berbahaya. Kesalahan ini masih terjadi pada Helm 3. Jadi mungkin lebih baik untuk menyertakan perbaikan atau solusi yang lebih aman.

itu bisa diperbaiki dengan menghapus "status": "disebarkan", di storage.go: 136

Lihat: https://github.com/helm/helm/pull/6933/commits/638229c3d3646e78d0fd5157309f8aeadfd01af1

Saya akan memperbaiki Permintaan Tarik ketika saya punya waktu.

Kode yang ada pada awalnya benar. Menghapus status: deployed dari hasil kueri dengan Helm menemukan rilis terbaru untuk dimutakhirkan, terlepas dari status saat ini yang dapat menyebabkan hasil yang tidak diinginkan. Ini mengelak dari masalah untuk sementara, tetapi itu memperkenalkan masalah yang jauh lebih besar di kemudian hari.

Jika Anda dapat memberikan output helm history ketika Anda menemukan bug ini, itu akan sangat membantu. Lebih membantu untuk menentukan bagaimana seseorang berakhir dalam kasus di mana buku besar rilis tidak memiliki rilis dalam status "diterapkan".

Saya mengalami masalah ini saat menerapkan untuk pertama kalinya ke cluster baru. Haruskah saya menggunakan --force juga?

Saya mengalami masalah ini ketika saya menghapus rilis sebelumnya tanpa menggunakan opsi --purge .

helm delete --purge <release-name>

Versi Helm

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

Saya juga mengalami masalah ini.

@bayu_joo
Saya memukul ini dengan helm3. Sejarah benar-benar kosong ketika ini terjadi, meskipun sumber daya k8s yang rusak ada sejak percobaan 1.

Reproduksi tampaknya sangat mudah:

1. helm upgrade - menginstal "sesuatu dengan pod yang memiliki kontainer yang keluar dengan kesalahan"
2. perbaiki apa yang menyebabkan penampung keluar, misalnya nilai dengan arg tidak valid untuk eksekusi di dalam penampung, dan coba lagi
   -> Kesalahan: UPGRADE GAGAL: "foo" tidak memiliki rilis yang diterapkan

Tampaknya flag --atomic mungkin merupakan cara maju dalam skenario (CI / CD) saya. Karena itu membersihkan rilis awal yang gagal sepenuhnya seolah-olah itu tidak pernah terjadi, saya tidak mengalami masalah ini pada upaya berikutnya.

Sama di sini, saya tidak melihat bagaimana menggunakan delete atau --force dapat disarankan terutama ketika ada volume yang persisten, saya sudah kehilangan semua dasbor grafana karena ini sekali, tidak melakukan itu lagi :)

Perbarui: btw dalam kasus saya rilis gagal karena:

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

bahkan jika saya belum mengubah apa pun dalam nilai grafana

@ alex88 dapatkah Anda memberikan output dari helm history ? Saya perlu tahu bagaimana orang lain menangani kasus ini sehingga kami dapat mencoba mencari akar penyebabnya dan menemukan solusinya.

@bacongobbler yakin saya akan sangat senang melihat ini diperbaiki karena saya sangat berhati-hati menggunakan helm karena telah kehilangan volume persisten beberapa kali (mungkin salah saya)

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

pada dasarnya saya sudah mencoba beberapa kali untuk menjalankan peningkatan untuk mengubah beberapa variabel env dan sejak saat ada kesalahan penerapan, variabel env berubah, saya terus melakukannya mengabaikan kesalahan

bagaimana Anda bisa mencapai kondisi di mana setiap rilis gagal? Di mana rilis 1, 2, dan 3?

bagaimana Anda bisa mencapai kondisi di mana setiap rilis gagal? Di mana rilis 1, 2, dan 3?

mengubah variabel env (harus melakukan banyak perubahan) dan menjalankan peningkatan setiap kali, itu mengubah variabel env tetapi saya tidak tahu cara memperbaiki kesalahan volume yang terus-menerus

Perbarui: btw saya menggunakan

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

Mengenai rilis sebelumnya mungkin helm hanya menyimpan 10 saja

Helm3: Saya mengalami masalah yang sama saat mengupgrade istio, rilis gagal, sekarang saya tidak dapat menerapkannya kembali meskipun kesalahan kecil pada template telah diperbaiki. Saya tidak dapat menghapus rilis produksi karena ini juga akan menghapus ELB terkait dengan layanan istio-ingress.

Apakah ada pekerjaan masa depan untuk mengubah logika ketika rilis awal berakhir dalam keadaan gagal?

Apa yang harus saya lakukan jika downtime tidak diterima?

% 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"}

Apa yang harus saya lakukan jika downtime tidak diterima?

untuk saat ini saya hanya menggunakan helm untuk menghasilkan template dan saya menyimpannya secara manual dan menerapkannya

Tampaknya flag --atomic mungkin merupakan cara maju dalam skenario (CI / CD) saya. Karena itu membersihkan rilis awal yang gagal sepenuhnya seolah-olah itu tidak pernah terjadi, saya tidak mengalami masalah ini pada upaya berikutnya.

@ henrikb123 karya-karya di atas hanya jika Anda allways digunakan --atomic bendera. Jika tidak, itu tidak akan berhasil. Misalnya: coba instal bagan rusak tanpa itu dan mereka menjalankan perintah yang sama dengan bendera --atomic . Ini akan rusak. FYI Saya menggunakan Helm versi terbaru -> 3.0.2

@ alex88 bisakah anda memberikan output dari sejarah helm? Saya perlu tahu bagaimana orang lain menangani kasus ini sehingga kami dapat mencoba mencari akar penyebabnya dan menemukan solusinya.

@bacongobbler mengapa Anda tidak melakukan apa yang dikatakan @ henrikb123 di sini untuk mensimulasikan masalah? Seperti yang ditunjukkan oleh @ henrikb123 , riwayatnya benar-benar kosong . Saya bisa memastikannya juga. Silakan lihat:

$ 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

Saya juga mengalami ini dengan Istio.

Ada masalah Istio dengan 1.4.3 di mana salah satu pekerjaan yang dijalankan penginstalan akan gagal jika tidak bisa masuk ke server API Kubernetes. Kemudian meninggalkan pekerjaan dan jika Anda mencoba untuk menjalankan kembali perintah Helm gagal karena pekerjaan sudah ada. Saya mencoba menghapus pekerjaan, mengubah banyak hal, dan menjalankan kembali peningkatan tetapi tidak pernah berhasil ... dan sekarang saya macet.

(Begitulah cara Anda masuk ke status rilis yang semuanya gagal, karena ada pertanyaan tentang itu.)

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

Ini dengan Helm 3.0.2.

IMO ini adalah masalah kritis yang perlu segera diperbaiki. Saya melihat banyak masalah serupa lainnya yang terbuka untuk masalah yang sama sejak versi 2 dan hingga sekarang tampaknya belum diperbaiki.

Saya hanya meminta pengembang untuk melakukan apa yang dikatakan @ henrikb123 pada komentarnya untuk mensimulasikan masalah ini. Ini adalah cara yang sangat sederhana untuk mensimulasikannya. Anda dapat mengujinya dengan versi Helm apa pun (2.xx dan 3.xx). Saya hampir yakin itu akan terjadi dengan semuanya.

Mungkin --atomic harus menjadi persyaratan yang sulit (bukan argumen baris perintah). Bahkan cukup mubazir sebagai --cleanup-on-fail . Perbedaannya adalah bahwa --cleanup-on-fail tidak memperbaiki masalah ini seperti yang dilakukan --atomic .

Kami juga baru saja menjumpai hal ini dalam produksi dan waktu henti bukanlah suatu pilihan. Kami menemukan solusi dengan hanya menambal configmap GAGAL terbaru agar memiliki label STATUS: DEPLOYED menggunakan perintah seperti ...

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

Dalam kasus kami, kami yakin bahwa revisi GAGAL terakhir pada akhirnya benar-benar berhasil diterapkan oleh kubernetes.

Bagaimana kita bisa menjadi seperti ini?

Pada dasarnya, tim pengembang kami mengabaikan peningkatan yang GAGAL karena Kubernetes masih melakukan modifikasi setelah waktu helm habis.

Secara khusus, kami menggunakan Helm 2 dan kami menetapkan TILLER_HISTORY_MAX=20 pada penerapan tiller-deploy. Kami menggunakan helm upgrade --wait --timeout 1080 untuk semua pemutakhiran RollingUpdate kami yang memakan waktu lebih lama dari waktu ke waktu. Kemudian upgrade helm mulai time-out tetapi tidak ada yang was-was (hanya kesal) karena Kubernetes masih berhasil melakukan modifikasi. Setelah 20 pemutakhiran habis waktunya (hari ini), kami khawatir karena kami tidak dapat menerapkan lagi karena sebagai gantinya kami melihat app-name has no deployed releases .

Mengapa tambalan berfungsi?

Kami menemukan bahwa kami hanya perlu menambal label STATUS di configmap karena kami menyadari bahwa Helm mungkin meminta peta konfigurasi menggunakan permintaan yang mirip dengan ...

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

Petunjuknya ditemukan ketika kita melihat configmap yaml dan melihat label berikut ...

$ 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...

Dan ini konsisten dengan https://github.com/helm/helm/issues/5595#issuecomment -552743196

@bacongobbler alih-alih bertanya-tanya bagaimana Anda bisa masuk ke status gagal, Anda harus mempertimbangkan perbaikan berharga untuk memutakhirkan instalasi yang gagal, yang .. seharusnya tidak gagal.

Namun sebenarnya, untuk menjawab kekhawatiran Anda: waktu menyendiri adalah alasan yang baik untuk rilis yang gagal. Rilis juga akan macet dan tidak dapat dibatalkan saat meningkatkan dan mengalami batas waktu.

Jadi memiliki volume yang dibuat secara dinamis oleh klaim. Saat menghapus klaim (dengan menghapus grafik) volume juga dihapus secara permanen . Kamu tidak menyukainya. Saya dan banyak pengembang

Anda tidak menyukai gagasan untuk menghapus status: deployed dari kueri. Jadi bagaimana dengan menambahkan label baru yang benar -

_Saya senang mendengar pendapat Anda tentang ini._

Kolokasi sempurna @AmazingTurtle.

Saya tidak yakin apakah ini telah dicatat, tetapi masalah ini juga muncul jika pemasangan bagan pertama gagal karena alasan apa pun (yang merupakan kejadian yang sangat umum terutama untuk pengguna bagan pertama kali yang mungkin perlu mengulanginya. konfigurasi agar semuanya berjalan).

Saya yakin satu-satunya solusi untuk pengguna CLI dalam hal ini adalah menghapus rahasia pelacakan rilis jika menggunakan driver rahasia, serta semua sumber daya yang dibuat oleh rilis terakhir (untuk menghindari pemeriksaan kepemilikan sumber daya Helm).

Ini adalah fungsi nyata dari alat yang saya tulis secara internal untuk menangani masalah ini saat muncul:

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 Apakah menggunakan helm delete --purge (v2) atau helm uninstall (v3) juga berfungsi, karena semuanya adalah rilis yang gagal?

Apa yang dikemukakan oleh @jlegrone benar adanya.
@hickeyma proposal Anda adalah solusi yang dapat berhasil. Tapi, saya butuh solusi yang pasti.

itu adalah bug berbahaya selama 2 tahun terakhir dan helm tidak akan memperbaikinya
helm delete tidak dapat diterima di sebagian besar kasus produksi
dengan helm3 kita tidak bisa kubectl edit secret sh.helm.release.... karena dienkripsi
helm rollback <latest-successful> hanya solusi yang benar

jadi jika Anda memiliki HISTORY_MAX = 10 secara default dan Anda mencoba 10 kali untuk mendapatkan sesuatu yang berfungsi - Anda benar-benar tersesat ...

dan jika Anda memiliki logika tentang install vs upgrade, Anda tidak dapat menghapus sh.helm.release ..... v * secret

helm harus mati atau memperbaikinya

menemukan solusi
helm3 memberi label pada rahasianya:
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
...

begitu juga untuk kubectl edit secret sh.helm.release.v1.helm-must-die.v36 dan setel status label = disebarkan
dan untuk rilis sebelumnya (v35) atur status label = diganti

berikutnya helm upgrade --install ... akan bekerja

@ kosta709 Mirip dengan temuan saya untuk Helm2, yang menyimpan rilis sebagai ConfigMaps di namespace sistem kube dengan label yang semuanya CAPS, Helm3 sekarang menyimpan rilis sebagai Rahasia di namespace aplikasi dengan label yang semuanya huruf kecil.

Jadi untuk Helm3, Anda bisa menggunakan perintah kubectl patch yang sedikit berbeda ...

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

Saya berharap kami tidak perlu mendiskusikan solusi ini. Memperbaiki ini pada produk harus menjadi prioritas utama. Pengingat betapa buruknya ini (dengan mengabaikan solusi):

Jika rilis gagal saat pertama kali diterapkan ATAU jika cukup rilis gagal memutar sukses terakhir dari riwayat, rilis tidak dapat diperbaiki tanpa intervensi manual.

Mengingat penggunaan Helm dari pipeline penerapan berkelanjutan mungkin merupakan pola umum atau setidaknya pola yang diinginkan, ini tidak bisa diterapkan.

Saya sepenuhnya setuju tetapi setidaknya ingin mendokumentasikan dengan jelas pekerjaan di sekitar karena ketika Anda masuk ke keadaan ini, rasanya tidak ada pilihan lain selain meninggalkan rilis dan melakukan pemadaman.

Seiring dengan tambalan untuk menghindari pemadaman, kami juga berhenti menggunakan helm --wait dan sebagai gantinya mengandalkan logika polling kami sendiri untuk mengetahui kapan rilis berhasil atau tidak. Ini lebih banyak pekerjaan tetapi sekarang kami memiliki visibilitas yang jauh lebih banyak, yang berguna ketika rilis membutuhkan waktu lebih lama dari yang diharapkan, dan kami dapat mendeteksi kegagalan lebih awal dari waktu tunggu.

Ini bukan masalah bagi saya pada versi helm yang lebih lama, dan tidak ada penerapan yang gagal, kubectl menunjukkan layanan yang sedang berjalan dan semuanya berfungsi.

Sekarang saya hanya mencoba menjalankan helm upgrade -f app.yaml --namespace prometheus prometheus prometheus dan saya mendapatkan kesalahan: Error: UPGRADE FAILED: "prometheus" has no deployed releases tetapi saya tidak dapat mencoba salah satu solusi karena ini dalam produksi ...

@zrsm apa yang kami lakukan untuk saat ini adalah membuat file yaml menggunakan helm dan menggunakan kubectl diff / dry-run untuk melihat perubahan sebelum menerapkannya secara manual

@zrsm apa yang kami lakukan untuk saat ini adalah membuat file yaml menggunakan helm dan menggunakan kubectl diff / dry-run untuk melihat perubahan sebelum menerapkannya secara manual

Terima kasih atas jawabannya, saya menurunkan versi ke 2.15.1 tetapi mengalami masalah serupa, namun, saya mencoba sesuatu seperti menghapus ~ / .helm saya dan kemudian saya menginisialisasi ulang akun layanan anakan dari kubectl, setelah melakukan ini saya dapat menerapkan grafik ke kubernetes . Saya akan mencoba menguji ini dengan helm 3 hari ini dan membalas dengan perbaikan. Saya merasa ini mungkin masalahnya.

Halo, jadi saya menguji ini ... dan sepertinya melakukan perintah berikut setelah juga menghapus ~ / .helm / menyelesaikan ini ...

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 -

Saya berpikir jika Anda menginstal edisi helm baru dan barang-barang akun layanan Anda tidak ada (saya menghapus laptop saya dan memulihkannya di beberapa titik) maka ini terjadi dan inilah perbaikannya. Saya harap ini juga berhasil untuk Anda.

Bug ini sedang berlangsung di Helm 3, apakah ada perbaikan yang direncanakan?

Juga mengalami masalah ini dengan cluster baru dan penerapan baru karena waktu tunggu. Saya tidak suka menghubungkan secara manual ke cluster kami untuk memperbaikinya, tapi saya rasa itulah satu-satunya pilihan sekarang.

Bisakah kami memastikan masalah ini diselesaikan secepatnya?

masalah ini sangat membuat frustasi sehingga menjadi alasan untuk berhenti menggunakan helm sama sekali.

Saya setuju. Ini membuatku gila. Saya akan bekerja untuk memperbaikinya. Doakan aku.

Saya setuju. Ini membuatku gila. Saya akan bekerja untuk memperbaikinya. Doakan aku.

terima kasih dan semoga berhasil!

Saya tidak keberatan meminta beberapa dari Anda melihat PR # 7653.

Saya yakin ini akan menyelesaikan masalah yang dijelaskan di atas.

Tidak percaya itu masih terbuka tanpa reaksi dari pengelola

cc @bacongobbler @mattfarina

Apakah menggunakan helm delete --purge (v2) atau helm uninstall (v3) juga berfungsi, karena semuanya merupakan rilis yang gagal?

@ickma tidak selalu; ini juga bisa menjadi hasil dari korupsi metadata rilis helm sehingga dalam beberapa kasus menghapus instalasi dapat menghapus sumber daya yang sedang dimuat.

terkadang rilis tidak gagal tetapi batas waktu dan helm menandainya sebagai yang gagal, dan di lain waktu rilis tersebut menunjukkan tidak ada rilis yang diterapkan, tetapi aplikasi sebenarnya berfungsi penuh, hal itu sering terjadi pada saya, jadi saya harus mengubah rilis beri label ke deployed satu. itu tidak selalu merupakan pilihan untuk melakukan helm delete --purge (v2) or helm uninstall (v3)

@rimusz bagaimana Anda mengubah label rilis?

@dudicoco dengan secara manual mengedit rahasia rilis terbaru helm v3, Anda dapat mengotomatiskannya dan menggunakan kubectl patch

telah pindah ke https://github.com/k14s/kapp yang berfungsi seperti pesona.

@rimusz itulah yang saya pikirkan, terima kasih.

Saya juga mem-porting perbaikan saya ke helm 2 di # 7668 tetapi saya masih menunggu umpan balik di # 7653

Masalah yang sama di sini,

Rilis yang di-deploy dengan --wait melakukan waktu tunggu, dan akhirnya aktif dan berjalan. Itu masih ditandai sebagai gagal.
Jadi, penerapan selanjutnya juga gagal.

Ini berarti status rilis bukanlah informasi yang dapat diandalkan.

Kami menggunakan k8s di perusahaan kami untuk banyak layanan dalam produksi.
Untuk beberapa kali dalam sebulan, kami memiliki masalah yang sama dengan helm pada aplikasi yang berbeda (" * tidak memiliki rilis yang diterapkan.").
Kami menggunakan berbagai versi helm (dari 2.7 hingga 3.0.3).
Masalahnya belum diperbaiki.
Ini menyebabkan banyak ketidaknyamanan bagi pengguna kami (pengembang yang menerapkan aplikasi dalam cluster)
Setiap kali, ketika kami menekannya, kami hanya menambal rahasia rilis terbaru (status untuk diterapkan).
Apakah ada rencana untuk menambahkan perilaku yang mengabaikan status rilis terakhir dan menginstal rilis baru?

Memiliki --history-max disetel ke 10 (nilai default), rilis pertama berhasil.
Kemudian, 10 rilis berikutnya gagal pada:
Error: UPGRADE FAILED: timed out waiting for the condition (Itu telah disimulasikan, diharapkan).
Setelah itu, rilis berikutnya (ke-11 gagal) gagal pada:
Error: UPGRADE FAILED: "app" has no deployed releases (itulah masalahnya!)

Mungkinkah helm selalu mempertahankan rilis terbaru yang berhasil dalam sejarah, selain 10 rilis terbaru (apa pun statusnya)?

Saya suka ide itu. Akan perlu mengubah fungsionalitas penyimpanan tetapi saya pikir itu bisa dilakukan.

https://github.com/helm/helm/pull/4978 telah digabungkan untuk Helm 2. Mungkin itu tidak ditransfer ke Helm 3. Jika seseorang punya waktu dan ingin mentransfernya, silakan.

Saya mencoba memindahkan ini ke Helm 3 dengan # 7806, dan ingin melihatnya digabungkan secepatnya. Terima kasih, @ultimateboy!

Bagaimana dengan rilis yang gagal pada instalasi _first_, yaitu tidak memiliki rilis sukses sebelumnya?
Kami menggunakan upgrade --install untuk penyebaran idempoten dari rilis helm dan ketika rilis pertama gagal, semua pemanggilan berikutnya dari upgrade --install gagal dengan kesalahan "tidak memiliki rilis yang diterapkan" (masalah ini).

Skenario "rilis pertama gagal" setidaknya lebih dapat dikelola, karena Anda biasanya menjalankan atau memantaunya secara manual (dan dapat menerapkan perbaikan saat itu juga) —berbeda dengan helm yang dijalankan oleh sistem CI / CD yang baru saja mulai gagal hari dan tidak pulih bahkan setelah memperbaiki kode.

Ini masih harus diperbaiki tentunya.

Ada juga nilai dalam mempertahankan rilis terakhir yang berhasil, bukan hanya karena bug ini. Misalnya masalah debugging dengan file nilai, dll.

@peterholak Skenario "rilis pertama gagal" terkadang juga dilakukan dengan CI / CD dan misalnya - kami telah membatasi akses ke cluster kami dan bahkan tidak dapat membuat "helm" bagaimana kami seharusnya "mengelola ini"?

Masalah ini harus menjadi prioritas utama mengingat kebanyakan orang menggunakan helm dalam produksi. Saya dapat menjalankan pemasangan helm dengan --atomic , tetapi bagaimana jika saya ingin memeriksa alasan kegagalan sebelum menerapkan? Saya akan diberi kotak waktu oleh batas waktu sebelum penginstalan gagal dan kemudian kembali. Jika saya berhasil meningkatkan, saya tidak perlu merasa tertekan saat memeriksa kegagalan.

Kami juga menggunakan pemutakhiran - instal untuk penyebaran helm yang idempoten . Karena begitulah cara kerja pipeline ci / cd otomatis. Kami tidak berencana untuk mengutak-atik helm secara manual karena hal itu akan melewati jalur pipa penerapan kami.

Dalam pipeline penerapan otomatis, penerapan pertama hampir selalu gagal. Penerapan selanjutnya tidak boleh dipicu secara berbeda dari upaya pertama.

Harap pertimbangkan untuk meningkatkan prioritas masalah ini secara signifikan.

Pengalamannya sangat buruk, kami tidak bisa begitu saja menghapus seluruh rilis, karena sedang dalam produksi! Ini akan menyebabkan downtime server! Bagaimana kita bisa mengatasi masalah ini pada akhirnya?

Selain itu, dapatkah seseorang menghapus label pertanyaan / dukungan? Masalah ini bukan tentang dokumentasi yang hilang, tetapi tentang perilaku Helm saat ini yang tidak terlalu mendukung penggunaan dalam pipeline penerapan otomatis.

PR # 7806 telah digabungkan ke master. Ini akan dirilis pada 3.2. Saya menutup masalah ini sesuai dengan itu.

Bagus! Ini menyelesaikan sebagian besar masalah kami dengan Helm.

Apa perilaku saat ini jika rilis pertama gagal (belum ada rilis yang diterapkan)?

Ada https://github.com/helm/helm/issues/3353 yang ditangani oleh https://github.com/helm/helm/pull/3597 tetapi hanya jika --force digunakan.

--force memiliki beberapa masalah di Helm 3 (https://github.com/helm/helm/issues/6378), dengan proposal untuk mengatasinya (https://github.com/helm/helm/ issues / 7082), ditambah dengan komentar lain di utas ini yang disebutkan, menggunakan --force tidak selalu cocok. Jadi keseluruhan situasinya masih agak tidak jelas.

@technosophos terima kasih atas perbaikannya. Penasaran, kapan 3.2. rilis tersedia untuk diinstal? Terus dapatkan kesalahan app-name has no deployed releases pada rilis gagal yang ada. Dan itu semacam pemblokir di pipeline CI / CD.

@peterholak lihat # 7913.

3.2 akan dibahas pada panggilan dev publik 16 April. Saya telah memprioritaskannya menjadi hanya yang saat ini terlihat seperti dapat langsung dibungkus. Kemudian kami akan memulai proses rilis beta (dengan asumsi semua pengelola setuju pada panggilan besok).

Saya menghadapi masalah yang sama pada penyelesaian AKS untuk memperbaiki masalah yang disebutkan dengan perintah berikut:

helm version : 3.1.2
Saya baru saja menghapus paket dari cluster k8s dengan perintah
helm delete <release-name>

dan jalankan siklus penerapan untuk memperbaiki masalah tersebut

Masalahnya masih ada di versi 3.2.0

@deimosfr Ini diperbaiki di # 7653 yang akan ada di rilis 3.2.1. Ini belum dirilis tetapi Anda bisa mendapatkan perbaikan jika Anda ingin membangun master.

Saya menggunakan 3.2.1 dan ini masih berlangsung

Masih ada alasan mengapa kesalahan ini bisa terjadi. 3.2.1 tidak begitu saja menghapus kesalahan. Ini menghilangkan beberapa penyebabnya. Jika Anda masih mengalaminya, masalah Anda bukan hanya masalah yang diperbaiki.

@yinzara Saya memiliki kasus klasik "jalur b" dari deskripsi asli pada cluster baru tanpa masalah. Saya juga dapat mereproduksi kesalahan ini di cluster lain di mana Helm v2 berfungsi dengan baik. Kita tentu saja dapat melakukan tarian klasik "ini disebabkan oleh sesuatu yang lain, buka masalah baru", tetapi saya pikir akan lebih cepat jika dikenali bahwa itu tidak benar-benar diperbaiki.

Berapakah keluaran dari helm list ? Apa "status" dari rilis gagal sebelumnya? Helm 2 mengalami masalah ini dan belum diperbaiki sama sekali, jadi menurut saya masalah Anda tidak seperti yang Anda pikirkan.

Masih terjadi pada versi 3.2.1.

Jika penerapan awal gagal 3 kali, semuanya macet ... Tidak ada cara untuk memperbaikinya jika Anda tidak menghapus bagan dan menerapkan yang bagus.

Detailnya:

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

Saya memiliki masalah yang sama pada bagan yang diterapkan dan podnya berfungsi dengan baik

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

Tapi saya tidak bisa memutakhirkannya.

$ 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

Saya mengonfirmasi itu terjadi di pihak saya juga

@zodraz Status helm Anda menunjukkan alasan kesalahan Anda. Rilis terbaru tidak ditampilkan sebagai gagal, itu ditampilkan sebagai "penginstalan tertunda". Ini akan menyiratkan bahwa proses yang mengelola peningkatan terakhir secara artifisial dihentikan sebelum diselesaikan (yaitu sebelum terjadi kesalahan atau berhasil).

Itu adalah keputusan pengelola proyek untuk tidak menyertakan status penginstalan tertunda sebagai status kesalahan yang valid untuk memungkinkan peningkatan. (yaitu ini berfungsi seperti yang dirancang)

Saya sarankan Anda mencoba untuk memastikan mengapa upgrade helm Anda dibatalkan sebelum selesai. Itu harus menjadi situasi yang bisa dihindari.

Saya memiliki masalah yang sama pada bagan yang diterapkan dan podnya berfungsi dengan baik

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

Tapi saya tidak bisa memutakhirkannya.

$ 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

Saya akan mengatakan masalah Anda cukup membingungkan saya. Saya tidak bisa melihat bagaimana itu bisa terjadi mengingat output log yang Anda miliki. Rilis perbaikan di 3.2.1 pasti tidak akan membantu situasi Anda karena Anda tidak memiliki rilis yang gagal. Saya akan menebak entah bagaimana beberapa rahasia telah dihapus dari Kubernetes yang berisi informasi rilis helm. Saya akan menyarankan untuk mencopot rilis sepenuhnya dan menginstal ulang jika Anda bisa.

Hai @yinara ,

Masalahnya adalah saya tidak membatalkannya ... Sejauh yang saya mengerti saat ketiga kalinya saya meluncurkan (dan melakukan kesalahan ... karena saya memiliki kesalahan pada penerapan sehingga gagal) membuatnya mencapai "status rusak" .. .

Status ini tidak dapat dipulihkan ... Jadi satu-satunya cara untuk memperbaikinya adalah dengan menghapus bagan ... Solusi saya untuk menghindarinya, gunakan bendera atom untuk selalu melakukan rollback dan tidak pernah mencapai "status rusak" ini ...

Saya memahami keputusan pengelola ... Tetapi ini menyebabkan kebingungan, tidak ada solusi yang mungkin sama sekali (jika tidak menghapus grafik) dan yah, seperti yang saya katakan, status ini tercapai ketika 3 kesalahan terjadi ... tanpa membatalkannya .. .

Pokoknya pelajaran dipelajari dan membuat rollback melalui bendera atom.

Hai @yinara

Saya menemukan alasan mengapa gagal.

Saya menetapkan parameter yang salah -selfScrapeInterval=10 seharusnya server.extraArgs.selfScrapeInterval = 10

Jadi masalah dengan - di parameter.
Mungkin kesalahan helm tidak berarti untuk jenis kesalahan variabel ini?

Gagal satu:

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

Keberhasilan:

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

Ini juga berfungsi:

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

Saya memiliki masalah yang sama: '(dan saya tidak dapat menggunakan pembersihan karena saya akan kehilangan data dan saya tidak dapat melakukannya, saya tahu masalah ini telah ditutup tetapi hanya saya yang mengungkapkan rasa sakit saya.

Kita harus membuang pelepasan helm, ketika kita menyebarkan beban kerja kritis, bahkan istioctl of istio parit helm karena alasan ini (saya asumsikan). Kami menggunakan template helm .... |

@GloriaPG dapatkah Anda berbagi lebih banyak informasi? Bagaimana Anda mengalami masalah yang sama? Seperti yang disebutkan @yinzara sebelumnya di utas, Anda mungkin mengalami kasus yang tidak dapat diperbaiki # 7652. Namun, kami membutuhkan lebih banyak informasi untuk membantu sebelum kami dapat mencapai kesimpulan itu.

Hai @bongobbler

Kami menggunakan helm upgrade dengan tanda --install dan --force :

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

Sayangnya saat rilis dalam keadaan gagal:

$ 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

itu menghasilkan:

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

Bagaimana itu bisa diatasi? Tampaknya --force dengan --install tidak berfungsi

Karena ini adalah produksi env, saya tidak bisa hanya membersihkan rilis dan membuatnya dari awal :(

Terima kasih atas sarannya

Kesalahan Anda tampaknya terkait dengan https://github.com/kubernetes/client-go/issues/508
Anda tidak dapat mengubah pemilih di Deployment. Anda harus membatalkan penerapan dan menerapkan ulang.

@yinzara lucunya adalah bahwa saya tidak mengubah pemilih pada penerapan saya, semuanya bekerja pada rilis 9/10. Dalam satu saat penerapan sth bermasalah, rilis dalam keadaan gagal dan saya tidak dapat memulihkannya dengan cara apa pun - penerapan itu sendiri berfungsi, Pod sedang berjalan tetapi saya tidak lagi dapat memodifikasinya.

Agak berlawanan dengan intuisi bahwa setelah rilis dalam keadaan gagal saya tidak dapat mengubahnya lagi menggunakan helm. Saya berharap bahwa bendera --force akan memungkinkan saya untuk mengganti seluruh penerapan atau memaksa untuk menerapkan perubahan tetapi saya tidak dapat menemukan cara untuk memperbaiki rilis yang ada dan bekerja dengannya.

Ya sayangnya ini sepertinya bukan masalah helm. Ada yang gagal tentang rilis Anda dan statusnya buruk di kubernetes. Kemungkinan besar pemilih kacau atau sesuatu tidak seperti yang Anda harapkan, tetapi kesalahan yang Anda lihat tentang "nama-aplikasi" tidak memiliki rilis yang diterapkan hanyalah masalah besar.

Saya sudah mencoba mengembalikan ke versi sebelumnya, rilis sekarang dalam status deployed . Sayangnya itu tidak mengubah apa pun jadi saya pikir satu-satunya cara adalah dengan menghapus dan menerapkan lagi sayangnya.

Jadi, masalah khusus saya dengan ini mudah direproduksi.

Mulailah menerapkan sesuatu dengan helm3 (dengan --atomic dan --cleanup-on-fail ), dan ctrl + c proses setelah mulai membuat sumber daya. Tidak ada yang dibatalkan, sumber daya masih ada, dan setiap upaya berikutnya untuk menjalankan install --upgrade menghasilkan kesalahan "tidak memiliki rilis yang diterapkan".

Ctrl + c ini adalah sesuatu yang pada dasarnya terjadi ketika seseorang mendorong komit baru ke cabang di sistem CI kami sementara build sudah berjalan - peningkatan helm akan dibatalkan, dan kemudian dalam keadaan benar-benar rusak.

Adakah yang bisa kita lakukan untuk memperbaikinya setelah tahap ini? Seperti banyak orang lain di utas ini, penghapusan bukanlah pilihan.

EDIT: setelah ini rusak, helm ls tidak menampilkan rilis, helm history menampilkannya dalam status instal tertunda.

Sebenarnya - tidak apa-apa. Bagi mereka yang terkena dampak ini, ada satu solusi: hapus catatan riwayat dari kubernetes secara manual. Itu disimpan sebagai rahasia. Jika saya menghapus entri negara bagian pending-install melanggar, maka saya berhasil menjalankan upgrade --install lagi!

@AirbornePorcine - Bisakah Anda menjelaskan lebih lanjut tentang perubahan yang diperlukan dalam kubernetes untuk menghapus entri pending-install.

@ tarunnarang0201 Helm membuat rahasia kubernetes untuk setiap penerapan, di namespace yang sama yang Anda gunakan, Anda akan melihatnya berjenis 'helm.sh/release.v1', dan diberi nama seperti 'sh.helm.release.v1.release -name.v1 '. Anda hanya perlu menghapus rahasia terbaru (lihat akhiran 'v1' dalam contoh, itu bertambah untuk setiap penerapan), dan itu tampaknya membuka blokir bagi saya.

@AirbornePorcine terima kasih!

@AirbornePorcine @ tarunnarang0201 @ ninja- Anda juga dapat menambal label status ... terutama, jika Anda tidak memiliki rilis DEPLOYED sebelumnya.

Untuk Helm 3, lihat komentar saya di https://github.com/helm/helm/issues/5595#issuecomment -580449247

Untuk detail lebih lanjut dan instruksi untuk Helm 2, lihat komentar saya di https://github.com/helm/helm/issues/5595#issuecomment -575024277

Percakapan ini terlalu panjang ... dan setiap komentar punya satu solusi .... apa kesimpulannya?
Kami telah menggunakan helm lama 2.12 dan kami tidak pernah mengalami masalah tetapi sekarang dengan v3.2.4 penerapan yang sebelumnya gagal gagal dengan kesalahan ini.

Kami menggunakan Terraform dengan cara dan penyedia helm terbaru. Jadi sebaiknya kita menggunakan --force atau --replace

@xbmono Percakapannya panjang karena ada

• Ada cukup banyak alasan mengapa rilis Anda bisa mencapai kondisi ini
• hal ini juga dimungkinkan pada Helm 2, dan solusi yang berhasil di sana dan pada Helm 3 berbeda.
• ada jalur berbeda yang diambil pengguna dalam masalah ini untuk sampai ke sana
• ada pilihan yang berbeda tergantung pada apa yang Anda coba lakukan, dan apakah Anda bersedia mengambil risiko / menoleransi hilangnya PVC dan berbagai kemungkinan kombinasi waktu henti.

Jika Anda berada pada kesalahan "tidak memiliki rilis yang diterapkan", saya tidak yakin install --replace atau upgrade --install --force akan membantu Anda sendiri.

Saran yang masuk akal mungkin hanya bisa diberikan

• jika Anda memberikan helm history untuk rilis sehingga orang-orang dapat melihat apa yang telah terjadi
• jika Anda berbagi alasan asli kegagalan / apa yang Anda lakukan untuk mencapainya - dan apakah Anda merasa masalah awal telah diatasi

Ringkasan saya tentang opsi yang memungkinkan

• jika Anda sama sekali tidak peduli dengan sumber daya k8s yang ada atau waktu henti, helm uninstall && helm install dapat menjadi opsi
• jika pemasangan bagan pertama kali gagal, Anda mungkin dapat menghapus metadata rahasia rilis dan helm install lagi. Mungkin perlu membersihkan sumber daya k8s secara manual jika cruft tertinggal karena kegagalan, tergantung apakah Anda menggunakan --atomic dll.
• jika Anda mengabaikan instalasi --wait ed sebagian dan helm history menunjukkan rilis terakhir dalam pending-install Anda dapat menghapus metadata rahasia rilis terbaru atau menambal status rilis
• dalam kombinasi skenario tertentu lainnya, dimungkinkan juga untuk menambal status rilis dari satu atau lebih rahasia rilis dan melihat apakah upgrade dapat dilanjutkan, namun setahu saya, sebagian besar kasus ini telah ditangani oleh # 7653 (untuk memastikan ada rilis deployed di suatu tempat dalam sejarah untuk kembali ke) jadi saya akan terkejut jika ini berguna sekarang.

Karena ini adalah masalah tertutup, saya curiga ada akar masalah yang sebaiknya di-debug dan didokumentasikan dalam tiket yang berbeda dan lebih spesifik.

@chadlwilson Terima kasih atas tanggapan Anda.

helm history tidak mengembalikan baris!

Error: release: not found

tapi helm list mengembalikan penerapan yang gagal

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

Kami menggunakan Terraform dan lingkungan kami diterapkan setiap jam secara otomatis oleh Jenkins. Dengan terraform saya tidak bisa menggunakan helm upgrade , itulah yang dilakukan penyedia helm

Dalam kode terraform saya telah mengatur force_update menjadi true , tidak berhasil dan saya menetapkan replace menjadi true , sekali lagi tidak berhasil

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}"

}

Jadi saya bertanya-tanya apakah ini ada hubungannya dengan wait=true ? Jadi alasan penerapan sebelumnya gagal adalah bahwa cluster tidak dapat berkomunikasi dengan repositori buruh pelabuhan sehingga timeout tercapai dan statusnya adalah failed tetapi kami memperbaiki masalah dan pods berhasil dimulai ulang, sekarang jelas helm delete berfungsi tetapi jika saya melakukan ini setiap kali manajer saya atau pengembang akan senang.

Dengan helm v2 jika penerapan gagal dan pengembang memperbaikinya, penerapan berikutnya akan meningkatkan penerapan yang gagal.

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

Kegagalan helm history tampak aneh (salah ketik? Namespace terlewat? Versi helm salah?), Tetapi mengingat revisi 1 di list di atasnya, tampaknya Anda mencoba melakukan yang pertama waktu pemasangan bagan baru dan pemasangan pertama kali gagal. Jika Anda mencoba untuk membuka blokir, Anda mungkin dapat menghapus metadata rahasia rilis seperti di atas atau menambal statusnya, dan coba lagi. Itu mungkin menunjukkan bahwa metadata dalam keadaan buruk dari perspektif Helm atau Helm Terraform Provider, tapi tidak bagaimana itu sampai di sana.

Bagaimanapun, saya tidak memiliki masalah dalam melakukan upgrade selama penerapan pertama kali yang gagal dengan Helm 3.2.1 sejak # 7653 digabungkan. Anda mungkin ingin memeriksa ulang versi Helm tertentu yang sebenarnya digunakan penyedia? Mungkin juga karena cara penyedia Helm Terraform mengetahui status rilis setelah kegagalan install . Saya tidak memiliki pengalaman dengan penyedia itu, dan secara pribadi saya tidak ingin membungkus Helm dengan abstraksi deklaratif lain seperti TF karena saya merasa lebih buram ketika ada yang salah, tetapi Anda mungkin ingin menggali lebih jauh di sana semua sama .

Bagaimanapun, seperti yang saya katakan di atas, jika kesalahan Anda adalah has no deployed releases setelah penerapan pertama kali gagal, saya tidak berpikir replace atau force kemungkinan akan membantu Anda menghidupkan kembali situasi tanpa intervensi lain dan akan lebih baik untuk men-debugnya lebih jauh dan melakukan percakapan di tempat lain, karena bolak-balik pada tiket tertutup lama dengan 51 peserta tampaknya tidak begitu produktif untuk semua pihak.

Tidak ada kesalahan ketik. Selain itu, ini terjadi terlepas dari penerapan pertama atau nanti.

Seperti yang saya sebutkan, kami menggunakan opsi --wait untuk menunggu penerapan di Jenkins dan kemudian untuk memberi tahu apakah penerapan gagal atau tidak.

Tampaknya, jika batas waktu tercapai dan penerapan tidak berhasil, helm menandai penerapan sebagai failed dan tidak ada cara untuk memulihkan selain menghapus rilis tersebut secara manual. Dan kami juga tidak ingin menghapus rilis secara otomatis karena itu menakutkan.

Jadi jika kita menghapus opsi --wait , helm akan menandai penerapan sebagai successful .

Solusi:

Sekarang saya menemukan solusi lain. Bagi mereka yang memiliki masalah yang sama dan ingin otomatisasi mereka berfungsi dengan baik seperti sebelumnya, berikut adalah solusi saya:

• Hapus --wait opsi dari helm penyebaran
• Gunakan perintah ini untuk mengambil daftar penerapan untuk namespace yang Anda gunakan: kubectl get deployments -n ${namespace} -o jsonpath='{range .items[*].metadata}{.name}{","}{end}'
• Anda dapat menggunakan split untuk mengubah daftar yang dipisahkan koma di atas menjadi array
• Kemudian Anda dapat menjalankan beberapa perintah secara paralel (kami menggunakan Jenkins sehingga mudah untuk melakukannya) sebagai kubectl rollout status deployment ${deploymentName} --watch=true --timeout=${timeout} -n ${namespace}
• Jika setelah timeout , misalnya 7m berarti 7 menit, penerapan masih tidak berhasil, perintah keluar dengan kesalahan
• Masalah terpecahkan.

Sebenarnya - tidak apa-apa. Bagi mereka yang terkena dampak ini, ada satu solusi: hapus catatan riwayat dari kubernetes secara manual. Itu disimpan sebagai rahasia. Jika saya menghapus entri negara bagian pending-install melanggar, maka saya berhasil menjalankan upgrade --install lagi!

Atau, ini berhasil untuk saya:

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

diperbaiki oleh kubectl -n $namespace delete secret -lstatus=pending-upgrade
Jalankan sekarang helm lagi.

Saya tidak yakin mengapa ini ditutup, saya baru saja memukulnya dengan Helm 3.3.4 yang baru. Jika pemasangan awal gagal, peningkatan helm kedua --install --force masih menunjukkan kesalahan yang sama. Semua solusi tersebut berfungsi, tetapi bersifat manual , tidak membantu ketika Anda ingin sepenuhnya, CI / CD 100% otomatis di mana Anda dapat dengan mudah mendorong perbaikan untuk memicu penerapan lain tanpa melakukan pembersihan secara manual.

Adakah yang pernah berpikir untuk menambahkan tanda bahwa ini adalah rilis pertama jadi sebaiknya aman dengan menghapusnya secara otomatis? Atau menambahkan sesuatu seperti "--force-delete-on-failure"? Mengabaikan masalah tidak akan membantu.

@ nick4fake AFIK ditutup oleh PR # 7653. @yinzara mungkin dapat memberikan detail lebih lanjut.

Itu adalah keputusan pengelola untuk tidak mengizinkan penimpaan rilis menunggu peningkatan. Tetapi pernyataan Anda bahwa semua solusi adalah solusi yang tidak berfungsi dalam pipeline CI / CD tidak benar. Solusi terakhir yang disarankan dapat ditambahkan sebagai langkah pembuatan sebelum menjalankan pemutakhiran helm Anda (saya juga tidak akan menggunakan --force dalam pipieline CI / CD). Ini memiliki efek yang sama seperti yang Anda sarankan, kecuali bahwa rilis tersebut menghapus rilis tepat sebelum Anda menginstal rilis berikutnya, bukan segera setelahnya, sehingga Anda dapat men-debug penyebab kegagalan.

Saya juga telah menggunakan yang berikut ini di bentukan otomatis saya untuk mencopot pemasangan rilis yang "menunggu keputusan" sebelum saya menjalankan perintah peningkatan (pastikan untuk menyetel variabel lingkungan NS_NAME ke ruang nama yang Anda terapkan):
`` pesta

! / usr / bin / env bash

RELEASES = $ (daftar helm --namespace $ NS_NAME --pending --output json | jq -r '. [] | Pilih (.status == "pending-install") | .name')
jika [[! -z "$ RELEASES"]]; kemudian
helm delete --namespace $ NS_NAME $ RELEASES
fi

@yinzara terima kasih atas cuplikannya, sangat membantu bagi mereka yang menemukan utas ini.

Maksud saya masih valid - tidak aman hanya dengan menghapus rilis. Mengapa Helm tidak bisa melakukan peningkatan paksa jika satu sumber daya gagal? Mengganti rilis dengan versi baru tampaknya merupakan solusi yang lebih baik daripada penghapusan penuh. Saya mungkin tidak mengerti beberapa dasar inti dari Helm (seperti bagaimana mengatur keadaan) jadi mungkin tidak mungkin untuk dilakukan, tapi saya masih tidak mengerti mengapa lebih baik memaksa pengguna untuk campur tangan secara manual jika instalasi pertama gagal.

Maksud saya, periksa saja utas diskusi ini, orang-orang masih menghadapi masalah ini. Apa pendapat Anda tentang kemungkinan menambahkan beberapa informasi tambahan ke pesan kesalahan Helm dengan tautan ke utas ini + beberapa saran tentang apa yang harus dilakukan?

@ nick4fake Saya pikir Anda mencampurkan "gagal" dengan "pending-install".

Pengelola perpustakaan setuju dengan Anda tentang rilis yang gagal, itulah mengapa mereka menerima PR saya.

Rilis yang "gagal" DAPAT ditingkatkan. Itulah yang PR saya lakukan. Jika sebuah rilis gagal karena salah satu sumber daya gagal, Anda hanya dapat mengupgrade rilis itu (yaitu upgrade --install juga berfungsi) dan itu tidak akan memberi "app-name" tidak memiliki kesalahan rilis yang diterapkan.

Anda sedang berbicara tentang rilis "pending-install". Pengelola tidak menganggap aman untuk mengizinkan Anda memutakhirkan rilis pemasangan yang tertunda (dipaksa atau sebaliknya) karena mungkin masih dalam proses atau dalam keadaan sebagian lengkap yang mereka rasa tidak dapat diselesaikan secara otomatis. Humas saya awalnya mengizinkan negara bagian ini dan pengelola meminta saya untuk menghapusnya.

Jika Anda menemukan rilis Anda dalam keadaan ini, Anda mungkin ingin mempertimbangkan kembali konfigurasi penerapan Anda. Ini tidak boleh terjadi dalam pipeline CI / CD yang dikonfigurasi dengan benar. Itu harus gagal atau berhasil. "tertunda" menyiratkan penginstalan dibatalkan saat masih diproses.

Saya bukan pengelola jadi pendapat saya tentang saran Anda tidak relevan namun saya tidak menemukan penyebutan dalam basis kode untuk masalah Github yang sebenarnya dicetak dalam kesalahan atau pesan, jadi saya bertaruh mereka tidak akan mengizinkannya, tetapi Anda dipersilakan untuk membuat PR dan lihat :-)

Karena itu, saya tidak setuju dengan pernyataan Anda bahwa maksud Anda masih valid. Saran saya mungkin menghapus rilis tertunda, namun saran @abdennour tepat sebelum milik Anda hanya untuk menghapus rahasia yang menjelaskan rilis instal yang tertunda. Jika Anda melakukannya, Anda tidak menghapus sumber daya apa pun dari rilis dan dapat mengupgrade rilis tersebut.

Apa pendapat Anda tentang kemungkinan menambahkan beberapa informasi tambahan ke pesan kesalahan Helm dengan tautan ke utas ini + beberapa saran tentang apa yang harus dilakukan?

+1 untuk ini. Kita masih harus mencari di Google, untuk menemukan utas ini, untuk memahami apa itu rilis pending-install , jadi kita bisa mulai bernalar tentang pesan kesalahan ini.

Saya memiliki masalah dengan helm upgrade dan hal itu membawa saya ke sini. Itu diselesaikan dengan menambahkan -n <namespace> . Mungkin itu akan membantu seseorang di luar sana.

Untuk Helm3, Bisa diselesaikan melalui patch
kubectl -n <namespace> patch secret <release-name>.<version> --type=merge -p '{"metadata":{"labels":{"status":"deployed"}}}'

release-name dan version - Bisa dilihat dari kubectl get secrets -n <namespace> | grep helm