Dapatkah Anda memberikan serangkaian langkah untuk mereproduksi masalah tersebut?

@bacongobbler Mohon maaf atas keterlambatannya. Menyadari lebih sulit untuk mereproduksi secara lokal dengan minikube karena kami telah menyiapkan semuanya untuk / dengan AWS EKS. Saat ini saya dapat mengonfirmasi apiVersion dari serviceMonitor tidak berubah sehingga sepertinya tidak ada hubungannya dengan # 6583 .

Saat saya menjalankan template helm pertama kali:

# Source: k8s-service/templates/servicemonitor.yaml
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: bid-management
  namespace: dcd
  labels:
    chart: k8s-service-v0.0.11
    app: bid-management
    heritage: "Helm"
    release: prometheus
spec:
  endpoints:
      - honorLabels: true
        interval: 10s
        path: /prometheus
        port: metrics
        scheme: http
        scrapeTimeout: 10s
  selector:
    matchLabels:
      app.kubernetes.io/name: bid-management

Setelah memutakhirkan dan setelah sumber daya berhasil dibuat, saya menjalankan template helm lagi dan mendapatkan kembali yang berikut di bawah ini:

# Source: k8s-service/templates/servicemonitor.yaml
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: bid-management
  namespace: dcd
  labels:
    chart: k8s-service-v0.0.11
    app: bid-management
    heritage: "Helm"
    release: prometheus
spec:
  endpoints:
      - honorLabels: true
        interval: 10s
        path: /prometheus
        port: metrics
        scheme: http
        scrapeTimeout: 10s
  selector:
    matchLabels:
      app.kubernetes.io/name: bid-management

Setelah menjalankan pemutakhiran helm untuk kedua kalinya, saya mendapatkan kembali kesalahan yang disebutkan di atas

Error: UPGRADE FAILED: rendered manifests contain a new resource that already exists. Unable to continue with update: existing resource conflict: kind: ServiceMonitor, namespace: dcd, name: bid-management

@bacongobbler Akan tetap mencoba dan membuat ulang langkah-langkah secara lokal dengan minikube tetapi mungkin membutuhkan waktu lebih lama dari yang diharapkan.

Menghadapi masalah yang sama di sini. @bacongobbler , @ efernandes-ANDigital
versi kubectl: 1.14.7
kubernetes versi 1.15 (PKS)
Pertama kali terjadi pada saya menggunakan Helm v3.0.0-rc.1, setelah memperbarui ke Helm v3.0.0-rc.2 hal ini masih terjadi.
Berhasil melakukan rollback ke status sebelumnya dengan rc.2 dan mengupgrade lagi tetapi tidak menyelesaikannya: setelah upgrade berhasil, mencoba upgrade baru memberikan pesan kesalahan yang sama.
helm diff tidak menunjukkan masalah (mendeteksi sumber daya dengan benar), dan bahkan jika saya melihat ke dalam rahasia yang terkait dengan revisi, itu menunjukkan sumber daya di sana, jadi seharusnya tidak mencoba menerapkannya kembali.
Bukan bagan yang rumit, hanya menggunakan rentang untuk mengulang daftar (~ 100 elemen) untuk menghasilkan beberapa sumber daya (ruang nama, peta konfigurasi, dll.)

Tidak dapat melakukan repro (dicoba di GKE)

@aespejel Sumber daya kind s apa yang gagal?

Namespaces, yang masuk akal mengingat ordo helm mencoba menerapkan manifes, bukan @ thomastaylor312 ?

Ya, Namespaces duluan, tetapi saya hanya memeriksa apakah ini terjadi dengan jenis sumber daya tertentu atau dengan bermacam-macam

Hanya untuk menambahkan, kami melihat sesuatu yang lain, setelah menonaktifkan monitor layanan. Saat menjalankan upgrade helm, ia mengembalikan pesan sukses "Release" bid-mangement "telah diupgrade. Selamat Membantu! Dll. Namun setelah memeriksa servicemonitor api-resources kita masih melihat servicemonitor yang telah dibuat.

Apa yang baru saja kami perhatikan adalah untuk bagan yang sama dengan layanan lain, ini berfungsi dengan baik dan kami tidak memiliki masalah. Layanan menggunakan bagan yang persis sama dengan hanya beberapa perubahan konfigurasi untuk layanan .... sangat aneh

Masalah juga terjadi saat mencoba memasang bagan (mis. Prometheus-operator), jika pemasangan gagal dan Anda mencoba memasangnya lagi, helm mengeluh tentang konflik sumber daya, dan jika Anda mencoba menghapus bagan, mengeluh mengatakan itu tidak pernah diterapkan .

@vakaobr Saya ragu itu masalah yang sama. Ketika penginstalan pertama gagal (dan hanya dengan penginstalan pertama), seperti yang Anda ketahui, helm tidak merilis. Oleh karena itu helm tidak akan memiliki informasi apapun tentang rilis untuk dibandingkan dengan sumber daya yang telah digunakan dan akan mencoba untuk menginstal mereka menunjukkan pesan itu karena sebenarnya beberapa sumber telah diinstal. Anda mungkin dapat menyelesaikan ini dengan menggunakan --atomic dengan instalasi atau menggunakan pemutakhiran helm --install --force berhati-hatilah dengan --force karena ini akan menghapus dan membuat ulang sumber daya.
Di sini kita menghadapi masalah yang terjadi dengan grafik yang sudah berhasil dipasang.

Pembaruan: masih terjadi setelah memperbarui ke helm v3.0.0 (stabil). @ efernandes-ANDigital, @bacongobbler , @ thomastaylor312
Jika saya menggunakan helm diff, tidak ada perbedaan, jika saya menggunakan helm upgrade --install --dry-run, gagal dengan kesalahan berikut: "Kesalahan: UPGRADE GAGAL: manifes yang diberikan berisi sumber daya baru yang sudah ada."
Menggunakan helm get manifest (dari rilis terakhir), menunjukkan sumber daya ini.
Menggunakan template helm menunjukkan sumber daya ini juga.
Mungkin ini terkait dengan bagaimana helm membandingkan sumber daya dengan manifes vs templat?
Saya membuat sumber daya yang mengiterasi daftar dengan jangkauan, mungkinkah itu terkait dengan ini?
Sepotong kode ini mungkin?

Solusi:
Menjalankan pemutakhiran --install dengan opsi --dry-run --debug dan -v 10 menunjukkan kepada kita bahwa helm entah bagaimana menggunakan beberapa revisi yang sangat lama. Kami menghapus semua revisi kecuali 2 yang terakhir dan mulai bekerja lagi.

Apakah Anda berhasil menyimpan buku besar rilis sebelum menghapusnya? Akan sangat membantu untuk mereproduksi masalah jika kami memiliki kasing yang solid yang dapat direproduksi.

Saya mendapatkan kesalahan ini saat mencoba mengubah versi api dari penerapan menjadi apps/v1 dari extensions/v1beta1 . Helm menolak untuk menerapkan tanpa saya menghapus penerapan lama secara manual.

@sheerun apakah Anda melihat jawaban saya terkait apiVersion perubahan dalam komentar ini: https://github.com/helm/helm/issues/6646#issuecomment -547650430?

Tl; dr adalah Anda harus menghapus objek lama secara manual untuk "meningkatkan". Kedua skema tersebut tidak kompatibel satu sama lain dan oleh karena itu tidak dapat ditingkatkan dari satu skema ke skema berikutnya dengan cara yang bersih. Apakah Anda mengetahui adanya perkakas yang menangani kasus ini?

Ini tidak terlalu membantu karena saya masih perlu menghapus sumber daya lama secara manual. Saya berharap bahwa flag untuk helm update perintah seperti --force akan secara otomatis menghapus dan menambahkan sumber daya yang memiliki api-tidak kompatibel, tetapi tidak demikian. Hal ini membuat peningkatan versi aplikasi di cluster kubernetes menjadi sangat tidak praktis. Jika --force tidak bertanggung jawab untuk ini maka flag lain akan berguna.

Ini masalah yang sangat penting saat ini karena kubernetes 1.16 baru saja menghentikan dukungan untuk API lama jadi kami perlu meningkatkan.

Saya mengerti maksud Anda ... Kami berpotensi mendukung bendera baru untuk itu.

Jika Anda memiliki saran, kami akan menyukai PR dengan tes, dokumen, dll. Ini pasti semakin banyak terutama dengan rilis 1.16, jadi kami akan dengan senang hati melihat proposal untuk menangani kasus itu.

ada pembaruan tentang ini?

7082 harus menangani kasus ini jika seseorang ingin mulai mengerjakan fitur itu.

Jika Anda harus menggunakan solusi berikut: https://github.com/helm/helm/issues/6646#issuecomment -546603596, Anda dapat menggunakan skrip berikut yang saya buat untuk mengotomatiskan proses tersebut: https: //gist.github. com / techmexdev / 5183be77abb26679e3f5d7ff99171731

kesalahan serupa

• mereproduksi langkah
  Saya sudah menginstall 10 revisi, saat saya menginstall sub chart baru di revisi 11, deloyed OK.
  lalu tingkatkan lagi dengan grafik yang sama, helm mengeluh rendered manifests contain a new resource that already exists .
• alasan
  helm membandingkan revisi saat ini dengan revisi pertama yang diterapkan yang tidak memiliki sumber daya yang baru saja kami pasang di revisi terakhir
• memperbaiki
  gunakan revisi terakhir yang di-deploy sebagai currentRelease, bukan revisi pertama

• bekerja di sekitar
  hapus rahasia lama yang dimiliki oleh helm kubectl get secret -L owner=helm

@ jason-liew Masalah ini tentang hal lain yang tidak terkait dengan jumlah rilis. Anda sedang memperbaiki bug lain dengan kesalahan serupa. Bug ini terkait dengan perubahan versi api sumber daya.

@sheerun maaf, saya telah menghapus referensi di pesan komit dan edit komentar di atas

Saya memiliki masalah yang sama. Env produksi diblokir dan tidak mungkin diperbaiki.
versi $ helm
version.BuildInfo {Versi: "v3.0.2", GitCommit: "19e47ee3283ae98139d98460de796c1be1e3975f", GitTreeState: "clean", GoVersion: "go1.13.5"}
Kesalahan: UPGRADE GAGAL: manifes yang dirender berisi sumber daya baru yang sudah ada. Tidak dapat melanjutkan pembaruan: konflik sumber daya yang ada: jenis: Layanan, ruang nama: ruang nama saya, nama: layanan-saya

Juga Amazon EKS

Tambahkan "Peringatan! Ada risiko untuk memiliki bata alih-alih diagram setelah pembaruan" ke https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/

Pekerjaan yang luar biasa. Aku bangga!

Masalah ini juga terbentur.

Setelah migrasi ke v3 dengan helm-v2-to-helm-v3 plugin, saya tidak dapat memperbarui bagan:

Error: UPGRADE FAILED: rendered manifests contain a new resource that already exists. Unable to continue with update: existing resource conflict: kind: Deployment, namespace: default, name: grafana-main

Ini benar-benar dapat dimengerti jika terjadi dalam versi beta, tetapi saya menjalankan v3.0.2 setelah mengikuti instruksi di blog resmi, mencapai masalah / bug yang dilaporkan selama versi beta. Rasanya tidak enak.

Apakah ada pekerjaan non-destruktif untuk saat ini? Apa yang dikemukakan oleh komentar ini terasa cukup merusak https://github.com/helm/helm/issues/6646#issuecomment -546603596

Juga mengalami masalah yang sama saat mengupgrade sumber daya ke versi api baru menggunakan helm3.

Untuk saat ini, kami juga membutuhkan solusi yang tepat. Menghapus sumber daya lama sebenarnya bukan merupakan opsi untuk beban kerja produksi kami.

Helm 3.0.2. Tidak dapat menerapkan atau bahkan melakukan rollback ketika penerapan sebelumnya mengubah jumlah penerapan (dihapus atau ditambahkan Deployment). Gagal dengan kesalahan:

Error: tidak ditemukan Deployment dengan nama "server2"

Sangat membuat frustasi.

Saya setuju. Mengesalkan karena Kubernetes API memperlakukan pembaruan apiVersion sebagai perubahan yang dapat menyebabkan gangguan.

Jika ada yang mengetahui solusi dalam Kubernetes yang memungkinkan seseorang untuk mengupgrade apiVersions tanpa harus membuat ulang objek, kami akan senang mendengarnya. Saat ini kami tidak mengetahui titik akhir API yang tersedia untuk alat pihak ketiga seperti Helm untuk "mengonversi" objek dari satu apiVersion ke yang berikutnya.

Satu-satunya pilihan yang kami ketahui dari Kubernetes 'API adalah menghapus dan membuat objek. Ini tentu saja tidak ideal, tetapi itu satu-satunya pilihan yang kami sadari saat ini.

Telah disebutkan di https://github.com/helm/helm/issues/7219 bahwa peningkatan dari Kubernetes 1.15 ke 1.16 memigrasikan objek dari apiVersion yang tidak digunakan lagi (seperti extensions/v1beta1 ) menjadi apps/v1 pada bagian belakang. Jika seseorang dapat mengkonfirmasi perilaku tersebut serta mendapatkan pemahaman yang lebih baik tentang bagaimana Kubernetes mencapai ini, itu dapat memberi kami solusi yang mungkin untuk masalah ini.

Saya mencoba melakukan penerapan ulang dari komputer lain (bukan yang sebelumnya menerapkan jumlah penerapan yang dimodifikasi), dan itu berjalan lancar. Mungkinkah masalah cache lokal?

@youurayy Apakah Anda menggunakan set Stateful? Atau Penerapan? Set stateful hanya mendukung peningkatan sumber daya tanpa batas di K8S. Penerapan masih memiliki masalah dengan layanan "Kesalahan peningkatan, Tidak mungkin untuk meningkatkan" misalnya.

Saya menghadapi masalah yang sama di sini. Sekadar informasi, saya bermigrasi dari v2 ke v3. Pada awalnya itu tidak berfungsi karena mengeluh bahwa beberapa API tidak valid. Saya mengupgrade API (Deployments and Statefulsets), lalu saya mengalami masalah ini.

Versi helm yang digunakan adalah 3.0.2

Masalah yang sama di sini. Sepertinya PR belum dibuka. Ada yang mengerjakan ini?

tidak, silakan menyelidiki lebih lanjut. Lihat komentar saya sebelumnya untuk informasi lebih lanjut tentang di mana untuk memulai.

@bacongobbler Ini adalah masalah besar bukan? Jika saya tidak salah, Anda tidak punya pilihan dengan helm3 untuk mengubah revisi api Anda dari v1beta1 ke v1 karena validasi OpenAPI, jadi bukankah itu berarti semua orang yang menggunakan helm cukup banyak harus menghapus penerapan sebelum memutakhirkan bagan?

Sebenarnya, ini mungkin bukan masalah besar seperti yang saya kira, menghapus --force menghilangkan sebagian masalah karena itu mengabaikan penggabungan 3 arah. Saya percaya satu-satunya masalah yang beredar adalah jika Anda memiliki bagan yang dipasang helm 2 yang menggunakan k8s api ver yang lebih tua yaitu v1beta1, Anda tidak dapat melakukan peningkatan helm 3 untuk mengatakan v1.

Saya mengalami masalah serupa dengan salah satu penerapan saya.
Kesalahan yang saya dapatkan adalah

Error: UPGRADE FAILED: rendered manifests contain a new resource that already exists. Unable to continue with update: existing resource conflict: kind: ServiceAccount, namespace: default, name: my-program
--
306 | helm.go:76: [debug] existing resource conflict: kind: ServiceAccount, namespace: default, name: my-program
307 | rendered manifests contain a new resource that already exists. Unable to continue with update

Saya mendapatkan kesalahan ini bahkan setelah menghapus akun layanan yang dikeluhkannya.

Saya mendapat kesalahan serupa saat mencoba mengubah versi api dari aplikasi DaemonSetto / v1 dari ekstensi yang tidak digunakan lagi / v1beta1. Helm3 menolak mengupgrade DaemonSet dari versi ekstensi / v1beta1 ke apps / v1.

Berikut adalah pesan kesalahan yang tepat dengan Helm3 ketika saya mencoba untuk meningkatkan grafik yang telah diinstal dengan Helm3

Kesalahan: UPGRADE GAGAL: manifes yang dirender berisi sumber daya baru yang sudah ada. Tidak dapat melanjutkan pembaruan: konflik sumber daya yang ada: jenis: DaemonSet, namespace: kube-system, name: omsagent

Helm2 melakukan upgrade tanpa masalah apapun.

Saya mencoba dengan semua versi Helm3 yang dirilis, tetapi tidak berhasil.

Hargai menangani ini di Helm3.

@ ganga1980 ini bukan solusi yang bagus tetapi cara kami menangani masalah ini adalah dengan menghapus sumber daya yang dikeluhkannya (daemonset omsagent dalam kasus Anda) hingga berhasil. sekali lagi, tidak ideal, tetapi pada akhirnya akan berfungsi setelah sumber daya yang bentrok yang menggunakan versi API yang dihentikan tidak lagi ada dan akan membuat kembali sumber daya menggunakan versi API yang diperbarui. kami menggunakan Kubernetes v1.15 dan Helm 3.0.2.

ini telah menjadi jalur peningkatan yang lebih baik bagi kami karena banyak bagan kami memiliki volume yang tetap, jadi menghapus bagan dari cluster kami dan menerapkan ulang bukanlah pilihan yang mudah. untungnya, volume persisten tidak ada dalam daftar API yang tidak digunakan lagi.

Masalah yang sama di sini meningkatkan stable/nginx-ingress berjalan:

# helm upgrade nginx-ingress stable/nginx-ingress --set rbac.create=true --set controller.publishService.enabled=true --set controller.tcp.configMapNamespace=tcp-services

keluaran:
Kesalahan: UPGRADE GAGAL: manifes yang dirender berisi sumber daya baru yang sudah ada. Tidak dapat melanjutkan pembaruan: konflik sumber daya yang ada: jenis: ClusterRole, namespace:, name: main-nginx-ingress

# helm version

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

Saya setuju. Mengesalkan karena Kubernetes API memperlakukan pembaruan apiVersion sebagai perubahan yang dapat menyebabkan gangguan.

Jika ada yang mengetahui solusi dalam Kubernetes yang memungkinkan seseorang untuk mengupgrade apiVersions tanpa harus membuat ulang objek, kami akan senang mendengarnya. Saat ini kami tidak mengetahui titik akhir API yang tersedia untuk alat pihak ketiga seperti Helm untuk "mengonversi" objek dari satu apiVersion ke yang berikutnya.

Satu-satunya pilihan yang kami ketahui dari Kubernetes 'API adalah menghapus dan membuat objek. Ini tentu saja tidak ideal, tetapi itu satu-satunya pilihan yang kami sadari saat ini.

Disebutkan di # 7219 bahwa peningkatan dari Kubernetes 1.15 ke 1.16 memigrasikan objek dari apiVersion yang sudah tidak digunakan lagi (seperti extensions/v1beta1 ) ke apps/v1 di backend. Jika seseorang dapat mengkonfirmasi perilaku tersebut serta mendapatkan pemahaman yang lebih baik tentang bagaimana Kubernetes mencapai ini, itu dapat memberi kami solusi yang mungkin untuk masalah ini.

Apa masalah sebenarnya di sini? Dimungkinkan untuk memperbarui objek dengan kubectl bahkan dengan perubahan api tanpa masalah apa pun. Objek tidak harus dihapus (bisa saja kubectl apply / replace) mengapa Helm tidak bisa melakukan hal yang sama?

@bacongobbler Saya setuju bahwa dari sudut pandang k8s, ini adalah perubahan yang rusak antara versi API. Namun, di k8s ada desain untuk menangani kasus seperti itu untuk memigrasi satu objek dari satu versi ke versi lainnya.
Misalnya, dalam satu kluster 1.14, jika penerapan dibuat dalam versi 'apps / v1', itu juga tersedia dalam versi 'apps / v1bet1', 'apps / v1bet2', 'extensions / v1beta1'. Lihat https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.14/#deployment -v1-apps.
Jadi menurut saya desain gvk helm3 sudah oke, tapi implementasinya harus lebih rumit. Objek rilis lama tidak hanya diambil dari penyimpanan pelepasan helm, tetapi juga dari lingkungan berjalan saat ini.

Terima kasih

Saya setuju. Mengesalkan karena Kubernetes API memperlakukan pembaruan apiVersion sebagai perubahan yang dapat menyebabkan gangguan.

Jika ada yang mengetahui solusi dalam Kubernetes yang memungkinkan seseorang untuk mengupgrade apiVersions tanpa harus membuat ulang objek, kami akan senang mendengarnya. Saat ini kami tidak mengetahui titik akhir API yang tersedia untuk alat pihak ketiga seperti Helm untuk "mengonversi" objek dari satu apiVersion ke yang berikutnya.

Satu-satunya pilihan yang kami ketahui dari Kubernetes 'API adalah menghapus dan membuat objek. Ini tentu saja tidak ideal, tetapi itu satu-satunya pilihan yang kami sadari saat ini.

Disebutkan di # 7219 bahwa peningkatan dari Kubernetes 1.15 ke 1.16 memigrasikan objek dari apiVersion yang sudah tidak digunakan lagi (seperti extensions/v1beta1 ) ke apps/v1 di backend. Jika seseorang dapat mengkonfirmasi perilaku tersebut serta mendapatkan pemahaman yang lebih baik tentang bagaimana Kubernetes mencapai ini, itu dapat memberi kami solusi yang mungkin untuk masalah ini.

Objek tunggal k8s dapat dikonversi dari satu versi ke versi lain jika kompatibel. Lihat https://github.com/kubernetes/kubernetes/blob/master/pkg/apis/apps/v1/conversion.go sebagai contoh.

Saya mengalami masalah yang terkait dengan ini.

Dalam kasus saya, saya telah mengaktifkan NamespaceAutoProvision admission controller untuk menghindari kegagalan karena ruang nama yang tidak ada. Itu sebagian besar membantu, tetapi di sinilah hal itu menciptakan masalah baru: di bagan kami, kami membuat beberapa ruang nama secara eksplisit untuk menetapkan beberapa label padanya, yang digunakan untuk kebijakan jaringan. Ini dilakukan sebagai langkah terpisah sebelum memasang bagan yang menggunakan ruang nama tersebut. Dengan helm 3 dan controller NamespaceAutoProvision , instalasi chart sekarang gagal

Error: rendered manifests contain a resource that already exists. Unable to continue with install: existing resource conflict: kind: Namespace, namespace: , name: monitoring

yang masuk akal, tetapi memblokir penyediaan. Saya sudah mencoba ini dengan dan tanpa --force untuk hasil yang sama.

Saya tidak tahu apakah ini telah di-float sebelumnya, tetapi mungkin ada cara untuk memberi tahu Helm untuk "mengadopsi" sumber daya jika mereka sudah ada - yaitu, dalam kasus namespace yang ada, itu akan ditambal dengan manifes yang disediakan pengguna dan dipahami dikelola oleh Helm sejak saat itu.

Objek tunggal k8s dapat dikonversi dari satu versi ke versi lain jika kompatibel. Lihat https://github.com/kubernetes/kubernetes/blob/master/pkg/apis/apps/v1/conversion.go sebagai contoh.

Itu adalah konversi dari apps / v1 ke representasi internal lain. Anda tidak dapat menggunakan ini untuk mengonversi dari v1beta1 ke v1. Perhatikan kodenya lebih dekat.

Misalnya, dalam satu kluster 1.14, jika penerapan dibuat dalam versi 'apps / v1', itu juga tersedia dalam versi 'apps / v1bet1', 'apps / v1bet2', 'extensions / v1beta1'

Cluster Kubernetes mendukung beberapa versi API, tetapi mereka diperlakukan sebagai objek terpisah. Skema internal sangat berbeda. Tidak ada API "ubah dari v1beta1 ke v1" yang kami ketahui saat ini.

Saya tidak tahu apakah ini telah di-float sebelumnya, tetapi mungkin ada cara untuk memberi tahu Helm untuk "mengadopsi" sumber daya jika mereka sudah ada - yaitu, dalam kasus namespace yang ada, itu akan ditambal dengan manifes yang disediakan pengguna dan dipahami dikelola oleh Helm sejak saat itu.

Lihat # 2730

@bacongobbler terima kasih atas jawaban dan bantuan Anda di sini. Saya memiliki masalah yang sama dengan versi api, tetapi dalam cluster itu sendiri, penerapan kami memiliki - apiVersion: apps / v1
Versi baru bagan juga memiliki: apiVersion: apps / v1
Tetapi dalam metadata / rilis Helm 3 kami memiliki ini:
apiVersion: extensions / v1beta1
jenis: Penerapan

Sangat tidak nyaman jika Anda perlu menginstal ulang beban kerja produksi hanya untuk memperbaiki metadata Helm, karena penerapan yang sebenarnya memiliki versi API yang benar. Ada saran di sini? Saya berpikir untuk mengubah metadata secara manual.

Ada saran di sini?

https://github.com/helm/helm/issues/7219#issuecomment -568175917

@bayu_joo
Saya akan menunjukkan bagaimana kubernetes hanlde beberapa versi API dari desain, kode, dan runtime.

1. Desing doc
   https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api_changes.md#operational -overview.
   Ada contoh di dokumen tentang cara membuat sumber daya di v7beta1 dan mengambilnya di v5. Jadi dari perspektif desain kubernetes, ini memungkinkan konversi objek tunggal di antara beberapa versi.

   Proses konversi secara logis adalah "bintang" dengan bentuk internal di tengahnya. Setiap API berversi dapat dikonversi ke bentuk internal (dan sebaliknya)

2. Kode sumber Kubernetes
   Seperti yang saya sebutkan di atas, ada konversi seperti itu
   https://github.com/kubernetes/kubernetes/blob/master/pkg/apis/apps/v1/conversion.go Convert_v1_DeploymentSpec_To_apps_DeploymentSpec dan Convert_apps_DeploymentSpec_To_v1_DeploymentSpec
   Selain itu, https://github.com/kubernetes/kubernetes/blob/master/pkg/apis/apps/v1beta2/conversion.go Convert_v1beta2_DeploymentSpec_To_apps_DeploymentSpec dan Convert_apps_DeploymentSpec_To_v1beta2_DeploymentSpec .
   Kode menggunakan struktur data interal sebagai hub dalam versi yang berbeda.

3. Perilaku runtime
   Saya menggunakan cluster 1,14 dan kubectl.
   kubectl get -n kube-system deployment coredns -o yaml -v 8
   Paksa untuk menggunakan versi api lain
   kubectl get -n kube-system deployment.v1.apps coredns -o yaml -v 8
   Anda dapat melihat satu objek (dengan uidnya) dapat diambil dengan beberapa versi API.

Hei,

Saya mengalami masalah yang sama. Masalah saya adalah mengenai set stateful yang sudah ada sebelumnya. Nasihat apa pun akan sangat dihargai.

Terima kasih,
Richard

Mari kita buka diskusi:
https://github.com/helm/helm/pull/7575

Halo,

Saya menghadapi masalah yang sama satu-satunya pemikiran yang telah saya lakukan saya meningkatkan dari helm 2.14.1 ke yang terbaru, kami mendapatkan kesalahan seperti yang disebutkan di atas: manifes yang diberikan berisi sumber daya yang sudah ada.

Terima kasih
Hany

Inilah peretasan kotor yang kami gunakan setiap kali sumber daya, seperti PV atau PVC, sudah ada dan kami tidak ingin menghapusnya, tetapi ingin meningkatkan kontainer. Ini biasanya terjadi setiap kali kita melakukan helm upgrade whatever dan penerapan lama dan penerapan baru macet dalam perlombaan.

kubectl get deployments -n monitoring
kubectl get -n monitoring deployment/prometheus-operator-grafana -o jsonpath="{.spec.replicas}"

# Set spec.replicas to 0
kubectl edit -n monitoring deployments/prometheus-operator-grafana
watch -n1 -d "kubectl get pods -n monitoring"

# Once all pods have terminated, set the spec.replicas back to 1 or whatever value you want
kubectl edit -n monitoring deployments/prometheus-operator-grafana
watch -n1 -d "kubectl get pods -n monitoring"

# At this point you'll have an updated pod/deployment/whatever

Saya mendapat kesalahan ini hanya dengan mengikuti tutorial dasar

Pukul ini untuk ClusterRoleBinding saat menginstal bagan dasbor kubernetes

Error: UPGRADE FAILED: rendered manifests contain a new resource that already exists. Unable to continue with update: existing resource conflict: namespace: , name: kubernetes-dashboard, existing_kind: rbac.authorization.k8s.io/v1, Kind=ClusterRoleBinding, new_kind: rbac.authorization.k8s.io/v1, Kind=ClusterRoleBinding

Masalah yang sama saat memasang bagan di dua ruang nama. Bagan saya bergantung pada bagan operator-prometheus yang akan membuat ClusterRole.
Error: rendered manifests contain a resource that already exists. Unable to continue with install: existing resource conflict: kind: ClusterRole, namespace: , name: p8s-operator

Sama disini. Saya memindahkan helm2 ke penyebaran helm 3 dan setelah itu tidak lagi dapat diupgrade karena kesalahan yang sama

./helm upgrade public-nginx-ingress stable/nginx-ingress --install --namespace ingress --wait -f public-nginx-ingress.yaml coalesce.go:199: warning: destination for extraContainers is a table. Ignoring non-table value [] coalesce.go:199: warning: destination for extraVolumes is a table. Ignoring non-table value [] coalesce.go:199: warning: destination for extraVolumeMounts is a table. Ignoring non-table value [] Error: UPGRADE FAILED: rendered manifests contain a new resource that already exists. Unable to continue with update: existing resource conflict: namespace: , name: public-nginx-ingress, existing_kind: rbac.authorization.k8s.io/v1, Kind=ClusterRole, new_kind: rbac.authorization.k8s.io/v1, Kind=ClusterRole
Saya coba lewati bagian rbac, karena sepertinya sudah ada dan tidak perlu dibuat lagi
Lalu saya mendapatkan edisi berikutnya
./helm upgrade public-nginx-ingress stable/nginx-ingress --install --namespace ingress --wait -f public-nginx-ingress.yaml --set rbac.create=false coalesce.go:199: warning: destination for extraContainers is a table. Ignoring non-table value [] coalesce.go:199: warning: destination for extraVolumeMounts is a table. Ignoring non-table value [] coalesce.go:199: warning: destination for extraVolumes is a table. Ignoring non-table value [] Error: UPGRADE FAILED: cannot patch "public-nginx-ingress-controller-metrics" with kind Service: Service "public-nginx-ingress-controller-metrics" is invalid: spec.clusterIP: Invalid value: "": field is immutable && cannot patch "public-nginx-ingress-controller" with kind Service: Service "public-nginx-ingress-controller" is invalid: spec.clusterIP: Invalid value: "": field is immutable && cannot patch "public-nginx-ingress-default-backend" with kind Service: Service "public-nginx-ingress-default-backend" is invalid: spec.clusterIP: Invalid value: "": field is immutable

Bisakah seseorang menjelaskan apa solusinya di sini? Saya melihat bahwa ini dibuka kembali lalu ditutup lagi 39 menit kemudian tetapi saya tidak melihat solusi yang jelas di utas ini.

Bisakah seseorang menjelaskan apa solusinya di sini? Saya melihat bahwa ini dibuka kembali lalu ditutup lagi 39 menit kemudian tetapi saya tidak melihat solusi yang jelas di utas ini.

Belum ada solusi tetapi yang ini menjanjikan dan hampir siap untuk diterapkan:

https://github.com/helm/helm/pull/7649

7649 telah digabungkan pagi ini.

7649 telah digabungkan pagi ini.

Ohh, ketinggalan itu;) baiklah, maka jawaban pertanyaan @micseydel ada di postingan pertama # 7649 di bagian Catatan Rilis