Helm: Helm 3 - upgrade nginx - spec.clusterIP : valeur non valide : " : le champ est immuable

Cela est probablement lié à un changement récent dans Helm 3 où il utilise désormais une stratégie de correctif de fusion à trois voies similaire à kubectl. Voir #6124

Si vous pouvez fournir des étapes sur la façon de reproduire cela, ce serait merveilleux. Merci!

Sûr!

J'ai créé un cluster AKS.

Je crée une adresse IP publique dans le groupe de ressources MC_*.

J'ai stocké l'adresse IP de cette IP publique dans $ip.

Ensuite, en gros, exécutez cette commande deux fois :

./helm upgrade --install
--set rbac.create=false
--set contrôleur.replicaCount=2
--set controller.service.loadBalancerIP=$ip
--wait main-ingress stable/nginx-ingress

Ceci est similaire à ce qui est fait dans https://docs.microsoft.com/en-us/azure/aks/ingress-static-ip.

La différence est que je fais une mise à niveau de helm --install deux fois. Le but de cela est d'avoir une seule ligne de commande (inconditionnelle) dans mon CI/CD.

Faites-moi savoir si vous avez besoin de plus de détails pour reproduire.

Était-ce suffisant pour se reproduire ? Je peux fournir un script bash si cela peut aider.

Désolé, je n'ai pas encore eu le temps de répondre au Helm Summit EU pour la semaine.

Ah... pas de soucis. Profitez du sommet !

je rencontre aussi ce problème

$ helm version --short
v3.0.0-beta.3+g5cb923e

Le graphique nginx-ingress s'installe correctement lors de la première exécution, mais lors d'une mise à niveau ...

$ helm upgrade --install first-chart stable/nginx-ingress --namespace infra
client.go:357: Cannot patch Service: "first-chart-nginx-ingress-controller" (Service "first-chart-nginx-ingress-controller" is invalid: spec.clusterIP: Invalid value: "": field is immutable)
client.go:376: Use --force to force recreation of the resource
client.go:357: Cannot patch Service: "first-chart-nginx-ingress-default-backend" (Service "first-chart-nginx-ingress-default-backend" is invalid: spec.clusterIP: Invalid value: "": field is immutable)
client.go:376: Use --force to force recreation of the resource
Error: UPGRADE FAILED: Service "first-chart-nginx-ingress-controller" is invalid: spec.clusterIP: Invalid value: "": field is immutable && Service "first-chart-nginx-ingress-default-backend" is invalid: spec.clusterIP: Invalid value: "": field is immutable

$ helm ls -n infra
NAME            NAMESPACE       REVISION        UPDATED                                 STATUS          CHART               
first-chart     infra           1               2019-09-17 16:15:25.513997106 -0500 CDT deployed        nginx-ingress-1.20.0
first-chart     infra           2               2019-09-17 16:15:30.845249671 -0500 CDT failed          nginx-ingress-1.20.0

Je pense qu'il s'agit d'un problème avec le graphique nginx-ingress, pas avec helm3. Par défaut, le graphique essaiera toujours de transmettre controller.service.clusterIP = "" et defaultBackend.service.clusterIP = "" moins que vous ne définissiez controller.service.omitClusterIP=true et defaultBackend.service.omitClusterIP=true .

lien vers les sources :
https://github.com/helm/charts/blob/master/stable/nginx-ingress/values.yaml#L321
https://github.com/helm/charts/blob/master/stable/nginx-ingress/templates/controller-service.yaml#L22

solution de contournement:

$ helm upgrade --install ingress-test stable/nginx-ingress --set controller.service.omitClusterIP=true --set defaultBackend.service.omitClusterIP=true

J'ai essayé de le faire, mais j'ai toujours la même erreur

helm upgrade --install ingx stable/nginx-ingress -f ingx-values.yaml                                             1 ↵
client.go:357: Cannot patch Service: "ingx-nginx-ingress-controller" (Service "ingx-nginx-ingress-controller" is invalid: spec.clusterIP: Invalid value: "": field is immutable)
client.go:376: Use --force to force recreation of the resource
client.go:357: Cannot patch Service: "ingx-nginx-ingress-default-backend" (Service "ingx-nginx-ingress-default-backend" is invalid: spec.clusterIP: Invalid value: "": field is immutable)
client.go:376: Use --force to force recreation of the resource
Error: UPGRADE FAILED: Service "ingx-nginx-ingress-controller" is invalid: spec.clusterIP: Invalid value: "": field is immutable && Service "ingx-nginx-ingress-default-backend" is invalid: spec.clusterIP: Invalid value: "": field is immutable

valeurs-ingx.yaml

rbac:
  create: true
controller:
  service:
    externalTrafficPolicy: Local
    omitClusterIP: true
  autoscaling:
    enabled: true
    minReplicas: 2
    maxReplicas: 100
    targetCPUUtilizationPercentage: "70"
    targetMemoryUtilizationPercentage: "70"
defaultBackend:
  service:
    omitClusterIP: true

Comme vous pouvez le voir ci-dessous, le modèle ne contient pas clusterIP

modèle de barre ingx stable/nginx-ingress -f ingx-values.yaml

---
# Source: nginx-ingress/templates/controller-serviceaccount.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  labels:
    app: nginx-ingress
    chart: nginx-ingress-1.20.0
    heritage: Helm
    release: ingx
  name: ingx-nginx-ingress
---
# Source: nginx-ingress/templates/default-backend-serviceaccount.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  labels:
    app: nginx-ingress
    chart: nginx-ingress-1.20.0
    heritage: Helm
    release: ingx
  name: ingx-nginx-ingress-backend
---
# Source: nginx-ingress/templates/clusterrole.yaml
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata:
  labels:
    app: nginx-ingress
    chart: nginx-ingress-1.20.0
    heritage: Helm
    release: ingx
  name: ingx-nginx-ingress
rules:
  - apiGroups:
      - ""
    resources:
      - configmaps
      - endpoints
      - nodes
      - pods
      - secrets
    verbs:
      - list
      - watch
  - apiGroups:
      - ""
    resources:
      - nodes
    verbs:
      - get
  - apiGroups:
      - ""
    resources:
      - services
    verbs:
      - get
      - list
      - update
      - watch
  - apiGroups:
      - extensions
      - "networking.k8s.io" # k8s 1.14+
    resources:
      - ingresses
    verbs:
      - get
      - list
      - watch
  - apiGroups:
      - ""
    resources:
      - events
    verbs:
      - create
      - patch
  - apiGroups:
      - extensions
      - "networking.k8s.io" # k8s 1.14+
    resources:
      - ingresses/status
    verbs:
      - update
---
# Source: nginx-ingress/templates/clusterrolebinding.yaml
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  labels:
    app: nginx-ingress
    chart: nginx-ingress-1.20.0
    heritage: Helm
    release: ingx
  name: ingx-nginx-ingress
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: ingx-nginx-ingress
subjects:
  - kind: ServiceAccount
    name: ingx-nginx-ingress
    namespace: default
---
# Source: nginx-ingress/templates/controller-role.yaml
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: Role
metadata:
  labels:
    app: nginx-ingress
    chart: nginx-ingress-1.20.0
    heritage: Helm
    release: ingx
  name: ingx-nginx-ingress
rules:
  - apiGroups:
      - ""
    resources:
      - namespaces
    verbs:
      - get
  - apiGroups:
      - ""
    resources:
      - configmaps
      - pods
      - secrets
      - endpoints
    verbs:
      - get
      - list
      - watch
  - apiGroups:
      - ""
    resources:
      - services
    verbs:
      - get
      - list
      - update
      - watch
  - apiGroups:
      - extensions
      - "networking.k8s.io" # k8s 1.14+
    resources:
      - ingresses
    verbs:
      - get
      - list
      - watch
  - apiGroups:
      - extensions
      - "networking.k8s.io" # k8s 1.14+
    resources:
      - ingresses/status
    verbs:
      - update
  - apiGroups:
      - ""
    resources:
      - configmaps
    resourceNames:
      - ingress-controller-leader-nginx
    verbs:
      - get
      - update
  - apiGroups:
      - ""
    resources:
      - configmaps
    verbs:
      - create
  - apiGroups:
      - ""
    resources:
      - endpoints
    verbs:
      - create
      - get
      - update
  - apiGroups:
      - ""
    resources:
      - events
    verbs:
      - create
      - patch
---
# Source: nginx-ingress/templates/controller-rolebinding.yaml
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: RoleBinding
metadata:
  labels:
    app: nginx-ingress
    chart: nginx-ingress-1.20.0
    heritage: Helm
    release: ingx
  name: ingx-nginx-ingress
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: ingx-nginx-ingress
subjects:
  - kind: ServiceAccount
    name: ingx-nginx-ingress
    namespace: default
---
# Source: nginx-ingress/templates/controller-service.yaml
apiVersion: v1
kind: Service
metadata:
  labels:
    app: nginx-ingress
    chart: nginx-ingress-1.20.0
    component: "controller"
    heritage: Helm
    release: ingx
  name: ingx-nginx-ingress-controller
spec:
  externalTrafficPolicy: "Local"
  ports:
    - name: http
      port: 80
      protocol: TCP
      targetPort: http
    - name: https
      port: 443
      protocol: TCP
      targetPort: https
  selector:
    app: nginx-ingress
    component: "controller"
    release: ingx
  type: "LoadBalancer"
---
# Source: nginx-ingress/templates/default-backend-service.yaml
apiVersion: v1
kind: Service
metadata:
  labels:
    app: nginx-ingress
    chart: nginx-ingress-1.20.0
    component: "default-backend"
    heritage: Helm
    release: ingx
  name: ingx-nginx-ingress-default-backend
spec:
  ports:
    - name: http
      port: 80
      protocol: TCP
      targetPort: http
  selector:
    app: nginx-ingress
    component: "default-backend"
    release: ingx
  type: "ClusterIP"
---
# Source: nginx-ingress/templates/controller-deployment.yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  labels:
    app: nginx-ingress
    chart: nginx-ingress-1.20.0
    component: "controller"
    heritage: Helm
    release: ingx
  name: ingx-nginx-ingress-controller
spec:
  replicas: 1
  revisionHistoryLimit: 10
  strategy:
    {}
  minReadySeconds: 0
  template:
    metadata:
      labels:
        app: nginx-ingress
        component: "controller"
        release: ingx
    spec:
      dnsPolicy: ClusterFirst
      containers:
        - name: nginx-ingress-controller
          image: "quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.25.1"
          imagePullPolicy: "IfNotPresent"
          args:
            - /nginx-ingress-controller
            - --default-backend-service=default/ingx-nginx-ingress-default-backend
            - --election-id=ingress-controller-leader
            - --ingress-class=nginx
            - --configmap=default/ingx-nginx-ingress-controller
          securityContext:
            capabilities:
                drop:
                - ALL
                add:
                - NET_BIND_SERVICE
            runAsUser: 33
            allowPrivilegeEscalation: true
          env:
            - name: POD_NAME
              valueFrom:
                fieldRef:
                  fieldPath: metadata.name
            - name: POD_NAMESPACE
              valueFrom:
                fieldRef:
                  fieldPath: metadata.namespace
          livenessProbe:
            httpGet:
              path: /healthz
              port: 10254
              scheme: HTTP
            initialDelaySeconds: 10
            periodSeconds: 10
            timeoutSeconds: 1
            successThreshold: 1
            failureThreshold: 3
          ports:
            - name: http
              containerPort: 80
              protocol: TCP
            - name: https
              containerPort: 443
              protocol: TCP
          readinessProbe:
            httpGet:
              path: /healthz
              port: 10254
              scheme: HTTP
            initialDelaySeconds: 10
            periodSeconds: 10
            timeoutSeconds: 1
            successThreshold: 1
            failureThreshold: 3
          resources:
            {}
      hostNetwork: false
      serviceAccountName: ingx-nginx-ingress
      terminationGracePeriodSeconds: 60
---
# Source: nginx-ingress/templates/default-backend-deployment.yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  labels:
    app: nginx-ingress
    chart: nginx-ingress-1.20.0
    component: "default-backend"
    heritage: Helm
    release: ingx
  name: ingx-nginx-ingress-default-backend
spec:
  replicas: 1
  revisionHistoryLimit: 10
  template:
    metadata:
      labels:
        app: nginx-ingress
        component: "default-backend"
        release: ingx
    spec:
      containers:
        - name: nginx-ingress-default-backend
          image: "k8s.gcr.io/defaultbackend-amd64:1.5"
          imagePullPolicy: "IfNotPresent"
          args:
          securityContext:
            runAsUser: 65534
          livenessProbe:
            httpGet:
              path: /healthz
              port: 8080
              scheme: HTTP
            initialDelaySeconds: 30
            periodSeconds: 10
            timeoutSeconds: 5
            successThreshold: 1
            failureThreshold: 3
          readinessProbe:
            httpGet:
              path: /healthz
              port: 8080
              scheme: HTTP
            initialDelaySeconds: 0
            periodSeconds: 5
            timeoutSeconds: 5
            successThreshold: 1
            failureThreshold: 6
          ports:
            - name: http
              containerPort: 8080
              protocol: TCP
          resources:
            {}
      serviceAccountName: ingx-nginx-ingress-backend
      terminationGracePeriodSeconds: 60
---
# Source: nginx-ingress/templates/controller-hpa.yaml
apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
  labels:
    app: nginx-ingress
    chart: nginx-ingress-1.20.0
    component: "controller"
    heritage: Helm
    release: ingx
  name: ingx-nginx-ingress-controller
spec:
  scaleTargetRef:
    apiVersion: apps/v1beta1
    kind: Deployment
    name: ingx-nginx-ingress-controller
  minReplicas: 2
  maxReplicas: 100
  metrics:
    - type: Resource
      resource:
        name: cpu
        targetAverageUtilization: 70
    - type: Resource
      resource:
        name: memory
        targetAverageUtilization: 70

Je soupçonne que cela s'est produit parce que je l'ai déployé à l'origine sans paramètres omitClusterIP, et helm v3 essaie de faire une fusion à trois avec le manifeste d'origine, qui contient clusterIP: ""

helm get manifest ingx --revision 1 | grep "clusterIP"
  clusterIP: ""
  clusterIP: ""

J'ai pu le réparer en supprimant d'abord le graphique existant et en le recréant avec les options omitClusterIP . En fin de compte, la solution de contournement suggérée par @bambash ne fonctionnera que si vous installez le graphique avec ces options définies sur true dès le début

$ helm upgrade --install ingress-test stable/nginx-ingress --set controller.service.omitClusterIP=true --set defaultBackend.service.omitClusterIP=true

Ce serait formidable s'il y avait un moyen dans helm v3 d'ignorer la fusion avec le manifeste existant

désolé, j'aurais dû préciser que ces valeurs doivent être définies lors de l'installation initiale de la version. La mise à jour d'une version existante peut s'avérer plus délicate...

Je rencontre ce problème avec metric-server-2.8.8, qui n'a pas de clusterIP dans ses valeurs, et d'autres graphiques, avec helm v3.0.0-rc.2. aucun conseil? Je ne sais pas comment procéder.

Mon problème semble être avec helmfile v0.95.0. Je vais le poursuivre là-bas :)

J'ai le même problème, même sans définir le type de service ou clusterIP avec helm v3.0.0-rc.2 si j'utilise l'option --force avec la commande helm update --install. Sans --force ça marche bien

@johannges , j'étais sur le point de poster la même chose. :+1:

le paramètre omitClusterIP: true semble fonctionner pour les services de contrôleur par défaut , mais pas pour les métriques .

Je pense que c'est un problème avec la barre avec l'option --force lors de la mise à niveau.
Helm essaie de recréer le service, mais il remplace également spec.clusterIP afin de générer une erreur.
Je peux le confirmer en utilisant mon propre tableau personnalisé.
Error: UPGRADE FAILED: failed to replace object: Service "litespeed" is invalid: spec.clusterIP: Invalid value: "": field is immutable

En fait, c'était une erreur de ma part, omettre la définition clusterIP lors de l'initialisation du service (ou du graphique) fonctionne très bien 👍

Je rencontrais également cette erreur pour les versions de graphiques _kafka_ et _redis_ déployées existantes. La suppression de --force a en effet résolu ce problème.

Maintenant, je reçois une nouvelle erreur de la version _redis_ :
Error: UPGRADE FAILED: release redis failed, and has been rolled back due to atomic being set: cannot patch "redis-master" with kind StatefulSet: StatefulSet.apps "redis-master" is invalid: spec: Forbidden: updates to statefulset spec for fields other than 'replicas', 'template', and 'updateStrategy' are forbidden

Convenu avec @bacongobbler que cela semble lié à la stratégie de correctif de fusion à trois voies Helm v3 qui entraîne probablement la transmission de champs (même avec les mêmes valeurs qu'auparavant) à la mise à jour/correctif que Kubernetes considère comme immuable/inchangeable après la première création.

Au cas où quelqu'un finirait par utiliser helm v3 via terraform, puisque vous ne pouvez pas lui dire directement de ne pas utiliser --force j'ai réussi à supprimer manuellement le graphique en utilisant helm delete puis à relancer terraform. ça craint mais ça marche.

edit: toute l'erreur: ("nginx-ingress-singleton-controller" est le nom de version que j'ai défini. il n'a pas de signification spécifique)

Error: cannot patch "nginx-ingress-singleton-controller" with kind Service: Service "nginx-ingress-singleton-controller" is invalid: spec.clusterIP: Invalid value:
"": field is immutable && cannot patch "nginx-ingress-singleton-default-backend" with kind Service: Service "nginx-ingress-singleton-default-backend" is invalid: sp
ec.clusterIP: Invalid value: "": field is immutable

  on .terraform/modules/app_dev/nginx-ingress.tf line 1, in resource "helm_release" "nginx_ingress":
   1: resource "helm_release" "nginx_ingress" {

@zen4ever a résolu le problème dans https://github.com/helm/helm/issues/6378#issuecomment -532766512. Je vais essayer de l'expliquer plus en détail...

Comme d'autres l'ont souligné, le problème se pose lorsqu'un graphique définit un clusterIP avec une chaîne vide. Lorsque le service est installé, Kubernetes remplit ce champ avec le clusterIP qu'il a attribué au service.

Lorsque helm upgrade est invoqué, le graphique demande que le clusterIP soit supprimé, d'où la raison pour laquelle le message d'erreur est spec.clusterIP: Invalid value: "": field is immutable .

Cela se produit à cause du comportement suivant :

1. Lors de l'installation, le graphique a spécifié qu'il voulait que clusterIP soit une chaîne vide
2. Kubernetes a attribué automatiquement au service un clusterIP . Nous utiliserons 172.17.0.1 pour cet exemple
3. Sur helm upgrade , le graphique veut que clusterIP soit une chaîne vide (ou dans le cas de @zen4ever ci -

Lors de la génération du patch à trois voies, il constate que l'ancien état était "" , l'état actuel est actuellement à "172.17.0.1" et l'état proposé est "" . Helm a détecté que l'utilisateur a demandé de changer le clusterIP de "172.17.0.1" à "", il a donc fourni un correctif.

Dans Helm 2, il ignorait l'état en direct, il n'a donc vu aucun changement (ancien état : clusterIP: "" vers le nouvel état : clusterIP: "" ), et aucun correctif n'a été généré, contournant ce comportement.

Ma recommandation serait de changer la sortie du modèle. Si aucun clusterIP n'est fourni en tant que valeur, alors ne définissez pas la valeur sur une chaîne vide... Omettez entièrement le champ.

par exemple dans le cas de stable/nginx-ingress :

spec:
{{- if not .Values.controller.service.omitClusterIP }}
  clusterIP: "{{ .Values.controller.service.clusterIP }}"
{{- end }}

Devrait être remplacé par :

spec:
{{- if not .Values.controller.service.omitClusterIP }}
  {{ with .Values.controller.service.clusterIP }}clusterIP: {{ quote . }}{{ end }}
{{- end }}

C'est aussi pourquoi --set controller.service.omitClusterIP=true fonctionne dans ce cas.

TL;DR ne le faites pas dans vos modèles de service :

clusterIP: ""

Sinon, Helm essaiera de changer le clusterIP du service d'une adresse IP générée automatiquement à la chaîne vide, d'où le message d'erreur.

J'espère que cela t'aides!

En tant que solution temporaire, si vous essayez de faire fonctionner cela pour l'instant pendant que ce problème est résolu, j'ai trouvé que si je faisais ce qui suit, je pouvais effectuer une mise à jour :

1. Obtenez les valeurs clusterIP pour le contrôleur et le backend par défaut via :
   kubectl get svc | grep ingress
2. Ajoutez les écrasements suivants à votre fichier de valeurs de barre existant :
   controller: service: clusterIP: <cluster-ip-address-for-controller> defaultBackend: service: clusterIP: <cluster-ip-address-for-default-backend>
3. Effectuez la mise à jour.

J'ai testé ceci pour un cluster que j'exécute et cela n'a nécessité aucune récréation.

Cela fonctionne aussi. Bon appel @treacher. définir la même valeur via --set ou dans votre fichier de valeurs ne génère aucun correctif, car la mise à niveau ne veut pas changer la valeur de clusterIP .

Fermeture comme fonctionnant intentionnellement selon le comportement du patch de fusion à trois voies décrit ci-dessus. L'élément d'action est que ces graphiques suivent la recommandation fournie ci-dessus dans https://github.com/helm/helm/issues/6378#issuecomment-557746499. Rien à faire ici du côté de Helm. :)

https://github.com/helm/charts/pull/19146/files créé ! Merci @bacongobbler

@zen4ever a résolu le problème dans #6378 (commentaire) . Je vais essayer de l'expliquer plus en détail...

Comme d'autres l'ont souligné, le problème se pose lorsqu'un graphique définit un clusterIP avec une chaîne vide. Lorsque le service est installé, Kubernetes remplit ce champ avec le clusterIP qu'il a attribué au service.

Lorsque helm upgrade est invoqué, le graphique demande que le clusterIP soit supprimé, d'où la raison pour laquelle le message d'erreur est spec.clusterIP: Invalid value: "": field is immutable .

Cela se produit à cause du comportement suivant :

1. Lors de l'installation, le graphique a spécifié qu'il voulait que clusterIP soit une chaîne vide
2. Kubernetes a attribué automatiquement au service un clusterIP . Nous utiliserons 172.17.0.1 pour cet exemple
3. Sur helm upgrade , le graphique veut que clusterIP soit une chaîne vide (ou dans le cas de @zen4ever ci -

Lors de la génération du patch à trois voies, il constate que l'ancien état était "" , l'état actuel est actuellement à "172.17.0.1" et l'état proposé est "" . Helm a détecté que l'utilisateur a demandé de changer le clusterIP de "172.17.0.1" à "", il a donc fourni un correctif.

Dans Helm 2, il ignorait l'état en direct, il n'a donc vu aucun changement (ancien état : clusterIP: "" vers le nouvel état : clusterIP: "" ), et aucun correctif n'a été généré, contournant ce comportement.

Ma recommandation serait de changer la sortie du modèle. Si aucun clusterIP n'est fourni en tant que valeur, alors ne définissez pas la valeur sur une chaîne vide... Omettez entièrement le champ.

par exemple dans le cas de stable/nginx-ingress :

spec:
{{- if not .Values.controller.service.omitClusterIP }}
  clusterIP: "{{ .Values.controller.service.clusterIP }}"
{{- end }}

Devrait être remplacé par :

spec:
{{- if not .Values.controller.service.omitClusterIP }}
  {{ with .Values.controller.service.clusterIP }}clusterIP: {{ quote . }}{{ end }}
{{- end }}

Salut @bacongobbler , je pense que si aucune valeur n'est fournie, nous nous retrouverons toujours avec clusterIP: "" ... mieux serait la valeur clusterIP: "" complètement commentée dans le fichier de valeurs. Cela l'omet des manifestes rendus lorsqu'il est défini et devrait éviter de futurs maux de tête. Cependant, si vous utilisez helm3 et que l'état actuel de helm a clusterIP: "" défini, il faut coder en dur les adresses IP du cluster dans les fichiers de valeurs.

C'est aussi pourquoi --set controller.service.omitClusterIP=true fonctionne dans ce cas.

TL;DR ne le faites pas dans vos modèles de service :

clusterIP: ""

Sinon, Helm essaiera de changer le clusterIP du service d'une adresse IP générée automatiquement à la chaîne vide, d'où le message d'erreur.

J'espère que cela t'aides!

Salut @bacongobbler , nous avons rencontré le même problème lors de la migration de la version helm v2 vers helm v3. Nous utilisons type: ClusterIP dans Service mais omettons ClusterIP et nous obtenons :

Error: UPGRADE FAILED: failed to replace object: Service "dummy" is invalid: spec.clusterIP: Invalid value: "": field is immutable

Nous n'avons pas spec.clusterIP: dans notre modèle de helm mais nous avons eu cette erreur après la migration de la version via helm 2to3

Modèle de service :

apiVersion: v1
kind: Service
metadata:
  name: {{ .Release.Name }}
  labels:
    app: {{ .Values.image.name }}
    chart: {{ .Chart.Name }}-{{ .Chart.Version | replace "+" "-" }}
    cluster: {{ default "unknown" .Values.cluster }}
    region: {{ default "unknown" .Values.region }}
    datacenter: {{ default "unknown" .Values.datacenter }}
    release: {{ .Release.Name }}
    heritage: {{ .Release.Service }}
spec:
  type: ClusterIP
  ports:
    - port: {{ .Values.service.port }}
      targetPort: {{ .Values.service.port }}
      protocol: TCP
      name: http
  selector:
    app: {{ .Values.image.name }}
    release: {{ .Release.Name }}

Même problème ici. Le fait est que nous n'avons pas touché au Service. C'est Ingress qui a été modifié avant la mise à niveau.

Cela affecte les ressources avec un champ immuable si vous supprimez le drapeau --force de helm upgrade --install et ne touchez pas au champ immuable, tout fonctionne correctement. Mais si vous voulez augmenter l'apiversion des ressources ??? Vous avez besoin de recréer des ressources mais la barre 3 ne mettra pas à niveau les ressources...
@bacongobbler ^^^

essayé de mettre à jour hpa avec la nouvelle apiVersion par helm 3:
Error: UPGRADE FAILED: rendered manifests contain a new resource that already exists. Unable to continue with update: existing resource conflict: kind: HorizontalPodAutoscaler, namespace: stage, name: dummy-stage

Le commentaire de @bacongobbler et @kritcher722 a été mis à jour si vous souhaitez supprimer les pouces vers le bas, mais si vous êtes toujours en désaccord, veuillez expliquer pourquoi c'est une bonne idée d'avoir clusterIP: "" dans les manifestes rendus.

On dirait que Microsoft est le mentor du projet. Je vois le style. :)

Veuillez rouvrir. Le problème n'est pas résolu. Ce « hack » suggéré par nasseemkullah n'est pas approprié. Ne demandez pas aux gens de sauter sur la tête. Réparez-le simplement. Chemin de migration très pauvre. Helm craint.

@antonakv quelle façon de commencer l'année :)
Je pense qu'en général, nous jouons avec le feu lorsque nous fournissons clusterIP en tant que valeur configurable dans un graphique, et nous ne pouvons pas totalement blâmer un outil/personne/PR en particulier.
Si clusterIP doit être une valeur configurable, par défaut, il ne devrait pas être dans le modèle rendu, c'est l'idée de mon commentaire dans les fichiers de valeurs selon https://github.com/helm/charts/blob/270172836fd8cf56d787cf7d04d938856de0c794/stable /nginx-ingress/values.yaml#L236

Ceci, si je ne me trompe pas, devrait éviter de futurs maux de tête à ceux qui installent la carte à partir de ce changement. Mais pour ceux d'entre nous (moi y compris) qui l'avaient installé auparavant, puis ont migré vers helm3, je crains que l'enregistrement des valeurs clusterIP actuelles dans nos fichiers de valeurs OU la désinstallation et la réinstallation du graphique (provoque des temps d'arrêt !) Sont les seules options que j'ai voir.

Les opinions sont les miennes, je ne suis pas payé pour travailler à la barre, juste un utilisateur final comme vous. Ceux qui sont payés pour travailler à temps plein peuvent être en mesure de fournir plus d'informations.

Bonne année et bonne chance! N'abandonnez pas la barre, ensemble nous pouvons l'améliorer.

Salut @bacongobbler , nous avons rencontré le même problème lors de la migration de la version helm v2 vers helm v3. Nous utilisons type: ClusterIP dans Service mais omettons ClusterIP et nous obtenons :

Error: UPGRADE FAILED: failed to replace object: Service "dummy" is invalid: spec.clusterIP: Invalid value: "": field is immutable

Nous n'avons pas spec.clusterIP: dans notre modèle de helm mais nous avons eu cette erreur après la migration de la version via helm 2to3

Modèle de service :

apiVersion: v1
kind: Service
metadata:
  name: {{ .Release.Name }}
  labels:
    app: {{ .Values.image.name }}
    chart: {{ .Chart.Name }}-{{ .Chart.Version | replace "+" "-" }}
    cluster: {{ default "unknown" .Values.cluster }}
    region: {{ default "unknown" .Values.region }}
    datacenter: {{ default "unknown" .Values.datacenter }}
    release: {{ .Release.Name }}
    heritage: {{ .Release.Service }}
spec:
  type: ClusterIP
  ports:
    - port: {{ .Values.service.port }}
      targetPort: {{ .Values.service.port }}
      protocol: TCP
      name: http
  selector:
    app: {{ .Values.image.name }}
    release: {{ .Release.Name }}

Nous avons le meme probleme. Nous ne définissons pas du tout clusterIP dans notre graphique et il n'est pas présent dans le modèle final. Cependant, nous obtenons toujours la même erreur et uniquement avec le drapeau --force .

Nous rencontrons le même problème :

apiVersion: v1
kind: Service
{{ include "mde.metadata" $ }}
spec:
  ports:
  - name: {{ include "mde.portName" $ | quote }}
    port: {{ include "mde.port" $ }}
    protocol: TCP
    targetPort: {{ include "mde.port" $ }}
  selector:
    app: {{ include "mde.name" $ }}
  sessionAffinity: None
  type: ClusterIP

spec.clusterIP ne fait pas partie du modèle de service, mais avec Helm 3.0.2 et un appel helm upgrade ... --force --install , nous voyons également :

Erreur : ÉCHEC DE LA MISE À JOUR : échec du remplacement de l'objet : le service "factice" n'est pas valide : spec.clusterIP : valeur invalide : " : le champ est immuable

Veuillez rouvrir.

@ tomcruise81, veuillez consulter https://github.com/helm/helm/issues/7350 pour le fil de discussion sur --force . Cela entraîne la même erreur, mais cela est dû à la façon dont kubectl replace semble fonctionner. Il s'agit d'un problème distinct de ce qui est décrit ici, qui concerne les clusterIP de service et la stratégie de correctif de fusion à trois voies ( helm upgrade sans l'indicateur --force ).

@bacongobbler - merci pour la réponse rapide et les éclaircissements. Regarder:

https://github.com/helm/helm/blob/a963736f6675e972448bf7a5fd141628fd0ae4df/pkg/kube/client.go#L405 -L411

qui utilisent https://github.com/kubernetes/cli-runtime/blob/master/pkg/resource/helper.go#L155 -L181, il ne semble pas que l'appel à helper.Replace fasse la même chose que kubectl replace -f ... --force (notez le --force à la fin).

Je suppose que c'est là que réside une grande partie de la confusion.

Je connais mon attente de helm upgrade ... --force et j'utilise une stratégie de remplacement, c'est qu'il ferait la même chose que kubectl replace -f ... --force .

Salut @bacongobbler , nous avons rencontré le même problème lors de la migration de la version helm v2 vers helm v3. Nous utilisons type: ClusterIP dans Service mais omettons ClusterIP et nous obtenons :
Error: UPGRADE FAILED: failed to replace object: Service "dummy" is invalid: spec.clusterIP: Invalid value: "": field is immutable
Nous n'avons pas spec.clusterIP: dans notre modèle de helm mais nous avons eu cette erreur après la migration de la version via helm 2to3
Modèle de service :

apiVersion: v1
kind: Service
metadata:
  name: {{ .Release.Name }}
  labels:
    app: {{ .Values.image.name }}
    chart: {{ .Chart.Name }}-{{ .Chart.Version | replace "+" "-" }}
    cluster: {{ default "unknown" .Values.cluster }}
    region: {{ default "unknown" .Values.region }}
    datacenter: {{ default "unknown" .Values.datacenter }}
    release: {{ .Release.Name }}
    heritage: {{ .Release.Service }}
spec:
  type: ClusterIP
  ports:
    - port: {{ .Values.service.port }}
      targetPort: {{ .Values.service.port }}
      protocol: TCP
      name: http
  selector:
    app: {{ .Values.image.name }}
    release: {{ .Release.Name }}

Nous avons le meme probleme. Nous ne définissons pas du tout clusterIP dans notre graphique et il n'est pas présent dans le modèle final. Cependant, nous obtenons toujours la même erreur et uniquement avec le drapeau --force .

J'ai également vérifié qu'il n'y avait pas de clusterIP dans le manifeste de version :

$ helm get manifest paywall-api-ee | grep clusterIP
$

même chose ici - nous ne définissons ClusterIP nulle part mais voyons toujours l'erreur

En jouant un peu plus avec cela, j'ai observé que:

• helm upgrade ... --force --install - résultats dans _Le service "dummy" n'est pas valide : spec.clusterIP : valeur invalide : " : le champ est immuable_
• helm template ... | kubectl apply -f - - fonctionne
• helm template ... | kubectl replace -f - - résultats dans _Le service "dummy" n'est pas valide : spec.clusterIP : valeur invalide : " : le champ est immuable_
• helm template ... | kubectl replace --force -f - - fonctionne

version kubectl - 1.14.6
version de barre - 3.0.2

@ tomcruise81, vous pouvez essayer d'utiliser le plugin helm 2to3 et migrer de helm2 vers la version helm3 et supprimer --force si vous l'avez déjà utilisé.
C'est du travail pour nous.
Quant à moi et ressemble à un autre gars --force a un mauvais comportement et devrait gérer ce cas avec un champ immuable comme pour moi

@alexandrsemak - merci pour la recommandation. Dans mon cas, je vois cela sur un graphique qui n'a été installé ou mis à niveau qu'à l'aide de helm 3.

Même problème pour moi ! Utilisant

$ helm install my-release xxxxx
$ helm upgrade --install --force my-release xxxxx

Dans mon cas, je ne définis ClusterIP sur aucun des services utilisés sur mon graphique, mais je suis confronté au même problème (voir les spécifications ci-dessous):

spec:
  type: {{ .Values.service.type }}
  {{- if and (eq .Values.service.type "LoadBalancer") (not (empty .Values.service.loadBalancerIP)) }}
  loadBalancerIP: {{ .Values.service.loadBalancerIP }}
  {{- end }}
  ports:
    - name: htttp-XXX
      port: {{ .Values.service.port }}
      targetPort: XXX
      {{- if and (or (eq .Values.service.type "NodePort") (eq .Values.service.type "LoadBalancer")) (not (empty .Values.service.nodePort)) }}
      nodePort: {{ .Values.service.nodePort }}
      {{- else if eq .Values.service.type "ClusterIP" }}
      nodePort: null
      {{- end }}
  selector:
    app.kubernetes.io/name: XXX
    app.kubernetes.io/instance: {{ .Release.Name }}

Comme d'autres utilisateurs l'ont déjà dit, la raison en est que Kubernetes attribue automatiquement au service un clusterIP la première fois (par exemple, clusterIP: 10.96.26.65 ) et cela entre en conflit avec clusterIP: "" lorsque vous essayez de mettre à niveau. Veuillez noter que je ne génère pas ceci sur mes modèles : clusterIP: ""

Veuillez rouvrir ce @bacongobbler

J'ai le même problème.

@juan131 @Ronsevet : remove --force Le sens a changé.

face au même problème, sur des graphiques personnalisés.
Nous ne définissons clusterip nulle part.
Casque v3.0.2
kubectl 1.14.8

Le problème est que parfois un graphique reste en état d'échec même si les pods sont créés et en cours d'exécution. Si nous essayons de mettre à niveau la même version, cela ne fonctionnera pas sans force.
Étant donné que les pods sont en cours d'exécution, la version ne peut pas être supprimée ni recréée.
Il doit y avoir un moyen d'utiliser la "force"

même chose pour moi - je viens d'ajouter une étiquette supplémentaire au service et j'ai rencontré cette erreur. De plus, je ne définis ClusterIP nulle part - veuillez rouvrir le problème

@bacongobbler Nous StorageClasses dans le cadre de notre graphique et les paramètres de StorageClass sont immuables. Ainsi, dans la prochaine version, lorsque nous mettons à jour la valeur d'un paramètre StorageClass, helm upgrade --force échoue également.
Je ne sais pas comment gérer ce cas pour la mise à jour de StorageClasses. Aucune suggestion?

Error: UPGRADE FAILED: failed to replace object: StorageClass.storage.k8s.io "ibmc-s3fs-standard-cross-region" is invalid: parameters: Forbidden: updates to parameters are forbidden.

Cela fonctionnait bien dans helm v2 car helm upgrade --force utilisé pour forcer la suppression et la recréation de StorageClass .

Si quelqu'un présente des symptômes qui ne résultent pas de l'explication fournie dans https://github.com/helm/helm/issues/6378#issuecomment -557746499, pouvez-vous s'il vous plaît ouvrir un nouveau problème avec vos conclusions et comment nous pouvons reproduire c'est de notre côté ?

Le problème soulevé par l'OP était dû au scénario fourni ci-dessus, où un graphique définissait le ClusterIP sur une chaîne vide lors de l'installation. Il est tout à fait possible qu'il existe d'autres scénarios où ce cas particulier peut survenir, comme d'autres l'ont mentionné avec l'utilisation du drapeau --force . Ces cas doivent être discutés séparément, car le diagnostic et la solution peuvent différer des conseils fournis précédemment.

Merci!

@mssachan voir #7082 et le projet de proposition dans #7431 pour votre cas d'utilisation. Cette proposition vise à implémenter kubectl replace —force , ce qui serait similaire au comportement de helm install —force de Helm 2.

@mssachan voir #7082 et le projet de proposition dans #7431 pour votre cas d'utilisation. Cette proposition vise à implémenter kubectl replace —force , ce qui serait similaire au comportement de helm install —force de Helm 2.

C'est bien que cela se produise. Même en omettant le drapeau --force , j'obtiens toujours l'erreur lors de la mise à niveau des graphiques. Par exemple, avec cert-manager :

2020-03-05 12:15:19 CRITICAL: Command returned [ 1 ] exit code and error message [ Error: UPGRADE FAILED: cannot patch "cert-manager-cainjector" with kind Deployment: Deployment.apps "cert-manager-cainjector" is invalid: spec.selector: Invalid value: v1.LabelSelector{MatchLabels:map[string]string{"app":"cainjector", "app.kubernetes.io/instance":"cert-manager", "app.kubernetes.io/managed-by":"Helm", "app.kubernetes.io/name":"cainjector"}, MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: field is immutable && cannot patch "cert-manager" with kind Deployment: Deployment.apps "cert-manager" is invalid: spec.selector: Invalid value: v1.LabelSelector{MatchLabels:map[string]string{"app":"cert-manager", "app.kubernetes.io/instance":"cert-manager", "app.kubernetes.io/managed-by":"Helm", "app.kubernetes.io/name":"cert-manager"}, MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: field is immutable && cannot patch "cert-manager-webhook" with kind Deployment: Deployment.apps "cert-manager-webhook" is invalid: spec.selector: Invalid value: v1.LabelSelector{MatchLabels:map[string]string{"app":"webhook", "app.kubernetes.io/instance":"cert-manager", "app.kubernetes.io/managed-by":"Helm", "app.kubernetes.io/name":"webhook"}, MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: field is immutable

@mssachan voir #7082 et le projet de proposition dans #7431 pour votre cas d'utilisation. Cette proposition vise à implémenter kubectl replace —force , ce qui serait similaire au comportement de helm install —force de Helm 2.

C'est bien que cela se produise. Même en omettant le drapeau --force , j'obtiens toujours l'erreur lors de la mise à niveau des graphiques. Par exemple, avec cert-manager :

2020-03-05 12:15:19 CRITICAL: Command returned [ 1 ] exit code and error message [ Error: UPGRADE FAILED: cannot patch "cert-manager-cainjector" with kind Deployment: Deployment.apps "cert-manager-cainjector" is invalid: spec.selector: Invalid value: v1.LabelSelector{MatchLabels:map[string]string{"app":"cainjector", "app.kubernetes.io/instance":"cert-manager", "app.kubernetes.io/managed-by":"Helm", "app.kubernetes.io/name":"cainjector"}, MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: field is immutable && cannot patch "cert-manager" with kind Deployment: Deployment.apps "cert-manager" is invalid: spec.selector: Invalid value: v1.LabelSelector{MatchLabels:map[string]string{"app":"cert-manager", "app.kubernetes.io/instance":"cert-manager", "app.kubernetes.io/managed-by":"Helm", "app.kubernetes.io/name":"cert-manager"}, MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: field is immutable && cannot patch "cert-manager-webhook" with kind Deployment: Deployment.apps "cert-manager-webhook" is invalid: spec.selector: Invalid value: v1.LabelSelector{MatchLabels:map[string]string{"app":"webhook", "app.kubernetes.io/instance":"cert-manager", "app.kubernetes.io/managed-by":"Helm", "app.kubernetes.io/name":"webhook"}, MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: field is immutable

@ sc250024 J'ai exactement le même problème après avoir mis à niveau helm v2 vers v3. La progression de la mise à niveau s'est déroulée sans heurts et sans erreur, puis j'essaie de mettre à niveau le gestionnaire de certificats à partir de la barre, a échoué avec le même résultat.

# helm upgrade cert-manager jetstack/cert-manager --namespace cert-manager --atomic --cleanup-on-fail

# helm version
version.BuildInfo{Version:"v3.1.1", GitCommit:"afe70585407b420d0097d07b21c47dc511525ac8", GitTreeState:"clean", GoVersion:"go1.13.8"}

Toutes les solutions de contournement lorsque --force n'est pas utilisé, ou aucune option concernant la définition de clusterIP . Voici mon manifeste de service :

apiVersion: v1
kind: Service
metadata:
  name: "{{ .Values.deploymentBaseName }}-{{ .Values.skaffoldUser }}"
  labels:
    name: "{{ .Values.deploymentBaseName }}-{{ .Values.skaffoldUser }}"
spec:
  ports:
    - port: {{ .Values.servicePort }}
      targetPort: {{ .Values.containerPort }}
      protocol: TCP
      name: http
    - name: debugger-http
      port: {{ .Values.debuggerPort }}
      targetPort: {{ .Values.debuggerPort }}
      protocol: TCP
  selector:
    app: "{{ .Values.deploymentBaseName }}-{{ .Values.skaffoldUser }}"
  type: ClusterIP

@davidfernandezm avez-vous déjà trouvé une solution pour cela ? Je vois la même chose de mon côté et mes services sont définis exactement comme les vôtres. Aucune option pour clusterIP n'est définie, et pourtant Helm échoue toujours lors d'une mise à niveau.

Pareil ici

Obtenir cela aussi, re: les deux commentaires ci-dessus.

Veuillez fournir plus d'informations. Nous ne pouvons pas vous aider sans comprendre la cause ou comment ce problème survient dans votre cas. Merci.

@antonakv ce numéro en double de 7956
@bacongobbler plus d'infos

J'ai le même problème, même sans définir le type de service ou clusterIP avec helm v3.0.0-rc.2 si j'utilise l'option --force avec la commande helm update --install. Sans --force ça marche bien

Cool! Je me suis inspiré de votre réponse, que je dois commenter la ligne force: .. dans helmfile yaml :

helmDefaults:
  tillerless: true
  verify: false
  wait: true
  timeout: 600
  # force: true <---- THI ONE IS COMMENTED

ça marche

J'ai essayé tout ce qui précède, aucun n'a fonctionné pour moi. J'ai dû désactiver nginx-ingress de mon graphique, effectuer une mise à niveau, l'activer à nouveau et mettre à niveau à nouveau. Cela a conduit à un changement de l'adresse IP attribuée par le fournisseur de cloud, mais aucun mal n'a été fait.

J'ai le même problème, même sans définir le type de service ou clusterIP avec helm v3.0.0-rc.2 si j'utilise l'option --force avec la commande helm update --install. Sans --force ça marche bien

Meilleure solution, cela fonctionne pour moi, merci!

Nous avons le même problème et n'avons pas pu trouver de solution pour le contourner.
C'est assez simple à reproduire

helm install in stable/inbucket 
helm upgrade in stable/inbucket 
Error: UPGRADE FAILED: cannot patch "in-inbucket" with kind Service: Service "in-inbucket" is invalid: spec.clusterIP: Invalid value: "": field is immutable

Je me demandais pourquoi le --force ne fonctionnait pas ici, n'est-il pas censé force resource updates through a replacement strategy s'il s'agit d'une stratégie de remplacement, alors le service devrait être supprimé puis remplacé ?

@bacongobbler Je suis arrivé à ce fil après avoir vérifié https://github.com/helm/helm/issues/7956

Comme pour tous les commentateurs précédents : nous n'avons pas du tout "clusterIP" dans les modèles, mais l'erreur est toujours présente avec le dernier Helm si l'indicateur --force est utilisé.

Version de la barre : 3.4.1

"helm -n kube-system get manifest CHART_NAME | grep clusterIP" n'affiche aucun résultat.

Erreur:
field is immutable && failed to replace object: Service "SERVICE_NAME" is invalid: spec.clusterIP: Invalid value: "": field is immutable

La même explication fournie dans https://github.com/helm/helm/issues/6378#issuecomment -557746499 s'applique également ici dans votre cas @nick4fake. La différence étant qu'avec --force , vous demandez à Kubernetes de prendre votre manifeste entièrement rendu et d'écraser de force l'objet en direct actuel. Étant donné que votre manifeste ne contient pas clusterIP champ clusterIP de l'objet en direct, d'où l'erreur Invalid value: "": field is immutable .

@bacongobbler Je suis vraiment désolé si je manque quelque chose ici, peut-être que je n'en sais tout simplement pas assez sur les composants internes de Helm.

"Ma recommandation serait de modifier la sortie du modèle. Si aucun clusterIP n'est fourni en tant que valeur, ne définissez pas la valeur sur une chaîne vide... Omettez complètement le champ."

Alors, quelle est la solution? Cela signifie-t-il que l'indicateur "--force" ne peut pas du tout être utilisé si le champ clusterIP n'est pas défini sur une valeur statique ?

En ce qui concerne Kubernetes : oui.

D'après ce que j'ai compris, il s'agit d'un problème avec Kubernetes, car "écraser de force" ne se comporte pas de la même manière que "supprimer et recréer à nouveau". Y a-t-il un bug en amont ?

D'un autre côté, Helm est également trompeur, car --force est décrit comme "forcer les mises à jour des ressources via une stratégie de remplacement". Alors qu'en réalité, il ne fait aucun remplacement, il tente simplement d'écraser les ressources de force (il serait préférable de nommer le drapeau --force-overwrite ). Le remplacement forcé ressemblerait à une suppression et à une recréation (il pourrait y avoir un indicateur --force-recreate ). Bien sûr, --force-recreate pourrait être un peu dangereux à utiliser pour certaines ressources, mais cela réussirait toujours.

Quoi qu'il en soit, Helm pourrait implémenter une solution de contournement pour ce type de problèmes. Si le comportement actuel (décrit comme --force-overwrite ) échoue et détecte une erreur de champ immuable, il doit supprimer et recréer la ressource (comme --force-recreate ).