<p>peningkatan helm --instal tidak lagi berfungsi</p>

Saya pikir saya mengalami masalah yang sama, tetapi ternyata saya baru saja menghapus yang lama (tetapi tidak dibersihkan), rilis berkeliaran. periksa helm list -a , dan jika rilis Anda ada di sana, helm delete --purge releasename. helm upgrade -i berhasil bekerja pada 2.7.2 untuk saya.

Ini adalah efek samping dari memperbaiki masalah seputar pemutakhiran rilis yang berada dalam kondisi buruk. https://github.com/kubernetes/helm/pull/3097 adalah PR yang memperbaiki masalah ini. Apakah ada kasus tepi di sini yang gagal kami tangkap?

Periksa helm list -a seperti yang disebutkan @tcolgate , mungkin juga menjelaskan cara mereproduksinya juga akan membantu untuk menentukan apakah itu kasus tepi yang tidak tertangkap atau bug.

Juga memiliki masalah yang sama, bersama dengan nama rilis duplikat:

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

Saat Anda mengupgrade, pesan apa yang ditampilkan?

kesalahan yang sama seperti diff di atas, tetapi instalasi akan mengatakan itu sudah diinstal.

Maksud saya dalam upaya peningkatan sebelumnya yang berakhir dengan status GAGAL. Saya ingin tahu bagaimana kita masuk ke situasi di mana semua rilis dalam keadaan gagal.

Ohh, penerapan nama rilis duplikat? Itu saya tidak yakin, saya cukup sering mendapatkannya. Terkadang semuanya dalam keadaan DEPLOYED, terkadang campuran FAILED dan DEPLOYED. Kami menggunakan server CI/CD Jenkins yang terus memperbarui setiap penggabungan PR sehingga kami melakukan beberapa helm upgrade 'sehari, biasanya hanya memiliki tag penampung baru. Biasanya duplikat hanya mengganggu ketika melihat apa yang digunakan, ini adalah pertama kalinya kami memiliki masalah yang sulit dengan mereka, dan biasanya kami tidak memutakhirkan pengontrol ingress seperti yang kami lakukan dalam kasus ini.

Sepertinya saya berakhir dengan sesuatu yang serupa, saya melihat beberapa duplikat dalam daftar rilis saya:

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

Semuanya tampaknya dalam keadaan DEPLOYED, tetapi bisa jadi peningkatan sebelumnya gagal di beberapa titik, karena saya telah menemukan bug itu beberapa kali. Saya masih di K8S 1.7, jadi belum update ke helm 2.7.

Masalah yang sama, tidak dapat memutakhirkan melalui penerapan GAGAL

Sama di sini menggunakan 2.7.2. Upaya rilis pertama gagal. Kemudian ketika saya mencoba memutakhirkan --install saya mendapatkan kesalahan "Kesalahan: UPGRADE FAILED: "${RELEASE}" tidak memiliki rilis yang disebarkan".

Masalah yang sama di sini dengan 2.7.2, helm upgrade --install gagal dengan:

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

Jika rilis sepenuhnya dibersihkan dengan helm del --purge APPNAME maka upgrade --install berfungsi dengan baik.

Saya mengalami masalah yang sama. Dikombinasikan dengan #3134 yang tidak memberikan opsi untuk penerapan idempoten otomatis tanpa beberapa skrip untuk menyelesaikannya.

@winjer baru saja mencoba menghapus dengan --purge dan bagi saya itu tidak berhasil meskipun kesalahannya berubah
/ # peningkatan helm foo /charts/foo/ -i --wait
Kesalahan: UPGRADE GAGAL: "foo" tidak memiliki rilis yang disebarkan
/ # helm delete --purge foo
rilis "foo" dihapus
/ # peningkatan helm foo /charts/foo/ -i --wait
Rilis "foo" tidak ada. Menginstalnya sekarang.
Kesalahan: rilis foo gagal: deployments.extensions "foo-foo-some-service-name" sudah ada

@prein Ini karena Anda memiliki layanan yang bukan "pemilik" oleh helm, tetapi sudah ada di cluster. Perilaku yang Anda alami tampaknya benar bagi saya. Penyebaran tidak dapat berhasil karena helm harus "mengambil kepemilikan" dari objek API yang tidak dimilikinya sebelumnya.

Masuk akal untuk dapat memutakhirkan rilis GAGAL, ​​jika manifes baru benar-benar benar dan tidak puas dengan sumber daya lain di cluster.

Saya juga melihat perilaku ini pada rilis yang disebut content :

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

Saya harus menghapus ini untuk dapat terus menyebarkan, beri tahu saya jika ada yang bisa saya lakukan untuk membantu men-debug ini.
(Saya pikir kita harus mengganti nama masalah, karena ini lebih tentang duplikat?)
(kami juga menjalankan 2.7.2 )

Saya sebenarnya memiliki rilis duplikat lain di cluster saya, jika Anda memiliki perintah untuk saya jalankan untuk membantu men-debug itu? Biarkan aku tahu!

baru saja ditingkatkan ke tiller 2.7.2 dan kami melihat hal yang sama. helm delete RELEASE_NAME diikuti oleh helm upgrade RELEASE_NAME . gagal dengan Error: UPGRADE FAILED: "RELEASE_NAME" has no deployed releases . upgrade adalah cara yang dimaksudkan untuk memulihkan rilis yang dihapus (tetapi tidak dibersihkan), benar?

Sepertinya Anda dapat memulihkan rilis dengan memutar kembali ke versi yang dihapus.

melihat masalah yang sama dengan v2.7.2 , gagal ketika tidak ada rilis sebelumnya yang berhasil digunakan

Juga melihat dua versi potensial dari masalah ini:

di CI:

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

di mesin lokal saya:

( baik di bash OSX saya dan dalam wadah gcloud/kubectl )

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

Peringatan itu normal untuk bagan kami.
Error ini menarik karena salah satu subchart kita memiliki pvc.yaml di dalamnya.

helm del --purge <release> memang mengurangi masalah.
Hal ini membuat saluran CI kami sulit untuk ditingkatkan.

@adamreese apa resolusi akhir untuk masalah ini? Kami menggunakan 2.8 dan kami masih tidak dapat meningkatkan versi sebelumnya FAILED dengan perubahan ke helm list .

Secara khusus, kami mengalami jenis masalah berikut:

• menyebarkan rilis, OK
• upgrade --install --wait , tapi mungkin ada bug kecil dan --wait tidak berhasil (misalnya, pemeriksaan keaktifan tidak pernah berhasil)
• setelah memperbaiki grafik, upgrade --install --wait gagal dengan xxx has no deployed releases

Menghapus/membersihkan tidak diinginkan atau diterima di sini: rilis mungkin memiliki banyak sumber daya (pod, penyeimbang beban) yang tidak terpengaruh oleh satu sumber daya yang tidak akan naik. Di versi Helm sebelumnya, upgrade --install memungkinkan kami untuk hanya menambal perubahan yang merusak rilis penuh tanpa harus menghapus semua sumber daya.

Helm adalah pemilik semua sumber daya yang terlibat setiap saat di sini -- sumber daya hanya ditandai FAILED karena --wait tidak berhasil menunggu semua sumber daya dalam keadaan baik. Saya berasumsi hal yang sama akan terjadi jika pod agak terlalu lambat untuk memulai dan dalam banyak kasus serupa.

@peay lihat #3353 untuk diskusi lanjutan.

Terima kasih -- itu menyelesaikannya. Sebenarnya menyadari bahwa kami hanya memukulnya ketika kami tidak memiliki rilis yang berhasil untuk memulai. Dalam hal ini, pembersihan adalah solusi yang bagus.

Ini masih terjadi jika penginstalan gagal.
Anda perlu membersihkan dan mencoba lagi.

UPGRADE FAILED: "API" has no deployed releases
maka Anda perlu membersihkan secara manual
helm delete --purge API
dan itu akan berhasil.

Pada helm 2.9 Anda juga dapat melakukan helm upgrade --install --force sehingga tidak perlu dibersihkan. Untuk rilis sebelumnya:

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

@bacongobbler Saya masih bingung dengan perilaku ini.
Bisakah Anda menjawab https://github.com/kubernetes/helm/pull/3597#issuecomment -382843932 ketika Anda punya waktu?

Terima kasih atas pekerjaan Anda dalam hal ini.

Tentu. Saya AFK saat ini tetapi saya dapat menjawabnya nanti malam. Sepenuhnya memahami kebingungan dan saya akan mencoba menjawab pertanyaan Anda sebaik mungkin. Ini hanya gila di kantor menyiapkan hal-hal lain untuk KubeCon UE. :)

Saya terbuka untuk membantu meretas ini dan/atau meningkatkan dokumen saat kami berada di luar sana.
Mari kita pasti bertemu :+1:

@bacongobbler apakah alamat ini #3353 dan meniadakan banyak kode yang saya tulis sebagai bagian dari #4004?

Dalam kasus saya helm upgrade --install --force melakukan delete --purge dan setelah itu menginstal.

Apakah ini perilaku yang diharapkan? Saya hampir kehilangan 2 bulan pekerjaan karena ini. Kapan force mulai berarti delete ?

^ Saya melakukan beberapa percakapan dengan orang-orang di kubecon dan menemukan bahwa beberapa tim disematkan ke v2.7.0 karena perubahan perilaku ini.

Saya setuju bahwa upgrade install tidak boleh merusak, bahkan dengan arti --force apa pun.

@bacongobbler , maaf saya tidak dapat bertemu ketika kami keluar di CPH.
Apakah ada dokumentasi di balik alasan untuk mengubah perilaku agar tidak mengizinkan peningkatan versi rilis yang gagal?
Perilaku lama tampaknya jauh lebih diinginkan daripada apa yang kita miliki sekarang.

Lihat komentar kedua di https://github.com/kubernetes/helm/issues/3353 untuk konteks latar belakang tentang mengapa kami harus melakukan perubahan itu

Saya benar-benar penasaran untuk mendengar apa jalan yang diusulkan ke depan. Kami tidak dapat mundur #3097 karena masalah yang ditunjukkan pada #3353, jadi saya ingin mendengar pendapat komunitas tentang jalan yang benar ke depan untuk memperbaiki masalah ini. Kami dapat mundur #3597 tetapi dari apa yang saya dengar tidak ada solusi yang baik untuk memperbaiki masalah helm upgrade --install . :kecewa:

Saya tahu kami sedang mengerjakan kembali penerapan logika untuk Helm 3 tetapi itu masih jauh

Terima kasih telah menautkan itu @bacongobbler :)
Saran Anda di sini terdengar seperti pendekatan yang masuk akal:

mungkin bermanfaat untuk tidak melakukan diff ketika tidak ada rilis yang berhasil di-deploy. Pengalamannya akan sama seperti jika pengguna menjalankan instalasi helm untuk pertama kalinya dalam arti bahwa tidak akan ada rilis "saat ini" untuk dilawan. Saya akan sedikit khawatir tentang kasus Edge tertentu. @adamreese apakah Anda punya pendapat tentang yang satu ini?

Ini akan memungkinkan kami untuk mundur #3597 karena satu-satunya kasus kegagalan (tidak ada yang berbeda) akan ditangani.
Ini membuat upgrade --install non-destruktif lagi dan lebih mirip dengan kubectl apply .

Secara intuitif, itulah yang saya harapkan dari upgrade --force untuk dilakukan: jangan lakukan operasi diff-and-patch tetapi cukup terapkan templat yang lengkap, abaikan apa yang ada saat ini. Saya benar-benar tidak dapat memikirkan alasan teknis mengapa ini tidak mungkin, tetapi saya juga tidak terbiasa dengan cara kerja Helm.
Ini masih bisa menjadi operasi yang berbahaya tetapi siapa pun yang menggunakan flag --force biasanya mengharapkan risiko tertentu dengan memaksa pembaruan. Meskipun saya berpendapat orang tidak mengharapkan ini untuk menghapus dan membuat ulang penerapan Anda, dengan potensi waktu henti.

Saya telah membaca diskusi, tetapi saya masih tidak jelas tentang bagaimana memiliki perintah idempoten upgrade --install (atau urutan perintah).

Dengan versi stabil saat ini, bagaimana saya bisa mencapai ini dalam skrip otomatis? Saya harus dapat menerapkan non-interaktif tanpa menggunakan delete --purge , bahkan jika upaya sebelumnya gagal.

Adapun rencana masa depan, ini adalah perilaku yang awalnya saya harapkan dari upgrade --install :

• Instal jika tidak ada instalasi sebelumnya yang dibuat
• Tingkatkan instalasi yang sebelumnya berhasil
• Ganti instalasi yang sebelumnya gagal
• Jika penginstalan gagal, sumber daya lama harus tetap ada, tanpa waktu henti jika memungkinkan
• Tidak ada operasi destruktif (seperti delete --purge disebutkan di atas)

Menurut pendapat pribadi saya, tidak ada tanda tambahan yang diperlukan untuk perilaku ini. Ini adalah bagaimana manajer paket umumnya berperilaku. Kecuali saya salah memahami persyaratannya, saya rasa flag --force , misalnya, tidak diperlukan.

Apakah ada pembaruan terkait hal ini? Apa cara yang tepat untuk menjalankan pemutakhiran secara andal pada instalasi yang ada tanpa harus menjalankan pembersihan jika ada yang gagal?

@MythicManiac FWIW:
Saya masih menyematkan tim kami di v2.7.0 karena perilaku ini.
Kami tampaknya tidak memiliki masalah dengan peningkatan dan penghapusan sumber daya ketika mereka seharusnya menggunakan helm upgrade --install dengan versi ini.

Kami juga memiliki masalah ini. Sangat menjengkelkan bahwa saya harus menghapus layanan K8 dan AWS ELB terkait karena helm has no deployed releases . Manajer paket hebat tetapi masalah ini menyebabkan waktu henti produksi yang tidak baik.

Sebagai solusi yang sangat rumit, jika masalah dengan penyebaran asal adalah
dapat diselesaikan (misalnya layanan yang sudah ada sebelumnya.), Melakukan rollback ke aslinya
rilis gagal dapat bekerja.

Pada Jumat, 5 Oktober 2018, 18:13 Eugene Glotov, [email protected] menulis:

Kami juga memiliki masalah ini. Sangat menjengkelkan bahwa saya harus menghapus K8s
layanan dan AWS ELB terkait karena helm tidak memiliki rilis yang diterapkan. Itu
manajer paket hebat tetapi masalah ini menyebabkan waktu henti produksi yang
tidak baik.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/helm/helm/issues/3208#issuecomment-427436187 , atau bisukan
benang
https://github.com/notifications/unsubscribe-auth/AAEo8_pISzHFAuOz6Lsv5EjrFaEo_HkYks5uh5M7gaJpZM4Qtexz
.

@tcolgate , terima kasih! Saya baru saja memperbaiki masalah lain (https://github.com/helm/helm/issues/2426#issuecomment-427388715) dengan solusi Anda dan akan mencoba mengujinya untuk ELB yang ada saat saya menerapkan bagan baru minggu depan di atas sumber daya yang ada .

Melakukan rollback ke rilis asli yang gagal dapat berhasil.

@tcolgate , saya baru saja menguji dan tidak, itu tidak berfungsi dalam kasus penyebaran pertama.

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

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

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

Saya ingin tahu, jika Helm tidak dapat menerapkan bagan di atas sumber daya yang ada, jadi mengapa helm delete menyebabkan penghapusan sumber daya ini?

@thomastaylor312 , kami menghadapi masalah ini ~ serta https://github.com/helm/helm/issues/2426~ (naik: Saya menemukan akar penyebab sebenarnya dari 2426) dengan helm 2.11.0. Apakah menurut Anda mereka harus dibuka kembali?

Saya menemukan utas ini setelah Error: UPGRADE FAILED: "xxx-service" has no deployed releases
Sementara itu terlihat dari helm ls -a.

Saya memutuskan untuk melihat apakah itu masalah karena nilai --set yang salah, dan --debug --dry-run --force sebenarnya MASIH menghapus pod saya yang sedang berjalan ... harapan saya adalah bahwa tindakan dry run TIDAK AKAN PERNAH berubah sumber daya klaster.

Itu berhasil, dan layanan dapat digunakan kembali setelah itu, tetapi kami mengalami waktu henti.

harapan saya adalah bahwa tindakan dry run tidak akan pernah mengubah sumber daya cluster.

Ini adalah harapan yang adil -- kita harus mewujudkannya... tidak terjadi

Saya percaya itu ditambal di https://github.com/helm/helm/pull/4402 tapi alangkah baiknya jika seseorang memeriksanya. Maaf tentang itu!

masalah yang sama setelah memutakhirkan ke 2.11.0

lintas pos:
https://github.com/reactiveops/reckoner/issues/48#issuecomment -453411283

Mengapa ini ditutup? Apakah kita memiliki cara yang tepat untuk menangani ini sekarang?

@gerbsen , tidak ada cara untuk mengatasi ini dengan versi Helm saat ini yang tidak merusak.
Kami masih menggunakan Helm 2.7.0 untuk semua yang ada di organisasi saya. Ini adalah versi yang sangat lama yang memiliki bug lain, tetapi tidak memiliki masalah ini.

Baru saja helm upgrade --install --force melakukan delete --purge dan menghancurkan pvc/pv saya tanpa memberi tahu saya (tentang daur ulang). Memiliki beberapa rilis yang gagal, jadi dalam keadaan berjalan di kubernetes, tetapi helm mengira tidak ada rilis yang berjalan. Bukan waktu yang baik sama sekali.

@notque setelah kehilangan semua dasbor grafana dua kali Saya sudah mulai melakukan pencadangan sebelum melakukan peningkatan apa pun, memiliki risiko semacam ini menghilangkan semua manfaat menggunakan helm

Bagi mereka yang mencari bantuan, masalahnya hilang bagi saya setelah memutakhirkan helm ke v.2.15.2

Masih melihat masalah ini di 2.16.0

Kenapa masih ditutup? 2.16.1 masih terpengaruh

@nick4fake Saya pikir ini duplikat dari https://github.com/helm/helm/issues/5595