<p>A atualização do helm falha com spec.clusterIP: Valor inválido: "": o campo é imutável</p>

Não foi fornecida informação suficiente para reproduzir. Diga-nos como criar um gráfico reproduzível e quais comandos do Helm você usou.

Olá, aqui estão as etapas de reprodução
Ter dois arquivos yaml de serviços conforme abaixo.

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

Em seguida, coloque dois arquivos em helm1 / templates / e instale. Mostra que o serviço prometheus usa clusterIP e a versão nginx é 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

Agora atualize a seção de nginx.yaml para a nova versão 1.16

        image: nginx:1.16

e prometheus.yaml alterando-o para LoadBalancer.

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

Agora coloque-os como helm2 e faça o upgrade. Então você pode ver a atualização lançar alguns erros, mas o serviço nginx continua, atualizando para uma nova versão, mas o prometheus não é atualizado porque ainda está usando o IP do cluster.

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

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

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

mostra a lista de leme

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

história do leme

# 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

Temos o mesmo comportamento com a v3.2.0, fazer o downgrade para a v3.1.3 é nossa correção temporária

Eu tenho muito disso com minha migração Helm 2 -> 3. Ao tentar atualizar as versões convertidas pela primeira vez, recebo muito disso. Isso é para Nginx Ingress, Prometheus Operator, Graylog e gráficos Jaeger até agora. Na maioria deles, estou satisfeito em apenas excluir os serviços e deixar o Helm recriá-los, mas para o Nginx Ingress isso não é uma opção ...

Acabei de encontrar este https://github.com/helm/helm/issues/6378#issuecomment -557746499 que explica o problema no meu caso.

Fechando como uma duplicata de # 6378. @cablespaghetti encontrou a explicação mais profunda para esse comportamento, que é descrito em detalhes.

Deixe-nos saber se isso não funcionar para você.

@GaramNick, por que o downgrade resolveria isso para você? Você pode elaborar mais sobre “o que” foi corrigido pela desclassificação?

@bacongobbler Enquanto você está aqui. Existe alguma maneira de corrigir esta situação sem excluir a versão e reimplantar? Não consigo fazer isso no helm 2 ou 3. Quero hackear os dados de lançamento existentes, então o Helm acha que o clusterIP sempre foi omitido e, portanto, nenhum patch é necessário.

Você já experimentou kubectl edit ?

Temos o mesmo problema e o downgrade para 3.1.3 também o corrigiu para nós. Meu palpite é que tem a ver com a nova lógica em https://github.com/helm/helm/pull/7649/commits/d829343c1514db17bee7a90624d06cdfbffde963 considerando isso um Create e não uma atualização, portanto, tentando definir vazio IP e não reutilizando o preenchido

Achado interessante. obrigado por investigar.

@jlegrone tem alguma chance de você ter tempo para investigar isso?

@bacongobbler Nosso pipeline de CI / CD usa Helm para atualizar nosso aplicativo que inclui um serviço com o tipo ClusterIP. O comando:

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/

Na v3.2.0, este comando falha com Service "service-name" is invalid: spec.clusterIP: Invalid value: "": field is immutable

Na v3.1.3 isso funciona bem.

Deixe-me saber se você gostaria de ter mais informações.

Mesmo aqui. Tivemos o seguinte service.yaml funcionando bem com helm2 por muitos meses.
Após a migração, o comando helm 3.2 helm upgrade falhou com o erro de salvamento acima. O downgrade para 3.1.3 resolveu.

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

Temos o mesmo problema e o downgrade para 3.1.3 também corrigiu para nós. Meu palpite é que tem a ver com a nova lógica em d829343 considerando isso um Criar e não uma atualização, tentando definir um IP vazio e não reutilizar o preenchido

@ n1koo Você pode explicar por que acha que este é o código que está causando o problema? Como este é o código de instalação e não atualização, e também o código em 3.1 é um ` create e funciona.

Estou revisando o problema com @adamreese , e _pensamos_ que é o patch que o @ n1koo identificou. O método Create irá ignorar a diferença normal de 3 vias no serviço, o que resultará no clusterIP do serviço sendo definido como "" em vez do valor preenchido pelo Kubernetes. Como resultado, o manifesto enviado ao servidor API _parece_ redefinir o IP do cluster, o que é ilegal em um serviço (e definitivamente não é o que o usuário pretendia).

Ainda estamos investigando isso e atualizarei se aprendermos mais.

Portanto, https://github.com/helm/helm/issues/6378#issuecomment -557746499 está correto. Leia isso antes de continuar com este problema. Se clusterIP: "" estiver definido, o Kubernetes atribuirá um IP. Na próxima atualização do Helm, se clusterIP:"" novamente, ocorrerá o erro acima, porque parece _para o Kubernetes_ que você está tentando redefinir o IP. (Sim, o Kubernetes modifica a seção spec: de um serviço!)

Quando o método Create ignora a diferença de 3 vias, ele define clusterIP: "" vez de defini-lo como o endereço IP atribuído pelo Kubernetes.

Reproduzir:

$ 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

Na segunda vez que você executar a atualização, ela falhará.

Não consigo reproduzir o caso de @IdanAdar em master .

@GaramNick , não há informações suficientes sobre o serviço que você está usando para que possamos reproduzir seu erro.

Minha situação:
version.BuildInfo{Version:"v3.2.0", GitCommit:"e11b7ce3b12db2941e90399e874513fbd24bcb71", GitTreeState:"clean", GoVersion:"go1.13.10"}
também testado com
version.BuildInfo{Version:"v3.2.1", GitCommit:"fe51cd1e31e6a202cba7dead9552a6d418ded79a", GitTreeState:"clean", GoVersion:"go1.13.10"}

dado o seguinte modelo de serviço:

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

que resulta no seguinte após upgrade --install :

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

Se eu fizer o upload deste gráfico exatamente igual à versão 0.0.5 e upgrade --install novamente, recebo o seguinte:
Error: UPGRADE FAILED: failed to replace object: Service "hub-alt-bor" is invalid: spec.clusterIP: Invalid value: "": field is immutable

A única diferença é o valor do rótulo helm.sh/chart que agora tem um valor de hub-0.0.5

Este é um grande bloqueador.

@GaramNick , não há informações suficientes sobre o serviço que você está usando para que possamos reproduzir seu erro.

@technosophos O que você precisa? Fico feliz em fornecer mais detalhes!

Atualizar! A atualização falha SOMENTE ao usar helm upgrade --install w / --force . Menos bloqueador agora.

Oh! Isso é interessante. Isso deve tornar o erro mais fácil de rastrear.

Olá @technosophos @bacongobbler , temos os mesmos 2 problemas:

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

1. Emitir
   Temos Service template sem clusterIP mas o kubernetes atribuirá clusterIP automaticamente:

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

depois de migrar para o leme 3 com helm 2to3 convert e tentar atualizar a mesma versão helm3 upgrade --install --force :

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

se eu fizer o mesmo sem --force -> helm3 upgrade --install funciona bem sem erros.

1. Emitir
   se eu quiser alterar spec.selector.matchLabels na implantação, que são campos imutáveis ​​sem --force , recebo o erro:

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

se eu fizer o mesmo com --force , recebo o erro:

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

É possível implementar o mesmo comportamento para --force como em helm 2 porque podemos, sem qualquer erro, atualizar o arquivo imutável?

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 .

Tentei remover a opção de força. Tentei com v3.1.3, v3.2.0, bem como v3.2.1, ainda com o mesmo problema.

Rastreamento de pilha

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

Estou tendo esse problema quando a versão do Helm Chart muda e há uma implantação existente.

Usando Helm v3.2.0

Posso confirmar que o downgrade para 3.1.2 funciona.

@ gor181 Como podemos reproduzir isso? O que quebrou no 3.2, mas funcionou no 3.1? O gráfico (ou pelo menos o modelo svc) e os comandos são o que precisamos para descobrir o que mudou.

@azarudeena @alexandrsemak - para vocês dois, o sinalizador --force é o que está causando isso. Se você remover --force , a atualização funciona?

@technosophos tentou sem força não funcionou. Planejando tentar 3.1.2

@azarudeena pode fornecer um conjunto de instruções para reproduzir o seu problema? Você mostrou alguma saída de um serviço e um modelo de implantação, mas também referenciou um values.yaml.tmp qual não sabemos a saída, nem o Chart.yaml.

Você pode fornecer um gráfico de amostra que possamos usar para reproduzir seu problema?

@bacongobbler Estou compartilhando a estrutura.

Chart.yaml

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

Coloquei meu template yaml acima,

meu valor yaml.tmp é como abaixo

zipkinProxy:
  replicaCount: 1

image:
  repository: openzipkin/zipkin

Eu empacotei como pacote helm --versionusando o mesmo com a atualização. Deixe-me saber se isso funciona? Vou atualizar aqui uma vez que eu tentar com 3.1.2

Editar

Tentado rebaixando para 3.1.2 e 3.1.1. Ainda não foi possível obter este patch.

Eu enfrentei o mesmo problema, mas com a atualização de um gráfico de leme por meio do fornecedor de leme de terraform.
Depois de alterar force_update = true para force_update = false , o erro foi embora.

Estou tendo esse problema quando a versão do Helm Chart muda e há uma implantação existente.

Usando Helm v3.2.0

Desativar --force flag fez funcionar.

@technosophos --force resolva o problema com o ClusterIP ao migrar para o helm 3 como o helm 2, não tente atualizar o ClusterIP quando o leme 3 o fizer.
O Helm 3 não conseguiu resolver o problema com o arquivo imutável como matchLabels

O Kubernetes modifica a seção spec: de um serviço

Isso deve ser considerado uma falha de design no Kubernetes na raiz? https://kubernetes.io/docs/concepts/services-networking/service/#choosing -your-own-ip-address não menciona esse comportamento. Eu esperava que um valor atribuído fosse colocado na seção status .

(Existe um comportamento semelhante para .spec.nodeName de Pod , mas é improvável que afete os usuários do Helm.)

v3.2.3: falha com --force, passa sem --force. Não há ClusterIP: no modelo de gráfico. O que eu acho que https://github.com/helm/helm/pull/8000/files deveria corrigir.

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

Estou observando esse problema em 3.2.3 mas não em 3.2.0 . A desativação da força também foi uma solução alternativa utilizável.

Para sua informação, a questão levantada pelo OP e os comentários levantados aqui sobre --force são questões separadas e discretas. Vamos tentar nos concentrar no problema de OP aqui.

Para esclarecer, o problema que OP está descrevendo é uma regressão potencial @ n1koo identificada em https://github.com/helm/helm/issues/7956#issuecomment -620749552. Isso parece um bug legítimo.

Os outros comentários que mencionam a remoção de --force trabalhando para eles é um comportamento intencional e esperado do ponto de vista do Kubernetes. Com --force , você está pedindo ao Helm para fazer uma solicitação PUT contra o Kubernetes. Efetivamente, você está pedindo ao Kubernetes para tomar seus manifestos de destino (os modelos renderizados em seu gráfico de helm upgrade ) como a fonte da verdade e substituir os recursos em seu cluster com os manifestos renderizados. Isso é idêntico a kubectl apply --overwrite .

Na maioria dos casos, seus modelos não especificam um IP de cluster, o que significa que helm upgrade --force está pedindo para remover (ou alterar) o IP de cluster do serviço. Esta é uma operação ilegal do ponto de vista do Kubernetes.

Isso também está documentado em # 7082.

É também por isso que a remoção de --force funciona: o Helm faz uma operação PATCH, comparando com o estado ativo, mesclando o IP do cluster no manifesto corrigido, preservando o IP do cluster durante a atualização.

Se você deseja forçar a remoção e recriar o objeto como o que foi feito no Helm 2, dê uma olhada em # 7431.

Espero que isso esclareça as coisas.

Seguindo em frente, vamos tentar nos concentrar na questão do OP aqui.

Existem soluções alternativas conhecidas? Enfrentou o mesmo problema ao tentar atualizar https://github.com/helm/charts/tree/master/stable/rabbitmq-ha de 1.34.1 para 1.46.4. Obviamente --force ou leme downgrade para 3.1.3 não ajudou, excluindo o serviço em questão e helm upgrade ajudou

@EvgeniGordeev Esta vai ser uma solução crua que funcionou para mim com um pequeno tempo de inatividade. Desinstale o gráfico / reinstale.

Também atingimos isso com o gráfico de entrada do nginxinc. Usamos --force geralmente.

Como esse problema ainda está aberto, há planos para algum tipo de solução para resolver isso, ou isso está funcionando conforme planejado (é difícil discernir disso + os outros problemas abertos com o mesmo comportamento)? Eu li uma explicação de que este é um problema com o gráfico que e clusterIP: "" não devem ser usados ​​e, em vez disso, o valor deve ser completamente omitido.

Isso é algo que devemos procurar com os desenvolvedores de gráficos?

@cdunford - a correção sugerida para parar de usar --force conforme sugerido https://github.com/helm/helm/issues/7956#issuecomment -643432099.

Este PR também pode resolver o problema: # 7431 (também sugerido nesse comentário) ...

Encontramos esse problema pela vez N, estamos usando a sinalização --force também em nosso pipeline.

o problema original veio junto com o helm2, então ele também será corrigido no helm2? @bacongobbler

@bacongobbler, por que você diz que fornecer "força" é diferente do problema se removê-la OU rebaixar ajuda?

Quer dizer, acabei de encontrar o problema com Helm 3.3.4, https://artifacthub.io/packages/helm/bitnami/nginx chart e nenhum valor mudou. Testado em três nuvens diferentes: GCP / GKE, Azure / AKS e AWS / EKS, falhou em todos os três.

Trabalhei imediatamente depois de ter rebaixado o Helm para 3.1.3 E também trabalhei no 3.3.4 sem o sinalizador "--force".

Achei que deixei bem claro em meu comentário anterior que existem dois casos separados e únicos em que um usuário pode ver esse erro. Um é o caso da OP. A outra é do uso de --force. Estamos nos concentrando na questão do OP aqui.

Por respeito às pessoas que estão enfrentando o mesmo problema que o OP, pare de sequestrar este tópico para falar sobre --force. Estamos tentando discutir como resolver o problema do OP. Se você quiser falar sobre tópicos irrelevantes para o problema descrito pelo OP, abra um novo tíquete ou dê uma olhada nas sugestões que fiz anteriormente.

@tibetsam com relação a consertar isso para o Helm 2: no. Não estamos mais fornecendo correções de bug para o Helm 2. Consulte https://helm.sh/blog/helm-v2-deprecation-timeline/ para obter mais informações.

Acho que consegui reproduzir o problema de OP com o gráfico de leme do jupytherhub.
Esperançosamente, com as instruções abaixo, você conseguirá reproduzir o problema:

Importante
O gráfico do leme Jupyterhub não contém um campo spec.clusterIP em suas especificações de serviço, como você pode ver (por exemplo) aqui: https://github.com/jupyterhub/zero-to-jupyterhub-k8s/blob/c0a43af12a89d54bcd6dcb927fdcc2f623a14 /jupyterhub/templates/hub/service.yaml#L17 -L29

Estou usando o leme e gentil para reproduzir o 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 reproduzir

1. Crie um novo tipo de cluster

kind create cluster

1. Crie um arquivo chamado config.yaml com o seguinte conteúdo (hexadecimal gerado aleatoriamente):

proxy:
  secretToken: "3a4bbf7405dfe1096ea2eb9736c0df299299f94651fe0605cfb1c6c5700a6786"

Para sua informação, estou seguindo as instruções para a instalação do arquivo de leme ( link )

1. Adicionar repositório de leme

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

1. Instale o gráfico (com a opção --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 o passo 5

Erro:

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

Estou no leme 3.3.4 e isso ainda é um problema

Problema do Helm 2.14.1 presente sem --force

Solução alternativa : mude para type.spec: NodePort corrigiu minha atualização do helmchart.

Temos o mesmo problema na v3.4.1 com --force flag.

@bacongobbler Sei que você tem tentado cuidadosamente evitar que o problema do OP (separado do # 6378) seja sequestrado. Achei que poderia ajudar aqueles que postam a revisar sua mensagem de erro para saber se este tópico é para eles ou não:

É a sua mensagem de erro "Erro: FALHA NO UPGRADE: falha ao _utilizou_ --force em seu comando? GOTO # 6378

A sua mensagem de erro é "Erro: FALHA NO UPGRADE: não é possível não usou _ --force em seu comando? Por favor, poste nesta edição como você o reproduziu.

@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

Estou tendo o mesmo problema no Helm 3.4.2. Eu executo um helm-chart que cria uma implantação, conta de serviço e serviço. Eu adiciono um rótulo ao meu conjunto existente de rótulos no meu gráfico na implantação, e agora ele se recusa a atualizar:

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

Basicamente, parece que você nunca pode adicionar um rótulo após a implantação inicial do leme.

Parece terrível, mas Helm poderia implementar uma lista de "campos imutáveis" que receberiam tratamento especial?

Nesse caso, um "campo imutável" seria o spec.clusterIP do objeto Serviço - o Helm o consideraria imutável e geraria uma solicitação de API que a) não tentaria substituí-lo, b) não tentaria removê-lo , c) não tente atualizá-lo.

Na prática, o Helm procuraria o valor atual de um campo imutável e incluiria esse valor na carga útil da solicitação da API. Como resultado, o servidor API k8s veria a solicitação do Helm como "ok, eles não estão tentando modificar este campo".

A situação atual é que o Helm não é confiável, especialmente com recursos de serviço, porque o Helm presume que ele contém a verdade de um determinado recurso. Essa é uma suposição falsa que leva ao problema nesta edição, uma vez que um recurso pode ter recebido novas propriedades do lado do servidor que o Helm desconhece. Portanto, Helm deve saber quais campos precisam de tratamento especial para ser um cidadão k8s em conformidade.

PS. Além disso, kubectl implementa muita lógica do lado do cliente, o que permite que kubectl atue com esses requisitos implícitos.

@ jbilliau-rcd

tente não usar --force

@pré

Acho que há algo estranho acontecendo com a fusão de três vias. Talvez a última anotação aplicada esteja sendo gravada indevidamente de alguma forma.

Acabei descobrindo; aparentemente, você pode alterar os rótulos em um Deployment e nas especificações do pod, mas NÃO no seletor de correspondência ... o Kubernetes não gosta disso. O que é estranho para mim; De que outra forma devo modificar minha implantação para selecionar apenas pods em version "v2" durante, digamos, uma implantação canário? Atualmente, não tenho como fazer isso, então estou confuso com relação a isso.

Atualizar para a versão 3.5.0 do helm resolveu o problema.

Atualizar para a versão 3.5.0 do helm resolveu o problema.

Como exatamente?

Atualizar para a versão 3.5.0 do helm resolveu o problema.

A versão 3.5.0 do Helm ainda não funciona.
Mas sem --force funciona.

Acerte isso no leme 3.5.2

Tentei remover --force mas ainda obtive o mesmo 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

Até agora, encontrei uma solução alternativa razoável - sinalizador --reuse-values . Funciona para o meu caso.

3.5.2 ainda tenho esse problema, com / sem --reuse-values

3.5.3 também tem: /