<p>la actualización del timón falla con spec.clusterIP: valor no válido: "": el campo es inmutable</p>

No se ha proporcionado suficiente información para reproducir. Díganos cómo crear un gráfico reproducible y qué comandos de Helm usó.

Hola, aquí están los pasos para reproducir
Tener dos servicios de archivo yaml como se muestra a continuación.

nginx.yaml

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

prometheus.yaml

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

Luego coloque allí dos archivos en helm1 / templates / luego instale. Muestra que el servicio prometheus usa clusterIP y la versión de nginx es 1.14.2

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

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

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

Ahora actualice la sección para nginx.yaml a la nueva versión 1.16

        image: nginx:1.16

y prometheus.yaml cambiándolo a LoadBalancer.

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

Ahora póngalos como helm2 y realice la actualización. Luego, puede ver que la actualización arroja algunos errores, pero el servicio nginx se ejecuta mediante la actualización a una nueva versión, pero prometheus no se actualiza porque todavía usa Cluster IP.

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

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

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

muestra la lista del timón

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

historia del timón

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

Tenemos el mismo comportamiento con v3.2.0, la degradación a v3.1.3 es nuestra solución temporal

Tengo mucho de esto con mi migración Helm 2 -> 3. Cuando intento actualizar las versiones convertidas por primera vez, obtengo mucho de esto. Esto es para los gráficos de Nginx Ingress, Prometheus Operator, Graylog y Jaeger hasta ahora. La mayoría de ellos estoy contento con simplemente eliminar los servicios y dejar que Helm los vuelva a crear, pero para Nginx Ingress esta no es una opción ...

Acabo de encontrar este https://github.com/helm/helm/issues/6378#issuecomment -557746499 que explica el problema en mi caso.

Cerrando como duplicado de # 6378. @cablespaghetti encontró la explicación más profunda de este comportamiento, que se describe con gran detalle.

Háganos saber si eso no funciona para usted.

@GaramNick, ¿

@bacongobbler Mientras estás aquí. ¿Hay alguna forma de solucionar esta situación sin eliminar la versión y volver a implementarla? No puedo parecer una forma de hacerlo con el timón 2 o 3. Quiero piratear los datos de la versión existente para que Helm piense que el clusterIP siempre se ha omitido y, por lo tanto, no es necesario ningún parche.

¿Has probado kubectl edit ?

Tenemos el mismo problema y la degradación a 3.1.3 solucionó también para nosotros. Supongo que tiene que ver con la nueva lógica en https://github.com/helm/helm/pull/7649/commits/d829343c1514db17bee7a90624d06cdfbffde963 considerando esto un Create y no una actualización, por lo tanto, tratando de establecer un vacío IP y no reutilizar la poblada

Interesante hallazgo. gracias por investigar.

@jlegrone, ¿hay alguna posibilidad de que tengas tiempo para investigar esto?

@bacongobbler Nuestro

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

En v3.2.0 este comando falla con Service "service-name" is invalid: spec.clusterIP: Invalid value: "": field is immutable

En v3.1.3 esto funciona bien.

Avísame si quieres tener más información.

Aquí igual. Tuvimos el siguiente service.yaml funcionando bien con helm2 durante muchos meses.
Después de la migración, el comando helm 3.2 helm upgrade falló con el error de guardado anterior. La degradación a 3.1.3 lo resolvió.

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

Tenemos el mismo problema y la actualización a 3.1.3 lo solucionó también para nosotros. Supongo que tiene que ver con la nueva lógica en d829343 considerando esto como una creación y no una actualización, por lo que se intenta establecer una IP vacía y no reutilizar la poblada

@ n1koo ¿Puede explicar por qué cree que este es el código que causa el problema? Como este es el código de instalación y no de actualización, y también el código en 3.1 es un ` create y funciona.

Estoy revisando el problema con @adamreese , y pensamos que es el parche que identificó @ n1koo . El método Create omitirá la diferencia de 3 vías normal en el servicio, lo que dará como resultado que la IP del clúster del servicio se establezca en "" en lugar del valor que rellena Kubernetes. Como resultado, el manifiesto enviado al servidor de API _ parece estar restableciendo la IP del clúster, lo cual es ilegal en un servicio (y definitivamente no es lo que el usuario pretendía).

Todavía estamos investigando esto y lo actualizaré si aprendemos más.

Entonces https://github.com/helm/helm/issues/6378#issuecomment -557746499 es correcto. Léalo antes de continuar con este problema. Si se establece clusterIP: "" , Kubernetes asignará una IP. En la próxima actualización de Helm, si clusterIP:"" nuevamente, dará el error anterior, porque parece _para Kubernetes_ que está intentando restablecer la IP. (¡Sí, Kubernetes modifica la sección spec: de un servicio!)

Cuando el método Create omite la diferencia de 3 vías, establece clusterIP: "" lugar de configurarlo en la dirección IP asignada por Kubernetes.

Reproducir:

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

La segunda vez que ejecute la actualización, fallará.

No puedo reproducir el caso de @IdanAdar en master .

@GaramNick no hay suficiente información sobre el servicio que está utilizando para que podamos reproducir su error.

Mi situación:
version.BuildInfo{Version:"v3.2.0", GitCommit:"e11b7ce3b12db2941e90399e874513fbd24bcb71", GitTreeState:"clean", GoVersion:"go1.13.10"}
también probado con
version.BuildInfo{Version:"v3.2.1", GitCommit:"fe51cd1e31e6a202cba7dead9552a6d418ded79a", GitTreeState:"clean", GoVersion:"go1.13.10"}

dada la siguiente plantilla de servicio:

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

lo que da como resultado lo siguiente después de upgrade --install :

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

Si luego subo exactamente el mismo gráfico que la versión 0.0.5 y upgrade --install nuevamente, obtengo lo siguiente:
Error: UPGRADE FAILED: failed to replace object: Service "hub-alt-bor" is invalid: spec.clusterIP: Invalid value: "": field is immutable

La única diferencia es el valor de la etiqueta helm.sh/chart que ahora tiene un valor de hub-0.0.5

Este es un gran bloqueador.

@GaramNick no hay suficiente información sobre el servicio que está utilizando para que podamos reproducir su error.

@technosophos ¿Qué necesitas? ¡Feliz de proporcionar más detalles!

¡Actualizar! La actualización falla SOLO cuando se usa helm upgrade --install w / --force . Menos bloqueador ahora.

¡Oh! Eso es interesante. Eso debería facilitar la localización del error.

Hola @technosophos @bacongobbler , tenemos los mismos 2 problemas:

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

1. Asunto
   Tenemos la plantilla Service sin clusterIP pero kubernetes asignará clusterIP automáticamente:

apiVersion: v1
kind: Service
metadata:
  name: {{ .Release.Name }}
  labels:
    app: {{ .Values.image.name }}
    release: {{ .Release.Name }}
spec:
  type: ClusterIP
  ports:
    - port: {{ .Values.service.port }}
      targetPort: {{ .Values.service.port }}
      protocol: TCP
      name: http
  selector:
    app: {{ .Values.image.name }}
    release: {{ .Release.Name }}

después de migrar a helm 3 con helm 2to3 convert e intentar actualizar la misma versión helm3 upgrade --install --force :

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

si hago lo mismo sin --force -> helm3 upgrade --install funciona bien sin error.

1. Asunto
   si quiero cambiar spec.selector.matchLabels en la implementación, que son campos inmutables sin --force , aparece el error:

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

si hago lo mismo con --force obtengo el error:

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

¿Es posible implementar el mismo comportamiento para --force que en helm 2 porque podemos sin ningún error actualizar el archivo inmutable?

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

---

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

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

He intentado eliminar la opción de fuerza. Intenté con v3.1.3, v3.2.0 y v3.2.1, pero seguí teniendo el mismo problema.

Seguimiento de pila

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

Tengo este problema cuando la versión de Helm Chart cambia y tengo una implementación existente.

Usando Helm v3.2.0

Puedo confirmar que la degradación a 3.1.2 funciona.

@ gor181 ¿Cómo podemos reproducir eso? ¿Qué se rompió en 3.2 pero funcionó en 3.1? El gráfico (o al menos la plantilla de servicio) y los comandos son lo que necesitamos para poder averiguar qué cambió.

@azarudeena @alexandrsemak - para ambos, el --force bandera es lo que está causando esto. Si elimina --force , ¿funciona la actualización?

@technosophos lo intentó sin fuerza, no funcionó. Planeando probar con 3.1.2

@azarudeena , ¿puede proporcionar un conjunto de instrucciones para reproducir su problema? Mostró algún resultado de un servicio y una plantilla de implementación, pero luego también hizo referencia a un values.yaml.tmp que no conocemos el resultado, ni al Chart.yaml.

¿Puede proporcionarnos una tabla de muestra que podamos utilizar para reproducir su problema?

@bacongobbler Estoy compartiendo la estructura.

Chart.yaml

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

He puesto mi plantilla yaml arriba,

mi valor yaml.tmp es el siguiente

zipkinProxy:
  replicaCount: 1

image:
  repository: openzipkin/zipkin

Lo empaqueto como paquete helm - versiónusando lo mismo con la actualización. ¿Hazme saber si esto funciona? Actualizaré aquí una vez que lo intente con 3.1.2

Editar

Probado rebajando a 3.1.2 y 3.1.1. Todavía no puedo conseguir este parche.

Enfrenté el mismo problema, pero con la actualización de un gráfico de timones a través del proveedor de timones terraform.
Después de haber cambiado force_update = true a force_update = false , el error desapareció.

Tengo este problema cuando la versión de Helm Chart cambia y tengo una implementación existente.

Usando Helm v3.2.0

La desactivación de la bandera --force lo hizo funcionar.

@technosophos --force resolver problema con ClusterIP cuando migra a helm 3 como helm 2 no intente actualizar ClusterIP cuando helm 3 lo hace.
Helm 3 no puede resolver el problema con inmutable presentado como matchLabels

Kubernetes modifica la sección spec: de un servicio

¿Debería considerarse esto una falla de diseño en Kubernetes en la raíz? https://kubernetes.io/docs/concepts/services-networking/service/#choosing -your-own-ip-address no menciona este comportamiento. Hubiera esperado que se colocara un valor asignado en la sección status .

(Existe un comportamiento similar para el .spec.nodeName de un Pod , pero es poco probable que afecte a los usuarios de Helm).

v3.2.3: falla con --force, pasa sin --force. No ClusterIP: en la plantilla de gráfico. Lo que supongo que se suponía que debía solucionar https://github.com/helm/helm/pull/8000/files .

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

Estoy observando este problema en 3.2.3 pero no en 3.2.0 . La fuerza de desactivación también fue una solución utilizable.

Para su información, el problema planteado por el OP y los comentarios planteados aquí sobre --force son problemas separados y discretos. Intentemos centrarnos en el problema de OP aquí.

Para aclarar, el problema que describe OP es una posible regresión @ n1koo identificada en https://github.com/helm/helm/issues/7956#issuecomment -620749552. Eso parece un error legítimo.

Los otros comentarios que mencionan la eliminación de --force trabajando para ellos es un comportamiento intencional y esperado desde el punto de vista de Kubernetes. Con --force , le pide a Helm que realice una solicitud PUT contra Kubernetes. Efectivamente, le está pidiendo a Kubernetes que tome sus manifiestos de destino (las plantillas representadas en su gráfico de helm upgrade ) como la fuente de la verdad y sobrescriba los recursos en su clúster con los manifiestos representados. Esto es idéntico a kubectl apply --overwrite .

En la mayoría de los casos, sus plantillas no especifican una IP de clúster, lo que significa que helm upgrade --force solicita eliminar (o cambiar) la IP de clúster del servicio. Esta es una operación ilegal desde el punto de vista de Kubernetes.

Esto también está documentado en # 7082.

Esta es también la razón por la que la eliminación de --force funciona: Helm realiza una operación PATCH, a diferencia del estado en vivo, fusionando la IP del clúster en el manifiesto parcheado, conservando la IP del clúster durante la actualización.

Si desea eliminar a la fuerza y ​​volver a crear el objeto como se hizo en Helm 2, eche un vistazo a # 7431.

Espero que esto aclare las cosas.

En el futuro, intentemos centrarnos en el problema de OP aquí.

¿Existen soluciones alternativas conocidas? Enfrenté el mismo problema al intentar actualizar https://github.com/helm/charts/tree/master/stable/rabbitmq-ha de 1.34.1 a 1.46.4. Obviamente, --force o la reducción del timón a 3.1.3 no ayudó, eliminar el servicio en cuestión y helm upgrade sí ayudó

@EvgeniGordeev Esta va a ser una solución cruda que funcionó para mí con un pequeño tiempo de inactividad. Desinstale el gráfico / vuelva a instalarlo.

También hemos logrado esto con el gráfico de ingreso de nginxinc. Usamos --force generalmente.

Dado que este problema aún está abierto, ¿hay planes para algún tipo de solución para abordarlo, o se considera que funciona según lo diseñado (es difícil distinguir de esto + los otros problemas abiertos con el mismo comportamiento)? Leí una explicación de que este es un problema con el gráfico que en sí mismo y clusterIP: "" no deben usarse y, en cambio, el valor debe omitirse por completo.

¿Es esto algo que deberíamos perseguir con los desarrolladores de gráficos?

@cdunford : la solución sugerida para dejar de usar --force como se sugirió https://github.com/helm/helm/issues/7956#issuecomment -643432099.

Este RP también podría abordar el problema: # 7431 (como se sugiere en ese comentario) ...

Llegamos a este problema por N vez, también estamos usando la bandera --force en nuestra canalización.

El problema original vino junto con helm2, entonces, ¿se solucionará también en helm2? @bacongobbler

@bacongobbler ¿por qué dice que proporcionar "fuerza" es diferente del problema si eliminarlo O degradar ayuda?

Quiero decir, acabo de resolver el problema con Helm 3.3.4, https://artifacthub.io/packages/helm/bitnami/nginx chart y no se cambiaron los valores. Probado en tres nubes diferentes: GCP / GKE, Azure / AKS y AWS / EKS, fallaron en las tres.

Trabajé inmediatamente después de haber degradado Helm a 3.1.3 Y también trabajé en 3.3.4 sin la bandera "--force".

Pensé que había dejado bastante claro en mi comentario anterior que hay dos casos únicos separados en los que un usuario puede ver este error. Uno es el caso de OP. El otro es del uso de --force. Nos estamos centrando en el problema de OP aquí.

Por respeto a las personas que están experimentando el mismo problema que el OP, deje de secuestrar este hilo para hablar sobre --force. Estamos tratando de discutir cómo resolver el problema de OP. Si desea hablar sobre temas que son irrelevantes para el problema que describió el OP, abra un nuevo ticket o eche un vistazo a las sugerencias que hice anteriormente.

@tibetsam con respecto a arreglar esto para Helm 2: no. Ya no proporcionamos correcciones de errores para Helm 2. Consulte https://helm.sh/blog/helm-v2-deprecation-timeline/ para obtener más información.

Creo que logré reproducir el problema de OP con el gráfico de timón jupytherhub.
Con suerte, con las instrucciones a continuación, podrá reproducir el problema:

Importante
El gráfico de timón de Jupyterhub no contiene un campo spec.clusterIP en sus especificaciones de servicio, como puede ver (por ejemplo) aquí: https://github.com/jupyterhub/zero-to-jupyterhub-k8s/blob/c0a43af12a89d54bcd6dcb927fdcc2f623a14aca /jupyterhub/templates/hub/service.yaml#L17 -L29

Estoy usando helm y kind para reproducir el problema:

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

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

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

Como reproducir

1. Crear un nuevo grupo de tipos

kind create cluster

1. Cree un archivo llamado config.yaml con el siguiente contenido (hexadecimal generado aleatoriamente):

proxy:
  secretToken: "3a4bbf7405dfe1096ea2eb9736c0df299299f94651fe0605cfb1c6c5700a6786"

Para su información, estoy siguiendo las instrucciones para la instalación del archivo helm ( enlace )

1. Agregar repositorio de helm

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

1. Instale el gráfico (con la opción --force )

RELEASE=jhub
NAMESPACE=jhub

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

1. Repita el paso 5.

Error:

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

Estoy en el timón 3.3.4 y esto sigue siendo un problema

Problema de Helm 2.14.1 presente sin --force

Solución alternativa : cambie a type.spec: NodePort arregló mi actualización de helmchart.

Tenemos el mismo problema en v3.4.1 con la bandera --force.

@bacongobbler Sé que ha intentado atentamente evitar que el problema del OP (aparte del número 6378) sea secuestrado. Pensé que podría ayudar a los que publican a revisar su mensaje de error para saber si este hilo es para ellos o no:

¿Su mensaje de error es "Error: ACTUALIZACIÓN FALLIDA: no se pudo _remplazar_ ..." y usted _ usó_ --force en su comando? GOTO # 6378

¿Su mensaje de error es "Error: ACTUALIZACIÓN FALLIDA: no se puede _parchar_ ..." y usted _ no usó _ --force en su comando? Publique en este número cómo lo reprodujo.

@zpittmansf

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

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

Tengo el mismo problema en Helm 3.4.2. Ejecuto un helm-chart que crea una implementación, una cuenta de servicio y un servicio. Agrego una etiqueta a mi conjunto de etiquetas existente en mi gráfico en la implementación, y ahora se niega a actualizar:

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

Básicamente, parece que nunca puede agregar una etiqueta después de la implementación inicial del timón.

Suena terrible, pero ¿podría Helm implementar una lista de "campos inmutables" que recibirían un tratamiento especial?

En este caso, un "campo inmutable" sería el spec.clusterIP : Helm lo consideraría inmutable y generaría una solicitud de API que a) no intentaría reemplazarlo, b) no intentaría eliminarlo , c) no intente actualizarlo.

En la práctica, Helm buscaría el valor actual de un campo inmutable e incluiría ese valor en la carga útil de la solicitud de API. Como resultado, el servidor de la API de k8s vería la solicitud de Helm como "ok, no están intentando modificar este campo".

La situación actual es que Helm es muy poco confiable, especialmente con los recursos del Servicio, porque Helm asume que contiene la verdad de un recurso dado. Esta es una suposición falsa que conduce al problema en este tema, ya que un recurso puede haber recibido nuevas propiedades del lado del servidor que Helm desconoce. Por lo tanto, Helm debe saber qué campos necesitan un tratamiento especial para ser un ciudadano conforme con k8.

PD. Además, kubectl implementa mucha lógica del lado del cliente, lo que permite que kubectl funcione con estos requisitos implícitos.

@ jbilliau-rcd

intenta no usar --force

@pre

Creo que está sucediendo algo extraño con la fusión de tres vías. Quizás la última anotación aplicada se está registrando incorrectamente de alguna manera.

Terminé resolviéndolo; aparentemente, puede cambiar las etiquetas en un Deployment y en la especificación del pod, pero NO en el selector de coincidencias ... A Kubernetes no le gusta eso. Que es extraño para mí; ¿De qué otra manera se supone que debo modificar mi implementación para seleccionar solo pods en version "v2" durante, digamos, una implementación de canary? Actualmente, no tengo forma de hacer eso, así que estoy confundido en esa parte.

La actualización a la versión 3.5.0 de helm resolvió el problema.

La actualización a la versión 3.5.0 de helm resolvió el problema.

¿cómo exactamente?

La actualización a la versión 3.5.0 de helm resolvió el problema.

Helm versión 3.5.0 todavía no funciona.
Pero sin --force se trabaja.

Golpea esto en Helm 3.5.2

Intenté eliminar --force pero sigo teniendo el mismo problema.

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

Hasta ahora he encontrado una solución razonable: la bandera --reuse-values . Funciona para mi caso.

3.5.2 todavía tiene este problema, con / sin --reuse-values

3.5.3 también tiene esto: /