<p>la mise à niveau de la barre échoue avec spec.clusterIP: valeur non valide: "": le champ est immuable</p>

Pas assez d'informations ont été fournies pour se reproduire. Veuillez nous dire comment créer un graphique reproductible et quelles commandes Helm vous avez utilisées.

Salut, voici les étapes de reproduction
Avoir deux fichiers yaml de services comme ci-dessous.

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

Ensuite, mettez-y deux fichiers dans helm1 / templates / puis installez. Il montre que le service prometheus utilise clusterIP et que la version nginx est 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

Maintenant, mettez à jour la section pour nginx.yaml vers la nouvelle version 1.16

        image: nginx:1.16

et prometheus.yaml en le changeant en LoadBalancer.

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

Maintenant, mettez-les en tant que helm2 et effectuez la mise à niveau. Ensuite, vous pouvez voir que la mise à niveau génère des erreurs, mais le service nginx passe par la mise à niveau vers une nouvelle version, mais le prometheus n'est pas mis à niveau car il utilise toujours l'IP de 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

montre la liste de barre

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

histoire de la barre

# 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

Nous avons le même comportement avec la v3.2.0, la rétrogradation à la v3.1.3 est notre correctif temporaire

J'en ai beaucoup avec ma migration Helm 2 -> 3. Lorsque j'essaye de mettre à niveau les versions converties pour la première fois, j'en reçois beaucoup. Ceci concerne les graphiques Nginx Ingress, Prometheus Operator, Graylog et Jaeger jusqu'à présent. La plupart d'entre eux me contentent de supprimer les services et de laisser Helm les recréer, mais pour Nginx Ingress, ce n'est pas une option ...

Je viens de trouver ce https://github.com/helm/helm/issues/6378#issuecomment -557746499 qui explique le problème dans mon cas.

Clôture en double du # 6378. @cablespaghetti a trouvé l'explication plus profonde de ce comportement, qui est décrite en détail.

Faites-nous savoir si cela ne fonctionne pas pour vous.

@GaramNick pourquoi la rétrogradation

@bacongobbler Pendant que vous êtes ici. Existe-t-il un moyen de résoudre cette situation sans supprimer la version et redéployer? Je ne peux pas sembler un moyen de le faire sous helm 2 ou 3. Je veux pirater les données de version existantes donc Helm pense que le clusterIP a toujours été omis et donc aucun correctif n'est nécessaire.

Avez-vous essayé kubectl edit ?

Nous avons le même problème et la rétrogradation à 3.1.3 a également corrigé pour nous. Je suppose que cela a à voir avec la nouvelle logique de https://github.com/helm/helm/pull/7649/commits/d829343c1514db17bee7a90624d06cdfbffde963 considérant que c'est un Create et non une mise à jour essayant ainsi de mettre vide IP et ne pas réutiliser celui rempli

Une trouvaille intéressante. merci d'avoir enquêté.

@jlegrone a-t-il une chance que vous ayez le temps d'examiner cela?

@bacongobbler Notre pipeline CI / CD utilise Helm pour mettre à jour notre application qui inclut un service de type ClusterIP. La commande:

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/

Sur v3.2.0, cette commande échoue avec Service "service-name" is invalid: spec.clusterIP: Invalid value: "": field is immutable

Sur la v3.1.3, cela fonctionne très bien.

Faites-moi savoir si vous souhaitez avoir plus d'informations.

Pareil ici. Nous avons eu le service.yaml suivant fonctionnant bien avec helm2 pendant de nombreux mois.
Après la migration, la commande helm 3.2 helm upgrade échoué avec l'erreur de sauvegarde comme ci-dessus. Le passage à la version 3.1.3 l'a résolu.

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 }}

Nous avons le même problème et le passage à la version 3.1.3 l'a corrigé également pour nous. Je suppose que cela a à voir avec la nouvelle logique dans d829343 considérant que c'est une création et non une mise à jour essayant ainsi de définir une adresse IP vide et de ne pas réutiliser celle remplie

@ n1koo Pouvez-vous expliquer pourquoi vous pensez que c'est le code à l'origine du problème? Comme il s'agit du code d'installation et non de mise à niveau, le code de 3.1 est également un ` create et cela fonctionne.

Je suis en train de passer en revue le problème avec @ n1koo . La méthode Create contournera le différentiel à 3 voies normal sur le service, ce qui entraînera la définition du clusterIP du service sur "" au lieu de la valeur renseignée par Kubernetes. En conséquence, le manifeste envoyé au serveur d'API _ semble_ réinitialiser l'adresse IP du cluster, ce qui est illégal sur un service (et certainement pas ce que l'utilisateur voulait).

Nous sommes toujours à la recherche de cela et je mettrai à jour si nous en apprenons plus.

Donc, https://github.com/helm/helm/issues/6378#issuecomment -557746499 est correct. Veuillez le lire avant de continuer avec ce problème. Si clusterIP: "" est défini, Kubernetes attribuera une adresse IP. Lors de la prochaine mise à jour de Helm, si clusterIP:"" nouveau, cela donnera l'erreur ci-dessus, car il semble _à Kubernetes_ que vous essayez de réinitialiser l'adresse IP. (Oui, Kubernetes modifie la section spec: d'un service!)

Lorsque la méthode Create contourne la différence à trois voies, elle définit clusterIP: "" au lieu de la définir sur l'adresse IP attribuée par Kubernetes.

Reproduire:

$ 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

La deuxième fois que vous exécutez la mise à niveau, elle échouera.

Je ne peux pas reproduire le cas de @IdanAdar sur master .

@GaramNick il n'y a pas assez d'informations sur le service que vous utilisez pour que nous puissions reproduire votre erreur.

Ma situation:
version.BuildInfo{Version:"v3.2.0", GitCommit:"e11b7ce3b12db2941e90399e874513fbd24bcb71", GitTreeState:"clean", GoVersion:"go1.13.10"}
également testé avec
version.BuildInfo{Version:"v3.2.1", GitCommit:"fe51cd1e31e6a202cba7dead9552a6d418ded79a", GitTreeState:"clean", GoVersion:"go1.13.10"}

étant donné le modèle de service suivant:

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

ce qui donne ce qui suit après 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: {}

Si je télécharge ensuite exactement le même graphique que la version 0.0.5 et upgrade --install nouveau, j'obtiens ce qui suit:
Error: UPGRADE FAILED: failed to replace object: Service "hub-alt-bor" is invalid: spec.clusterIP: Invalid value: "": field is immutable

La seule différence est la valeur de l'étiquette helm.sh/chart qui a maintenant une valeur de hub-0.0.5

C'est un énorme bloqueur.

@GaramNick il n'y a pas assez d'informations sur le service que vous utilisez pour que nous puissions reproduire votre erreur.

@technosophos De quoi avez-vous besoin? Heureux de fournir plus de détails!

Mettre à jour! La mise à jour échoue UNIQUEMENT lors de l'utilisation de helm upgrade --install w / --force . Moins de bloqueur maintenant.

Oh! C'est intéressant. Cela devrait faciliter la traçabilité de l'erreur.

Bonjour @technosophos @bacongobbler, nous avons les mêmes 2 problèmes:

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

1. Publier
   Nous avons Service modèle clusterIP mais kubernetes attribuera automatiquement clusterIP :

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 }}

après avoir migré vers helm 3 avec helm 2to3 convert et essayez de mettre à jour la même version helm3 upgrade --install --force :

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

si je fais la même chose sans --force -> helm3 upgrade --install fonctionne bien sans erreur.

1. Publier
   si je veux changer spec.selector.matchLabels dans le déploiement qui sont un champ immuable sans --force j'obtiens une erreur:

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

si je fais la même chose avec --force j'obtiens une erreur:

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

Est-il possible d'implémenter le même comportement pour --force que dans helm 2 parce que nous pouvons sans aucune erreur mettre à niveau un fichier immuable?

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 .

J'ai essayé de supprimer l'option de force. J'ai essayé avec v3.1.3, v3.2.0 ainsi que v3.2.1 toujours le même problème.

Trace de la pile

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

Je rencontre ce problème lorsque la version de Helm Chart change et que j'ai un déploiement existant.

Utilisation de Helm v3.2.0

Je peux confirmer que le passage à la version 3.1.2 fonctionne.

@ gor181 Comment pouvons-nous reproduire cela? Qu'est-ce qui a cassé sur 3.2 mais a fonctionné sur 3.1? Le graphique (ou au moins le modèle svc) et les commandes sont ce dont nous avons besoin pour être en mesure de comprendre ce qui a changé.

@azarudeena @alexandrsemak - pour vous deux, c'est le drapeau --force qui en est la cause. Si vous supprimez --force , la mise à jour fonctionne-t-elle?

@technosophos a essayé sans force n'a pas fonctionné. Planification d'essayer avec 3.1.2

@azarudeena pouvez-vous s'il vous plaît fournir un ensemble d'instructions pour reproduire votre problème? Vous avez montré une sortie d'un service et d'un modèle de déploiement, mais vous avez également référencé un values.yaml.tmp dont nous ne connaissons pas la sortie, ni le Chart.yaml.

Pouvez-vous s'il vous plaît fournir un exemple de graphique que nous pouvons utiliser pour reproduire votre problème?

@bacongobbler Je partage la structure.

Chart.yaml

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

J'ai mis mon template yaml dessus,

ma valeur yaml.tmp est comme ci-dessous

zipkinProxy:
  replicaCount: 1

image:
  repository: openzipkin/zipkin

Je le package en tant que package helm --versionen utilisant la même chose avec la mise à niveau. Laissez-moi savoir si cela fonctionne? Je mettrai à jour ici une fois que j'essayerai avec 3.1.2

Éditer

Essayé en rétrogradant à 3.1.2 et 3.1.1. Je ne parviens toujours pas à corriger ce problème.

J'ai rencontré le même problème, mais avec la mise à niveau d'un graphique de barre via le fournisseur de barre terraform.
Après avoir changé le force_update = true en force_update = false , l'erreur a disparu.

Je rencontre ce problème lorsque la version de Helm Chart change et que j'ai un déploiement existant.

Utilisation de Helm v3.2.0

La désactivation de l'indicateur --force l'a fait fonctionner.

@technosophos --force résout le problème avec ClusterIP lorsque vous migrez vers helm 3 en tant que helm 2, n'essayez pas de mettre à niveau ClusterIP lorsque helm 3 le fait.
Helm 3 ne parvient pas à résoudre le problème avec le fichier immuable en tant que matchLabels

Kubernetes modifie la section spec: d'un service

Cela devrait-il être considéré comme un défaut de conception dans Kubernetes à la racine? https://kubernetes.io/docs/concepts/services-networking/service/#choosing -your-own-ip-address ne fait aucune mention de ce comportement. Je m'attendais à ce qu'une valeur attribuée soit placée dans la section status .

(Un comportement similaire existe pour le .spec.nodeName d'un Pod , mais il est peu probable que cela affecte les utilisateurs de Helm.)

v3.2.3: il échoue avec --force, il passe sans --force. Non ClusterIP: dans le modèle de graphique. Ce que je suppose que https://github.com/helm/helm/pull/8000/files était censé corriger.

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

J'observe ce problème sur 3.2.3 mais pas sur 3.2.0 . La désactivation de la force était également une solution de contournement utilisable.

Pour info, la question soulevée par le PO et les commentaires soulevés ici à propos de --force sont des problèmes distincts et distincts. Essayons de nous concentrer sur le problème d'OP ici.

Pour clarifier, le problème décrit par OP est une régression potentielle @ n1koo identifiée dans https://github.com/helm/helm/issues/7956#issuecomment -620749552. Cela semble être un bug légitime.

Les autres commentaires mentionnant la suppression de --force fonctionnant pour eux sont un comportement intentionnel et attendu du point de vue de Kubernetes. Avec --force , vous demandez à Helm de faire une requête PUT contre Kubernetes. En fait, vous demandez à Kubernetes de prendre vos manifestes cibles (les modèles rendus dans votre graphique à partir de helm upgrade ) comme source de vérité et de remplacer les ressources de votre cluster par les manifestes rendus. Ceci est identique à kubectl apply --overwrite .

Dans la plupart des cas, vos modèles ne spécifient pas d'adresse IP de cluster, ce qui signifie que helm upgrade --force demande de supprimer (ou de modifier) ​​l'adresse IP de cluster du service. Il s'agit d'une opération illégale du point de vue de Kubernetes.

Ceci est également documenté dans # 7082.

C'est aussi pourquoi la suppression de --force fonctionne: Helm effectue une opération PATCH, différente de l'état réel, fusionnant l'adresse IP du cluster dans le manifeste corrigé, préservant l'adresse IP du cluster pendant la mise à niveau.

Si vous voulez supprimer et recréer de force l'objet comme ce qui a été fait dans Helm 2, jetez un œil à # 7431.

J'espère que cela clarifie les choses.

Pour aller de l'avant, essayons de nous concentrer sur le problème d'OP ici.

Existe-t-il des solutions de contournement connues? Face au même problème lors de la tentative de mise à niveau de https://github.com/helm/charts/tree/master/stable/rabbitmq-ha de 1.34.1 à 1.46.4. Évidemment, --force ou la rétrogradation de la barre à 3.1.3 n'a pas aidé, la suppression du service en question et helm upgrade a aidé

@EvgeniGordeev Cela va être une solution grossière qui a fonctionné pour moi avec un petit temps d'arrêt. Désinstallez le graphique / réinstallez.

Nous avons également touché cela avec le graphique d'entrée de nginxinc. Nous utilisons généralement --force .

Étant donné que ce problème est toujours ouvert, existe-t-il des plans pour une sorte de solution pour résoudre ce problème, ou est-ce que cela fonctionne comme prévu (il est difficile de discerner à partir de cela + les autres problèmes ouverts avec le même comportement)? J'ai lu une explication selon laquelle il s'agit d'un problème avec le graphique qui lui-même et clusterIP: "" ne doit pas être utilisé et à la place, la valeur doit être complètement omise.

Est-ce quelque chose que nous devrions rechercher avec les développeurs de graphiques?

@cdunford - le correctif suggéré pour arrêter d'utiliser --force comme cela a été suggéré https://github.com/helm/helm/issues/7956#issuecomment -643432099.

Ce PR pourrait également aborder le problème: # 7431 (comme suggéré dans ce commentaire) ...

Nous avons rencontré ce problème pour la N fois, nous utilisons également l'indicateur --force dans notre pipeline.

problème d'origine est venu avec helm2, alors sera-t-il également corrigé dans helm2? @bacongobbler

@bacongobbler pourquoi dites-vous que fournir de la «force» est différent du problème si le décapage OU la rétrogradation aide?

Je veux dire, je viens de rencontrer le problème avec le graphique Helm 3.3.4, https://artifacthub.io/packages/helm/bitnami/nginx et aucune valeur n'a été modifiée. Testé sur trois clouds différents: GCP / GKE, Azure / AKS et AWS / EKS, a échoué sur les trois.

Immédiatement après avoir rétrogradé Helm à 3.1.3 ET aussi travaillé sur 3.3.4 sans le drapeau "--force".

Je pensais avoir clairement indiqué dans mon commentaire précédent qu'il existe deux cas distincts et uniques dans lesquels un utilisateur peut voir cette erreur. L'un est le cas d'OP. L'autre provient de l'utilisation de --force. Nous nous concentrons ici sur le problème d'OP.

Par respect pour les personnes qui rencontrent le même problème que l'OP, arrêtez de détourner ce fil pour parler de --force. Nous essayons de discuter de la façon de résoudre le problème d'OP. Si vous souhaitez parler de sujets sans rapport avec le problème décrit par le PO, veuillez ouvrir un nouveau ticket ou consulter les suggestions que j'ai faites précédemment.

@tibetsam en ce qui concerne la problème pour Helm 2: non. Nous ne fournissons plus de correctifs de bogues pour Helm 2. Voir https://helm.sh/blog/helm-v2-deprecation-timeline/ pour plus d'informations.

Je pense que j'ai réussi à reproduire le problème d'OP avec le graphique de barre de jupytherhub.
Espérons qu'avec les instructions ci-dessous, vous réussirez à reproduire le problème:

Important
Le graphique de barre Jupyterhub ne contient pas spec.clusterIP champ https://github.com/jupyterhub/zero-to-jupyterhub-k8s/blob/c0a43af12a89d54bcd6dcb927fdcc2f623a14aca /jupyterhub/templates/hub/service.yaml#L17 -L29

J'utilise helm et aimable pour reproduire le problème:

➜ 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"}

Comment reproduire

1. Créer un nouveau cluster de types

kind create cluster

1. Créez un fichier appelé config.yaml avec le contenu suivant (hexadécimal généré aléatoirement):

proxy:
  secretToken: "3a4bbf7405dfe1096ea2eb9736c0df299299f94651fe0605cfb1c6c5700a6786"

Pour info, je suis les instructions pour l'installation du fichier de barre ( lien )

1. Ajouter un référentiel de barre

helm repo add jupyterhub https://jupyterhub.github.io/helm-chart/
helm repo update

1. Installez le graphique (avec l'option --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. Répétez l'étape 5

Erreur:

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

Je suis à la barre 3.3.4 et c'est toujours un problème

Problème Helm 2.14.1 présent soit sans / sans --force

Solution de contournement : passer à type.spec: NodePort corrigé ma mise à niveau de helmchart.

Nous avons le même problème sur la v3.4.1 avec l'option --force.

@bacongobbler Je sais que vous avez essayé avec vigilance d'éviter que le problème du PO (séparé de # 6378) ne soit détourné. J'ai pensé que cela pourrait aider ceux qui postent à revoir leur message d'erreur pour savoir si ce fil est pour eux ou non:

Votre message d'erreur est-il «Erreur: ÉCHEC DE LA MISE À NIVEAU: échec de _ avez

Votre message d'erreur est-il «Erreur: ÉCHEC DE LA MISE À NIVEAU: impossible de n'avez pas utilisé _ --force dans votre commande? Veuillez indiquer dans ce numéro comment vous l'avez reproduit.

@zpittmansf

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

J'ai le même problème sur Helm 3.4.2. J'exécute un helm-chart qui crée un déploiement, un compte de service et un service. J'ajoute une étiquette à mon ensemble d'étiquettes existant sur mon graphique sur le déploiement, et maintenant il refuse la mise à niveau:

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

Fondamentalement, il semble que vous ne puissiez jamais ajouter d'étiquette après le déploiement initial de la barre.

Cela semble terrible, mais Helm pourrait-il implémenter une liste de "champs immuables" qui recevraient un traitement spécial?

Dans ce cas, un "champ immuable" serait le spec.clusterIP l'objet Service - Helm le considérerait comme immuable et générerait une telle requête API qui a) n'essaierait pas de le remplacer, b) n'essaierait pas de le supprimer , c) n'essayez pas de le mettre à jour.

En pratique, Helm recherchait la valeur actuelle d'un champ immuable et inclurait cette valeur dans la charge utile de la requête API. En conséquence, le serveur API k8s verrait la requête de Helm comme "ok, ils n'essaient pas de modifier ce champ".

La situation actuelle est que Helm est très peu fiable avec en particulier les ressources de service, car Helm suppose qu'il détient la vérité d'une ressource donnée. Il s'agit d'une fausse hypothèse qui conduit au problème dans ce problème, car une ressource peut avoir reçu de nouvelles propriétés côté serveur dont Helm n'est pas au courant. Par conséquent, Helm doit savoir quels domaines nécessitent un traitement spécial pour être un citoyen k8 conforme.

PS. De plus, kubectl implémente beaucoup de logique côté client, ce qui permet à kubectl de fonctionner avec ces exigences implicites.

@ jbilliau-rcd

essayez de ne pas utiliser --force

@pré

Je pense qu'il se passe quelque chose de farfelu avec la fusion à trois. Peut-être que la dernière annotation appliquée est mal enregistrée d'une manière ou d'une autre.

J'ai fini par comprendre; apparemment, vous pouvez changer les étiquettes sur un Deployment et sur la spécification du pod, mais PAS sur le sélecteur de correspondance ...... Kubernetes n'aime pas ça. Ce qui m'est étrange; comment suis-je censé modifier mon déploiement pour sélectionner uniquement des pods sur version "v2" pendant, par exemple, un déploiement Canary? Actuellement, je n'ai aucun moyen de le faire, donc je suis confus sur cette partie.

La mise à niveau vers la version 3.5.0 de helm a résolu le problème.

La mise à niveau vers la version 3.5.0 de helm a résolu le problème.

de quelle façon précisément?

La mise à niveau vers la version 3.5.0 de helm a résolu le problème.

La version 3.5.0 de Helm ne fonctionne toujours pas.
Mais sans --force c'est travaillé.

Frappez ceci dans la barre 3.5.2

J'ai essayé de supprimer --force mais j'ai toujours le même problème.

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

Jusqu'à présent, nous avons trouvé une solution de contournement raisonnable - --reuse-values flag. Fonctionne pour mon cas.

3.5.2 a toujours ce problème, avec / sans --reuse-values

3.5.3 a également ceci: /