<p>pemutakhiran helm gagal dengan spec.clusterIP: Nilai tidak valid: "": bidang tidak dapat diubah</p>

Dibuat pada 20 Apr 2020  ·  64Komentar  ·  Sumber: helm/helm

Saat melakukan upgrade helm, muncul error seperti, ("my-service" berubah dari "clusterIP: None" menjadi "type: LoadBalancer" tanpa field clusterIP)

Error: UPGRADE FAILED: Service "my-service" is invalid: spec.clusterIP: Invalid value: "": field is immutable 

Namun, semua pod lain dengan versi baru masih akan direstart, kecuali Jenis "my-service" tidak berubah menjadi "LoadBalancer" jenis baru

Saya mengerti mengapa upgrade gagal karena helm tidak mendukung perubahan di beberapa bidang tertentu. Tetapi mengapa helm masih meningkatkan layanan / pod lain dengan memulainya kembali. Haruskah helm tidak melakukan apa-apa jika terjadi kesalahan selama peningkatan? Saya mengecualikan helm untuk memperlakukan seluruh rangkaian layanan sebagai paket untuk meningkatkan semua atau tidak sama sekali, tetapi tampaknya harapan saya mungkin salah.

Dan jika kita pernah berakhir dalam situasi seperti itu, lalu apa yang harus kita lakukan untuk keluar dari situasi tersebut? seperti bagaimana cara meningkatkan "layanan-saya" untuk memiliki tipe baru?

Dan jika saya menggunakan opsi --dry-run, helm tidak menunjukkan kesalahan apa pun.

Apakah ini dianggap bug atau diharapkan, mis. Pemutakhiran menimbulkan beberapa kesalahan tetapi beberapa layanan masih ditingkatkan.

Output dari helm version :

Client: &version.Version{SemVer:"v2.12.3", GitCommit:"eecf22f77df5f65c823aacd2dbd30ae6c65f186e", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.14.3", GitCommit:"0e7f3b6637f7af8fcfddb3d2941fcc7cbebb0085", GitTreeState:"clean"}

Output dari kubectl version :

Client Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.0", GitCommit:"2bd9643cee5b3b3a5ecbd3af49d09018f0773c77", GitTreeState:"clean", BuildDate:"2019-09-18T14:36:53Z", GoVersion:"go1.12.9", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"14+", GitVersion:"v1.14.10-gke.27", GitCommit:"145f9e21a4515947d6fb10819e5a336aff1b6959", GitTreeState:"clean", BuildDate:"2020-02-21T18:01:40Z", GoVersion:"go1.12.12b4", Compiler:"gc", Platform:"linux/amd64"}

Penyedia / Platform Cloud (AKS, GKE, Minikube, dll.):
GKE dan Minkube

bug

Komentar yang paling membantu

FYI, masalah yang diangkat oleh OP dan komentar yang diangkat di sini tentang --force adalah masalah yang terpisah dan terpisah. Mari coba fokus pada masalah OP di sini.

Untuk memperjelas, masalah yang dijelaskan OP adalah potensi regresi @ n1koo yang diidentifikasi di https://github.com/helm/helm/issues/7956#issuecomment -620749552. Sepertinya itu bug yang sah.

Komentar lain yang menyebutkan penghapusan --force berfungsi untuk mereka adalah perilaku yang disengaja dan diharapkan dari sudut pandang Kubernetes. Dengan --force , Anda meminta Helm untuk membuat permintaan PUT terhadap Kubernetes. Secara efektif, Anda meminta Kubernetes untuk mengambil manifes target Anda (templat yang dirender dalam bagan Anda dari helm upgrade ) sebagai sumber kebenaran dan menimpa sumber daya di cluster Anda dengan manifes yang dirender. Ini identik dengan kubectl apply --overwrite .

Dalam kebanyakan kasus, template Anda tidak menentukan IP cluster, yang berarti helm upgrade --force meminta untuk menghapus (atau mengubah) IP cluster layanan. Ini adalah operasi ilegal dari sudut pandang Kubernetes.

Ini juga didokumentasikan di # 7082.

Ini juga mengapa menghapus --force berfungsi: Helm membuat operasi PATCH, berbeda dengan status live, menggabungkan IP cluster ke dalam manifes yang ditambal, mempertahankan IP cluster selama peningkatan.

Jika Anda ingin menghapus secara paksa dan membuat ulang objek seperti yang dilakukan di Helm 2, lihat # 7431.

Semoga ini menjelaskan banyak hal.

Ke depan, mari coba fokus pada masalah OP di sini.

Semua 64 komentar

Tidak cukup informasi yang diberikan untuk mereproduksi. Beri tahu kami cara membuat bagan yang dapat direproduksi, dan perintah Helm mana yang Anda gunakan.

Hai, ini langkah-langkah reproduksinya
Memiliki dua layanan file yaml seperti di bawah ini.

nginx.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

prometheus.yaml

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: prometheus
spec:
  template:
    metadata:
      labels:
        app: prometheus
    spec:
      containers:
      - image: prom/prometheus
        name: prometheus
        ports:
        - containerPort: 9090
        imagePullPolicy: Always
      hostname: prometheus
      restartPolicy: Always
---
apiVersion: v1
kind: Service
metadata:
  name: prometheus
spec:
  selector:
    app: prometheus
  clusterIP: None
  ports:
  - name: headless
    port: 9090
    targetPort: 0

Kemudian taruh di sana dua file di helm1 / templates / lalu install. Ini menunjukkan layanan prometheus menggunakan clusterIP dan versi nginx adalah 1.14.2

# helm upgrade --install test helm1
Release "test" does not exist. Installing it now.
NAME: test
LAST DEPLOYED: Tue Apr 21 20:42:55 2020
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST SUITE: None

# kubectl get svc
NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)    AGE
kubernetes   ClusterIP   10.96.0.1    <none>        443/TCP    35d
prometheus   ClusterIP   None         <none>        9090/TCP   7s

# kubectl describe deployment nginx |grep Image
    Image:        nginx:1.14.2

Sekarang perbarui bagian untuk nginx.yaml ke versi baru 1.16

        image: nginx:1.16

dan prometheus.yaml dengan mengubahnya menjadi LoadBalancer.

spec:
  selector:
    app: prometheus
  ports:
  - name: "9090"
    port: 9090
    protocol: TCP
    targetPort: 9090
  type: LoadBalancer

Sekarang taruh mereka sebagai helm2 dan lakukan upgrade. Kemudian Anda dapat melihat peningkatan menampilkan beberapa kesalahan, tetapi layanan nginx berhasil, dengan meningkatkan ke versi baru, tetapi prometheus tidak ditingkatkan karena masih menggunakan IP Cluster.

# helm upgrade --install test helm2
Error: UPGRADE FAILED: cannot patch "prometheus" with kind Service: Service "prometheus" is invalid: spec.clusterIP: Invalid value: "": field is immutable

# kubectl get svc
NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)    AGE
kubernetes   ClusterIP   10.96.0.1    <none>        443/TCP    35d
prometheus   ClusterIP   None         <none>        9090/TCP   5m34s

# kubectl describe deployment nginx |grep Image
    Image:        nginx:1.16

daftar helm menunjukkan

# helm list
NAME    NAMESPACE   REVISION    UPDATED                                 STATUS  CHART                                       APP VERSION
test    default     2           2020-04-21 20:48:20.133644429 -0700 PDT failed  

sejarah helm

# helm history test
REVISION    UPDATED                     STATUS      CHART       APP VERSION DESCRIPTION                                                                                                                                               
1           Tue Apr 21 20:42:55 2020    deployed    helm-helm   1.0.0.6     Install complete                                                                                                                                          
2           Tue Apr 21 20:48:20 2020    failed      helm-helm   1.0.0.6     Upgrade "test" failed: cannot patch "prometheus" with kind Service: Service "prometheus" is invalid: spec.clusterIP: Invalid value: "": field is immutable

Kami memiliki perilaku yang sama dengan v3.2.0, menurunkan versi ke v3.1.3 adalah perbaikan sementara kami

Saya mendapatkan banyak hal ini dengan migrasi Helm 2 -> 3 saya. Ketika mencoba untuk meningkatkan Rilis yang dikonversi untuk pertama kalinya, saya mendapatkan banyak ini. Ini untuk grafik Nginx Ingress, Prometheus Operator, Graylog dan Jaeger sejauh ini. Sebagian besar dari mereka saya puas hanya dengan menghapus layanan dan membiarkan Helm membuatnya kembali tetapi untuk Nginx Ingress ini bukan pilihan ...

Baru saja menemukan https://github.com/helm/helm/issues/6378#issuecomment -557746499 ini yang menjelaskan masalah dalam kasus saya.

Menutup sebagai duplikat dari # 6378. @cablespaghetti menemukan penjelasan yang lebih dalam untuk perilaku ini, yang dijelaskan dengan sangat detail.

Beri tahu kami jika itu tidak berhasil untuk Anda.

@GaramNick mengapa downgrade memperbaikinya untuk Anda? Dapatkah Anda menjelaskan lebih lanjut tentang "apa" yang diperbaiki dengan menurunkan versi?

@bacongobbler Saat Anda di sini. Adakah cara untuk memperbaiki situasi ini tanpa menghapus rilis dan menerapkan ulang? Sepertinya saya tidak bisa melakukan itu di bawah kemudi 2 atau 3. Saya ingin meretas data rilis yang ada sehingga Helm berpikir clusterIP selalu dihilangkan sehingga tidak diperlukan tambalan.

Sudahkah Anda mencoba kubectl edit ?

Kami memiliki masalah yang sama dan menurunkan ke 3.1.3 memperbaikinya juga untuk kami. Dugaan saya adalah itu ada hubungannya dengan logika baru di https://github.com/helm/helm/pull/7649/commits/d829343c1514db17bee7a90624d06cdfbffde963 menganggap ini Create dan bukan pembaruan sehingga mencoba mengosongkan IP dan tidak menggunakan kembali yang terisi

Temuan menarik. terima kasih telah menyelidiki.

@jlegrone, adakah kemungkinan Anda punya waktu untuk menyelidiki ini?

@bacongobbler Pipeline CI / CD kami menggunakan Helm untuk memperbarui aplikasi kami yang menyertakan Layanan dengan tipe ClusterIP. Perintah:

helm upgrade --install --force \
        --wait \
        --set image.repository="$CI_REGISTRY_IMAGE" \
        --set image.tag="$CI_COMMIT_REF_NAME-$CI_COMMIT_SHA" \
        --set image.pullPolicy=IfNotPresent \
        --namespace="$KUBE_NAMESPACE" \
        "$APP_NAME" \
        ./path/to/charts/

Pada v3.2.0 perintah ini gagal dengan Service "service-name" is invalid: spec.clusterIP: Invalid value: "": field is immutable

Pada v3.1.3 ini berfungsi dengan baik.

Beri tahu saya jika Anda ingin mengetahui info lebih lanjut.

Sama disini. Kami memiliki layanan berikut. Yaml bekerja dengan baik dengan helm2 selama berbulan-bulan.
Setelah migrasi, perintah helm 3.2 helm upgrade gagal dengan kesalahan penyimpanan seperti di atas. Menurunkan versi ke 3.1.3 menyelesaikannya.

apiVersion: v1
kind: Service
metadata:
  name: {{ .Values.global.name }}
  namespace: {{ index .Values.global.namespace .Values.global.env }}
  labels:
     microservice: {{ .Values.global.name }}
spec:
   type: ClusterIP
   ports:
   - port: 8080
   selector:
      microservice: {{ .Values.global.name }}

Kami memiliki masalah yang sama dan menurunkan versi ke 3.1.3 juga memperbaikinya untuk kami. Dugaan saya adalah bahwa ini ada hubungannya dengan logika baru di d829343 mengingat ini adalah Buat dan bukan pembaruan sehingga mencoba untuk mengatur IP kosong dan tidak menggunakan kembali yang terisi

@ n1koo Dapatkah Anda menjelaskan mengapa menurut Anda kode inilah yang menyebabkan masalah? Karena ini adalah kode instal dan bukan peningkatan, dan juga kode di 3.1 adalah ` create dan berfungsi.

Saya meninjau masalah dengan @adamreese , dan kami _think_ itu adalah tambalan yang diidentifikasi oleh @ n1koo . Metode Create akan mengabaikan perbedaan 3-arah normal pada Layanan, yang akan mengakibatkan clusterIP layanan disetel ke "" alih-alih nilai yang diisi oleh Kubernetes. Akibatnya, manifes yang dikirim ke server API _appears_ untuk menyetel ulang IP cluster, yang ilegal pada layanan (dan jelas bukan yang diinginkan pengguna).

Kami masih menyelidiki ini dan saya akan memperbarui jika kita mempelajari lebih lanjut.

Jadi https://github.com/helm/helm/issues/6378#issuecomment -557746499 benar. Harap baca itu sebelum melanjutkan dengan masalah ini. Jika clusterIP: "" disetel, Kubernetes akan menetapkan IP. Pada Helm upgrade berikutnya, jika clusterIP:"" lagi, akan muncul error di atas, karena muncul _to Kubernetes_ bahwa Anda mencoba untuk mereset IP. (Ya, Kubernetes mengubah bagian spec: dari sebuah layanan!)

Ketika metode Create melewati perbedaan 3 arah, metode ini menetapkan clusterIP: "" alih-alih menyetelnya ke alamat IP yang ditetapkan oleh Kubernetes.

Untuk mereproduksi:

$ helm create issue7956
$ # edit issue7956/templates/service.yaml and add `clusterIP: ""` under `spec:`
$ helm upgrade --install issue7956 issue7956
...
$ helm upgrade issue7956 issue7956
Error: UPGRADE FAILED: cannot patch "issue-issue7956" with kind Service: Service "issue-issue7956" is invalid: spec.clusterIP: Invalid value: "": field is immutable

Kedua kali Anda menjalankan peningkatan, itu akan gagal.

Saya tidak dapat mereproduksi kasus @IdanAdar pada master .

@GaramNick tidak ada cukup info tentang layanan yang Anda gunakan bagi kami untuk mereproduksi kesalahan Anda.

Situasi saya:
version.BuildInfo{Version:"v3.2.0", GitCommit:"e11b7ce3b12db2941e90399e874513fbd24bcb71", GitTreeState:"clean", GoVersion:"go1.13.10"}
juga diuji dengan
version.BuildInfo{Version:"v3.2.1", GitCommit:"fe51cd1e31e6a202cba7dead9552a6d418ded79a", GitTreeState:"clean", GoVersion:"go1.13.10"}

diberikan template layanan berikut:

apiVersion: v1
kind: Service
metadata:
  name: {{ include "app.fullname" . }}
  labels:
    {{- include "app.labels" . | nindent 4 }}
  annotations:
    getambassador.io/config: |
      ---
      apiVersion: ambassador/v1
      kind: Mapping
      name: {{ include "app.fullname" . }}_mapping
      prefix: /{{ include "app.fullname" . }}
      host: "^{{ include "app.fullname" . }}.*"
      host_regex: true
      service: {{ include "app.fullname" . }}.{{ .Release.Namespace }}
      rewrite: ""
      timeout_ms: 60000
      bypass_auth: true
      cors:
        origins: "*"
        methods: POST, GET, OPTIONS
        headers:
        - Content-Type
        - Authorization
        - x-client-id
        - x-client-secret
        - x-client-trace-id
        - x-flow-proto
      ---
      apiVersion: ambassador/v1
      kind: Mapping
      name: {{ include "app.fullname" . }}_swagger_mapping
      ambassador_id: corp
      prefix: /swagger
      host: "^{{ include "app.fullname" . }}.corp.*"
      host_regex: true
      service: {{ include "app.fullname" . }}.{{ .Release.Namespace }}
      rewrite: ""
      bypass_auth: true
      cors:
        origins: "*"
        methods: POST, GET, OPTIONS
        headers:
        - Content-Type
        - x-client-id
        - x-client-secret
        - Authorization
        - x-flow-proto
  namespace: {{ .Release.Namespace }}
spec:
  type: {{ .Values.service.type }}
  selector:
    {{- include "app.selectorLabels" . | nindent 4 }}
  ports:
  - port: {{ .Values.service.port }}
    name: http-rest-hub
    targetPort: http-rest
  - port: {{ .Values.service.healthPort }}
    name: http-health
    targetPort : http-health

yang menghasilkan berikut ini setelah upgrade --install :

apiVersion: v1
kind: Service
metadata:
  annotations:
    getambassador.io/config: |
      ---
      apiVersion: ambassador/v1
      kind: Mapping
      name: hub-alt-bor_mapping
      prefix: /hub-alt-bor
      host: "^hub-alt-bor.*"
      host_regex: true
      service: hub-alt-bor.brett
      rewrite: ""
      timeout_ms: 60000
      bypass_auth: true
      cors:
        origins: "*"
        methods: POST, GET, OPTIONS
        headers:
        - Content-Type
        - Authorization
        - x-client-id
        - x-client-secret
        - x-client-trace-id
        - x-flow-proto
      ---
      apiVersion: ambassador/v1
      kind: Mapping
      name: hub-alt-bor_swagger_mapping
      ambassador_id: corp
      prefix: /swagger
      host: "^hub-alt-bor.corp.*"
      host_regex: true
      service: hub-alt-bor.brett
      rewrite: ""
      bypass_auth: true
      cors:
        origins: "*"
        methods: POST, GET, OPTIONS
        headers:
        - Content-Type
        - x-client-id
        - x-client-secret
        - Authorization
        - x-flow-proto
    meta.helm.sh/release-name: alt-bor
    meta.helm.sh/release-namespace: brett
  creationTimestamp: ...
  labels:
    app: hub
    app.kubernetes.io/instance: alt-bor
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/name: hub
    app.kubernetes.io/version: v1.6.0-rc.26
    deploy.xevo.com/stackname: bor-v0.1-test
    helm.sh/chart: hub-0.0.4
    owner: gateway
    ownerSlack: TODOunknown
  name: hub-alt-bor
  namespace: brett
  resourceVersion: ...
  selfLink: ...
  uid: ...
spec:
  clusterIP: 172.20.147.13
  ports:
  - name: http-rest-hub
    port: 80
    protocol: TCP
    targetPort: http-rest
  - name: http-health
    port: 90
    protocol: TCP
    targetPort: http-health
  selector:
    app.kubernetes.io/instance: alt-bor
    app.kubernetes.io/name: hub
  sessionAffinity: None
  type: ClusterIP
status:
  loadBalancer: {}

Jika saya kemudian mengunggah bagan yang sama persis dengan versi 0.0.5 dan upgrade --install lagi saya mendapatkan yang berikut:
Error: UPGRADE FAILED: failed to replace object: Service "hub-alt-bor" is invalid: spec.clusterIP: Invalid value: "": field is immutable

Satu-satunya perbedaan adalah nilai label helm.sh/chart yang sekarang bernilai hub-0.0.5

Ini adalah pemblokir besar.

@GaramNick tidak ada cukup info tentang layanan yang Anda gunakan bagi kami untuk mereproduksi kesalahan Anda.

@technosophos Apa yang Anda butuhkan? Senang memberikan detail lebih lanjut!

Memperbarui! Pembaruan gagal HANYA saat menggunakan helm upgrade --install w / --force . Lebih sedikit pemblokir sekarang.

Oh! Itu menarik. Itu seharusnya membuat kesalahan lebih mudah dilacak.

Halo @technosophos @bacongobbler, kami memiliki 2 masalah yang sama:

version.BuildInfo{Version:"v3.2.1", GitCommit:"fe51cd1e31e6a202cba7dead9552a6d418ded79a", GitTreeState:"clean", GoVersion:"go1.13.10"}

  1. Isu
    Kami memiliki Service template tanpa clusterIP tetapi kubernetes akan menetapkan clusterIP secara otomatis:
apiVersion: v1
kind: Service
metadata:
  name: {{ .Release.Name }}
  labels:
    app: {{ .Values.image.name }}
    release: {{ .Release.Name }}
spec:
  type: ClusterIP
  ports:
    - port: {{ .Values.service.port }}
      targetPort: {{ .Values.service.port }}
      protocol: TCP
      name: http
  selector:
    app: {{ .Values.image.name }}
    release: {{ .Release.Name }}

setelah bermigrasi ke helm 3 dengan helm 2to3 convert dan coba upgrade rilis yang sama helm3 upgrade --install --force :

failed to replace object: Service "dummy-stage" is invalid: spec.clusterIP: Invalid value: "": field is immutable

jika saya akan melakukan hal yang sama tanpa --force -> helm3 upgrade --install berfungsi dengan baik tanpa kesalahan.

  1. Isu
    jika saya ingin mengubah spec.selector.matchLabels dalam Deployment yang merupakan bidang yang tidak dapat diubah tanpa --force Saya mendapatkan kesalahan:
cannot patch "dummy-stage" with kind Deployment: Deployment.apps "dummy-stage" is invalid: spec.selector: Invalid value: v1.LabelSelector{MatchLabels:map[string]string{"app.kubernetes.io/name":"web-nerf-dummy-app"}, MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: field is immutable

jika saya akan melakukan hal yang sama dengan --force saya mendapatkan kesalahan:

failed to replace object: Deployment.apps "dummy-stage" is invalid: spec.selector: Invalid value: v1.LabelSelector{MatchLabels:map[string]string{"app.kubernetes.io/name":"web-nerf-dummy-app"}, MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: field is immutable

Apakah mungkin menerapkan perilaku yang sama untuk --force seperti di helm 2 karena kita dapat mengupgrade tanpa kesalahan apapun mengajukan immutable?

apiVersion: v1
kind: Service
metadata:
  name: zipkin-proxy
  namespace: monitoring
spec:
  ports:
  - port: 9411
    targetPort: 9411
  selector:
    app: zipkin-proxy
  type: ClusterIP

---

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: zipkin-proxy
  namespace: monitoring
spec:
  replicas: {{ .Values.zipkinProxy.replicaCount }}
  template:
    metadata:
      labels:
        app: zipkin-proxy
      annotations:
        prometheus.io/scrape: 'true'
    spec:
      containers:
      - image: {{ .Values.image.repository }}/zipkin-proxy
        name: zipkin-proxy
        env:
        - name: STORAGE_TYPE
          value: stackdriver

helm upgrade -i --debug --force --namespace monitoring zipkin-proxy --values ./values.yaml.tmp .

Saya telah mencoba dengan menghapus opsi gaya. Saya mencoba dengan v3.1.3, v3.2.0 serta v3.2.1 masih masalah yang sama.

Jejak tumpukan

history.go:52: [debug] getting history for release zipkin-proxy
upgrade.go:84: [debug] preparing upgrade for zipkin-proxy
upgrade.go:92: [debug] performing update for zipkin-proxy
upgrade.go:234: [debug] creating upgraded release for zipkin-proxy
client.go:163: [debug] checking 2 resources for changes
client.go:195: [debug] error updating the resource "zipkin-proxy":
         cannot patch "zipkin-proxy" with kind Service: Service "zipkin-proxy" is invalid: spec.clusterIP: Invalid value: "": field is immutable
client.go:403: [debug] Looks like there are no changes for Deployment "zipkin-proxy"
upgrade.go:293: [debug] warning: Upgrade "zipkin-proxy" failed: cannot patch "zipkin-proxy" with kind Service: Service "zipkin-proxy" is invalid: spec.clusterIP: Invalid value: "": field is immutable
Error: UPGRADE FAILED: cannot patch "zipkin-proxy" with kind Service: Service "zipkin-proxy" is invalid: spec.clusterIP: Invalid value: "": field is immutable
helm.go:75: [debug] cannot patch "zipkin-proxy" with kind Service: Service "zipkin-proxy" is invalid: spec.clusterIP: Invalid value: "": field is immutable
helm.sh/helm/v3/pkg/kube.(*Client).Update
        /home/circleci/helm.sh/helm/pkg/kube/client.go:208
helm.sh/helm/v3/pkg/action.(*Upgrade).performUpgrade
        /home/circleci/helm.sh/helm/pkg/action/upgrade.go:248
helm.sh/helm/v3/pkg/action.(*Upgrade).Run
        /home/circleci/helm.sh/helm/pkg/action/upgrade.go:93
main.newUpgradeCmd.func1
        /home/circleci/helm.sh/helm/cmd/helm/upgrade.go:137
github.com/spf13/cobra.(*Command).execute
        /go/pkg/mod/github.com/spf13/[email protected]/command.go:826
github.com/spf13/cobra.(*Command).ExecuteC
        /go/pkg/mod/github.com/spf13/[email protected]/command.go:914
github.com/spf13/cobra.(*Command).Execute
        /go/pkg/mod/github.com/spf13/[email protected]/command.go:864
main.main
        /home/circleci/helm.sh/helm/cmd/helm/helm.go:74
runtime.main
        /usr/local/go/src/runtime/proc.go:203
runtime.goexit
        /usr/local/go/src/runtime/asm_amd64.s:1357
UPGRADE FAILED
main.newUpgradeCmd.func1
        /home/circleci/helm.sh/helm/cmd/helm/upgrade.go:139
github.com/spf13/cobra.(*Command).execute
        /go/pkg/mod/github.com/spf13/[email protected]/command.go:826
github.com/spf13/cobra.(*Command).ExecuteC
        /go/pkg/mod/github.com/spf13/[email protected]/command.go:914
github.com/spf13/cobra.(*Command).Execute
        /go/pkg/mod/github.com/spf13/[email protected]/command.go:864
main.main
        /home/circleci/helm.sh/helm/cmd/helm/helm.go:74
runtime.main
        /usr/local/go/src/runtime/proc.go:203
runtime.goexit
        /usr/local/go/src/runtime/asm_amd64.s:1357

Saya mengalami masalah ini ketika versi Diagram Helm berubah dan memiliki penerapan yang sudah ada.

Menggunakan Helm v3.2.0

Saya dapat mengonfirmasi bahwa penurunan versi ke 3.1.2 berfungsi.

@ gor181 Bagaimana kita bisa mereproduksi itu? Apa yang rusak di 3.2 tetapi bekerja di 3.1? Bagan (atau setidaknya template svc) dan perintah adalah apa yang kita butuhkan untuk dapat mengetahui apa yang berubah.

@azarudeena @alexandrsemak - untuk Anda berdua, flag --force adalah penyebabnya. Jika Anda menghapus --force , apakah upgrade berhasil?

@technosophos memang mencoba tanpa paksaan tidak berhasil. Berencana untuk mencoba dengan 3.1.2

@azarudeena dapatkah Anda memberikan serangkaian petunjuk untuk mereproduksi masalah Anda? Anda menunjukkan beberapa keluaran dari layanan dan template penerapan, tetapi kemudian Anda juga mereferensikan values.yaml.tmp yang tidak kami ketahui keluarannya, atau juga Chart.yaml.

Bisakah Anda memberikan contoh bagan yang dapat kami gunakan untuk mereproduksi masalah Anda?

@bacongobbler Saya membagikan strukturnya.

Chart.yaml

apiVersion: v1
description: Deploys Stackdriver Trace Zipkin Proxy
name: zipkin-proxy
version: 1.0.0

Saya telah meletakkan template saya yaml di atas,

nilai saya yaml.tmp adalah seperti di bawah ini

zipkinProxy:
  replicaCount: 1

image:
  repository: openzipkin/zipkin

Saya mengemasnya sebagai paket helm --versimenggunakan yang sama dengan peningkatan. Beri tahu saya jika ini berhasil? Akan saya perbarui di sini setelah saya mencoba dengan 3.1.2

Sunting

Mencoba dengan menurunkan versi ke 3.1.2 dan 3.1.1. Masih belum bisa menambal ini.

Saya menghadapi masalah yang sama, tetapi dengan meningkatkan bagan helm melalui penyedia helm terraform.
Setelah saya mengubah force_update = true menjadi force_update = false , kesalahan hilang.

Saya mengalami masalah ini ketika versi Diagram Helm berubah dan memiliki penerapan yang sudah ada.

Menggunakan Helm v3.2.0

Menonaktifkan - flag force membuatnya berfungsi.

@technosophos --force selesaikan masalah dengan ClusterIP saat Anda bermigrasi ke helm 3 karena helm 2 jangan mencoba memutakhirkan ClusterIP saat helm 3 melakukannya.
Helm 3 tidak dapat menyelesaikan masalah dengan file yang tidak dapat diubah sebagai matchLabels

Kubernetes mengubah bagian spec: dari sebuah layanan

Haruskah ini dianggap sebagai cacat desain di Kubernetes di root? https://kubernetes.io/docs/concepts/services-networking/service/#choosing -your-own-ip-address tidak menyebutkan perilaku ini. Saya mengharapkan nilai yang ditetapkan untuk ditempatkan di bagian status .

(Perilaku serupa ada untuk .spec.nodeName dari Pod , tapi itu sepertinya tidak akan mempengaruhi pengguna Helm.)

v3.2.3: gagal dengan --force, ia melewati w / o --force. Tidak ada ClusterIP: dalam templat-bagan. Yang saya kira https://github.com/helm/helm/pull/8000/files seharusnya diperbaiki.

upgrade.go:121: [debug] preparing upgrade for eos-eve-srv-d1
upgrade.go:129: [debug] performing update for eos-eve-srv-d1
upgrade.go:308: [debug] creating upgraded release for eos-eve-srv-d1
client.go:173: [debug] checking 6 resources for changes
client.go:432: [debug] Replaced "eos-eve-srv-d1-fsnode" with kind ServiceAccount for kind ServiceAccount
client.go:432: [debug] Replaced "eos-eve-srv-d1-fsnode-imagepullsecret" with kind Secret for kind Secret
client.go:432: [debug] Replaced "eos-eve-srv-d1-fsnode-config" with kind ConfigMap for kind ConfigMap
client.go:205: [debug] error updating the resource "eos-eve-srv-d1-fsnode":
         failed to replace object: Service "eos-eve-srv-d1-fsnode" is invalid: spec.clusterIP: Invalid value: "": field is immutable
client.go:432: [debug] Replaced "eos-eve-srv-d1-fsnode" with kind Deployment for kind Deployment
client.go:432: [debug] Replaced "eos-eve-srv-d1-fsnode" with kind Ingress for kind Ingress
upgrade.go:367: [debug] warning: Upgrade "eos-eve-srv-d1" failed: failed to replace object: Service "eos-eve-srv-d1-fsnode" is invalid: spec.clusterIP: Invalid value: "": field is immutable
Error: UPGRADE FAILED: failed to replace object: Service "eos-eve-srv-d1-fsnode" is invalid: spec.clusterIP: Invalid value: "": field is immutable
helm.go:84: [debug] failed to replace object: Service "eos-eve-srv-d1-fsnode" is invalid: spec.clusterIP: Invalid value: "": field is immutable
helm.sh/helm/v3/pkg/kube.(*Client).Update
        /private/tmp/helm-20200608-50972-gq0j1j/src/helm.sh/helm/pkg/kube/client.go:218
helm.sh/helm/v3/pkg/action.(*Upgrade).performUpgrade
        /private/tmp/helm-20200608-50972-gq0j1j/src/helm.sh/helm/pkg/action/upgrade.go:322
helm.sh/helm/v3/pkg/action.(*Upgrade).Run
        /private/tmp/helm-20200608-50972-gq0j1j/src/helm.sh/helm/pkg/action/upgrade.go:130
main.newUpgradeCmd.func1
        /private/tmp/helm-20200608-50972-gq0j1j/src/helm.sh/helm/cmd/helm/upgrade.go:144
github.com/spf13/cobra.(*Command).execute
        /private/tmp/helm-20200608-50972-gq0j1j/pkg/mod/github.com/spf13/[email protected]/command.go:842
github.com/spf13/cobra.(*Command).ExecuteC
        /private/tmp/helm-20200608-50972-gq0j1j/pkg/mod/github.com/spf13/[email protected]/command.go:950
github.com/spf13/cobra.(*Command).Execute
        /private/tmp/helm-20200608-50972-gq0j1j/pkg/mod/github.com/spf13/[email protected]/command.go:887
main.main
        /private/tmp/helm-20200608-50972-gq0j1j/src/helm.sh/helm/cmd/helm/helm.go:83
runtime.main
        /usr/local/Cellar/[email protected]/1.13.12/libexec/src/runtime/proc.go:203
runtime.goexit
        /usr/local/Cellar/[email protected]/1.13.12/libexec/src/runtime/asm_amd64.s:1357
UPGRADE FAILED
main.newUpgradeCmd.func1
        /private/tmp/helm-20200608-50972-gq0j1j/src/helm.sh/helm/cmd/helm/upgrade.go:146
github.com/spf13/cobra.(*Command).execute
        /private/tmp/helm-20200608-50972-gq0j1j/pkg/mod/github.com/spf13/[email protected]/command.go:842
github.com/spf13/cobra.(*Command).ExecuteC
        /private/tmp/helm-20200608-50972-gq0j1j/pkg/mod/github.com/spf13/[email protected]/command.go:950
github.com/spf13/cobra.(*Command).Execute
        /private/tmp/helm-20200608-50972-gq0j1j/pkg/mod/github.com/spf13/[email protected]/command.go:887
main.main
        /private/tmp/helm-20200608-50972-gq0j1j/src/helm.sh/helm/cmd/helm/helm.go:83
runtime.main
        /usr/local/Cellar/[email protected]/1.13.12/libexec/src/runtime/proc.go:203
runtime.goexit
        /usr/local/Cellar/[email protected]/1.13.12/libexec/src/runtime/asm_amd64.s:1357

Saya mengamati terbitan ini pada 3.2.3 tetapi tidak pada 3.2.0 . Menonaktifkan kekuatan juga merupakan solusi yang dapat digunakan.

FYI, masalah yang diangkat oleh OP dan komentar yang diangkat di sini tentang --force adalah masalah yang terpisah dan terpisah. Mari coba fokus pada masalah OP di sini.

Untuk memperjelas, masalah yang dijelaskan OP adalah potensi regresi @ n1koo yang diidentifikasi di https://github.com/helm/helm/issues/7956#issuecomment -620749552. Sepertinya itu bug yang sah.

Komentar lain yang menyebutkan penghapusan --force berfungsi untuk mereka adalah perilaku yang disengaja dan diharapkan dari sudut pandang Kubernetes. Dengan --force , Anda meminta Helm untuk membuat permintaan PUT terhadap Kubernetes. Secara efektif, Anda meminta Kubernetes untuk mengambil manifes target Anda (templat yang dirender dalam bagan Anda dari helm upgrade ) sebagai sumber kebenaran dan menimpa sumber daya di cluster Anda dengan manifes yang dirender. Ini identik dengan kubectl apply --overwrite .

Dalam kebanyakan kasus, template Anda tidak menentukan IP cluster, yang berarti helm upgrade --force meminta untuk menghapus (atau mengubah) IP cluster layanan. Ini adalah operasi ilegal dari sudut pandang Kubernetes.

Ini juga didokumentasikan di # 7082.

Ini juga mengapa menghapus --force berfungsi: Helm membuat operasi PATCH, berbeda dengan status live, menggabungkan IP cluster ke dalam manifes yang ditambal, mempertahankan IP cluster selama peningkatan.

Jika Anda ingin menghapus secara paksa dan membuat ulang objek seperti yang dilakukan di Helm 2, lihat # 7431.

Semoga ini menjelaskan banyak hal.

Ke depan, mari coba fokus pada masalah OP di sini.

Apakah ada solusi yang diketahui? Menghadapi masalah yang sama saat mencoba meningkatkan https://github.com/helm/charts/tree/master/stable/rabbitmq-ha dari 1.34.1 ke 1.46.4. Jelas --force atau helm downgrade ke 3.1.3 tidak membantu, menghapus layanan yang dipermasalahkan dan helm upgrade memang membantu

@EvgeniGordeev Ini akan menjadi solusi kasar yang berhasil untuk saya dengan waktu henti yang kecil. Copot pemasangan bagan / instal ulang.

Kami telah mencapai ini juga dengan bagan masuk nginxinc. Kami menggunakan --force secara umum.

Karena masalah ini masih terbuka, apakah ada rencana untuk perbaikan untuk mengatasi ini, atau apakah ini dianggap berfungsi sebagaimana mestinya (sulit untuk membedakan dari ini + masalah lain yang dibuka dengan perilaku yang sama)? Saya membaca satu penjelasan bahwa ini adalah masalah dengan bagan itu sendiri dan clusterIP: "" tidak boleh digunakan dan sebaliknya nilainya harus benar-benar dihilangkan.

Apakah ini sesuatu yang harus kita kejar dengan para pengembang grafik?

@cdunford - saran perbaikan untuk berhenti menggunakan --force seperti yang disarankan https://github.com/helm/helm/issues/7956#issuecomment -643432099.

Humas ini juga dapat mengatasi masalah: # 7431 (seperti yang disarankan dalam komentar itu) ...

Kami mengalami masalah ini untuk kali N, kami menggunakan --force flag juga di pipeline kami.

masalah asli datang bersama dengan helm2, jadi apakah itu juga akan diperbaiki di helm2? @bayu_joo

@bacongobbler mengapa Anda mengatakan memberikan "kekuatan" berbeda dari masalah jika menghapusnya ATAU menurunkan versi membantu?

Maksud saya, saya baru saja mengalami masalah dengan Helm 3.3.4, https://artifacthub.io/packages/helm/bitnami/nginx chart dan tidak ada nilai yang berubah. Diuji pada tiga cloud yang berbeda: GCP / GKE, Azure / AKS, dan AWS / EKS, gagal pada ketiganya.

Saya langsung bekerja setelah saya menurunkan versi Helm ke 3.1.3 DAN juga mengerjakan 3.3.4 tanpa bendera "--force".

Saya pikir saya membuatnya cukup jelas dalam komentar saya sebelumnya bahwa ada dua kasus unik yang terpisah di mana pengguna dapat melihat kesalahan ini. Salah satunya adalah kasus OP. Yang lainnya adalah dari penggunaan --force. Kami fokus pada masalah OP di sini.

Untuk menghormati orang-orang yang mengalami masalah yang sama dengan OP, harap berhenti membajak utas ini untuk membicarakan - force. Kami mencoba membahas bagaimana menyelesaikan masalah OP. Jika Anda ingin berbicara tentang topik yang tidak relevan dengan masalah yang dijelaskan OP, silakan buka tiket baru atau lihat saran yang saya buat sebelumnya.

@tibetsam sehubungan dengan perbaikan ini untuk Helm 2: no. Kami tidak lagi menyediakan perbaikan bug untuk Helm 2. Lihat https://helm.sh/blog/helm-v2-deprecation-timeline/ untuk info lebih lanjut.

Saya rasa saya berhasil mereproduksi masalah OP dengan bagan helm jupytherhub.
Mudah-mudahan, dengan petunjuk di bawah ini, Anda akan berhasil mereproduksi masalah tersebut:


Penting
Bagan helm Jupyterhub tidak berisi bidang spec.clusterIP dalam spesifikasi Layanannya, seperti yang Anda lihat (misalnya) di sini: https://github.com/jupyterhub/zero-to-jupyterhub-k8s/blob/c0a43af12a89d54bcd6dcb927fdcc2f623a14aca /jupyterhub/templates/hub/service.yaml#L17 -L29


Saya menggunakan helm dan baik hati untuk mereproduksi masalah:

➜ helm version
version.BuildInfo{Version:"v3.4.0", GitCommit:"7090a89efc8a18f3d8178bf47d2462450349a004", GitTreeState:"clean", GoVersion:"go1.14.10"}

➜ kind version
kind v0.9.0 go1.15.2 linux/amd64

➜ kubectl version
Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.2", GitCommit:"52c56ce7a8272c798dbc29846288d7cd9fbae032", GitTreeState:"clean", BuildDate:"2020-04-16T11:56:40Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.1", GitCommit:"206bcadf021e76c27513500ca24182692aabd17e", GitTreeState:"clean", BuildDate:"2020-09-14T07:30:52Z", GoVersion:"go1.15", Compiler:"gc", Platform:"linux/amd64"}

Bagaimana cara memperbanyak

  1. Buat cluster jenis baru
kind create cluster
  1. Buat file bernama config.yaml dengan konten berikut (hex yang dihasilkan secara acak):
proxy:
  secretToken: "3a4bbf7405dfe1096ea2eb9736c0df299299f94651fe0605cfb1c6c5700a6786"

FYI saya mengikuti instruksi untuk instalasi file helm ( tautan )

  1. Tambahkan repositori helm
helm repo add jupyterhub https://jupyterhub.github.io/helm-chart/
helm repo update
  1. Instal grafik (dengan opsi --force )
RELEASE=jhub
NAMESPACE=jhub

helm upgrade --cleanup-on-fail --force \
  --install $RELEASE jupyterhub/jupyterhub \
  --namespace $NAMESPACE \
  --create-namespace \
  --version=0.9.0 \
  --values config.yaml
  1. Ulangi langkah 5

Kesalahan:

Error: UPGRADE FAILED: failed to replace object: PersistentVolumeClaim "hub-db-dir" is invalid: spec: Forbidden: spec is immutable after creation except resources.requests for bound claims
  core.PersistentVolumeClaimSpec{
        AccessModes:      []core.PersistentVolumeAccessMode{"ReadWriteOnce"},
        Selector:         nil,
        Resources:        core.ResourceRequirements{Requests: core.ResourceList{s"storage": {i: resource.int64Amount{value: 1073741824}, s: "1Gi", Format: "BinarySI"}}},
-       VolumeName:       "",
+       VolumeName:       "pvc-c614de5c-4749-4755-bd3a-6e603605c44e",
-       StorageClassName: nil,
+       StorageClassName: &"standard",
        VolumeMode:       &"Filesystem",
        DataSource:       nil,
  }
 && failed to replace object: Service "hub" is invalid: spec.clusterIP: Invalid value: "": field is immutable && failed to replace object: Service "proxy-api" is invalid: spec.clusterIP: Invalid value: "": field is immutable && failed to replace object: Service "proxy-public" is invalid: spec.clusterIP: Invalid value: "": field is immutable

Saya memimpin 3.3.4 dan ini masih menjadi masalah

Masalah Helm 2.14.1 hadir baik tanpa --force

Solusi : beralih ke type.spec: NodePort perbaiki pemutakhiran helmchart saya.

Kami memiliki masalah yang sama di v3.4.1 dengan --force flag.

@bacongobbler Saya tahu Anda telah berusaha dengan waspada untuk menjaga masalah OP (terpisah dari # 6378) agar tidak dibajak. Saya pikir mungkin membantu posting tersebut untuk meninjau pesan kesalahan mereka untuk mengetahui apakah utas ini untuk mereka atau tidak:

Apakah kesalahan Anda pesan "Error: Comodo GAGAL: gagal untuk _replace_ ..." dan Anda _did digunakan_ force dalam perintah Anda? GOTO # 6378

Apakah pesan kesalahan Anda "Kesalahan: UPGRADE GAGAL: tidak bisa _patch_ ..." dan Anda _ tidak menggunakan _ - force dalam perintah Anda? Silakan posting dalam edisi ini bagaimana Anda mereproduksinya.

@bayu_joo

helm3 upgrade concourse concourse/concourse -f temp.yaml  --force
Error: UPGRADE FAILED: failed to replace object: Service "concourse-web" is invalid: spec.clusterIP: Invalid value: "None": field is immutable && failed to replace object: Service "concourse-web-prometheus" is invalid: spec.clusterIP: Invalid value: "": field is immutable && failed to replace object: Service "concourse-web-worker-gateway" is invalid: spec.clusterIP: Invalid value: "": field is immutable

helm3 upgrade concourse concourse/concourse -f temp.yaml
Error: UPGRADE FAILED: cannot patch "concourse-web" with kind Service: Service "concourse-web" is invalid: spec.clusterIP: Invalid value: "None": field is immutable

Saya mengalami masalah yang sama di Helm 3.4.2. Saya menjalankan bagan helm yang membuat penerapan, akun layanan, dan layanan. Saya menambahkan label ke kumpulan label saya yang ada di bagan saya pada penerapan, dan sekarang menolak untuk meningkatkan:

helm upgrade test-whale charts/app-template/ --install --values values.yaml --namespace whale --force
Error: UPGRADE FAILED: failed to replace object: Service "test-whale" is invalid: spec.clusterIP: Invalid value: "": field is immutable && failed to replace object: Deployment.apps "test-whale-canary" is invalid: spec.selector: Invalid value: v1.LabelSelector{MatchLabels:map[string]string{"app":"test-whale", "app-id":"302040", "environment":"test", "version":"latest"}, MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: field is immutable && failed to replace object: Deployment.apps "test-whale" is invalid: spec.selector: Invalid value: v1.LabelSelector{MatchLabels:map[string]string{"app":"test-whale", "app-id":"302040", "environment":"test", "version":"latest"}, MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: field is immutable

Pada dasarnya, sepertinya Anda tidak dapat menambahkan label setelah penggunaan helm awal.

Kedengarannya mengerikan, tetapi dapatkah Helm menerapkan daftar "bidang yang tidak dapat diubah" yang akan menerima perlakuan khusus?

Dalam kasus ini, "bidang yang tidak dapat diubah" akan menjadi objek Layanan spec.clusterIP - Helm akan menganggapnya tidak dapat diubah dan menghasilkan permintaan API yang akan a) tidak mencoba menggantinya, b) tidak mencoba menghapusnya , c) tidak mencoba memperbaruinya.

Dalam praktiknya, Helm akan mencari nilai saat ini dari bidang yang tidak dapat diubah dan menyertakan nilai tersebut dalam payload permintaan API. Akibatnya, server API k8s akan melihat permintaan Helm sebagai "ok, mereka tidak mencoba mengubah bidang ini".

Situasi saat ini adalah Helm sangat tidak dapat diandalkan terutama dengan sumber daya Layanan karena Helm berasumsi kebenaran sumber daya yang diberikan. Ini adalah asumsi salah yang mengarah ke masalah dalam masalah ini, karena sumber daya mungkin telah menerima properti sisi server baru yang tidak disadari Helm. Oleh karena itu, Helm harus mengetahui bidang mana yang memerlukan perlakuan khusus agar dapat menjadi warga negara k8 yang patuh.

PS. Juga kubectl mengimplementasikan banyak sisi-klien logika, yang memungkinkan kubectl untuk bekerja dengan persyaratan implisit ini.

@ jbilliau-rcd

cobalah untuk tidak menggunakan --force

@pra

Saya pikir ada sesuatu yang aneh terjadi dengan penggabungan tiga cara. Mungkin anotasi yang terakhir diterapkan entah bagaimana tidak direkam dengan benar.

Saya akhirnya memahaminya; tampaknya Anda dapat mengubah label pada Deployment dan pada spesifikasi pod, tetapi BUKAN pada pemilih pertandingan ...... Kubernetes tidak menyukainya. Yang aneh bagi saya; bagaimana lagi saya bisa mengubah penerapan saya untuk hanya memilih pod di version "v2" selama, katakanlah, penerapan canary? Saat ini, saya tidak punya cara untuk melakukan itu, jadi saya bingung pada bagian itu.

Upgrade ke helm versi 3.5.0 menyelesaikan masalah.

Upgrade ke helm versi 3.5.0 menyelesaikan masalah.

bagaimana sebenarnya?

Upgrade ke helm versi 3.5.0 menyelesaikan masalah.

Helm versi 3.5.0 masih tidak berfungsi.
Tapi tanpa --force sudah bekerja.

Pukul ini di helm 3.5.2

Saya mencoba menghapus --force tetapi masih mendapatkan masalah yang sama.

Upgrade "gateway" failed: failed to replace object: Service "ingress"
    is invalid: spec.clusterIPs[0]: Invalid value: []string(nil): primary clusterIP
    can not be unset

Sejauh ini menemukan solusi yang masuk akal - --reuse-values . Bekerja untuk kasus saya.

3.5.2 masih mendapatkan masalah ini, dengan / tanpa --reuse-values

3.5.3 memiliki ini juga: /

Apakah halaman ini membantu?
0 / 5 - 0 peringkat