Menghapus sepenuhnya rilis dari Helm melalui helm delete release berfungsi, tetapi ini bukan solusi yang layak.

Mengapa Helm tidak dapat menimpa apa pun yang sedang dipasang? Bukankah kita hidup di dunia deklaratif dengan Kubernetes?

Baru saja mendapat hal yang sama ... cukup baru bagi saya karena sepertinya ini adalah masalah baru. menghapus sumber daya akan memperbaikinya.
v2.7.2 dengan Kubernetes 1.7.7.
cantik itu berhasil sebelumnya ...

Saya punya masalah ini - itu karena PersistentVolume yang saya buat. Untuk mengatasinya, saya menghapus PV dan PVC. Menjalankan helm upgrade XXX XXX dan berfungsi dengan baik. Mungkin masih ada sesuatu yang harus diselidiki karena PV-nya memang ada.

Saya merasa ini mungkin terkait dengan pv buruk ... tetapi kesalahannya cukup menyesatkan!
juga beberapa log aneh dari anakan ... tampaknya berfungsi pada 2 versi pada saat yang sama ...

baru saja mencoba dengan 2.7.1 namun tidak berhasil ...

[utama] 2017/12/21 15:30:48 Memulai Tiller v2.7.1 (tls = false)
[main] 2017/12/21 15:30:48 GRPC mendengarkan di: 44134
[utama] 2017/12/21 15:30:48 Probe mendengarkan pada: 44135
[utama] 2017/12/21 15:30:48 Driver penyimpanan adalah ConfigMap
[main] 2017/12/21 15:30:48 Histori maksimal per rilis adalah 0
[tiller] 21/12 2017 15:30:55 menyiapkan pembaruan untuk xxx
[penyimpanan] 21/12 2017 15:30:55 mendapatkan rilis yang diterapkan dari riwayat "xxx"
[tiller] 2017/12/21 15:30:56 menyalin nilai dari xxx (v65) ke rilis baru.
[penyimpanan] 21/12 2017 15:30:56 mendapatkan revisi terakhir dari "xxx"
[penyimpanan] 21/12 2017 15:30:56 mendapatkan riwayat rilis untuk "xxx"
[tiller] 21/12 2017 15:30:59 membuat bagan helm-xxx menggunakan nilai
2017/12/21 15:30:59 info: manifest "helm-xxx / templates / scheduler-deploy.yaml" kosong. Melewati.
2017/12/21 15:30:59 info: manifest "helm-xxx / templates / recomposer-deploy.yaml" kosong. Melewati.
2017/12/21 15:31:00 info: manifest "helm-xxx / templates / recomposer-pvc.yaml" kosong. Melewati.
2017/12/21 15:31:00 info: manifest "helm-xxx / templates / scheduler-pvc.yaml" kosong. Melewati.
2017/12/21 15:31:00 info: manifest "helm-xxx / templates / scheduler-secret.yaml" kosong. Melewati.
2017/12/21 15:31:00 info: manifest "helm-xxx / templates / recomposer-secret.yaml" kosong. Melewati.
[tiller] 2017/12/21 15:31:09 membuat rilis terbaru untuk xxx
[penyimpanan] 2017/12/21 15:31:09 membuat rilis "xxx.v80"
[tiller] 2017/12/21 15:31:09 melakukan pembaruan untuk xxx
[tiller] 2017/12/21 15:31:09 mengeksekusi 0 kait pra-peningkatan untuk xxx
[tiller] 2017/12/21 15:31:09 pengait selesai untuk pra-peningkatan xxx
[tiller] 21/12 2017 15:31:11 menyiapkan pembaruan untuk xxx
[penyimpanan] 21/12/17 15:31:11 mulai menerapkan rilis dari riwayat "xxx"
[penyimpanan] 21/12 2017 15:31:11 mendapatkan revisi terakhir dari "xxx"
[penyimpanan] 21/12/17 15:31:11 mendapatkan riwayat rilis untuk "xxx"
[anakan] 2017/12/21 15:31:18 membuat bagan helm-xxx menggunakan nilai
2017/12/21 15:31:18 info: manifest "helm-xxx / templates / scheduler-secret.yaml" kosong. Melewati.
2017/12/21 15:31:18 info: manifest "helm-xxx / templates / scheduler-pvc.yaml" kosong. Melewati.
2017/12/21 15:31:19 info: manifest "helm-xxx / templates / scheduler-deploy.yaml" kosong. Melewati.
[kube] 2017/12/21 15:31:28 membangun resource dari manifes yang diperbarui
[tiller] 2017/12/21 15:31:46 membuat rilis terbaru untuk xxx
[penyimpanan] 2017/12/21 15:31:46 membuat rilis "xxx.v81"
[tiller] 2017/12/21 15:31:47 melakukan pembaruan untuk xxx
[tiller] 2017/12/21 15:31:47 menjalankan 0 kait pra-peningkatan untuk xxx
[tiller] 2017/12/21 15:31:47 pengait selesai untuk pra-peningkatan xxx
[kube] 2017/12/21 15:31:49 memeriksa 7 resource untuk perubahan
[kube] 2017/12/21 15:31:49 Sepertinya tidak ada perubahan untuk Rahasia "xxx-helm-xxx-nginx-secret"
[kube] 2017/12/21 15:31:50 Sepertinya tidak ada perubahan untuk Rahasia "xxx-application-secret"
[kube] 2017/12/21 15:31:50 Sepertinya tidak ada perubahan untuk Rahasia "biru-rahasia"
[kube] 2017/12/21 15:31:51 Sepertinya tidak ada perubahan untuk ConfigMap "xxx-helm-xxx-nginx-config"
[kube] 2017/12/21 15:31:51 Sepertinya tidak ada perubahan untuk ConfigMap "xxx-application-config"
[kube] 2017/12/21 15:31:51 Sepertinya tidak ada perubahan untuk Layanan "xxx-application-svc"
[kube] 2017/12/21 15:31:51 Sepertinya tidak ada perubahan untuk StatefulSet "xxx-application"
[tiller] 2017/12/21 15:31:51 mengeksekusi 0 kait pasca-peningkatan untuk xxx
[tiller] 2017/12/21 15:31:51 pengait selesai untuk pasca-peningkatan xxx
[penyimpanan] 21/12/21 15:31:51 memperbarui rilis "xxx.v65"
[tiller] 21/12 2017 15:31:51 memperbarui status untuk rilis terbaru untuk xxx
[penyimpanan] 21/12/17 15:31:51 memperbarui rilis "xxx.v80"
[kube] 2017/12/21 15:31:57 membuat resource dari manifes yang diperbarui
[kube] 2017/12/21 15:32:10 memeriksa 11 sumber daya untuk perubahan
[kube] 2017/12/21 15:32:10 Sepertinya tidak ada perubahan untuk Rahasia "xxx-helm-xxx-nginx-secret"
[tiller] 2017/12/21 15:32:10 peringatan: Upgrade "xxx" gagal: tidak ada resource dengan nama "xxx-recomposer-secret" yang ditemukan
[penyimpanan] 21/12/17 15:32:10 memperbarui rilis "xxx.v65"
[penyimpanan] 21/12/17 15:32:10 memperbarui rilis "xxx.v81"

sepertinya bingung melakukan rilis pada saat yang sama ...

baru saja menerapkan ulang konfigurasi yang sama dua kali ...

[tiller] 21/12 2017 15:50:46 menyiapkan pembaruan untuk xxx
[penyimpanan] 21/12/17 15:50:46 mendapatkan rilis yang diterapkan dari riwayat "xxx"
[penyimpanan] 2017/12/21 15:50:46 mendapatkan revisi terakhir dari "xxx"
[penyimpanan] 21/12/17 15:50:46 mendapatkan riwayat rilis untuk "xxx"
[anakan] 2017/12/21 15:50:50 membuat bagan helm-xxx menggunakan nilai
2017/12/21 15:50:50 info: manifest "helm-xxx / templates / scheduler-pvc.yaml" kosong. Melewati.
2017/12/21 15:50:50 info: manifest "helm-xxx / templates / recomposer-deploy.yaml" kosong. Melewati.
2017/12/21 15:50:50 info: manifest "helm-xxx / templates / scheduler-secret.yaml" kosong. Melewati.
2017/12/21 15:50:50 info: manifest "helm-xxx / templates / scheduler-deploy.yaml" kosong. Melewati.
2017/12/21 15:50:50 info: manifest "helm-xxx / templates / recomposer-secret.yaml" kosong. Melewati.
2017/12/21 15:50:50 info: manifest "helm-xxx / templates / recomposer-pvc.yaml" kosong. Melewati.
[tiller] 2017/12/21 15:50:58 membuat rilis terbaru untuk xxx
[penyimpanan] 2017/12/21 15:50:58 membuat rilis "xxx.v85"
[tiller] 21/12 2017 15:50:59 melakukan pembaruan untuk xxx
[tiller] 2017/12/21 15:50:59 menjalankan 0 hook pra-peningkatan untuk xxx
[tiller] 21/12/17 15:50:59 pengait selesai untuk pra-peningkatan xxx
[kube] 2017/12/21 15:51:13 membangun resource dari manifes yang diperbarui
[kube] 2017/12/21 15:51:22 memeriksa 7 resource untuk perubahan
[kube] 2017/12/21 15:51:22 Sepertinya tidak ada perubahan untuk Rahasia "xxx-helm-xxx-nginx-secret"
[kube] 2017/12/21 15:51:23 Sepertinya tidak ada perubahan untuk Rahasia "xxx-application-secret"
[kube] 2017/12/21 15:51:23 Sepertinya tidak ada perubahan untuk Rahasia "biru-rahasia"
[kube] 2017/12/21 15:51:23 Sepertinya tidak ada perubahan untuk ConfigMap "xxx-helm-xxx-nginx-config"
[kube] 2017/12/21 15:51:23 Sepertinya tidak ada perubahan untuk ConfigMap "xxx-application-config"
[kube] 2017/12/21 15:51:24 Sepertinya tidak ada perubahan untuk Layanan "xxx-application-svc"
[kube] 21/12 2017 15:51:24 Menghapus "xxx-recomposer-secret" di xxx ...
[kube] 2017/12/21 15:51:24 Gagal menghapus "xxx-recomposer-secret", err: secret "xxx-recomposer-secret" tidak ditemukan
[kube] 21/12 2017 15:51:24 Menghapus "xxx-recomposer-config" di xxx ...
[kube] 2017/12/21 15:51:24 Gagal menghapus "xxx-recomposer-config", err: configmaps "xxx-recomposer-config" tidak ditemukan
[kube] 2017/12/21 15:51:24 Menghapus "xxx-recomposer-pv" di ...
[kube] 2017/12/21 15:51:24 Gagal menghapus "xxx-recomposer-pv", err: persistentvolumes "xxx-recomposer-pv" tidak ditemukan
[kube] 21/12 2017 15:51:24 Menghapus "xxx-recomposer-pvc" di xxx ...
[kube] 2017/12/21 15:51:24 Gagal menghapus "xxx-recomposer-pvc", err: persistentvolumeclaims "xxx-recomposer-pvc" tidak ditemukan
[kube] 21/12 2017 15:51:24 Menghapus "xxx-recomposer" di xxx ...
[kube] 2017/12/21 15:51:24 Menggunakan mesin penuai untuk menghapus "xxx-recomposer"
[kube] 2017/12/21 15:51:24 Gagal menghapus "xxx-recomposer", err: deployments.extensions "xxx-recomposer" tidak ditemukan
[tiller] 2017/12/21 15:51:24 mengeksekusi 0 kait pasca-peningkatan untuk xxx
[tiller] 2017/12/21 15:51:24 pengait selesai untuk pasca-peningkatan xxx
[penyimpanan] 21/12 2017 15:51:24 memperbarui rilis "xxx.v68"
[tiller] 2017/12/21 15:51:24 memperbarui status untuk rilis terbaru untuk xxx
[penyimpanan] 21/12 2017 15:51:24 memperbarui rilis "xxx.v85"
[penyimpanan] 2017/12/21 15:51:25 mendapatkan revisi terakhir dari "xxx"
[penyimpanan] 2017/12/21 15:51:25 mendapatkan riwayat rilis untuk "xxx"
[kube] 2017/12/21 15:51:38 Melakukan get untuk Rahasia: "xxx-helm-xxx-nginx-secret"
[kube] 2017/12/21 15:51:39 dapatkan pod relasi objek: xxx / Secret / xxx-helm-xxx-nginx-secret
[kube] 2017/12/21 15:51:39 Melakukan get untuk Rahasia: "xxx-application-secret"
[kube] 2017/12/21 15:51:39 dapatkan pod relasi objek: xxx / Secret / xxx-application-secret
[kube] 2017/12/21 15:51:39 Melakukan get untuk Rahasia: "azure-secret"
[kube] 2017/12/21 15:51:39 dapatkan pod relasi objek: xxx / Secret / azure-secret
[kube] 2017/12/21 15:51:39 Melakukan get untuk ConfigMap: "xxx-helm-xxx-nginx-config"
[kube] 2017/12/21 15:51:39 dapatkan pod relasi objek: xxx / ConfigMap / xxx-helm-xxx-nginx-config
[kube] 2017/12/21 15:51:39 Melakukan get untuk ConfigMap: "xxx-application-config"
[kube] 2017/12/21 15:51:39 dapatkan pod relasi objek: xxx / ConfigMap / xxx-application-config
[kube] 2017/12/21 15:51:39 Melakukan get untuk Layanan: "xxx-application-svc"
[kube] 2017/12/21 15:51:39 dapatkan pod relasi objek: xxx / Service / xxx-application-svc
[kube] 2017/12/21 15:51:39 Melakukan get untuk StatefulSet: "xxx-application"
[kube] 2017/12/21 15:51:39 dapatkan pod relasi objek: xxx / StatefulSet / xxx-application

mungkin terkait dengan # 2941

kata di utas lain, salah satu cara untuk memperbaiki masalah ini adalah dengan menghapus konfigurasi buggy ... sepertinya melakukannya untuk saya saat ini ...

Itu semua bagus dan keren. Hingga saat itu, ketika Anda harus menghapus sesuatu yang penting dari namespace produksi. Yang, kebetulan, baru saja terjadi pada saya. : c

Saya juga menghadapi masalah saat kami mengupgrade rilis jika ada beberapa status DEPLOYED dari rilis ini, Harus memperbaikinya dengan menghapus configmaps yang sesuai.

Permasalahan yang sama. Semuanya baik-baik saja kemarin dan saya melakukan beberapa peningkatan. Hari ini saya baru saja menambahkan yaml baru dengan service dan deployment blok dipisahkan dengan --- dan peningkatan gagal.

Hal yang menarik adalah , helm menciptakan service dan kemudian mengeluhkannya (dan tidak melakukan penerapan).
Saya mengomentari service dan baru saja menjalankan peningkatan dengan blok deployment - berhasil. Namun, helm tidak menghapus layanan - yang seharusnya sudah dihapus dari file yaml.

Pembaruan : Saya secara manual menghapus service , menghapus komentar dari yaml dan menjalankan peningkatan - kali ini berfungsi seperti pesona!

Saya mengalami kesalahan persis seperti ini. Sepertinya masalah ini terkait dengan template dengan beberapa objek API yang mirip dengan yang dilihat @amritb . Dalam kasus saya, saya memiliki template yang memiliki beberapa objek API yang dapat diaktifkan dan dinonaktifkan seperti:

{{ if .Values.enabled }}
---
...

Memecahnya menjadi file templatnya sendiri dan membersihkan objek yatim piatu yang dibuat helm dan lupa tentang menyelesaikan masalah untuk saya. Sepertinya ada bug dalam cara helm mendapatkan konfigurasi sebelumnya jika jumlah objek per template berubah di antara rilis.

Menambahkan titik data lain: Sepertinya saya mengalami masalah yang sama persis dengan @awwithro. Kami menggunakan loop jinja untuk membuat beberapa cronjobs melalui sebuah template, dan ketika upgrade baru menyebabkan loop ini mengisi cronjob tambahan, kami menemukan bug tersebut. Tampaknya memicu # 2941 juga (atau mungkin satu bug menyebabkan yang lain), dan menghapus konfigurasi zombie akan memperbaikinya.

Hanya terjebak ke dalam ini bahkan tanpa menggunakan configmaps

Beberapa warna ekstra untuk siapa saja yang mungkin terjebak:
Saya mengalami ini saat memperkenalkan subchart dan objek baru ke rilis saya. Saya dapat menyelesaikannya dengan memeriksa setiap jenis objek yang sedang ditambahkan, dan menghapus objek yang ada yang akan menyebabkan benturan penamaan.

Ini tampaknya sejalan dengan bukti orang lain bahwa penghapusan adalah satu-satunya cara untuk menyelesaikannya saat ini 😕

Juga berjalan melintasi ini = \

Saya juga perlu menghapus sumber daya yang terpengaruh. Tidak baik untuk lingkungan produksi = _ (

Saya melihat sesuatu yang menurut saya serupa. Masalahnya tampaknya helm upgrade tidak --reuse-values ​​dari penerapan sebelumnya. Jika saya menetapkan kumpulan nilai yang sama pada baris perintah seperti yang dilakukan penginstalan awal, maka helm upgrade berfungsi. Entah apakah ini membantu (atau siapa pun dapat mengonfirmasi ini).

Seperti @amritb , setelah saya menghapus secara manual objek yang awalnya gagal helm, berhasil setelah peningkatan berikutnya. Saya tidak mengalami # 2941.

Masalah yang sama menggunakan helm 2.8.0 . Versi Kubernetes client=v1.8.6 dan server=v1.8.5-gke.0 .

$ helm upgrade bunny ./app --debug
[debug] Created tunnel using local port: '54274'

[debug] SERVER: "127.0.0.1:54274"

Error: UPGRADE FAILED: no ConfigMap with the name "bunny-proxy-config" found

Tapi configmap ada di $ kubectl get configmap . Jika saya menghapus configmap secara manual, itu berfungsi, tetapi lain kali gagal lagi.

Berikut adalah configmapnya:

apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ template "proxy.fullname" . }}-config
  # namespace: {{ .Release.Namespace }} # I've tried adding and removing it
  labels: # labels are the same as labels from $ kubectl describe configmap bunny-proxy-config
    app: {{ template "proxy.name" . }}
    chart: {{ template "proxy.chart" . }}
    release: {{ .Release.Name }}
    heritage: {{ .Release.Service }}
data:
  asd: qwe

Saya menghapus rilis dan menginstal ulang lagi. Juga, saya menggunakan api versi extensions/v1beta untuk penerapan, saya telah mengubah ke apiVersion: apps/v1beta2 , saya tidak tahu apakah ini membantu atau tidak.
Juga saat ini saya menjalankan tiller secara lokal.

Saat ini sepertinya semuanya bekerja.

Ini sangat mudah untuk direproduksi, terjadi jika ada kesalahan dalam manifes.

Seperti kita memiliki resource1 dan resource2, resource2 bergantung pada terlebih dahulu. Saat kami mengupgrade rilis, resource1 dibuat (mis. PV & PVC), tetapi resource2 gagal. Setelah ini hanya penghapusan resource1 yang membantu, karena helm selalu melaporkan masalah saat upgrade (PersistentVolume dengan nama ... tidak ditemukan)

Kami memiliki masalah yang sama (sumber daya yang membuat kami adalah Rahasia). Menghapus rahasia baru dan menerapkannya kembali memperbaikinya.

Perhatikan bahwa karena kegagalan, kami sekarang memiliki 11 rilis berbeda ketika kami melakukan helm list , 10 yang GAGAL dan 1 DEPLOYED. Itu tidak diharapkan, bukan? Masalah yang sama seperti di sini tampaknya: https://github.com/kubernetes/helm/issues/2941

Hal ini membuat helm tidak dapat digunakan untuk penerapan produksi reguler bagi kami :( Saat ini kami sedang menyelidiki melakukan hal-hal seperti memberikan --dry-run to helm dan menyalurkannya ke kubectl apply ... Karena ini tampaknya hanya memengaruhi sebagian pengguna , saya tidak yakin apa yang kami lakukan salah :(

Setelah mengekor log anakan, saya menemukan bahwa anakan mencoba memperbarui rilis lama pada saat yang bersamaan:

[storage] 2018/02/14 18:25:40 updating release "s2osf.v10"
[storage] 2018/02/14 18:25:40 updating release "s2osf.v44"

Menghapus configmap lama untuk s2osf.v10 dan kemudian memutakhirkannya berhasil.

Client: &version.Version{SemVer:"v2.7.2", GitCommit:"8478fb4fc723885b155c924d1c8c410b7a9444e6", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.7.2", GitCommit:"8478fb4fc723885b155c924d1c8c410b7a9444e6", GitTreeState:"clean"}

Memiliki masalah yang sama dengan @binoculars :

[storage] 2018/02/15 10:20:50 updating release "control.v136"
[storage] 2018/02/15 10:20:50 updating release "control.v226"

Menyebabkan masalah aneh dengan UPGRADE FAILED: no Secret with the name "foobar" found .
Saya bahkan mencoba menghapus rahasia ini yang kemudian menyebabkan kesalahan pada beberapa configmap, dan menjalankannya sekali lagi mengeluhkan rahasia sebelumnya.

Ini mungkin terpicu setelah meningkatkan dari helm 2.7.x ke 2.8.1.

Client: &version.Version{SemVer:"v2.8.1", GitCommit:"6af75a8fd72e2aa18a2b278cfe5c7a1c5feca7f2", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.8.1", GitCommit:"6af75a8fd72e2aa18a2b278cfe5c7a1c5feca7f2", GitTreeState:"clean"}

jika upaya terakhir Anda adalah menghapus rilis lama, mungkin ada solusi yang tidak terlalu merusak seperti komentar saya https://github.com/kubernetes/helm/issues/3513#issuecomment -366918019

pada dasarnya menemukan revisi lama itu di log dan mengedit configmap secara manual di mana tiller menyimpan status yang diterapkan. Tidak boleh ada dua revisi dengan status DEPLOYED afaik.

Menemukan solusi baru untuk masalah ini.

kubectl -n kube-system edit cm name_of_your_release.v2 , di mana v2 adalah nomor revisi terbaru yang ditandai GAGAL di helm list . Anda mungkin juga ingin mengedit salah satu rilis DEPLOYED dan mengubah status menjadi SUPERSEDED, sehingga kami tidak memiliki dua rilis yang diterapkan pada waktu yang sama.

@zuzzas inilah yang saya maksud. Bekerja untuk saya juga

@balboah masalahnya adalah kita hanya memiliki satu penerapan dalam status DEPLOYED, tetapi jika itu bukan yang terbaru (yang ditandai sebagai GAGAL, ​​dalam banyak skenario), itu akan tetap macet. Masalahnya tampaknya tidak terkait dengan memiliki dua atau lebih penerapan dalam status DEPLOYED di sebagian besar kasus kami.

@zuzzas apakah Anda memiliki banyak rilis dalam namespace yang sama atau hanya satu? Suatu kali, saya memiliki masalah dengan dua rilis yang memperbarui objek yang sama, maka mereka akan saling bertentangan.

Jika hanya satu, berapa banyak kegagalan yang Anda miliki hingga versi yang diterapkan? bagaimana Anda memverifikasi bahwa hanya satu yang diterapkan?

Kami yakin ini telah diperbaiki (bergerak maju) melalui # 3539. Silakan buka kembali jika kami kebetulan salah. :)

Terima kasih semuanya atas pekerjaan Anda dalam hal ini!

Perhatikan bahwa ini belum diperbaiki untuk bagan yang ada di negara bagian ini; Anda masih harus menghapus rilis lama yang berstatus DEPLOYASI agar semuanya berfungsi kembali. @balboah baru saja mencegah kasus di mana Anda bisa masuk ke status "beberapa rilis ditandai sebagai DEPLOYED". :)

Hm, saya masih mendapatkan masalah ini di Helm 2.8.2 (bukan yang terbaru, tetapi saya mencoba dengan 2.9.0 dan ternyata memberikan kesalahan yang sama.) Biasanya menghapus sumber daya yang melanggar secara manual dapat memperbaikinya, meskipun sering kali itu mengalir ke beberapa sumber daya yang semua perlu dihapus sebelum berhasil mengupgrade.

Saya memiliki sedikit bagan helm besar dengan ketergantungan bersarang; mungkinkah itu?

Saya melihat masalah yang sama dengan clusterrolebinding. Saya menambahkan sumber daya baru ke bagan saya dan upgrade serta upgrade --install akan gagal dengan Error: UPGRADE FAILED: no ClusterRoleBinding with the name "test-clusterrolebinding" found

Saya mengalami masalah yang sama seperti @ramyala dengan ClusterRole. ClusterRole ada, tetapi membuat RoleBinding gagal dengan kesalahan itu.

Di Helm 2.9.1 Saya mengalami masalah yang sama:

helm upgrade --install --namespace my-namespace my-stack stack
Error: UPGRADE FAILED: no ConfigMap with the name "my-stack-my-app" found

Sementara saya melihat ConfigMap ini di cluster saya.

Saya mengalami masalah ini jika saya memiliki banyak sumber daya dengan kait dalam satu file

+1, ini terjadi lagi dengan 2.9.1. Harap buka kembali.

Memberi label ulang ini sebagai bug. Kami tidak yakin apa yang menyebabkan regresi ini terjadi, tetapi jika ada yang dapat memberikan langkah-langkah tentang cara mereproduksi bug ini di 2.9.1, itu akan sangat kami hargai.

@bayu_joo

Saya melihat ini juga saat mencoba menerapkan Ingress baru di bagan helm saya. Saya memang baru mengenal Ingress tetapi sepertinya itu benar berdasarkan semua contoh dan saya telah melakukan hal-hal helm / k8s lainnya selama beberapa bulan.

Saya sudah menerapkan bagan helm stable/nginx-ingress sehingga pengontrolnya ada. Kesalahan tampaknya menyarankan itu mencoba menemukan yang saya coba buat. Inilah perintah yang saya jalankan:

helm upgrade some-existing-release-name -i --set imageTag=$TAG-$BUILD_NUMBER --namespace=default ./deploy/helm mana deploy/helm berisi manifes bagan saya.

Error: UPGRADE FAILED: no Ingress with the name "my-ingress" found

yaml:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: my-ingress
  labels:
    app: my-app
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/ssl-redirect: "false"
spec:
  rules:
  - host: {{ $.Values.appDomain }}
    http:
      paths:
      - path: /*
        backend:
          serviceName: web-app
          servicePort: 80
      - path: /api/*
        backend:
          serviceName: api
          servicePort: 8080

MEMPERBARUI
Saya menghapus /* dari kedua jalur saya dan tidak lagi memberikan kesalahan saat mencoba memutakhirkan / menginstal. Mungkin itu bukan sintaks yang valid

Hai,
Berikut adalah langkah-langkah yang memperkenalkan masalah di env saya:

1. Saya memiliki bagan helm yang dipasang dan ditingkatkan beberapa kali.
2. Membuat objek CronJob baru di bagan dan ditingkatkan lagi - tugas cron berhasil dibuat.
3. Semua peningkatan berikutnya gagal dengan kesalahan yang dilaporkan "Kesalahan: UPGRADE GAGAL: tidak ada CronJob dengan nama" nama-cronjob "yang ditemukan"

Saya juga melihat masalah ketika saya menambahkan Rahasia yang sebelumnya tidak ada. Saya mencoba menambahkan "db-credentials"
rahasia yang mengarah pada:

Error: UPGRADE FAILED: no Secret with the name "db-credentials" found

perbaikan yang mungkin relevan: # 4146

jika ada yang mengalami kesalahan ini dapat menguji PR itu dan melihat apakah itu memperbaikinya, maka kami akan dapat mengonfirmasi bahwa itu kemungkinan regresi dalam API k8s dan bergerak maju dengan perbaikan itu. Terima kasih!

Saya tidak dapat 100% mengonfirmasi apakah ini akan selalu mereproduksi, tetapi saya perhatikan ini cenderung terjadi dalam situasi berikut:

1. Saya meningkatkan bagan Helm, termasuk sumber daya baru
2. Peningkatan tersebut gagal, tetapi sumber daya dibuat sebagai bagian dari peningkatan yang gagal
3. Semua peningkatan berikutnya gagal

Jika saya melakukan helm rollback hingga penerapan terakhir yang berhasil dan kemudian mencoba memutakhirkan ulang, tampaknya berhasil.

Tampaknya sangat mudah untuk mereproduksinya secara manual, tanpa sengaja mencoba mengupgrade diagram dengan perubahan berbahaya (misalnya, memodifikasi objek Job yang tidak dapat diubah):

1. Ambil beberapa bagan dan terapkan (tetapi hilangkan satu sumber daya, katakanlah Layanan)
2. Tambahkan sumber daya yang dihilangkan secara manual (misalnya, dengan "kubectl create"), tetapi dengan nama yang sesuai dengan rilis
3. Tambahkan sumber daya yang dihilangkan kembali ke bagan dan kemudian coba perbarui, helm harus melaporkan "UPGRADE GAGAL: tidakdengan namaditemukan"

Langkah-langkahnya berbeda tetapi akar masalahnya tetap sama. Koreksi saya jika saya salah dalam asumsinya, tetapi menurut saya rilis revisi DEPLOYED terakhir tidak memiliki informasi tentang sumber daya tertentu, baik karena telah ditambahkan Helm "di luar" (secara manual misalnya) atau pemutakhiran terbaru gagal pada beberapa langkah (katakanlah tentang memutakhirkan Pekerjaan yang tidak dapat diubah), pada saat yang sama menerapkan objek lain dan kemudian merekamnya dalam revisi GAGAL (tetapi masih tanpa trek apa pun dalam revisi DEPLOYED apa yang diharapkan, jika tidak itu berarti mengubah riwayat) . Pada proses berikutnya, klien kube Tiller melihat sumber daya di cluster, yang berarti mereka harus sudah diterapkan dan dengan demikian dicatat, ia memeriksa revisi DEPLOYED terbaru (tampaknya revisi GAGAL tidak dihubungi sama sekali) dan tidak melihatnya terdaftar di sana sehingga melaporkan kesalahan.

@bacongobbler Saya menguji # 4146 dengan gambar anakan khusus dan itu memperbaiki masalah ini! Bagi orang lain yang mencari solusi, Anda dapat menerapkan tambalan dalam masalah pada master saat ini dan kompilasi:

make bootstrap build docker-build

Anda harus mengunggah gambar anakan ke repo Anda dan menginstal ulang anakan ke cluster Anda. Saya bisa lolos dengan pengaturan ulang paksa dan menginstal ulang tanpa merusak rilis saat ini.

$GO_HOME/src/k8s.io/helm/bin/helm init -i gcr.io/my-repo/tiller:1 --service-account tiller

terima kasih @ramyala telah menguji perbaikannya! Saya akan menyebutkannya dalam panggilan dev besok dan melihat apakah ada pengelola inti lainnya yang melihat kasus tepi yang mungkin muncul dengan tambalan. Jika tidak, mari bergabung.

Jadi saya menemukan beberapa bug dengan # 4146 yang membuatnya menjadi PR yang tidak diinginkan untuk dilanjutkan. Saya melaporkan temuan saya antara master, # 4146, dan # 4223 di sini: https://github.com/kubernetes/helm/pull/4223#issuecomment -397413568

@adamreese dan saya berhasil mengidentifikasi bug yang mendasari yang menyebabkan kesalahan khusus ini, dan melalui berbagai skenario dan kasus tepi dengan masing-masing PR yang diusulkan. Jika ada orang lain yang dapat mengkonfirmasi temuan saya atau menemukan kasus edge lainnya, itu akan sangat kami hargai!

Oh, dan sesuatu yang tidak saya sebutkan: karena cluster dalam keadaan tidak konsisten, ini dapat dengan mudah diatasi dengan mengintervensi dan menghapus sumber daya yang dilaporkan kesalahan sebagai "tidak ditemukan" secara manual. Mengikuti contoh yang saya tunjukkan di https://github.com/kubernetes/helm/pull/4223#issuecomment -397413568:

><> helm fetch --untar https://github.com/kubernetes/helm/files/2103643/foo-0.1.0.tar.gz
><> helm install ./foo/
...
><> vim foo/templates/service.yaml
><> kubectl create -f foo/templates/service.yaml
service "foo-bar" created
><> helm upgrade $(helm last) ./foo/
Error: UPGRADE FAILED: no Service with the name "foo-bar" found
><> kubectl delete svc foo-bar
service "foo-bar" deleted
><> helm upgrade $(helm last) ./foo/
Release "riotous-echidna" has been upgraded. Happy Helming!
...
><> kubectl get svc
NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
foo-bar      ClusterIP   10.104.143.52   <none>        80/TCP    3s
kubernetes   ClusterIP   10.96.0.1       <none>        443/TCP   1h

Untuk kepentingan menyatukan semuanya, saya akan menutup ini sebagai duplikat dari # 1193 karena kedua tiket itu identik. Silakan laporkan temuan apa pun di sana sehingga kami semua dapat mengerjakan satu tiket. Terima kasih!

Peringatan: informasi ini agak samar dan saya tidak dapat memahaminya, tetapi kalau-kalau ini berguna bagi seseorang, saya mengatasi masalah ini dengan mengubah pemilih layanan saya dari:

selector:
    app: {{ template "mything.name" . }}

untuk

selector:
    app: mything

Mungkin ada masalah dengan penggunaan variabel dalam konteks ini?

Coba helm delete RELEASE_NAME --purge
dan pasang kembali.

Saya mengalami masalah ini juga. Saya mencoba menambahkan subchart dengan penerapan di bagan saya, berhasil ketika ditingkatkan dengan helm upgrade chart chart-1.0.1.tgz hanya untuk pertama kalinya, setelah itu ketika saya mencoba helm upgrade chart chart-1.0.1.tgz gagal dengan kesalahan Error: UPGRADE FAILED: no Deployment with name "subchart-deployment" found

Client: &version.Version{SemVer:"v2.12.0", GitCommit:"d325d2a9c179b33af1a024cdb5a4472b6288016a", GitTreeState:"clean"} Server: &version.Version{SemVer:"v2.12.0", GitCommit:"d325d2a9c179b33af1a024cdb5a4472b6288016a", GitTreeState:"clean"}

Log kemudi kemudi hanya mencatat kesalahan yang sama. Ada yang mengalami ini juga?

Permasalahan yang sama. Semuanya baik-baik saja kemarin dan saya melakukan beberapa peningkatan. Hari ini saya baru saja menambahkan yaml baru dengan service dan deployment blok dipisahkan dengan --- dan peningkatan gagal.

Hal yang menarik adalah , helm menciptakan service dan kemudian mengeluhkannya (dan tidak melakukan penerapan).
Saya mengomentari service dan baru saja menjalankan peningkatan dengan blok deployment - berhasil. Namun, helm tidak menghapus layanan - yang seharusnya sudah dihapus dari file yaml.

Pembaruan : Saya secara manual menghapus service , menghapus komentar dari yaml dan menjalankan peningkatan - kali ini berfungsi seperti pesona!

hai, saya juga memiliki masalah ini, dan saya tidak dapat menyelesaikannya, dapatkah Anda memberi saya beberapa petunjuk.

lihat https://github.com/helm/helm/issues/1193#issuecomment -419555433.

Hanya mengkonfirmasikan bahwa saya menyaksikan masalah yang sama dan penyebabnya juga seperti yang ditunjukkan sebelumnya.

Menambahkan rahasia baru, mereferensikannya dalam volume (sintaks tidak valid). Peningkatan gagal, peningkatan berikutnya gagal dengan kesalahan seperti di atas.

Rahasia pencatatan menunjukkan bahwa itu telah dibuat. Rahasia yang dihapus secara manual dan peningkatan berhasil dilakukan.

Sama, @thedumbtechguy. Saya mengalami masalah ini secara rutin. Ini sangat menyenangkan ketika Helm memutuskan Anda perlu menghapus _all_ rahasia Anda, configmaps, peran, dll. Upgrade menjadi permainan gila-gilaan dengan daftar argumen yang terus bertambah menjadi kubectl delete . Saya seharusnya menyerah pada tugas sisyphean ini beberapa bulan yang lalu, tapi sudah terlambat untuk itu sekarang. Tentu berharap ini dan lusinan masalah serupa bisa diperbaiki!

Saya telah menggunakan helm selama satu minggu dan sudah menghadapi semua yang digariskan
di sini https://medium.com/@7mind_dev/the -problems-with-helm-72a48c50cb45

Banyak yang perlu diperbaiki di sini.

Pada hari Jumat, 15 Mar 2019, 22:49 Tom Davis [email protected] menulis:

Sama, @thedumbtechguy https://github.com/thedumbtechguy . Saya mengalami
masalah ini secara rutin. Sangat menyenangkan ketika Helm memutuskan Anda perlu
hapus semua rahasia Anda, configmaps, role, dll. Upgrade menjadi a
permainan wack-a-mole dengan daftar argumen yang terus bertambah ke kubectl
menghapus. Aku seharusnya menyerah pada tugas berbulan-bulan sisyphean ini
lalu, tapi sudah terlambat untuk itu sekarang. Tentu berharap ini dan lusinannya
masalah serupa bisa diperbaiki!

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/helm/helm/issues/3275#issuecomment-473464809 , atau nonaktifkan
utasnya
https://github.com/notifications/unsubscribe-auth/AA4XZU4KMQePtZKcir8S5kWulkbYg-8Uks5vXCNggaJpZM4RGz7W
.

Saya mengalami hal yang sama dengan Helm v2.10. Saya sudah memiliki bagan yang diterapkan, menambahkan configMap lain ke bagan. Ini melaporkan bahwa penerapan gagal karena tidak dapat menemukan configMap "blah". aku melakukannya

helm upgrade <NAME> chart --debug --dryrun 

Untuk memverifikasi configMap memang sedang dirender, itu benar. Memeriksa configMaps di cluster, dan menemukannya di sana. Menghapus blah configMap, menjalankan kembali peningkatan, itu berhasil.

https://github.com/helm/helm/pull/5460 sebaiknya mengklarifikasi pesan kesalahan dengan lebih baik di masa mendatang.

Poin yang adil.

$ helm upgrade linting-unicorn testrail                                                                                                                                                                                        
Error: UPGRADE FAILED: no ConfigMap with the name "linting-unicorn-testrail-php-config" found

Pertahankan tim helm kerja yang baik.

Jika ini adalah masalah besar bagi orang lain, sebaiknya saya tunjukkan https://github.com/helm/helm/pull/4871 harus memperbaiki masalah ini.

Perhatikan bahwa tampaknya itu masih belum disetujui oleh tim Helm. Ditambah ada beberapa kekhawatiran tentang sumber daya penghapusan otomatis. Sebutkan saja jika ada yang ingin membangunnya dari sumber dan mencobanya.

Memiliki masalah yang sama dan hanya solusi yang tampaknya menjadi helm delete --purge release dan instal lagi!

Saya mengalami masalah yang sama. @fbcosa sepertinya digabungkan 2 minggu yang lalu. Semoga ini menjadi bagian dari rilis berikutnya 2.14.0 .

Memiliki masalah yang sama dan hanya solusi yang tampaknya menjadi helm delete --purge release dan instal lagi!

Opsi yang tidak terlalu merusak adalah melakukan helm rollback ke / saat ini / versi (yaitu dengan 0 langkah). Saya tidak dapat menjamin kesuksesan, tetapi bagi kami sejauh ini, hal itu selalu berhasil tanpa ikatan.

Adakah ide jika ini akan menjadi rilis berikutnya, dan jika iya ketika akan datang?

5460 telah digabungkan 2 bulan yang lalu, yang berarti harus memegang kendali 2.14.0.

Saya memperbaiki masalah ini pada

1. hapus sumber daya yang dikeluhkan oleh "peningkatan helm". (Dikatakan Tidak ditemukan tetapi sebenarnya dapat ditemukan). Jangan hapus seluruh rilis, jika dalam produksi Anda akan disekrup sepenuhnya.
2. ulangi peningkatan helm. Sekarang kali ini seharusnya "Selamat Menolong" muncul. :)

Kami mengalami masalah ini di PROD, ketika persyaratan untuk bagan helm payung kami menambahkan peta konfigurasi berdasarkan kondisional. Bagi kami, pekerjaan perbaikan adalah untuk

helm rollback <some revision that's acceptable>
helm upgrade <desired version>

Bagi kami, rollback sederhana ke revisi saat ini selalu berhasil:

helm ls
helm rollback <NAME> <current REVISION>

@tobypeschel apakah Anda tahu cara kerja perbaikan Anda?