Helm: Helm 3 - actualizar nginx - spec.clusterIP: valor no válido: "": el campo es inmutable

Es probable que esto esté relacionado con un cambio reciente en Helm 3, donde ahora usa una estrategia de parche de fusión de tres vías similar a kubectl. Ver # 6124

Si puede proporcionar pasos sobre cómo reproducir esto, sería maravilloso. ¡Gracias!

¡Seguro!

Creé un clúster de AKS.

Creo una IP pública en el grupo de recursos MC_ *.

Guardé la dirección IP de esa IP pública en $ ip.

Luego, básicamente, ejecutó ese comando dos veces:

./helm upgrade --install
--set rbac.create = falso
--set controller.replicaCount = 2
--set controller.service.loadBalancerIP = $ ip
--esperar main-ingress estable / nginx-ingress

Esto es similar a lo que se hace en https://docs.microsoft.com/en-us/azure/aks/ingress-static-ip.

La diferencia es que realizo una actualización del timón: lo instalo dos veces. El propósito de eso es tener una sola línea de comando (incondicional) en mi CI / CD.

Avísame si necesitas más detalles para reproducir.

¿Fue suficiente para reproducirse? Puedo proporcionar un script bash si ayuda.

Lo siento, en Helm Summit EU esta semana, así que aún no he tenido tiempo de responder.

Ah ... no te preocupes. ¡Disfruta la cumbre!

También estoy experimentando este problema

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

nginx-ingress chart se instala bien en la primera ejecución, sin embargo, en una actualización ...

$ 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

Creo que esto es un problema con el gráfico nginx-ingress, no con helm3. De forma predeterminada, el gráfico siempre intentará pasar controller.service.clusterIP = "" y defaultBackend.service.clusterIP = "" menos que establezca controller.service.omitClusterIP=true y defaultBackend.service.omitClusterIP=true .

enlace a fuentes:
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

solución alterna:

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

Intenté hacerlo, pero sigo recibiendo el mismo error.

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

ingx-valores.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

Como puede ver a continuación, la plantilla no tiene clusterIP.

plantilla de timón ingx estable / nginx-ingress -f ingx-valores.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

Sospecho que sucedió porque lo implementé originalmente sin los parámetros omitClusterIP, y helm v3 está tratando de hacer una fusión de 3 vías con el manifiesto original, que tiene clusterIP: "" en él

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

Pude solucionarlo eliminando primero el gráfico existente y volviéndolo a crear con las opciones omitClusterIP . En pocas palabras , la solución alternativa sugerida de

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

Sería genial si hubiera una forma en helm v3 de omitir la fusión con el manifiesto existente

lo siento, debería haber especificado que estos valores deben establecerse cuando la versión se instala inicialmente. Actualizar una versión existente puede resultar más complicado ...

Me encuentro con este problema con metric-server-2.8.8, que no tiene ningún clusterIP en sus valores, y algunos otros gráficos, con helm v3.0.0-rc.2. ¿algún consejo? No estoy seguro de cómo proceder.

Mi problema parece ser helmfile v0.95.0. Lo perseguiré allí :)

Tengo el mismo problema, incluso sin configurar el tipo de servicio o clusterIP con helm v3.0.0-rc.2 si uso la opción --force con el comando helm update --install. Sin la fuerza, funciona bien

@johannges , estaba a punto de publicar lo mismo. : +1:

la configuración de omitClusterIP: true parece funcionar para los servicios de controlador y defaultBackend , pero no para las métricas .

Creo que este es un problema con el timón con la opción --force durante la actualización.
Helm está intentando recrear el servicio, pero también reemplaza spec.clusterIP por lo que arroja un error.
Puedo confirmar esto usando mi propio gráfico personalizado.
Error: UPGRADE FAILED: failed to replace object: Service "litespeed" is invalid: spec.clusterIP: Invalid value: "": field is immutable

En realidad, fue un error de mi parte, omitir la definición de clusterIP en la inicialización del servicio (o el gráfico) funciona bien 👍

También me encontré con este error para las versiones de gráficos _kafka_ y _redis_ implementadas existentes. La eliminación de --force resolvió esto.

Ahora recibo un nuevo error del lanzamiento de _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

Estuvo de acuerdo con

En caso de que alguien termine aquí usando helm v3 a través de terraform, ya que no puede decirle directamente que no use --force tuve éxito al eliminar manualmente el gráfico usando helm delete luego volver a ejecutar terraform. esto apesta pero funciona.

editar: todo el error: ("nginx-ingress-singleton-controller" es el nombre de la versión que configuré. No tiene un significado específico)

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 resolvió el problema en https://github.com/helm/helm/issues/6378#issuecomment -532766512. Intentaré explicarlo con más detalle ...

Como han señalado otros, el problema surge cuando un gráfico define un clusterIP con una cadena vacía. Cuando se instala el Servicio, Kubernetes llena este campo con la IP de clúster que le asignó al Servicio.

Cuando se invoca helm upgrade , el gráfico solicita que se elimine clusterIP , por lo que el mensaje de error es spec.clusterIP: Invalid value: "": field is immutable .

Esto sucede debido al siguiente comportamiento:

1. En la instalación, el gráfico especificó que quería que clusterIP fuera una cadena vacía
2. Kubernetes asignó automáticamente al Servicio clusterIP . Usaremos 172.17.0.1 para este ejemplo
3. En helm upgrade , el gráfico quiere que clusterIP sea ​​una cadena vacía (o en el caso de @ zen4ever anterior , se omite)

Al generar el parche de tres vías, ve que el estado anterior era "" , el estado activo actualmente es "172.17.0.1" y el estado propuesto es "" . Helm detectó que el usuario solicitó cambiar clusterIP de "172.17.0.1" a "", por lo que proporcionó un parche.

En Helm 2, ignoró el estado en vivo, por lo que no vio ningún cambio (estado anterior: clusterIP: "" al nuevo estado: clusterIP: "" ) y no se generó ningún parche, omitiendo este comportamiento.

Mi recomendación sería cambiar la salida de la plantilla. Si no se proporciona clusterIP como valor, no establezca el valor en una cadena vacía ... Omita el campo por completo.

por ejemplo, en el caso de stable/nginx-ingress :

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

Debería cambiarse a:

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

Esta es también la razón por la que --set controller.service.omitClusterIP=true funciona en este caso.

TL; DR no haga esto en sus plantillas de servicio:

clusterIP: ""

De lo contrario, Helm intentará cambiar la IP del clúster del servicio de una dirección IP generada automáticamente a una cadena vacía, de ahí el mensaje de error.

¡Espero que esto ayude!

Como solución temporal, si está tratando de que esto funcione por ahora mientras se resuelve este problema, descubrí que si hice lo siguiente, podría realizar una actualización:

1. Obtenga los valores de clusterIP para el controlador y el backend predeterminado a través de:
   kubectl get svc | grep ingress
2. Agregue las siguientes sobrescrituras a su archivo de valores de timón existente:
   controller: service: clusterIP: <cluster-ip-address-for-controller> defaultBackend: service: clusterIP: <cluster-ip-address-for-default-backend>
3. Realice la actualización.

Probé esto para un clúster que estoy ejecutando y no requirió ninguna recreación.

Eso también funciona. Buena llamada @treacher. establecer el mismo valor a través de --set o en su archivo de valores no genera ningún parche, ya que la actualización no quiere cambiar el valor de clusterIP .

Cerrar porque funciona intencionalmente según el comportamiento del parche de combinación de tres vías descrito anteriormente. El elemento de acción es que estos gráficos sigan la recomendación proporcionada anteriormente en https://github.com/helm/helm/issues/6378#issuecomment-557746499. Nada que hacer aquí por el lado de Helm. :)

https://github.com/helm/charts/pull/19146/files creados! Gracias @bacongobbler

@ zen4ever clavó el problema en # 6378 (comentario) . Intentaré explicarlo con más detalle ...

Como han señalado otros, el problema surge cuando un gráfico define un clusterIP con una cadena vacía. Cuando se instala el Servicio, Kubernetes llena este campo con la IP de clúster que le asignó al Servicio.

Cuando se invoca helm upgrade , el gráfico solicita que se elimine clusterIP , por lo que el mensaje de error es spec.clusterIP: Invalid value: "": field is immutable .

Esto sucede debido al siguiente comportamiento:

1. En la instalación, el gráfico especificó que quería que clusterIP fuera una cadena vacía
2. Kubernetes asignó automáticamente al Servicio clusterIP . Usaremos 172.17.0.1 para este ejemplo
3. En helm upgrade , el gráfico quiere que clusterIP sea ​​una cadena vacía (o en el caso de @ zen4ever anterior , se omite)

Al generar el parche de tres vías, ve que el estado anterior era "" , el estado activo actualmente es "172.17.0.1" y el estado propuesto es "" . Helm detectó que el usuario solicitó cambiar clusterIP de "172.17.0.1" a "", por lo que proporcionó un parche.

En Helm 2, ignoró el estado en vivo, por lo que no vio ningún cambio (estado anterior: clusterIP: "" al nuevo estado: clusterIP: "" ) y no se generó ningún parche, omitiendo este comportamiento.

Mi recomendación sería cambiar la salida de la plantilla. Si no se proporciona clusterIP como valor, no establezca el valor en una cadena vacía ... Omita el campo por completo.

por ejemplo, en el caso de stable/nginx-ingress :

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

Debería cambiarse a:

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

Hola @bacongobbler , creo que si no se proporciona ningún valor, aún terminaremos con clusterIP: "" ... mejor sería el valor clusterIP: "" completamente comentado en el archivo de valores. Esto lo omite de los manifiestos renderizados cuando se configura y debería evitar futuros dolores de cabeza. Sin embargo, si el uso de helm3 y el estado actual de helm tiene clusterIP: "" establecido, es necesario codificar las direcciones IP del clúster en los archivos de valores.

Esta es también la razón por la que --set controller.service.omitClusterIP=true funciona en este caso.

TL; DR no haga esto en sus plantillas de servicio:

clusterIP: ""

De lo contrario, Helm intentará cambiar la IP del clúster del servicio de una dirección IP generada automáticamente a una cadena vacía, de ahí el mensaje de error.

¡Espero que esto ayude!

Hola @bacongobbler , nos enfrentamos al mismo problema durante la migración de la versión de helm v2 a la versión de helm v3. Usamos type: ClusterIP en Servicio pero omitimos ClusterIP y obtenemos:

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

No tenemos spec.clusterIP: en nuestra plantilla de timón, pero obtuvimos este error después de migrar la versión a través de helm 2to3

Plantilla de servicio:

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

El mismo problema aqui. Es que no hemos tocado el Servicio. Es Ingress lo que se cambió antes de la actualización.

Afecta a los recursos con un campo inmutable si elimina la bandera --force de helm upgrade --install y no toca el campo inmutable, todo funciona bien. Pero si quieres aumentar la desviacion de recursos ??? Necesita recrear los recursos, pero el timón 3 no actualizará los recursos ...
@bacongobbler ^^^

intenté actualizar hpa con la nueva apiVersion de 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

El comentario de @bacongobbler y @ kritcher722 pulgar clusterIP: "" en los manifiestos renderizados.

Parece que Microsoft es el mentor del proyecto. Veo estilo. :)

Vuelva a abrir. El problema no está solucionado. Este "truco" sugerido por nasseemkullah no es apropiado. No le pidas a la gente que salte de cabeza. Solo arréglalo. Ruta migratoria muy pobre. Helm apesta.

@antonakv que manera de empezar el año :)
Creo que, en general, estamos jugando con fuego cuando proporcionamos clusterIP como un valor configurable en un gráfico, y no podemos culpar totalmente a una herramienta / persona / RP en particular.
Si clusterIP necesita ser un valor configurable, por defecto no debería estar en la plantilla renderizada, esa es la idea de comentar en los archivos de valores según https://github.com/helm/charts/blob/270172836fd8cf56d787cf7d04d938856de0c794/stable /nginx-ingress/values.yaml#L236

Esto, si no me equivoco, debería evitar futuros dolores de cabeza para aquellos que instalen el gráfico a partir de ese cambio. Pero para aquellos de nosotros (incluido yo mismo) que lo habíamos instalado antes y luego migrado a helm3, me temo que grabar los valores actuales de clusterIP en nuestros archivos de valores O desinstalar y reinstalar el gráfico (¡causa tiempo de inactividad!) Son las únicas opciones que tengo. ver.

Las opiniones son mías, no me pagan por trabajar en Helm, solo un usuario final como tú. Aquellos a quienes se les paga por trabajar en este tiempo completo pueden brindar más información.

¡Feliz año nuevo y buena suerte! No renuncies al timón, juntos podemos mejorarlo.

Hola @bacongobbler , nos enfrentamos al mismo problema durante la migración de la versión de helm v2 a la versión de helm v3. Usamos type: ClusterIP en Servicio pero omitimos ClusterIP y obtenemos:

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

No tenemos spec.clusterIP: en nuestra plantilla de timón, pero obtuvimos este error después de migrar la versión a través de helm 2to3

Plantilla de servicio:

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

Tenemos el mismo problema. No definimos clusterIP en absoluto en nuestro gráfico y no está presente en la plantilla final. Sin embargo, seguimos obteniendo el mismo error y solo con la bandera --force .

Nos encontramos con el mismo problema:

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 no es parte de la plantilla de Servicio, sin embargo, con Helm 3.0.2 y una llamada helm upgrade ... --force --install , también estamos viendo:

Error: ACTUALIZACIÓN FALLIDA: no se pudo reemplazar el objeto: El servicio "ficticio" no es válido: spec.clusterIP: Valor no válido: "": el campo es inmutable

Vuelva a abrir.

@ tomcruise81 , consulte https://github.com/helm/helm/issues/7350 para ver el hilo en --force . Eso da como resultado el mismo error, pero se debe a cómo parece funcionar kubectl replace . Es un problema diferente al que se describe aquí, que pertenece a Service clusterIPs y la estrategia de parche de fusión de tres vías ( helm upgrade sin el indicador --force ).

@bacongobbler - gracias por la rápida respuesta y aclaración. Mirando a:

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

que hacen uso de https://github.com/kubernetes/cli-runtime/blob/master/pkg/resource/helper.go#L155 -L181, no parece que la llamada a helper.Replace sí lo mismo que kubectl replace -f ... --force (tenga en cuenta la --force al final).

Supongo que aquí es donde está gran parte de la confusión.

Sé que mi expectativa de helm upgrade ... --force y está usando una estrategia de reemplazo era que haría lo mismo que kubectl replace -f ... --force .

Hola @bacongobbler , nos enfrentamos al mismo problema durante la migración de la versión de helm v2 a la versión de helm v3. Usamos type: ClusterIP en Servicio pero omitimos ClusterIP y obtenemos:
Error: UPGRADE FAILED: failed to replace object: Service "dummy" is invalid: spec.clusterIP: Invalid value: "": field is immutable
No tenemos spec.clusterIP: en nuestra plantilla de timón, pero obtuvimos este error después de migrar la versión a través de helm 2to3
Plantilla de servicio:

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

Tenemos el mismo problema. No definimos clusterIP en absoluto en nuestro gráfico y no está presente en la plantilla final. Sin embargo, seguimos obteniendo el mismo error y solo con la bandera --force .

También verifiqué que no hay clusterIP en el manifiesto de lanzamiento:

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

Lo mismo aquí: no definimos ClusterIP ninguna parte, pero aún vemos el error

Jugando un poco más con esto, he observado que:

• helm upgrade ... --force --install - da como resultado _El servicio "ficticio" no es
• helm template ... | kubectl apply -f - - funciona
• helm template ... | kubectl replace -f - - da como resultado _El servicio "ficticio" no es
• helm template ... | kubectl replace --force -f - - funciona

versión kubectl - 1.14.6
versión de timón - 3.0.2

@ tomcruise81 puede intentar usar el complemento helm 2to3 y migrar de helm2 a la versión helm3 y eliminar --force si lo usó anteriormente.
Es un trabajo para nosotros.
En cuanto a mí, y parece que para otros chicos --force tiene un mal comportamiento y debería manejar este caso con un campo inmutable como para mí

@alexandrsemak - gracias por la recomendación. En mi caso, veo esto en un gráfico que solo se ha instalado o actualizado con helm 3.

¡El mismo problema para mí! Utilizando

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

En mi caso, no estoy definiendo ClusterIP en ninguno de los servicios utilizados en mi gráfico, pero me enfrento al mismo problema (consulte las especificaciones a continuación):

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

Como dijeron otros usuarios antes, la razón es que Kubernetes asigna automáticamente al Servicio una IP de clúster la primera vez (por ejemplo, clusterIP: 10.96.26.65 ) y entra en conflicto con clusterIP: "" cuando intenta actualizar. Tenga en cuenta que no estoy generando esto en mis plantillas: clusterIP: ""

Vuelva a abrir este @bacongobbler

Tengo el mismo problema.

@ juan131 @Ronsevet : remove --force El significado cambió.

frente al mismo problema, en gráficos personalizados.
No definimos clusterip en ninguna parte.
Helm v3.0.2
kubectl 1.14.8

El problema es que, a veces, un gráfico permanece en estado fallido aunque los pods se hayan creado y se estén ejecutando. Si intentamos actualizar la misma versión, no funciona sin forzar.
Dado que los pods se están ejecutando, la versión no se puede eliminar ni volver a crear.
Tiene que haber alguna forma de usar la "fuerza"

Lo mismo para mí: acabo de agregar una etiqueta adicional al servicio y enfrenté este error. Además, no defino ClusterIP en ninguna parte; vuelva a abrir el problema

@bacongobbler Estamos implementando StorageClasses como parte de nuestro gráfico y los parámetros de StorageClass son inmutables. Entonces, en la próxima versión, cuando actualizamos el valor de algún parámetro StorageClass, también helm upgrade --force está fallando.
No estoy seguro de cómo manejar este caso para la actualización de StorageClasses. ¿Alguna sugerencia?

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.

Funcionaba bien en helm v2 ya que helm upgrade --force usaba para forzar la eliminación y recrear StorageClass .

Si alguien experimenta síntomas que no son el resultado de la explicación proporcionada en https://github.com/helm/helm/issues/6378#issuecomment -557746499, ¿puede abrir un nuevo problema con sus hallazgos y cómo podemos reproducirlos? ¿Está de nuestro lado?

El problema planteado por el OP se debió al escenario proporcionado anteriormente, donde un gráfico establece el ClusterIP en una cadena vacía en la instalación. Es muy posible que haya otros escenarios en los que este caso en particular pueda surgir, como otros han mencionado con el uso de la bandera --force . Esos casos deben discutirse por separado, ya que el diagnóstico y la solución pueden diferir de los consejos brindados anteriormente.

¡Gracias!

@mssachan vea el n. ° 7082 y el borrador de propuesta en n. ° 7431 para su caso de uso. Esa propuesta tiene como objetivo implementar kubectl replace —force , que sería similar al comportamiento de helm install —force Helm 2.

@mssachan vea el n. ° 7082 y el borrador de propuesta en n. ° 7431 para su caso de uso. Esa propuesta tiene como objetivo implementar kubectl replace —force , que sería similar al comportamiento de helm install —force Helm 2.

Es bueno que esto esté sucediendo. Incluso omitiendo la bandera --force , sigo recibiendo el error al actualizar los gráficos. Por ejemplo, con 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 vea el n. ° 7082 y el borrador de propuesta en n. ° 7431 para su caso de uso. Esa propuesta tiene como objetivo implementar kubectl replace —force , que sería similar al comportamiento de helm install —force Helm 2.

Es bueno que esto esté sucediendo. Incluso omitiendo la bandera --force , sigo recibiendo el error al actualizar los gráficos. Por ejemplo, con 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 Tengo exactamente el mismo problema después de actualizar helm v2 a v3. El progreso de la actualización fue fluido y sin errores, luego trato de actualizar el cert-manager de helm, fallé con el mismo resultado.

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

Cualquier solución para cuando --force no se use, o no se establezca ninguna opción alrededor de clusterIP . Este es mi manifiesto de servicio:

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 , ¿alguna vez encontró una solución para esto? Veo lo mismo por mi parte y mis servicios se definen exactamente como los suyos. No se está configurando ninguna opción para clusterIP y, sin embargo, Helm aún falla en una actualización.

Aquí igual

Obteniendo esto también, re: los dos comentarios anteriores.

Proporcione más información. No podemos ayudarlo sin comprender la causa o cómo surge este problema en su caso. Gracias.

@antonakv este número es un duplicado de 7956
@bacongobbler más información

Tengo el mismo problema, incluso sin configurar el tipo de servicio o clusterIP con helm v3.0.0-rc.2 si uso la opción --force con el comando helm update --install. Sin la fuerza, funciona bien

¡Frio! Me inspiré en tu respuesta, que tengo que comentar force: .. line en helmfile yaml:

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

Funciona 🎉

Probé todo lo anterior, ninguno funcionó para mí. Tuve que deshabilitar nginx-ingress de mi gráfico, hacer una actualización, habilitarlo nuevamente y actualizar nuevamente. Esto provocó un cambio en la dirección IP asignada por el proveedor de la nube, pero no se produjo ningún daño.

Tengo el mismo problema, incluso sin configurar el tipo de servicio o clusterIP con helm v3.0.0-rc.2 si uso la opción --force con el comando helm update --install. Sin la fuerza, funciona bien

La mejor solución, a mí me funciona, ¡gracias!

Estamos teniendo el mismo problema y no pudimos encontrar ninguna solución.
Es bastante simple de reproducir.

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

Me preguntaba por qué --force no funciona aquí, ¿no se supone que force resource updates through a replacement strategy si esta es una estrategia de reemplazo, entonces el servicio debe ser eliminado y luego reemplazado?

@bacongobbler Llegué a este hilo después de verificar https://github.com/helm/helm/issues/7956

Al igual que con todos los comentaristas anteriores: no tenemos "clusterIP" en las plantillas, pero el error aún está presente con la última versión de Helm si se usa la marca --force.

Versión del timón: 3.4.1

"helm -n kube-system get manifest CHART_NAME | grep clusterIP" no muestra resultados.

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

La misma explicación proporcionada en https://github.com/helm/helm/issues/6378#issuecomment -557746499 también se aplica aquí en su caso @ nick4fake. La diferencia es que con --force , le está pidiendo a Kubernetes que tome su manifiesto completamente renderizado y sobrescriba con fuerza el objeto en vivo actual. Dado que su manifiesto no contiene un campo clusterIP , Kubernetes lo toma y asume que está tratando de eliminar el campo clusterIP del objeto en vivo, de ahí el error Invalid value: "": field is immutable .

@bacongobbler Lo siento mucho si me pierdo algo aquí, tal vez simplemente no sé lo suficiente sobre los aspectos internos de Helm.

"Mi recomendación sería cambiar la salida de la plantilla. Si no se proporciona ningún clusterIP como valor, no establezca el valor en una cadena vacía ... Omita el campo por completo".

¿Entonces, cuál es la solución? ¿Significa eso que el indicador "--force" no se puede usar en absoluto si el campo clusterIP no está configurado en algún valor estático?

En lo que respecta a Kubernetes: sí.

Según tengo entendido, esto es un problema con Kubernetes, porque "sobrescribir a la fuerza" no se comporta de la misma manera que "eliminar y volver a crear". ¿Hay algún error aguas arriba?

Por otro lado, Helm también es engañoso, porque --force se describe como "forzar actualizaciones de recursos a través de una estrategia de reemplazo". Si bien en realidad no realiza ningún reemplazo, solo intenta sobrescribir con fuerza los recursos (sería mejor nombrar la bandera --force-overwrite ). El reemplazo forzoso parecería eliminar y volver a crear (podría haber una marca --force-recreate ). Por supuesto, --force-recreate podría ser un poco peligroso de usar para algunos recursos, pero siempre tendría éxito.

De todos modos, Helm podría implementar una solución alternativa para este tipo de problemas. Si el comportamiento actual (descrito como --force-overwrite ) falla y detecta un error de campo inmutable, debe eliminar y volver a crear el recurso (como --force-recreate ).