Helm: `helm upgrade --install` tidak melakukan install / upgrade jika instalasi pertama gagal

Ini disengaja oleh desain https://github.com/kubernetes/helm/pull/3097. Pada dasarnya, membeda-bedakan penerapan yang gagal menyebabkan perilaku yang tidak diinginkan, terutama daftar panjang bug berikut:

• https://github.com/kubernetes/helm/issues/2257
• https://github.com/kubernetes/helm/issues/2341
• https://github.com/kubernetes/helm/issues/2346
• https://github.com/kubernetes/helm/issues/2437
• https://github.com/kubernetes/helm/issues/3068

Jika rilis awal Anda berakhir dengan status gagal, sebaiknya hapus rilis tersebut melalui helm delete --purge foo dan coba lagi. Setelah rilis awal berhasil, rilis gagal berikutnya akan diabaikan, dan helm akan melakukan perbedaan terhadap rilis sukses terakhir yang diketahui.

Karena itu, mungkin ada baiknya untuk tidak melakukan diff ketika tidak ada rilis yang berhasil diterapkan. Pengalamannya akan sama seperti jika pengguna menjalankan helm install untuk pertama kalinya dalam arti bahwa tidak akan ada rilis "saat ini" untuk dibedakan. Saya akan sedikit khawatir tentang kasus tepi tertentu. @ adamreese apakah Anda punya pendapat tentang yang satu ini?

Perbaikan yang disarankan tampaknya sama sekali tidak dapat dipertahankan dalam sistem otomatis. Saya benar-benar tidak ingin semua yang memanggil helm harus tahu tentang "jika rilis pertama gagal, hapus dan coba lagi". Untuk satu, sebagian besar perkakas saya tidak menyadari apakah itu pemasangan atau peningkatan, atau jika ini pertama kalinya atau ke-100 kalinya, hampir selalu berjalan helm upgrade --install .

Saya juga ingin menyampaikan bahwa saya mengomentari PR asli https://github.com/kubernetes/helm/pull/3097#discussion_r151808599 menanyakan secara khusus tentang kasus ini.

Perilaku lama lebih baik untuk kasus ini.
Saya setuju dengan @chancez. Ini membuat upgrade --install non-idempoten untuk kejadian umum.

@bayu_joo
Jika kita khawatir tentang rilis yang gagal dan meninggalkan pecahan peluru karena kait yang gagal, saya akan mengatakan itu masalah desain bagan. (Hook bekerja lebih baik saat idempoten)
Pengguna bebas untuk membangun penanganan kesalahan dan perilaku non-idempoten di sekitar kemudi.

Kasus tepi lain apa yang kita khawatirkan?
Sepertinya # 3097 banyak menangani 👍

Pengembangan lokal saya akan berjalan lebih lancar jika saya dapat membuat helm upgrade -i menjadi idempoten bahkan terhadap rilis Gagal untuk setidaknya beberapa kombinasi argumen. Kasus penggunaan saya adalah ketika saya memiliki skrip dari banyak rilis yang saya tahu saya ingin bangun untuk memulai env pengembangan lokal.

Ini mungkin analog dengan bendera --replace untuk helm install . Perhatikan bahwa --replace adalah salah satu dari hanya dua tanda dari helm install yang hilang di helm upgrade , yang lainnya adalah --name-template .

Untuk menjadi sangat jelas, ya ini akan menjadi hal yang baik untuk diperbaiki. Adakah yang ingin mengambil celah saat kita sibuk dengan pekerjaan lain?

Hai,
Saya telah membuat PR https://github.com/kubernetes/helm/pull/3437 yang akan memperbaiki masalah ini

Saya tidak yakin mengapa kita membutuhkan perintah install dan upgrade , saya hanya pernah menggunakan perintah upgrade --install dan sepertinya banyak orang melakukan hal yang sama. Saya hanya perlu satu perintah yang menghasilkan upgrade --install dan tidak tersandung karena gagal dijalankan. Bisakah kita mengganti nama upgrade --install menjadi deploy , membuatnya benar-benar idempoten, dan membuang dua lainnya?

(Saya berjuang dengan varian baru masalah perilaku ini di 2.8.0. Sejak memutakhirkan dari 2.7.2 sekarang jika saya memiliki instalasi yang gagal, dan kemudian delete --purge itu, dan upgrade --install itu , Saya masih bisa mendapatkan kesalahan Error: UPGRADE FAILED: "xyz" has no deployed releases . Sepertinya --purge tidak efektif penuh di 2.8.0 dan anakan mengalami beberapa status macet tidak muncul di list --all . Saya harus lalu ke install untuk mendapatkan anakan kembali ke keadaan di mana saya dapat melakukan upgrade --install lagi.)

Saya setuju dengan @whereisaaron , saya akan senang dengan perintah deploy yang bekerja lebih seperti kubectl apply . Membuat otomatisasi Helm jauh lebih mudah juga, karena Anda tidak perlu memeriksa rilis yang ada di beberapa skrip shell :)

Mungkin solusinya adalah memiliki helm otomatis menjalankan helm delete --purge ?
Sesuatu seperti:
1) Pengguna mengeksekusi helm upgrade --install
2) Rilis pertama gagal
3) Pengguna membuat beberapa perubahan pada grafik dan menjalankan lagi helm upgrade --install
4) Helm mencoba menjalankan perintah
5) Gagal dan hanya ada satu rilis sebelumnya dalam keadaan gagal
6) Helm secara diam-diam mengeksekusi helm delete --purge
6) Setelah pembersihan, Helm mencoba ulang secara otomatis helm upgrade --install dan menampilkan keluaran dari sana

Mungkin perilaku ini dapat dipicu melalui tanda --force yang sudah memiliki perilaku serupa untuk skenario lain

Ide bagus, tapi saya tidak berpikir kita harus pernah menghapus rilis buku tanpa pengguna secara eksplisit meminta untuk menghapus data. Operator Helm ingin mempelajari mengapa layanan gagal memutakhirkan dari rilis yang gagal sebelumnya, atau menyimpulkan kegagalan dengan mengumpulkan data tersebut dari buku besar.

Saya memberikan komentar sebelumnya di utas yang menjelaskan solusi untuk masalah ini. Ini mirip dengan solusi Anda dalam eksekusi, tetapi tanpa perlu menghapus seluruh buku besar rilis. Saya yakin # 3437 mencoba menerapkan solusi itu sebagai tambalan.

@rchernobelskiy terjadi pada saya juga. Persis seperti yang Anda gambarkan.

Saya mengalami masalah ini mungkin sekali sehari saat menerapkan aplikasi baru.
Sakit sekali!

@gmanolache Kami masih memimpin 2.7.0 karena alasan ini.
Tidak jelas bagi saya apakah memutakhirkan untuk menggunakan bendera --force aman: komentar

Jika Anda perlu menurunkan versi, berikut cara yang baik untuk melakukannya: turunkan versi ke 2.7.0

Apa info diagnostik 'helm ledger' yang terdengar berguna ini dan bagaimana kita mendapatkannya? :tersenyum:

Saya khawatir di bawah ini mungkin dibaca sebagai murung, itu benar-benar hanya undangan untuk petunjuk tentang bagaimana kami bisa mendapatkan info diagnostik ketika Anda memiliki penerapan yang gagal. Karena sepertinya aku melewatkan sesuatu. Kedengarannya negara gagal seharusnya memiliki beberapa utilitas untuk operator? Saya menelusuri situs manual kemudi lagi; akankah sesuatu seperti 'helm mendapatkan manifest' bekerja dalam keadaan gagal untuk mengekstrak info diagnostik yang berguna?

Pengalaman pengguna saya ketika saya mendapatkan penerapan yang gagal adalah Anda tidak mendapatkan info yang berguna. Helm menolak semua sumber daya yang dibuat / tersisa sebagian sehingga 'status helm' tidak menunjukkan apa-apa. Yang bisa Anda lakukan hanyalah 'rollback' atau 'delete --purge' (Anda tidak bisa hanya 'menghapus' atau 'upgrade --install' CI Anda akan terus gagal). Keadaan gagal tampaknya hanya berfungsi untuk mematahkan idempotensi 'upgrade --install' yang kita semua dambakan untuk penerapan CI kita.

Apakah masuk akal untuk memiliki opsi '--auto-rollback' untuk situasi CI, misalnya 'upgrade --install --auto-rollback'. Saya biasanya lebih suka memutar balik yang harus bangun dari tempat tidur untuk menangani keadaan gagal 😆 😴 💤

Apa info diagnostik 'helm ledger' yang terdengar berguna ini dan bagaimana kita mendapatkannya? 😄

helm help history

Terima kasih @bacongobbler. Oke, saya mengerti bahwa daftar itu yang dimaksud dengan buku besar. Dan jika Anda masih memiliki buku besar, Anda dapat menggunakan helm get manifest --revision 123 untuk melihat apa yang gagal diterapkan? Yang pasti bermanfaat untuk melestarikan. Dan jika kita rollback kita tidak kehilangan informasi itu.

History prints historical revisions for a given release.

A default maximum of 256 revisions will be returned. Setting '--max'
configures the maximum length of the revision list returned.

The historical release set is printed as a formatted table, e.g:

    $ helm history angry-bird --max=4
    REVISION   UPDATED                      STATUS           CHART        DESCRIPTION
    1           Mon Oct 3 10:15:13 2016     SUPERSEDED      alpine-0.1.0  Initial install
    2           Mon Oct 3 10:15:13 2016     SUPERSEDED      alpine-0.1.0  Upgraded successfully
    3           Mon Oct 3 10:15:13 2016     SUPERSEDED      alpine-0.1.0  Rolled back to 2
    4           Mon Oct 3 10:15:13 2016     DEPLOYED        alpine-0.1.0  Upgraded successfully

Jika kita memiliki helm upgrade --install --auto-rollback maka kedua penerapan yang gagal, rollback akan dicatat dalam buku besar dan tersedia untuk operator. Dan itu akan sangat membantu untuk mencegah penerapan CI mencapai keadaan 'gagal' yang sulit di mana 'peningkatan helm - instal' berhenti berfungsi. Penerapan CI yang gagal biasanya adalah pengembang yang memasukkan kesalahan ketik / kesalahan ke dalam sistem penerapan. Dengan '--auto-rollback' Mereka dapat memeriksa pesan kesalahan perintah helm disimpan di log server penerapan, memperbaiki dan menerapkan nilai yang dikoreksi.

Saya rasa bahkan tanpa opsi '--auto-rollback' kita dapat menggunakan pembungkus otomatis untuk menjalankan helm rollback kapan saja helm update --install mengembalikan kesalahan 'GAGAL'. Dan mungkin mendeteksi di mana itu pemasangan awal, dan helm delete --purge sebagai gantinya dalam kasus tersebut.

Artinya, kita dapat membuat skrip pembungkus untuk memastikan hasil dari 'pemutakhiran helm - instal' CI selalu dalam keadaan di mana 'pemutakhiran helm - instal' CI berikutnya akan selalu memungkinkan. Sambil menyimpan informasi buku besar untuk setiap upaya yang gagal (setidaknya untuk rilis yang penginstalan awalnya berfungsi).

helm deploy =

• helm upgrade --install
• jika GAGAL maka
  
  
  
  • jika revisi = 1
  
  
  • lalu helm delete --purge
  
  
  • lain helm rollback
  
  

@whereisaaron itu pasti elegan 👍

Adakah cara mudah untuk mendapatkan rilis terbaru yang berfungsi selain dari sesuatu seperti helm history ${name} | tail -2 | head -1 | awk '{print $1}' , untuk digunakan oleh helm rollback ?

Halo,

Saya menggunakan Helm 2.12.2 dan masih mengalami masalah, helm itu gagal, saat penerapan pertama gagal. Apakah ini mungkin regresi?

Saya tidak yakin ini regresi, tetapi tidak pernah benar-benar "diperbaiki".

@ RickS-C137 Saya pikir ini seharusnya diperbaiki dengan menggunakan helm upgrade --install --force yang akan 'menghapus' kemudian 'menginstal - ganti' rilis yang gagal.

Masih mencoba untuk memperbaiki masalah ini di Jenkins Pipeline yang saya coba gunakan.
Saya mencoba untuk menerapkan gambar baru dari aplikasi saya dan saya tidak peduli apakah penerapan sudah ada atau tidak.
Saya ingin menjalankan satu perintah yang menggantikan penerapan saat ini atau hanya menginstalnya jika tidak ada.
Saya mencoba helm install --replace Saya sering mendapatkan Error: a released named xyz is in use, cannot re-use a name that is still in use Yang jelas mematikan pipeline saya dan build gagal.

@bacongobbler Apa pendapat Anda tentang https://github.com/helm/helm/issues/3353#issuecomment -385222233?

Saya tidak melihat bagaimana akan ada waktu henti atau kehilangan data jika kita menghancurkan dan membuat ulang rilis awal jika rilis awal gagal.

Saya menerapkan ini di build kami:

if helm history --max 1 "$name" 2>/dev/null | grep FAILED | cut -f1 | grep -q 1; then
    helm delete --purge "$name"
fi

helm upgrade --install --wait "$release" chart/

Dengan helm saat ini, Anda tidak tahu kombinasi perintah + opsi helm mana yang akan digunakan tanpa memeriksa keadaan saat ini. Dan untuk komando helm yang diberikan Anda tidak tahu apa yang akan Anda dapatkan, karena itu tergantung pada bagaimana keadaan saat ini. Itu bukanlah mimpi keadaan yang diinginkan secara deklaratif ☁️ 💤 😄

Di helm 3 kita berpotensi dapat menghentikan install / upgrade / --replace / --upgrade / --force dan mengganti semuanya dengan idempoten helm deploy yang mencapai status yang diinginkan, atau membiarkan status tidak berubah. Mungkin menggunakan algoritma yang mirip dengan di atas , yang jika helm deploy gagal, memutar mundur (revisi> 1) atau menghapus + pembersihan (revisi = 1), untuk membiarkan keadaan seperti sebelumnya. Manifes yang gagal akan tetap tersedia melalui helm history/get . Dan bahkan mungkin ada opsi '--tidak ada rollback' untuk orang yang ingin mempertahankan penerapan dalam keadaan gagal untuk diselidiki

Opsi helm upgrade --install --force semakin dekat, kecuali bahwa alih-alih memutar kembali dan memutakhirkan, ia menghapus dan mengganti rilis yang gagal (bahkan untuk revisi> 1), yang membuat beberapa orang marah pada # 3208 ... 😮 ⚡️ 💥

Untuk saat ini kita dapat menggunakan skrip pembungkus atau alat meta seperti helmsman yang daftar fiturnya sebagian menggunakan helm tetapi mengurangi masalah ini:

• Idempotensi : Selama file status yang Anda inginkan tidak berubah, Anda dapat mengeksekusi
• Lanjutkan dari kegagalan : Dalam kasus penerapan parsial karena kegagalan penerapan bagan tertentu, perbaiki bagan kemudi Anda dan jalankan juru mudi lagi tanpa perlu memutar ulang keberhasilan parsial terlebih dahulu.

ganti semuanya dengan penyebaran helm idempoten yang mencapai keadaan yang diinginkan, atau membiarkan keadaan tidak berubah

Dalam retrospeksi, ini adalah tujuan desain yang sangat jelas.

Hai,
Dalam kasus kami, rilis awal tidak benar-benar gagal ... Hanya saja aplikasi kami tidak sepenuhnya aktif saat waktu tunggu penginstalan berlalu atau beberapa masalah aneh lainnya telah diperbaiki. Bagaimanapun, aplikasi berjalan dengan baik, dan dengan demikian harus menghapusnya akan menjadi masalah bagi kami (kami memiliki beberapa penyimpanan persisten yang terpasang yang juga akan dihapus !!).

Apakah ada solusi untuk menerapkan bagan ketika rilis awal 'tampaknya gagal' tetapi sebenarnya tidak apa-apa?

Jadi apakah kesimpulan bahwa upgrade --force terlalu memaksa, yaitu ada kalanya delete + replace + retry_upgrade tidak benar untuk memperbaiki kegagalan upgrade?

Apakah ada masalah terpisah dalam melacak gagasan menggabungkan install & upgrade menjadi perintah deploy ?

Setahu saya tidak tentang @dcow. Apa kasus penggunaan atas perintah helm upgrade --install ?

https://github.com/helm/helm/issues/3353#issuecomment -362497951

Saya tidak yakin mengapa kita membutuhkan perintah install dan upgrade, saya hanya pernah menggunakan perintah upgrade --install dan sepertinya banyak orang melakukan hal yang sama. Saya hanya perlu satu perintah yang dapat memutakhirkan - instal dan tidak tersandung karena gagal dijalankan. Bisakah kita mengganti nama peningkatan - instal untuk menyebarkan, membuatnya benar-benar idempoten, dan membuang dua lainnya?
...

dan

https://github.com/helm/helm/issues/3353#issuecomment -469109854

Dengan helm saat ini, Anda tidak tahu kombinasi perintah + opsi helm mana yang akan digunakan tanpa memeriksa keadaan saat ini. Dan untuk komando helm yang diberikan Anda tidak tahu apa yang akan Anda dapatkan, karena itu tergantung pada bagaimana keadaan saat ini. Itu tidak benar-benar senyum zzz awan mimpi keadaan deklaratif yang diinginkan

Di helm 3 kami berpotensi menghentikan install / upgrade / --replace / --upgrade / --force dan mengganti semuanya dengan penerapan helm idempoten yang mencapai status yang diinginkan, atau membiarkan status tidak berubah.
...

Saya umumnya setuju bahwa helm harus bekerja seperti kubectl apply dan berusaha mencapai kenyataan yang diinginkan daripada perlu menjalankan berbagai jenis perintah tergantung pada status cluster Anda. Berharap untuk menambahkan dukungan ke masalah khusus jika ada atau setidaknya mencari tahu apa resolusinya karena deploy saat ini tidak diterapkan dan kami sedang memimpin 3.2.

@dcow Ok, apakah Anda ingin membuat masalah dengan proposal Anda?

@hickeyma selesai https://github.com/helm/helm/issues/8415!