Helm: UPGRADE GAGAL: Tidak ditemukan sumber daya dengan nama ""

Saya mengalami masalah serupa di mana saya memiliki bagan dengan dependensi yang dibundel. Jika saya menambahkan ketergantungan baru dan menjalankan helm upgrade hasilnya sama seperti yang dijelaskan. Sumber daya dibuat dengan benar namun helm mengembalikan kesalahan.

Jadi, jika ini sudah diinstal: helm install -n my-release

my-thing/
  Chart.yml
  charts/
    depended-upon-thing/

Dan kemudian bagan baru ditambahkan sebagai ketergantungan:

my-thing/
  Chart.yml
  charts/
    depended-upon-thing/
    new-dependency/

Ketika rilis ditingkatkan dengan: helm upgrade my-release my-thing helm menghasilkan kesalahan berikut:

Error: UPGRADE FAILED: No resource with the name new-dependency found.

@devth Saya tidak dapat mereproduksi masalah ini di master. Apakah Anda masih melihat masalah ini? Versi helm / anakan apa yang Anda jalankan?

Terima kasih!

@elementalvoid Saya juga tidak dapat mereproduksi kesalahan ketergantungan baru pada master. Apakah Anda masih melihat masalah ini? Versi helm / anakan apa yang Anda jalankan?

Terima kasih.

Saat itu saya menggunakan alfa 4. Menggunakan contoh alfa 5 dan @devth , saya juga tidak dapat mereproduksi masalah tersebut.

Baik. Saya akan menutup ini untuk saat ini. Jangan ragu untuk mengajukan masalah jika Anda melihat salah satu dari masalah ini lagi.

Terima kasih lagi.

@ michelleN terima kasih! Maaf saya tidak punya waktu minggu ini untuk mencoba repro pada master. Berharap untuk segera meningkatkan!

Sama untuk saya saat memindahkan spesifikasi Deployment / Volume hostPath ke PVC.
Bug tampaknya terjadi saat peningkatan Manifes bergantung pada yang baru ("hilang" di yang lama?)
versi: 2.7.2.0

Aneh, saya melihat perilaku yang sama mencoba memutakhirkan bagan di versi 2.7.2 dengan peran baru. Tiller mengeluh tidak dapat menemukan peran tersebut dan gagal dalam penerapan, meskipun peran tersebut benar-benar dibuat.

Situasi saya adalah bahwa saya memiliki sumber daya baru, dan saya menerapkan versi baru bagan kemudi dengan sumber daya baru. Penerapan itu gagal karena saya salah paham dengan beberapa ubi. Nah, objek baru dibuat di kubernetes. Saya memperbaiki yaml, dan menjalankan peningkatan pada bagan saya lagi, dan voila, pesan kesalahan bahwa sumber daya tidak ditemukan muncul. Saya harus masuk ke kubernetes dan menghapus sumber daya baru (dalam kasus saya, peran dan rolebinding) yang dibuat oleh penerapan yang gagal. Setelah itu, pemeriksaan helm untuk melihat apakah objek saat ini ada gagal (https://github.com/kubernetes/helm/blob/7432bdd716c4bc34ad95a85a761c7cee50a74ca3/pkg/kube/client.go#L257) tidak akan berhasil, dan sumber daya dibuat lagi. Sepertinya bug, di mana mungkin sumber daya baru untuk bagan yang gagal harus diperhitungkan?

Mendapatkan kesalahan serupa saat meningkatkan:

$ helm upgrade --install bunny ./app --namespace=staging --reuse-values --debug
[debug] Created tunnel using local port: '53859'

[debug] SERVER: "127.0.0.1:53859"

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

Configmap dibuat

$ k get configmap
NAME                 DATA      AGE
bunny-proxy-config   1         7m

Configmap saya:

apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ template "proxy.fullname" . }}-config
  labels:
    app: {{ template "proxy.name" . }}
    chart: {{ template "proxy.chart" . }}
    release: {{ .Release.Name }}
    heritage: {{ .Release.Service }}
data:
  asd: qwe

Kami memiliki masalah yang sama.

Saya menghapus seluruh rilis dan menginstal lagi. Saat ini tampaknya berfungsi.

$ helm del --purge bunny

Saya juga mengalami masalah ini

Klien: & version.Version {SemVer: "v2.8.0", GitCommit: "14af25f1de6832228539259b821949d20069a222", GitTreeState: "clean"}
Server: & version.Version {SemVer: "v2.8.0", GitCommit: "14af25f1de6832228539259b821949d20069a222", GitTreeState: "clean"}

Ini sering terjadi dengan penggunaan helm kami dan membutuhkan --purge . Itu _bukan_ solusi.

Ini tidak berlaku jika Anda menggunakan CI / CD.
Apa yang terjadi jika peningkatan gagal dan Anda menggunakan strategi pembaruan berkelanjutan. Haruskah saya menghapus rilis saya yang masih berfungsi?

Saya melihat masalah yang sama juga ketika ada masalah Penerapan atau serupa tetapi rahasia / cm dibuat tetapi kemudian Helm kehilangan jejaknya, menolak untuk membiarkan Anda melakukan banyak hal.

Saya pernah melihatnya, jarang sekali, terjadi bahkan pada rilis yang tidak rusak (yaitu terlihat telah melalui) tetapi saya belum menemukan apa yang dapat menyebabkannya.

Kami juga dapat mereproduksi masalah ini (server v2.8.2) saat menambahkan sumber daya ke penerapan helm yang ada. Harus menghapus penerapan dan menerapkan ulang setiap kali sumber daya baru harus ditambahkan akan menjadi masalah besar dalam produksi.

Dalam kasus kami, kami menambahkan configmap ke bagan dan bagan gagal ditingkatkan dengan:

Kesalahan: UPGRADE GAGAL: tidak ada sumber daya dengan nama "" ditemukan

Catatan: Kami menggunakan 2.7.2;

Saya yakin ini terjadi karena ketika helm menentukan apa yang telah berubah, helm mencari sumber configmap baru di rilis lama , dan gagal menemukannya. Lihat https://github.com/kubernetes/helm/blob/master/pkg/kube/client.go#L276 -L280 untuk kode asal kesalahan ini.

Log Tiller untuk pemutakhiran yang gagal:

[tiller] 2018/05/03 19:09:14 preparing update for staging-collector
[storage] 2018/05/03 19:09:14 getting deployed release from "staging-collector" history
[tiller] 2018/05/03 19:10:39 getting history for release staging-collector
[storage] 2018/05/03 19:10:39 getting release history for "staging-collector"
[tiller] 2018/05/03 19:10:41 preparing update for staging-collector
[storage] 2018/05/03 19:10:41 getting deployed release from "staging-collector" history
[storage] 2018/05/03 19:10:42 getting last revision of "staging-collector"
[storage] 2018/05/03 19:10:42 getting release history for "staging-collector"
[tiller] 2018/05/03 19:10:44 rendering collector chart using values
[tiller] 2018/05/03 19:10:44 creating updated release for staging-collector
[storage] 2018/05/03 19:10:44 creating release "staging-collector.v858"
[tiller] 2018/05/03 19:10:44 performing update for staging-collector
[tiller] 2018/05/03 19:10:44 executing 0 pre-upgrade hooks for staging-collector
[tiller] 2018/05/03 19:10:44 hooks complete for pre-upgrade staging-collector
[kube] 2018/05/03 19:10:44 building resources from updated manifest
[kube] 2018/05/03 19:10:44 checking 3 resources for changes
[tiller] 2018/05/03 19:10:44 warning: Upgrade "staging-collector" failed: no resource with the name "collector-config" found 
[storage] 2018/05/03 19:10:44 updating release "staging-collector.v857"
[storage] 2018/05/03 19:10:44 updating release "staging-collector.v858" 

Masalah ini juga muncul saat mengubah label name dari Layanan yang diterapkan, mungkin hal-hal lain juga.

Saya mengubah nama Layanan dalam rilis dan gagal memutakhirkan dengan:

Kesalahan: UPGRADE GAGAL: tidak ada Layanan dengan nama "nama-layanan-baru" yang ditemukan

Saya bersedia membuat PR untuk memperbaiki perilaku ini, tetapi saya ingin tahu cara yang dimaksudkan atau disarankan untuk menangani hal ini. Bahkan flag CLI yang memungkinkan --force untuk didahulukan akan sangat bagus.

Setuju tentang pentingnya.

Masalah ini bisa menjadi aneh jika Anda tidak bisa begitu saja menghapus penerapan.

Saya menemukan masalah kami karena penerapan yang gagal.

Helm tidak berusaha membersihkan setelah penerapan yang gagal, yang berarti hal-hal seperti ConfigMap baru yang saya tambahkan di atas dibuat tetapi tanpa referensi dalam penerapan 'sebelumnya'. Itu berarti ketika penerapan berikutnya terjadi, helm menemukan sumber daya di k8s dan mengharapkannya untuk direferensikan dalam revisi yang diterapkan terbaru (atau sesuatu; Saya tidak yakin logika persis apa yang digunakannya untuk menemukan rilis 'sebelumnya') untuk memeriksa apa ada perubahan. Itu tidak ada dalam rilis itu, jadi tidak dapat menemukan sumber daya, dan gagal.

Ini terutama menjadi masalah saat mengembangkan bagan karena penerapan yang gagal membuat k8s dalam keadaan helm tidak melacak dengan benar. Ketika saya mengetahui inilah yang terjadi, saya tahu saya hanya perlu menghapus ConfigMap dari k8s dan mencoba menerapkan lagi.

@krishicks Ya, ini adalah salah satu cara untuk memperbaikinya. Penerapan yang gagal + sumber daya yang tidak pernah dibuat (yaitu configmap tidak valid) juga dapat menyebabkan ini seperti yang saya perhatikan, yang kemudian mengarah ke status tidak dapat dipulihkan

Kami akan melakukan yang ini juga. Ini adalah masalah yang sama yang disebutkan oleh @jaredallard :

1. Kami memiliki penerapan yang gagal:
   UPGRADE FAILED: the server was unable to return a response in the time allotted, but may still be processing the request (get configmaps)
2. Setiap perubahan berikutnya, juga untuk rilis lain, gagal dengan peringatan seperti
   Error: UPGRADE FAILED: no Service with the name "…" found

Saya akan mencoba menggunakan flag helm upgrade --timeout … untuk mengurangi masalah pertama, tetapi penerapan yang gagal memblokir semuanya cukup menjadi masalah bagi kami. Selain itu, menggunakan helm rollback … tidak menyelesaikan masalah ini.

Karena helm upgrade … berjalan secara otomatis dalam kasus penggunaan kita, tanda --auto-rollback untuk helm upgrade akan sangat membantu, yang mengembalikan perubahan yang gagal.

Ini terjadi pada saya dengan v2.7.2 saat menambahkan sumber daya baru ke bagan.
Apakah ada perkiraan kapan perbaikan akan dilakukan untuk ini?

Ini harus diperbaiki dengan # 4146.

EDIT: lihat di bawah

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

@bacongobbler Itu tidak selalu berhasil. Kami pernah mengalami situasi di mana menghapusnya berhasil dan beberapa di mana masih tidak berfungsi setelah melakukan itu.

ini dapat dengan mudah diatasi dengan mengintervensi dan menghapus sumber daya secara manual

@bacongobbler Harap dipahami bahwa sumber daya ini mungkin merupakan objek Layanan atau Penerapan namespace produksi, yang mungkin (dan sudah) sangat mengganggu jaminan layanan kami.

Ya saya tahu. Saya hanya menjelaskan dan mengamati perilaku bug sehingga orang lain tahu apa yang terlibat. :)

Baru saja mengalami masalah ini dua kali di cluster yang berbeda. Setiap kali dengan configmaps. Menghapus sumber daya tidak menyelesaikan masalah, jadi kami harus menghapus seluruh rilis.

Sama disini. Tidak hanya Configmaps saya punya satu dengan ServiceAccount.

PVC di sini. :)

Pada dasarnya setiap jenis objek yang diprioritaskan tunduk pada bug ini.

Apakah ada seseorang yang ditugaskan untuk memperbaikinya? Apakah sudah ada PR untuk ini? Ada yang bisa saya bantu?

Saya telah digigit oleh masalah ini lebih dari sekali karena ini adalah situasi yang mudah untuk Anda ikuti, tetapi tampaknya tidak ada cara mudah untuk keluar. Saya kira bagian "baik" dalam kasus saya adalah bahwa sumber daya diperbarui bahkan dengan kesalahan pada rilis (tidak yakin apakah itu membuat saya senang atau khawatir)

Saya pikir helm harus melarang pengguna masuk ke kondisi yang salah ini atau menanganinya dengan benar.
Apakah ada perbaikan nyata untuk ini selain menghapus semuanya (yang hanya dapat dilakukan untuk penggunaan non-produksi)?

Jika orang lain dapat menentukan kasus tepi lain di mana menghapus sumber daya tidak memecahkan masalah, itu akan sangat membantu dalam menentukan akar penyebab untuk memecahkan isu tertentu. Mungkin ada beberapa jalur yang bisa berakhir dengan kesalahan yang sama.

@Draiken tidak, kami telah mencoba beberapa solusi untuk masalah ini, dan tidak satupun dari solusi yang tampak masuk akal juga

a) jangan melakukan peningkatan sebagaimana dimaksudkan, atau
b) memperkenalkan bug baru

Saya menulis tentang solusi tersebut di sini dan mengapa mereka tidak berhasil. Jika Anda dapat menemukan solusi alternatif, kami akan dengan senang hati melihatnya.

Kami juga tidak bisa menjaga pengguna agar tidak masuk ke kondisi yang salah ini; kita telah melihat solusinya tetapi sekali lagi mereka semua memperkenalkan serangkaian masalah yang berbeda. Setelah penginstalan dalam keadaan tidak konsisten, sulit untuk "memperbaikinya" tanpa intervensi manual. 😢

Solusi yang berhasil bagi saya adalah melakukan helm rollback ... tepat sebelum kegagalan terjadi. Saya kemudian memvalidasi bahwa bagan berfungsi pada rilis baru dengan helm install -n new-test-release . .

Setelah semuanya bekerja, saya membersihkan rilis uji dan menjalankan helm upgrade ... terhadap rilis lama; dan semuanya bekerja. Ini adalah solusi yang menjengkelkan tetapi tampaknya berhasil.

Saya tidak tahu apakah ini membantu sama sekali, tetapi saya baru saja mengalami masalah ini pada cluster pengujian dan produksi saya.

Perubahan yang saya buat pada file helm saya cukup sederhana:
Saya memiliki 1 penerapan yang sudah ada, dengan layanan terkait dan poddisruptionbudget, yang tidak diubah.
Saya menambahkan penerapan kedua, dengan layanannya sendiri dan poddisruptionbudget.
Saya menaikkan nomor versi bagan.

Saat menjalankan helm saya mendapat kesalahan ini pertama kali:

KUBECONFIG=**** helm upgrade --kube-context=mycluster -f helm/project/mycluster.yaml project ./helm/project --install --wait --timeout 1200

Error: UPGRADE FAILED: Deployment.apps "blah-blah" is invalid: spec.template.metadata.labels: Invalid value: map[string]string{"app":"blah-blah", "chart":"blah-3", "name":"blah", "release":"project"}: `selector` does not match template `labels`

Saat menjalankan kemudi lagi, saya sekarang mendapatkan kesalahan ini berulang kali:

KUBECONFIG=**** helm upgrade --kube-context=mycluster -f helm/project/mycluster.yaml project ./helm/project --install --wait --timeout 1200

Error: UPGRADE FAILED: no Service with the name "blah-blah" found

Bagan helm tentu saja berfungsi dalam pengujian ketika saya menghapus semuanya dan menerapkan ulang. Itu sebenarnya bukan pilihan untuk mendorong.

@veqryn Saya sering mengalami ini, pada dasarnya saya menggunakan build saya di # 4146 setiap kali saya mengalami masalah ini dan kemudian menukar kembali ke yang utama. Bekerja setiap saat. Saya tahu pengelola mungkin tidak merekomendasikannya, tetapi _itu berfungsi_ yang lebih baik daripada tidak sama sekali.

EDIT : Jika ada yang tertarik untuk mencobanya, saya dapat mendorongnya ke repo buruh pelabuhan publik dan menyertakan cuplikan singkat tentang cara menggunakannya.

@jaredall kami tertarik. Terima kasih!

Saya tahu pengelola mungkin tidak merekomendasikannya, tetapi cara kerjanya lebih baik daripada tidak sama sekali.

@jaredallard kami tidak dapat merekomendasikan tambalan itu hanya karena tambalan itu tidak berfungsi sendiri (ref: https://github.com/helm/helm/pull/4223#issuecomment-397413568). Itu melewati kesalahan, tetapi tidak meningkatkan sumber daya, jadi tambalan tidak melakukan apa yang awalnya ingin dilakukan pengguna. Ini memperbaiki satu masalah tetapi memperkenalkan yang lain tanpa memperbaiki masalah asli yang ingin dilakukan pengguna: meningkatkan sumber daya.

Namun, ini menarik:

Saya pada dasarnya menggunakan build saya di # 4146 setiap kali saya mengalami masalah ini dan kemudian menukar kembali ke yang utama.

Jika saya membaca ini dengan benar, Anda menyarankan bahwa Anda telah menemukan solusi untuk itu

a) melewati kesalahan
b) memungkinkan seseorang untuk meningkatkan sumber daya seperti yang mereka inginkan

dengan melakukan 2 helm upgrade s: satu dengan tambalan, dan satu tanpa tambalan? Itu dapat membantu kami mengidentifikasi akar penyebab dengan lebih baik dan cara memperbaiki kesalahan ini.

@ bacongobbler Saya harus mengunjungi kembali ini untuk memverifikasi 100% bahwa itu adalah perilakunya. Saya akan memperbarui komentar ini atau memposting yang lain ketika saya punya.

Saya tahu pengelola mungkin tidak merekomendasikannya, tetapi cara kerjanya lebih baik daripada tidak sama sekali.

Juga, untuk memperjelas, saya tidak mencoba untuk membuang bayangan di sana! Sedikit kata-kata buruk jika dilihat kembali sekarang, maaf

Saya masih bingung mengapa helm saya gagal saat pertama kali memulai.
Itu tidak mendapatkan kesalahan no X with the name Y sampai kedua kalinya saya mencoba menerapkannya.

@veqryn Saya menulis tentang bagaimana masalah ini muncul di tempat pertama dalam masalah yang saya tautkan di atas. Silakan baca komentarnya; dengan senang hati membantu mengklarifikasi masalah ini secara lebih mendetail jika tidak jelas.

Untuk pemalas: https://github.com/helm/helm/pull/4223#issuecomment -397413568

Saya benar-benar membaca itu, dan pemahaman saya adalah bahwa masalah tersebut terjadi pada Anda karena Anda mengubah nama layanan Anda.

Namun, tidak ada satu pun layanan saya atau sumber daya yang mengubah nama.

Dan setelah membaca kembali komentar Anda dan berbicara dengan kru saya, kami menemukan penyebab kesalahan kami:
Saya telah menemukan versi helm Chart saya.
Versi bagan itu direferensikan sebagai label oleh penerapan dan layanan saya.
Kube / helm tidak suka jika label Anda berubah, dan inilah yang menyebabkan kesalahan asli.

Solusinya (bagi saya) adalah menggunakan helm untuk kembali ke penerapan terakhir yang berhasil, lalu mengembalikan perubahan versi bagan sehingga versi bagan tetap sama, yang kemudian berhasil.

perbaikan (jelek) ini bekerja untuk saya:

1. Saya mendapatkan kesalahan:

helm upgrade az-test-2-prom ./prometheus --namespace monitor --set cluster_name="az-test-2" -f values.yaml
Error: UPGRADE FAILED: no ConfigMap with the name "az-test-2-prom-prometheus-grafana-config" found

1. temukan revisi DEPLOYED terakhir

export TEMPLATE='{{range .items}}{{.metadata.name}}{{"\t"}}{{.metadata.labels.STATUS}}{{"\n"}}{{end}}'
kubectl -nkube-system get cm -l 'OWNER=TILLER' -ogo-template="$TEMPLATE"

az-test-2-prom.v1   SUPERSEDED
az-test-2-prom.v10  SUPERSEDED
az-test-2-prom.v11  SUPERSEDED
az-test-2-prom.v12  SUPERSEDED
az-test-2-prom.v13  SUPERSEDED
az-test-2-prom.v14  SUPERSEDED
az-test-2-prom.v15  SUPERSEDED
az-test-2-prom.v16  SUPERSEDED
az-test-2-prom.v17  DEPLOYED
az-test-2-prom.v18  FAILED
az-test-2-prom.v19  FAILED
az-test-2-prom.v2   SUPERSEDED
az-test-2-prom.v20  FAILED
az-test-2-prom.v21  FAILED
az-test-2-prom.v22  FAILED
az-test-2-prom.v23  FAILED
az-test-2-prom.v24  FAILED
az-test-2-prom.v25  FAILED
az-test-2-prom.v26  FAILED
az-test-2-prom.v27  FAILED
az-test-2-prom.v28  FAILED
az-test-2-prom.v29  FAILED
az-test-2-prom.v3   SUPERSEDED
az-test-2-prom.v30  FAILED
az-test-2-prom.v4   SUPERSEDED
az-test-2-prom.v5   FAILED
az-test-2-prom.v6   SUPERSEDED
az-test-2-prom.v7   SUPERSEDED
az-test-2-prom.v8   SUPERSEDED
az-test-2-prom.v9   FAILED



md5-6d9e4edff5e9111525fecb734bfec15a



for ii in {17..30}
> do
>   kubectl -nkube-system delete cm az-test-2-prom.v${ii}
> done



md5-cf6357e67a21fb9f80abb7b78b9e5b8e



kubectl -nkube-system patch cm az-test-2-prom.v16 -p '{"metadata": {"labels": {"STATUS": "DEPLOYED"}}}'

** 4. (Penting) Temukan semua sumber daya yang ada, sumber daya baru yang ditambahkan sejak terakhir digunakan (v16) dan hapus, misalnya
kubectl -nmonitor delete cm az-test-2-prom-prometheus-grafana-config
kubectl -nmonitor delect svc ...

Jalankan helm upgrade ... dan lihat Happy Helming

Seperti yang dikatakan @ kosta709 , kembali ke rilis terakhir yang diterapkan, memperbaiki (secara manual) bagan atau status saat ini (apa pun yang salah) dan melakukan pemutakhiran baru, biasanya berfungsi.

Helm adalah perangkat lunak hebat yang dapat dibuang di beberapa alur kerja otomatis (CI / CD) jika hasil dari sebuah perintah tidak stabil.

Adakah pilihan bahwa solusi yang diketahui akhirnya diimplementasikan untuk (mencoba) menyelesaikan masalah yang terkenal (dan agak mengganggu) ini? Terima kasih.

Jadi, baru-baru ini saya juga sering melakukan ini, cukup untuk membuat saya menangani masalah ini sendiri. Sebagai permulaan, saya telah membuat solusi (
https://github.com/Nopik/helm/commit/afe6451cc2c6295e71ea2213ccce654ec3f5b686) yang pada dasarnya menyebabkan Tiller mendapatkan resource yang ada sebagai titik awal, bukan resource yang diambil dari manifes lama. Bekerja seperti pesona bagi saya, meskipun saya yakin pengembang inti tidak akan ingin menggabungkannya, karena mengandung perilaku hard-code.

Mungkin ada dua bug yang tersembunyi di bawah perilaku yang sama, karena setidaknya sekali ketika bug ini menggigit saya, saya harus menghapus banyak (> 40) sumber daya, termasuk beberapa yang sudah ada untuk> 20 versi rilis yang berhasil. Tetapi dalam 99% kasus, hanya menghapus sumber daya yang baru dibuat (namun tidak diketahui oleh helm) sudah cukup.

Jadi, saya telah memikirkan tentang bagaimana menyelesaikannya dengan cara yang tepat. Saya menjelaskannya di bawah. Pengembang inti tolong perbaiki saya di sini dan timbang jika Anda setuju dengan saya. Jika ya, saya bersedia memimpin upaya ini dan memberikan PR untuk memperbaikinya.

Umumnya helm tampaknya beroperasi dalam mode 'tambalan': jika pengguna memodifikasi sumber daya entah bagaimana, dan versi rilis baru mengubah beberapa parameter lain, helm menghitung tambalan antara 2 revisi dan menerapkannya - Saya yakin bahwa ini mencoba untuk menjaga perubahan pengguna tetap utuh.

Sayangnya hal itu membuat kita memiliki masalah penggabungan 3 arah, karena kita memiliki versi sumber daya yang diambil dari manifes lama, versi lain dari manifes baru, dan versi lain dari sumber daya yang saat ini hidup. Dan helm tampaknya buruk dalam menyelesaikan konflik, ketika konflik itu muncul.

Saya pikir cara yang tepat adalah memilih default yang lebih baik (pada dasarnya menggabungkan cabang saya akan berhasil), atau memberikan tanda untuk pengguna. Misal seperti ini:

• --ignore-old-manifest=never (default, perilaku saat ini)
• --ignore-old-manifest=create-only (berlaku untuk kasus ini, ketika manifes lama tidak memiliki gagasan tentang sumber daya, tetapi sumber daya sudah ada, kita dapat menganggap ini sebagai basis baru dan hanya menambalnya, jika perlu) - Saya akan merekomendasikan ini menjadi baru default. Ini juga akan memungkinkan helm untuk mulai mengambil kepemilikan sumber daya yang dibuat secara manual.
• --ignore-old-manifest=always - hanya demi kelengkapan, mungkin tidak sepenuhnya diperlukan. Itu akan selalu membuat tambalan antara sumber daya saat ini dan manifes terbaru, pada dasarnya menghapus semua modifikasi pengguna.

Tentu saja Anda dapat mengganti nama bendera untuk menggunakan logika terbalik: --use-current-resources=never(currently default)/create-only/always atau semacamnya.

Nantinya, tanda ini dapat diambil dari anotasi sumber daya, seperti:

annotations:
  helm.io/ignore-old-manifest: always

helm mana yang dapat mengenali dan menerapkan strategi ini per sumber daya. Saya tidak yakin apakah helm devs ingin pergi ke sana;)

Jadi, apa pendapat Anda tentang proposal ini?

Lihat juga masalah # 3805 di mana pengembang Helm sedang mempertimbangkan patch penggabungan 3 arah.

Masalah yang sama di sini.
Mencoba menyiapkan lingkungan CD / CI dengan google cloud build.
Error: UPGRADE FAILED: no Deployment with the name "baobab-sidekiq" found

Lucunya, penerapan itu ada:

kc get deployments
NAME             DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
baobab           3         3         3            2           2d
baobab-ermis     1         1         1            1           23h
baobab-sidekiq   1         1         1            1           23h

Ini adalah bagan pertama yang saya buat dan saya mengharapkan helm menjadi solusi untuk menangani kompleksitas penerapan aplikasi kompleks di lingkungan CI / CD.

Apakah niat dari kemudi untuk dapat bekerja dalam pipeline CI / CD?

Terima kasih

Client: &version.Version{SemVer:"v2.9.1", GitCommit:"20adb27c7c5868466912eebdf6664e7390ebe710", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.9.1", GitCommit:"20adb27c7c5868466912eebdf6664e7390ebe710", GitTreeState:"clean"}

Saya juga mengalami hal ini, mencoba mengupgrade helm 0.8.0 menjadi helm 1.0.0.

helm version --tls Client: &version.Version{SemVer:"v2.9.1", GitCommit:"20adb27c7c5868466912eebdf6664e7390ebe710", GitTreeState:"clean"} Server: &version.Version{SemVer:"v2.9.1", GitCommit:"20adb27c7c5868466912eebdf6664e7390ebe710", GitTreeState:"clean"}

Saya telah mengalami ini juga saat meningkatkan persyaratan bagan. Saya melihat bahwa Istio mengalami bug ini juga, dokumen instal mereka menggunakan helm template . Apakah itu solusi untuk masalah ini?

Lihat diskusi terbaru di https://github.com/helm/helm/issues/3805

Memiliki ini juga, masih terjadi untuk helm terbaru 2.10

Sudah waktunya untuk masalah ini dipertimbangkan dengan serius, sudah 2 tahun sekarang dan banyak orang melaporkan masalah yang sama persis yang membuat helm sangat tidak dapat digunakan dalam produksi, dan sangat merepotkan ketika penerapan Anda bergantung pada helm.

Dengan banyaknya bintang GitHub, datanglah tanggung jawab yang besar

@ brendan-rius Anda dipersilakan untuk memberikan kode untuk memperbaiki masalah ini, atau memikirkan ide. Lihat # 3805 dan # 4146 untuk beberapa petunjuk.

@ brendan-rius, # 3805 khususnya memiliki diskusi terbaru seputar bug ini. Saya sangat menyarankan untuk membaca utas itu untuk mendapatkan gambaran tentang apa yang kami hadapi.

Memposting ulang komentar saya di sini karena ini lebih terkait dengan masalah ini daripada strategi penggabungan 3 arah:

Jika penggabungan tiga cara tidak memungkinkan untuk penerapan baru di Helm 2.yz, kapan # 1193 akan diperbaiki? Bug telah terbuka selama hampir dua tahun tanpa resolusi jelas yang direncanakan untuk Helm 2.0.

Pada titik ini, kami bingung bagaimana melanjutkannya. Kami telah membahas bug selama berminggu-minggu dan tidak ada solusi yang diusulkan yang akan berfungsi di semua kasus, baik dengan memperkenalkan bug baru atau mengubah perilaku peningkatan anakan secara signifikan.

Misalnya, @michelleN dan saya melakukan brainstorming awal minggu ini dan memikirkan dua solusi yang mungkin, keduanya tidak terlalu fantastis:

1. Saat pemutakhiran gagal, kami secara otomatis memutar kembali dan menghapus sumber daya yang dibuat selama rilis ini.

Ini sangat berisiko karena kluster mungkin dalam status tidak diketahui setelah peningkatan gagal, jadi Helm mungkin tidak dapat melanjutkan dengan cara yang bersih, berpotensi menyebabkan waktu henti aplikasi.

1. Selama peningkatan, jika kita membuat sumber daya baru dan kita melihat bahwa itu sudah ada, sebagai gantinya kita menerapkan perubahan itu ke sumber daya yang ada, atau menghapus / membuatnya kembali.

Ini sangat berisiko karena Helm dapat menghapus objek yang diinstal melalui paket lain atau melalui kubectl create , yang mungkin tidak diinginkan pengguna.

Opsi teraman sejauh ini adalah meminta pengguna untuk campur tangan secara manual dalam kasus konflik ini, yang akan saya tunjukkan di bawah.

Jika ada yang memiliki saran / umpan balik / proposal alternatif, kami ingin mendengar pendapat Anda.

@bacongobbler , jika tidak ada dukungan untuk fitur penggabungan 3 arah yang direncanakan, kami memerlukan alternatif atau solusi. Jika tidak, # 1193 adalah bocker yang sangat menyakitkan.

Untuk mengulangi masalah serta solusinya:

Ketika pemutakhiran yang menginstal sumber daya baru gagal, rilis masuk ke status GAGAL dan menghentikan proses pemutakhiran. Lain kali Anda memanggil helm upgrade , Helm melakukan diff terhadap rilis DEPLOYED terakhir. Dalam rilis DEPLOYED terakhir, objek ini tidak ada, jadi mencoba membuat sumber daya baru, tetapi gagal karena sudah ada. Pesan kesalahan benar-benar menyesatkan seperti yang ditunjukkan @arturictus .

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/helm/helm/pull/4223#issuecomment -397413568:

><> helm fetch --untar https://github.com/helm/helm/files/2103643/foo-0.1.0.tar.gz
><> helm install ./foo/
...
><> vim foo/templates/service.yaml                    # change the service name from "foo" to "foo-bar"
><> kubectl create -f foo/templates/service.yaml      # create the service
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

Dengan kata lain, menghapus sumber daya yang dibuat selama rilis GAGAL dapat mengatasi masalah tersebut.

@bacongobbler pertama, saya ingin mengucapkan terima kasih telah melihat masalah ini secara lebih rinci selama beberapa minggu terakhir. Saya tidak begitu yakin apa masalahnya dalam peningkatan Istio 0.8.0 ke Istio 1.0.0 yang menyebabkan masalah atau apakah benar-benar cocok dengan pernyataan masalah Anda. Spekulasi saya adalah bahwa sekitar 3 hari sebelum rilis, beberapa objek yang sebelumnya tidak dikelola (yaitu ditambahkan dalam pekerjaan pasca-pemasangan) dimigrasikan agar tidak dipasang pada pekerjaan pasca-pemasangan.

Saat berbicara dengan komunitas operator Istio yang memiliki banyak pengalaman sebelumnya dengan Helm, beberapa operator memberi tahu kami bahwa sumber daya yang tidak terkelola di Helm adalah berita buruk, dan sering kali menyebabkan kegagalan peningkatan. Jika implementasi bagan Istio memiliki cacat yang membuatnya tidak kompatibel dengan pemutakhiran dengan Helm 2.yz, memperbaiki ketidakcocokan tersebut akan sangat bagus - jadi kami tidak akan mengalami kegagalan pemutakhiran di masa mendatang.

Kami bersedia melakukan 1 kali peningkatan dari 0.8.0 ke versi 1.0.0. Jika peningkatan terus-menerus tidak stabil - itu masalah yang berbeda.

Saya menjalankan dua kali lipat pada Istio - karena pemutakhiran bekerja hingga 27 Juli (3 hari sebelum rilis Istio 1.0.0) dan menemukan bahwa komit ini bermasalah: https://github.com/istio/istio/commit/301612af08128b15069d27ff6d03cdb87420e15b

PR ini pada dasarnya menghapus pendaftaran objek dari pekerjaan pasca pemasangan. Saya yakin, tetapi saya tidak yakin, kami telah menghapus semua pekerjaan pasca-pemasangan dalam 3 hari runup ke Istio 1.0.0.

Dapatkah Anda menawarkan saran tentang bagan Helm khusus Istio yang berkaitan dengan peningkatan? Akankah menjauhkan pendaftaran objek dari pekerjaan pemasangan pasca menyelesaikan masalah peningkatan kami secara permanen?

Saya tidak dapat benar-benar menawarkan saran atau proposal yang kuat untuk memperbaiki masalah ini secara menyeluruh karena orang-orang dengan pengalaman yang lebih baru dengan Helm tidak dapat menemukan solusi umum (dan bukan karena kurangnya melihat masalah). Saya tidak berpikir saya bisa berbuat lebih baik.

Bersulang
-steve

Memperbarui judul agar lebih mencerminkan kesalahan.

Kami juga terpengaruh oleh masalah tersebut. Kami menggunakan helm terbaru 2.10 dengan GKE 10.6.
Kapan saya bisa berharap itu akan diperbaiki?
Apakah kami memiliki solusi yang masuk akal untuk masalah ini? Menghapus seluruh penerapan dengan opsi --purge sangat buruk.

Silahkan mempertimbangkan komentar terakhir saya. Kami sangat membutuhkan umpan balik tentang cara terbaik untuk melanjutkan di sini.

Solusi telah diulang beberapa kali di utas ini. Harap baca https://github.com/helm/helm/issues/1193#issuecomment -419555433.

Saya suka ide fitur helm auto-rollback ( opsi 1 ) untuk mengatasi masalah ini. Kami tahu bahwa rilis DEPLOYED Helm terakhir berfungsi dan kluster dalam keadaan baik sehingga seharusnya aman untuk kembali ke sana. Jika berisiko untuk beberapa kasus penggunaan, itu bisa diikutsertakan melalui peningkatan flag to helm.

Ini sangat berisiko karena kluster mungkin dalam status tidak diketahui setelah peningkatan gagal, jadi Helm mungkin tidak dapat melanjutkan dengan cara yang bersih, berpotensi menyebabkan waktu henti aplikasi.

Menurut saya banyak pengguna helm yang menggunakan helm secara otomatis melalui CD atau CM tool dan lebih beresiko membiarkan helm lepas dalam keadaan GAGAL. Sumber daya yang tidak lengkap tersebut dalam rilis yang gagal dapat memengaruhi sumber daya lain secara tidak terduga dan dapat menyebabkan downtime sendiri. Misalnya, jika spesifikasi pod berisi versi gambar yang hilang yang entah bagaimana berhasil mencapai produksi, maka beban kerja Anda akan berada dalam status ImagePullBackOff yang tidak berfungsi. Untuk perusahaan kami, ini bahkan lebih buruk karena kami memiliki beberapa pelanggan lokal yang dapat meningkatkan diri mereka sendiri melalui UI kami dan jika gagal, kami harus mendapatkan akses ke sistem mereka untuk melakukan debug.

Meskipun mengabaikan fakta bahwa ini dapat memperbaiki masalah ini, rollback otomatis akan menjadi fitur yang berguna dan akan membantu memastikan rilis Helm lebih bersifat transaksional. Ini membedakan Helm dari penerapan upaya terbaik hingga memprioritaskan stabilitas dan penerapan yang berhasil.

@bacongobbler akankah pendekatan berikut dapat digunakan untuk penerapan baru :

• Tambahkan bendera - -three-way-merge
• Hanya izinkan bendera itu digunakan dalam helm install (penerapan baru)
• Setelah tanda ini diaktifkan, peningkatan versi akan selalu menggunakan penggabungan 3 arah
• Penerapan yang ada akan terhenti tanpa jalur migrasi - solusi standar yang tampaknya digunakan orang-orang saat ini adalah helm delete --purge diikuti oleh helm reinstall jadi ini mungkin tidak sesulit yang pertama kali muncul.

Apakah ini benar-benar menyelesaikan masalah?

Beberapa individu sedang mempertimbangkan penerapan Operator untuk mengatasi batasan Helm ini. Itu akan sangat memalukan. Lihat https://github.com/istio/istio/issues/8841#issue -361871147

Bersulang
-steve

Kembali ke komentar sebelumnya @bacongobbler :

1. Selama peningkatan, jika kita membuat sumber daya baru dan kita melihat bahwa itu sudah ada, sebagai gantinya kita menerapkan perubahan itu ke sumber daya yang ada, atau menghapus / membuatnya kembali.
   Ini sangat berisiko karena Helm mungkin menghapus objek yang diinstal melalui paket lain atau melalui kubectl create, yang mungkin tidak diinginkan oleh pengguna.

Saya ingin tahu apakah kita dapat mengurangi risiko ini dengan membuat perilaku baru ikut serta? Dalam namespace tertentu saya biasanya menggunakan helm secara eksklusif, dan saya curiga ini adalah kasus bagi banyak orang. Jika saya dapat memberi Helm install / upgrade sebuah flag untuk memberitahukannya bahwa apa pun di namespace yang diberikan yang bukan bagian dari rilis yang ada boleh dihapus / ditimpa, apakah itu membantu?

Karena Anda juga mengatakan "melalui paket lain", saya anggap Anda tidak ingin Helm harus memeriksa rilis lain sebagai bagian dari melakukan rilis, jadi saran saya tidak akan berfungsi kecuali dalam model single-release-per-namespace. Untuk menjawab keberatan itu, saya akan mengatakan: jika Anda ingin mengelola beberapa paket dalam namespace dan masih mendapatkan perilaku ini, buat bagan payung yang tujuan utamanya adalah menentukan dependensi bagan yang Anda inginkan. Kemudian gunakan bendera baru ("--exclusive"?) Saat menerapkan bagan payung itu.

Jelas ini tidak menyelesaikan masalah untuk semua kasus penggunaan, tetapi mungkin itu solusi yang cukup.

@bacongobbler Saya bisa jauh dari sini. Saya menghadapi masalah serupa dalam peningkatan. Menilai dari betapa sulitnya memecahkan masalah ini, saya bertanya-tanya apakah sesuatu yang lebih mendasar perlu dipertimbangkan kembali. Bagian dari kerumitan tampaknya disebabkan oleh fakta bahwa Helm mempertahankan versinya sendiri dari konfigurasi yang diketahui, terpisah dari source-of-truth yang sebenarnya yaitu kubernetes. Akankah sistem lebih dapat diandalkan jika Helm hanya menyimpan salinan diagram helm yang digunakan sebelumnya untuk tujuan sejarah dan rollback, tetapi tidak menggunakannya sama sekali selama peningkatan. Sebaliknya, Helm akan mendapatkan kebenaran dari kubectl itu sendiri, dan kemudian selalu memiliki perbedaan 2 arah untuk dilakukan?

Jika diagram helm mengatakan ia harus memiliki sumber daya X, dan kubectl melihat sumber daya X yang ada, maka:

• Jika sumber daya yang ada ditandai sebagai dikendalikan oleh Helm, Helm melakukan peningkatan yang diperlukan
• Jika sumber daya yang ada tidak ditandai sebagai dikendalikan oleh Helm, Helm akan gagal dengan pesan kesalahan yang bersih (atau beberapa tanda baris perintah dapat digunakan untuk --memaksa peningkatan dan menyebabkan Helm mengambil kepemilikan atas Sumber Daya X yang ada).

Jika bagan helm mengatakan ia harus memiliki sumber daya X dan tidak ada satu pun menurut kubectl, maka Helm membuatnya.

Jika kubectl melaporkan bahwa ia memiliki sumber daya bertanda Y yang dikendalikan oleh bagan helm ini, dan tidak ada sumber daya Y dalam bagan kemudi ini, helm akan menghapus sumber daya tersebut.

Sumber daya apa pun yang tidak ditandai sebagai dikendalikan oleh bagan helm ini selalu diabaikan oleh helm saat melakukan peningkatan, kecuali dalam kasus yang disebutkan di atas di mana bagan helm mengatakan bahwa ia membutuhkan sumber daya X dan X tetapi tidak diberi tag.

Jika karena alasan tertentu peluncuran bagan helm terjadi dan gagal, dan hanya setengah sumber daya yang diluncurkan, maka selama rollback helm akan menggunakan file konfigurasi yang disimpan dari penerapan sukses sebelumnya dan menjalankan algoritme yang sama persis, atau hal-hal lainnya. bisa dibiarkan dalam keadaan rusak relatif terhadap beberapa bendera baris perintah helm. Jika pengguna mencoba untuk meningkatkan lagi, karena kubernetes digunakan sebagai sumber kebenaran dan bukan penyebaran sukses yang terakhir diketahui, itu masih harus menjadi perbedaan 2-arah sederhana antara bagan helm baru dan keadaan sistem yang ada.

Kami juga melihat masalah ini. Langkah mereproduksi kami:

1. helm install bagan yang berhasil menginstal penerapan
2. Perbarui diagram untuk menyertakan sumber daya kustom selain penerapan yang sudah ada
3. Ubah gambar podspec penerapan untuk meniru kegagalan penerapan
4. helm install bagan baru. Ini akan menyebabkan pembaruan berkelanjutan dari penerapan, yang sengaja kami siapkan gagal.
5. Pemasangan helm seharusnya gagal. Tetapi sumber daya kustom harus dibiarkan di k8s etcd. (verifikasi menggunakan kubectl )
6. (Saat ini, helm dalam kondisi buruk)
7. Perbaiki diagram - letakkan gambar goot di podspec penerapan.
8. helm install . Kami berharap ini berhasil, tetapi ternyata tidak. Melaporkan "Tidak ada sumber daya dengan nama ___". Namanya adalah resource kustom.
9. Pemulihan: hapus sumber daya kustom sisa menggunakan kubectl . Sekarang helm install akan bekerja.

Perhatikan bahwa percobaan pertama pada helm install dengan sumber daya ubahsuaian yang baru diperkenalkan di bagan harus gagal masuk ke status ini.

@ rbair23 kami mencobanya sebelumnya dan tidak berhasil. Ada Kelompok Kerja Apply yang berusaha memperbaiki keadaan manajemen objek deklaratif dengan memperbaiki kubectl apply, memindahkan logika dari klien ke server , tetapi itu masih dalam tahap awal. Kubectl (dan tiller) keduanya perlu menyimpan salinan dari konfigurasi yang terakhir diterapkan untuk melakukan diff. Anda tidak dapat melakukan diff terhadap status live cluster tanpa melakukan strategi merge patch tiga arah, memutar kembali ke tiket ini.

Karena # 3275 ditutup sebagai duplikat dari itu: kami memiliki situasi yang sama seperti di # 3275

Sudah ada pekerjaan berjalan my-long-running-job . Und kami mencoba untuk mengupgrade rilis:

>helm upgrade --install my-release --namespace my-environment my-chart --timeout 60
Error: UPGRADE FAILED: no Job with the name "my-long-running-job" found

Pekerjaan itu ada:

>kubectl -n=my-environment get jobs
NAME                                DESIRED   SUCCESSFUL   AGE
my-long-running-job                 1         0            16m

Menghapus pekerjaan itu:

>kubectl -n=my-environment delete job my-long-running-job
job.batch "my-long-running-job" deleted

Mengatasi hambatan itu:

>helm upgrade --install my-release --namespace my-environment my-chart --timeout 60
Error: UPGRADE FAILED: timed out waiting for the condition

Setidaknya pesan no Job with the name "my-long-running-job" found menyesatkan, tetapi harapan saya adalah, bahwa pekerjaan itu akan diperbarui juga.

Masih melihat ini di v2.9.1 (versi stabil yang dirilis saat ini)

Saya tidak setuju bahwa "sangat berbahaya" untuk mundur dari peningkatan. Saya pikir melakukan itu adalah solusi yang tepat.

Kubernetes bersifat deklaratif. Jepret apa status cluster sebelum mencoba mengupgrade.
Jika ada kesalahan di tengah jalan, putar kembali ke snapshot.
Jika seseorang memiliki kait skrip yang akan membuat cluster dalam keadaan buruk saat melakukan ini, maka itu adalah kesalahan mereka sendiri. (Mungkin itu juga bisa diatasi dengan kait putar balik)

Tentu saja, akan lebih bagus jika peningkatan dilakukan terlebih dahulu dan tidak mengajukan sebanyak mungkin.
Kesalahan dalam bagan ketergantungan yang dihasilkan oleh nilai atau argumen --set harus dapat diperiksa sebelum mencoba mengubah apa pun, misalnya. Hal-hal seperti lupa menabrak nomor versi juga bisa dilakukan sebelumnya untuk menghindari membuat perubahan saat tidak berfungsi.

Hai,

Memiliki masalah yang sama dengan:

Klien: v2.10.0 + g9ad53aa
Server: v2.10.0 + g9ad53aa

Menghapus serviceAccount, configMap, dan layanan adalah satu-satunya cara untuk membuat Helm mengupgrade rilis.

Hai,

kami memiliki masalah yang sama seperti yang dijelaskan @dilumr ... dengan versi 2.11.0:

Client: &version.Version{SemVer:"v2.11.0", GitCommit:"2e55dbe1fdb5fdb96b75ff144a339489417b146b", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.11.0", GitCommit:"2e55dbe1fdb5fdb96b75ff144a339489417b146b", GitTreeState:"clean"}

Error: UPGRADE FAILED: no ConfigMap with the name "xxx" found

Berlari ke ini di v2.9.1.

Pembaruan bagan yang saya jalankan melompati beberapa versi utama pada bagan pribadi dengan banyak perubahan jadi saya tidak yakin apa sebenarnya yang memicu kesalahan ke depannya, tetapi alasan penerapan awalnya berakhir di negara bagian FAILED adalah bahwa saya memiliki bendera --wait dan waktunya habis.

Kami mendapatkan beberapa penerapan duplikat FAILED di helm list tetapi penerapan terakhir yang berhasil adalah DEPLOYED . Membuat penerapan baru menghasilkan No resource with the name x found .

Dapat diperbaiki dengan menjalankan helm rollback ke versi terakhir yang ada di status DEPLOYED pada helm list . Setelah itu upgrade bisa berjalan tanpa error.

Lihat ini https://github.com/helm/helm/pull/4871.

Seperti orang lain dari kelihatannya, kesalahan ini tampaknya paling sering terjadi (saya tidak yakin tentang selalu) bagi saya ketika penerapan terakhir saya gagal, dan aset baru dari penerapan itu dibiarkan terpasang.

Saya memahami bagaimana mungkin rumit dan / atau tidak diinginkan untuk menghapus komponen dari penerapan Helm yang gagal, tetapi bagaimana perilaku Helm yang ideal untuk situasi semacam ini?

Pertama, saya pikir Helm seharusnya baik-baik saja dengan ruang nama dan sumber daya lain yang sudah ada jika mencoba menginstal (ulang) mereka. Kubernetes adalah tentang "membuat konfigurasi yang benar, dan biarkan kube mencari cara untuk membuat dunia cocok dengan konfigurasi".
Kedua, saya pikir Helm harus semuanya-atau-tidak sama sekali. Jika penyebaran gagal, cluster harus dalam keadaan sebelum penyebaran dimulai.
Jika ada dua rilis yang sama-sama ingin membuat namespace X, maka ada masalah penghitungan referensi. Jika ada rilis yang ingin membuat namespace X, tetapi sudah ada, maka ada masalah asalnya. Namun, helm dapat merekam ini dengan menggunakan anotasi pada objek, dan melakukan hal yang benar.

Saya mengalami masalah ini juga dengan helm terbaru 2.12.0 dan kubernetes 1.10.11, bahkan memutar kembali ke rilis bagus terbaru seperti yang disarankan @aguilarm tidak berfungsi, juga menghapus sumber daya yang dikeluhkan helm tidak membantu, dan setelah peningkatan perintah gagal itu meninggalkan sumber daya yang sama seperti yang sebenarnya dibuat ulang sebagian. Sangat menjengkelkan untuk ...

Saya memiliki 2 cluster dengan lingkungan yang sangat mirip, perbedaan utama antara 2 adalah jumlah total node. Dalam satu kasus, helm delete --purge diikuti oleh helm install tetapi di kasus lain tidak berhasil dan saya belum menemukan cara untuk mengubahnya ke perubahan template terbaru.

Apakah ada ETA untuk ini?

Saya dapat menyelesaikannya dengan helm rollback dan menentukan revisi terbaru (yang gagal)

Memiliki masalah yang sama hari ini,
Error: UPGRADE FAILED: no Service with the name "xxx-api" found
kubectl get svc -n stage | grep xxx-api
xxx-api ClusterIP 172.20.149.229 <none> 8300/TCP 19h
helm rollback bekerja.

Kami mengalami ini secara cukup teratur saat melakukan peningkatan helm - ini terjadi setelah penerapan yang berhasil, bukan hanya penerapan yang gagal. Kami tidak dapat menghapus helm --purge karena ini adalah sistem produksi dengan komponen non-sepele yang 1) tidak dapat tersedia dan 2) akan membutuhkan waktu terlalu lama untuk pulih sepenuhnya dari awal agar dapat diterima.

Lihat diagnosis dan solusi yang saya posting di atas. Beri tahu saya jika itu berhasil untuk Anda.

@bacongobbler Terima kasih atas tanggapannya. Itu sebenarnya solusi yang saya dapatkan juga dan itu harus cukup untuk saat ini, tetapi kami menggunakan peningkatan helm lusinan kali sehari melalui CICD kami sehingga ini cukup sering muncul untuk menjadi sakit kepala. Saya tidak yakin di atas adalah keseluruhan cerita meskipun karena sumber daya yang disebutkan sering kali sudah ada, bagian dari penerapan yang berhasil dan tidak diubah dalam penerapan saat ini - iirc hampir selalu merupakan kumpulan sumber daya terbaru dalam penerapan terakhir yang berhasil meski cukup menarik.

+1 ke @ajcann dan terima kasih @bacongobbler
Saya berada dalam situasi yang sama persis.
CICD kami otomatis dan sering kali penerapan dilakukan oleh bot kendur untuk lingkungan yang lebih rendah.
Jika gagal, saya harus melakukan helm rollback dan menerapkan lagi secara manual.
Masalahnya tidak konsisten sama sekali tetapi sering terjadi.
Bagi saya, itu hanya terjadi selama penerapan kedua bagan / sumber daya sejauh ini.
Sumber daya selalu ada.

kami mengamati masalah yang sama. Ini terjadi jika Anda memiliki template, yaitu:

• dalam pernyataan {{if $condition -}}
• atau dalam {{ range $index, $value := $array-}}

@jkroepke baru saja menunjukkan kepada saya bahwa PR # 5143 memberikan solusi yang baik untuk ini. Ketika flag --atomic dirilis di versi minor berikutnya, Anda harus dapat menggunakannya untuk membersihkan atau mengembalikan secara otomatis ketika ada kesalahan.

@bacongobbler mengingat Anda telah terlibat dengan sebagian besar bolak-balik yang satu ini, adakah hal lain yang dapat dilakukan untuk memperbaiki ini sepenuhnya, atau apakah bendera --atomic sudah cukup?

Saya pikir @distorhead mungkin ingin melihat yang satu itu dan melihat apakah itu juga menyelesaikan kekhawatirannya yang dia sampaikan di https://github.com/helm/helm/pull/4871. Selain itu, sepertinya --atomic harus mengatasi masalah dengan asumsi Anda selalu menggunakan tanda --atomic .

Saya tidak percaya ada solusi yang diusulkan untuk mengatasi masalah saat Anda masuk ke negara bagian ini, tetapi saya bisa saja salah. Jika strategi mitigasi untuk masalah ini

• secara manual melalui status live cluster dan perbaiki sesuai solusi
• tingkatkan ke Helm 2.13.0 dan gunakan helm upgrade --atomic untuk seterusnya

Maka saya pikir ini aman untuk ditutup.

Mudah-mudahan Helm 2.13.0 tidak terlalu jauh.
Bug ini merusak CI jika kesalahan terjadi di suatu tempat pada rilis.

Atomic tidak akan menyelesaikan masalah

Contoh bagan: https://github.com/distorhead/ex-helm-upgrade-failure

1. Lihat master, jalankan penerapan.

git clone https://github.com/distorhead/ex-helm-upgrade-failure
cd ex-helm-upgrade-failure
helm upgrade --atomic --install --namespace myns myrelease .

Bagan berisi 2 penerapan - myserver1 dan myserver2 :

Release "myrelease" does not exist. Installing it now.
NAME:   myrelease
LAST DEPLOYED: Tue Feb  5 23:48:57 2019
NAMESPACE: myns
STATUS: DEPLOYED

RESOURCES:
==> v1beta1/Deployment
NAME       READY  UP-TO-DATE  AVAILABLE  AGE
myserver1  1/1    1           1          5s
myserver2  1/1    1           1          5s

1. Buatlah perubahan besar. Hapus penerapan myserver1 dari bagan dan ubah penerapan myserver2 dengan kesalahan pengguna (hapus bidang gambar misalnya):

git checkout break-atomic
git diff master

diff --git a/templates/deploy.yaml b/templates/deploy.yaml
index 198516e..64be153 100644
--- a/templates/deploy.yaml
+++ b/templates/deploy.yaml
@@ -1,21 +1,5 @@
 apiVersion: apps/v1beta1
 kind: Deployment
-metadata:
-  name: myserver1
-spec:
-  replicas: 1
-  template:
-    metadata:
-      labels:
-        service: myserver1
-    spec:
-      containers:
-      - name: main
-        command: ["/bin/bash", "-c", "while true ; do date ; sleep 1 ; done"]
-        image: ubuntu:16.04
----
-apiVersion: apps/v1beta1
-kind: Deployment
 metadata:
   name: myserver2
 spec:
@@ -28,4 +12,3 @@ spec:
       containers:
       - name: main
         command: ["/bin/bash", "-c", "while true ; do date ; sleep 1 ; done"]
-        image: ubuntu:16.04

1. Jalankan penerapan:

git checkout break-atomic
helm upgrade --atomic --install --namespace myns myrelease .

Sapa teman kita lagi:

UPGRADE FAILED
ROLLING BACK
Error: Deployment.apps "myserver2" is invalid: spec.template.spec.containers[0].image: Required value
Error: no Deployment with the name "myserver1" found

@bacongobbler @ thomastaylor312 @jkroepke

@distorhead apa perilaku yang Anda harapkan untuk skenario ini?

Sedikit offtop tentang rollback, tapi bagaimanapun juga.

Bagi orang-orang, yang ingin menggunakan rollback, tetapi juga tidak ingin rollback terjadi segera setelah penerapan seperti pada --atomic karena beberapa alasan. Karena, misalnya, tidak ada cara bagi pengguna untuk secara manual memeriksa status klaster yang buruk setelah kegagalan dan karena --wait flag tidak menyebabkan helm mencatat informasi apa pun tentang kegagalan dalam sumber daya yang sedang diterapkan. Lalu ada beberapa cara: rollback saat menjalankan berikutnya, sebelum meningkatkan (info selengkapnya https://github.com/helm/helm/issues/3149#issuecomment-462271103)

Untuk mengulangi masalah serta solusinya:

Ketika pemutakhiran yang menginstal sumber daya baru gagal, rilis masuk ke status GAGAL dan menghentikan proses pemutakhiran. Lain kali Anda memanggil helm upgrade , Helm melakukan diff terhadap rilis DEPLOYED terakhir. Dalam rilis DEPLOYED terakhir, objek ini tidak ada, jadi mencoba membuat sumber daya baru, tetapi gagal karena sudah ada. Pesan kesalahan benar-benar menyesatkan seperti yang ditunjukkan @arturictus .

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 # 4223 (komentar) :

><> helm fetch --untar https://github.com/helm/helm/files/2103643/foo-0.1.0.tar.gz
><> helm install ./foo/
...
><> vim foo/templates/service.yaml                    # change the service name from "foo" to "foo-bar"
><> kubectl create -f foo/templates/service.yaml      # create the service
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

Dengan kata lain, menghapus sumber daya yang dibuat selama rilis GAGAL dapat mengatasi masalah tersebut.

Terima kasih telah menyelesaikan masalah ini bersama temukan sebagai sebuah proses juga. Satu masalah yang menyakitkan di sini adalah selama peningkatan yang kompleks, banyak sumber daya baru - kadang-kadang beberapa tingkat ketergantungan yang dalam - mungkin menemukan diri mereka dalam keadaan ini. Saya belum menemukan cara untuk sepenuhnya menghitung status ini secara otomatis yang mengarah ke situasi di mana seseorang harus berulang kali gagal meningkatkan versi untuk "mencari" semua sumber daya yang relevan. Misalnya, baru-baru ini ketergantungan yang baru ditambahkan itu sendiri memiliki ketergantungan pada bagan postgresql. Untuk mengatasi masalah ini, perlu untuk menghapus rahasia, configmap, layanan, penyebaran dan pvc - masing-masing menemukan jalan pintas.

Anda dapat menulis sebuah plugin yang mirip dengan helm diff yang akan menghitung template yang dibuat pada rilis terakhir. Anda bahkan dapat menggunakan pkg/kube langsung dari Helm. client.Update memiliki beberapa logika bisnis yang ditulis untuk pelacakan / penghapusan sumber daya helm yang dapat digunakan kembali dengan mengambil dua rilis dari Tiller dan membalik urutan perbandingan. target.Difference(original) akan memberikan hasil dari semua sumber daya yang diperkenalkan sejak rilis sebelumnya.

@bacongobbler Solusi apa yang akan Anda rekomendasikan untuk mengambil aplikasi yang diterapkan sebagai bagian dari rilis A (misalnya rilis yang lebih besar yang terdiri dari beberapa aplikasi) dan memecahnya dari rilis A menjadi rilisnya sendiri (atau sebaliknya) tanpa menimbulkan waktu henti (solusi untuk menghapus sumber daya akan menyebabkan beberapa waktu henti) ... Mencoba memperbarui sumber daya melalui rilis yang berbeda menghasilkan kesalahan yang dijelaskan oleh masalah Github ini.

Sepertinya bagan baru ini telah dipasang dan menggantikan bagan lama bahkan sebelum penerapan yang berhasil. Hal yang sama dengan upgrade yang gagal --install. Itu tidak bisa dipasang jika grafiknya salah.
Cukup kembalikan ke keadaan sebelumnya pada kesalahan atau perbarui grafik anakan pada kesuksesan.

Ini adalah proses yang saya gunakan untuk memulihkan masalah ini (sejauh ini telah berhasil setiap saat tanpa insiden apa pun ... tapi tetap berhati-hati):

1. Jalankan helm list dan temukan revisi terbaru untuk bagan yang terpengaruh

   NAME        REVISION UPDATED                  STATUS  CHART              NAMESPACE
   fetlife-web 381      Thu Mar 15 19:46:00 2018 FAILED  fetlife-web-0.1.0  default
   

2. Pergi dari sana dan temukan revisi terbaru dengan DEPLOYED state
   kubectl -n kube-system edit cm fetlife-web.v381 kubectl -n kube-system edit cm fetlife-web.v380 kubectl -n kube-system edit cm fetlife-web.v379 kubectl -n kube-system edit cm fetlife-web.v378
3. Setelah Anda menemukan revisi DEPLOYED terakhir, ubah statusnya dari DEPLOYED menjadi SUPERSEDED dan simpan file
4. Coba lakukan helm upgrade lagi, jika berhasil maka Anda sudah selesai!
5. Jika Anda mengalami kesalahan peningkatan seperti ini:
   Error: UPGRADE FAILED: "fetlife-web" has no deployed releases
   kemudian edit status untuk revisi terakhir dari FAILED menjadi DEPLOYED
kubectl -n kube-system edit cm fetlife-web.v381
6. Coba lakukan helm upgrade lagi, jika gagal lagi balik saja tabelnya ...

@bacongobbler @michelleN
Adakah yang membuatnya sulit untuk memperbaiki pesan kesalahan untuk masalah ini?

Saya percaya pesan kesalahan harus menyatakan bahwa "ada konflik karena sumber daya tidak dibuat oleh helm dan diperlukan intervensi manual" dan tidak "tidak ditemukan". Hanya perubahan kecil pada kesalahan ini yang akan meningkatkan pengalaman pengguna dengan selisih yang bagus.

@selslack Saya akan sangat mendukung peningkatan pesan kesalahan 👍

@michelleN Saya telah menyiapkan PR untuk mengubah teks kesalahan: # 5460.

Saya mengalami masalah ini dan saya berada dalam situasi di mana saya tidak yakin bagaimana cara mengatasinya.

Saya mencoba semua langkah yang terdaftar oleh @reneklacan di sini: https://github.com/helm/helm/issues/1193#issuecomment -470208910

Sayangnya itu tidak berhasil. Satu-satunya hal yang menyelesaikan masalah adalah menghapus sumber daya yang menghasilkan pesan kesalahan, lalu helm upgrade lagi, yang akan berhasil.

Namun, peningkatan helm berikutnya akan gagal dengan kesalahan yang sama, dan saya harus menghapus sumber daya lagi dan memperbarui ... ini tidak berkelanjutan atau bagus.

Saya memiliki dua lingkungan tempat saya menggunakan helm sebagai bagian dari proses CI kami: QA dan lingkungan produksi.

Lingkungan QA memiliki masalah yang sama jadi saya menggunakan helm delete --purge , dan kemudian helm upgrade - yang menyelesaikan masalah secara permanen.

Namun saya tidak bisa melakukan ini untuk lingkungan produksi - saya tidak bisa begitu saja menghapusnya dan mengupgrade ulang, jadi saat ini saya terjebak menghapus sumber daya sebelum setiap penerapan. Saya hanya beruntung itu bukan sumber impor.

@zacharyw kesalahan apa yang Anda hadapi saat ini? No resource with the name ... atau "fetlife-web" has no deployed releases ?

Dapatkah Anda membagikan info tambahan yang akan membantu debugging ini?

Mungkin keluaran kubectl -n kube-system describe cm -l NAME=YOUR_RELEASE_NAME | grep -A1 STATUS= (ganti YOUR_RELEASE_NAME )

Jangan ragu untuk mengirimi saya email dengan info lebih lanjut jika Anda tidak ingin mengirim spam ke masalah ini dengan data yang mungkin tidak terkait (rene (at) klacan (dot) sk).

Silakan lihat https://github.com/helm/helm/issues/1193#issuecomment -419555433 untuk kemungkinan diagnosis dan solusi, @zacharyw.

@reneklacan Ini adalah kesalahan no resource with the name ... . Dalam kasus kami, kami menambahkan masuknya, tampaknya berfungsi, tetapi kemudian peningkatan berikutnya mulai gagal dengan kesalahan ini ... meskipun masuknya sudah ada.

Status rilis terbaru saya (setelah menghapus ingress yang melanggar dan mengizinkan peningkatan helm untuk membuatnya kembali) adalah DEPLOYED :

STATUS=DEPLOYED
VERSION=197

Namun, jika saya mencoba meningkatkan lagi, itu akan gagal.

@bacongobbler Kecuali jika saya salah paham, saya rasa saya sudah melakukan pemecahan masalah dalam komentar itu: Saya menghapus sumber daya dan membiarkannya dibuat ulang ... masalahnya adalah saya harus melakukan ini setiap waktu.

@reneklacan di https://github.com/helm/helm/issues/1193#issuecomment -470208910 menyelamatkan hidup saya.

Sangat mengecewakan Helm gagal dengan cara ini. Menghapus sesuatu di hampir semua lingkungan jauh dari ideal.

Akan sangat bagus jika helm memperbarui basis datanya sendiri ketika kesalahan semacam ini muncul, dan kemudian coba lagi.

Saya yakin bahwa dengan flag --cleanup-on-fail diaktifkan, kasus kesalahan ini akan hilang. Penutupan diselesaikan melalui # 4871 dan # 5143.

Jika ada masalah lebih lanjut yang muncul tanpa tanda tersebut, buka kembali masalah baru. Terima kasih!

Masalah ditutup, oleh saya berpikir untuk menambahkan komentar tentang cara menangani masalah tanpa harus menghapus rilis helm atau penerapan yang sedang berjalan.

Jadi, saya mereproduksi masalah tersebut dengan langkah-langkah berikut:

1. Instal grafik test-chart-failure dengan template layanan.
2. Tambahkan subchart dengan template layanan yang memiliki string (misalnya "test") di port layanan
3. Tingkatkan grafik. Ini akan gagal dengan kesalahan Service in version "v1" cannot be handled as a Service: v1.Service.Spec: v1.ServiceSpec.Ports: []v1.ServicePort: v1.ServicePort.Port: readUint32: unexpected character: ...

Saya dapat meningkatkan setelah mengoreksi port ke nomor, tanpa menjalankan helm delete , dengan menerapkan saran di http://centosquestions.com/helm-how-to-delete-bad-deployment :

1. Menemukan revisi yang gagal dengan helm history test-chart-failure
2. Menghapus peta konfigurasi dari revisi tertentu dengan kubectl delete cm -n kube-system test-chart-failure.v2
3. Mengeksekusi helm upgrade dengan grafik yang dikoreksi