<p>Helm-Upgrade schlägt mit spec.clusterIP fehl: Ungültiger Wert: "": Feld ist unveränderlich</p>

Es wurden nicht genügend Informationen zur Reproduktion bereitgestellt. Bitte teilen Sie uns mit, wie Sie ein reproduzierbares Diagramm erstellen und welche Helm-Befehle Sie verwendet haben.

Hallo, hier sind die Reproduktionsschritte
Mit zwei Diensten yaml Datei wie unten.

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

Dann legen Sie dort zwei Dateien in helm1 / templates / und installieren. Es zeigt, dass der Prometheus-Dienst ClusterIP verwendet und die Nginx-Version 1.14.2 ist

# 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

Aktualisieren Sie nun den Abschnitt für nginx.yaml auf die neue Version 1.16

        image: nginx:1.16

und prometheus.yaml durch Ändern in LoadBalancer.

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

Setzen Sie sie nun als helm2 und führen Sie das Upgrade durch. Dann können Sie sehen, dass das Upgrade einige Fehler auslöst, aber der Nginx-Dienst wird durch ein Upgrade auf eine neue Version durchlaufen, aber der Prometheus wird nicht aktualisiert, da er immer noch Cluster-IP verwendet.

# 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

Steuerliste zeigt

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

Steuergeschichte

# 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

Wir haben das gleiche Verhalten wie in Version 3.2.0. Ein Downgrade auf Version 3.1.3 ist unser vorübergehender Fix

Ich habe viel davon mit meiner Helm 2 -> 3 Migration. Wenn ich zum ersten Mal versuche, die konvertierten Releases zu aktualisieren, bekomme ich viel davon. Dies gilt bisher für Nginx Ingress-, Prometheus Operator-, Graylog- und Jaeger-Diagramme. Die meisten von ihnen geben sich damit zufrieden, nur die Dienste zu löschen und Helm sie neu erstellen zu lassen, aber für Nginx Ingress ist dies keine Option ...

Ich habe gerade diese https://github.com/helm/helm/issues/6378#issuecomment -557746499 gefunden, die das Problem in meinem Fall erklärt.

Schließen als Duplikat von # 6378. @cablespaghetti hat die tiefere Erklärung für dieses Verhalten gefunden, die sehr detailliert beschrieben wird.

Lassen Sie uns wissen, wenn das bei Ihnen nicht funktioniert.

@GaramNick, warum sollte ein Downgrade dies für Sie beheben? Können Sie näher erläutern, was durch ein Downgrade behoben wurde?

@bacongobbler Während du hier bist. Gibt es eine Möglichkeit, diese Situation zu beheben, ohne die Version zu löschen und erneut bereitzustellen? Ich kann unter Helm 2 oder 3 keine Möglichkeit finden, dies zu tun. Ich möchte die vorhandenen Release-Daten hacken, damit Helm der Meinung ist, dass das ClusterIP immer weggelassen wurde und daher kein Patch erforderlich ist.

Haben Sie kubectl edit ausprobiert?

Wir haben das gleiche Problem und ein Downgrade auf 3.1.3 es auch für uns behoben. Ich vermute, dass es mit der neuen Logik in https://github.com/helm/helm/pull/7649/commits/d829343c1514db17bee7a90624d06cdfbffde963 zu tun hat, wenn man bedenkt, dass dies ein Create und kein Update, das versucht, leer zu werden IP und nicht die wiederverwendete

Interessanter Fund. Vielen Dank für die Untersuchung.

@jlegrone Gibt es eine Chance, dass Sie Zeit haben, sich damit zu

@bacongobbler Unsere CI / CD-Pipeline verwendet Helm, um unsere Anwendung zu aktualisieren, die einen Dienst vom Typ ClusterIP enthält. Der Befehl:

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/

In Version 3.2.0 schlägt dieser Befehl mit Service "service-name" is invalid: spec.clusterIP: Invalid value: "": field is immutable fehl

In Version 3.1.3 funktioniert dies einwandfrei.

Lassen Sie mich wissen, wenn Sie weitere Informationen wünschen.

Hier gilt das gleiche. Wir hatten den folgenden service.yaml, der viele, viele Monate lang gut mit helm2 zusammengearbeitet hat.
Nach der Migration schlug der Befehl helm 3.2 helm upgrade mit dem oben beschriebenen Speicherfehler fehl. Ein Downgrade auf 3.1.3 hat das Problem behoben.

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

Wir haben das gleiche Problem und ein Downgrade auf 3.1.3 hat es auch für uns behoben. Ich vermute, dass es mit der neuen Logik in d829343 zu tun hat, wenn man bedenkt, dass dies ein Create und kein Update ist, also versucht man, eine leere IP zu setzen und die aufgefüllte nicht wiederzuverwenden

@ n1koo Kannst du erklären, warum du denkst, dass dies der Code ist, der das Problem verursacht? Da dies der Installations- und nicht der Upgrade-Code ist und auch der Code in 3.1 ein ` create und es funktioniert.

Ich überprüfe das Problem mit @adamreese und wir denken, es ist der Patch, den @ n1koo identifiziert hat. Die Create-Methode umgeht den normalen 3-Wege-Unterschied im Dienst, was dazu führt, dass die Cluster-IP des Dienstes auf "" anstatt auf den von Kubernetes angegebenen Wert gesetzt wird. Infolgedessen scheint das an den API-Server gesendete Manifest die Cluster-IP zurückzusetzen, was für einen Dienst unzulässig ist (und definitiv nicht das, was der Benutzer beabsichtigt hat).

Wir prüfen dies noch und ich werde es aktualisieren, wenn wir mehr erfahren.

Https://github.com/helm/helm/issues/6378#issuecomment -557746499 ist also korrekt. Bitte lesen Sie dies, bevor Sie mit diesem Problem fortfahren. Wenn clusterIP: "" ist, weist Kubernetes eine IP zu. Wenn beim nächsten Helm-Upgrade clusterIP:"" erneut angezeigt wird, wird der obige Fehler ausgegeben, da Kubernetes _ der Ansicht ist, dass Sie versuchen, die IP zurückzusetzen. (Ja, Kubernetes ändert den Abschnitt spec: eines Dienstes!)

Wenn die Create -Methode den 3-Wege-Diff umgeht, setzt sie clusterIP: "" anstatt sie auf die von Kubernetes zugewiesene IP-Adresse zu setzen.

Fortpflanzen:

$ 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

Wenn Sie das Upgrade zum zweiten Mal ausführen, schlägt es fehl.

Ich kann den Fall von @IdanAdar auf master nicht reproduzieren.

@GaramNick Es gibt nicht genügend Informationen über den Dienst, den Sie verwenden, damit wir Ihren Fehler reproduzieren können.

Meine Situation:
version.BuildInfo{Version:"v3.2.0", GitCommit:"e11b7ce3b12db2941e90399e874513fbd24bcb71", GitTreeState:"clean", GoVersion:"go1.13.10"}
auch getestet w /
version.BuildInfo{Version:"v3.2.1", GitCommit:"fe51cd1e31e6a202cba7dead9552a6d418ded79a", GitTreeState:"clean", GoVersion:"go1.13.10"}

gegeben die folgende Service-Vorlage:

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

was nach upgrade --install Folgendes ergibt:

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

Wenn ich dann genau das gleiche Diagramm wie Version 0.0.5 und upgrade --install erneut hochlade, erhalte ich Folgendes:
Error: UPGRADE FAILED: failed to replace object: Service "hub-alt-bor" is invalid: spec.clusterIP: Invalid value: "": field is immutable

Der einzige Unterschied ist der Wert des Labels helm.sh/chart das jetzt einen Wert von hub-0.0.5

Dies ist ein riesiger Blocker.

@GaramNick Es gibt nicht genügend Informationen über den Dienst, den Sie verwenden, damit wir Ihren Fehler reproduzieren können.

@technosophos Was brauchst du? Gerne geben wir Ihnen weitere Details!

Aktualisieren! Das Update schlägt NUR fehl, wenn helm upgrade --install w / --force . Jetzt weniger ein Blocker.

Oh! Das ist interessant. Das sollte es einfacher machen, den Fehler aufzuspüren.

Hallo @technosophos @bacongobbler, wir haben die gleichen 2 Probleme:

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

1. Problem
   Wir haben eine Service Vorlage ohne clusterIP aber Kubernetes weist clusterIP automatisch zu:

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

Nach der Migration auf Helm 3 mit helm 2to3 convert und dem Upgrade derselben Version helm3 upgrade --install --force :

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

Wenn ich das gleiche ohne --force -> helm3 upgrade --install mache, funktioniert das ohne Fehler.

1. Problem
   Wenn ich spec.selector.matchLabels in Deployment ändern möchte, die unveränderliche Felder ohne --force , wird folgende Fehlermeldung angezeigt:

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

Wenn ich das gleiche mit --force mache, bekomme ich folgende Fehlermeldung:

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

Ist es möglich, das gleiche Verhalten für --force wie in helm 2 implementieren, weil wir ohne Fehler ein unveränderliches Upgrade durchführen können?

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 .

Ich habe versucht, die Force-Option zu entfernen. Ich habe mit v3.1.3, v3.2.0 sowie v3.2.1 immer noch das gleiche Problem versucht.

Stapelspur

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

Ich habe dieses Problem, wenn sich die Helm Chart-Version ändert und eine vorhandene Bereitstellung vorliegt.

Verwenden von Helm v3.2.0

Ich kann bestätigen, dass ein Downgrade auf 3.1.2 funktioniert.

@ gor181 Wie können wir das reproduzieren? Was ist bei 3.2 kaputt gegangen, hat aber bei 3.1 funktioniert? Das Diagramm (oder zumindest die SVC-Vorlage) und die Befehle sind das, was wir brauchen, um herauszufinden, was sich geändert hat.

@azarudeena @alexandrsemak - für Sie beide ist die Flagge --force Ursache dafür. Wenn Sie --force entfernen, funktioniert das Upgrade?

@technosophos hat es ohne Gewalt versucht hat nicht funktioniert. Planen Sie es mit 3.1.2 zu versuchen

@azarudeena Können Sie bitte eine Reihe von Anweisungen zur Reproduktion Ihres Problems bereitstellen? Sie haben einige Ausgaben eines Dienstes und einer Bereitstellungsvorlage angezeigt, aber dann haben Sie auch auf ein values.yaml.tmp verwiesen, dessen Ausgabe wir nicht kennen, und auch nicht auf Chart.yaml.

Können Sie uns bitte ein Beispieldiagramm zur Verfügung stellen, mit dem wir Ihr Problem reproduzieren können?

@ Bacongobbler Ich

Chart.yaml

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

Ich habe meine Vorlage Yaml oben gestellt,

Mein Wert yaml.tmp ist wie folgt

zipkinProxy:
  replicaCount: 1

image:
  repository: openzipkin/zipkin

Ich verpacke es als Helmpaket --versionVerwenden Sie das gleiche mit Upgrade. Lassen Sie mich wissen, ob dies funktioniert? Ich werde hier aktualisieren, sobald ich es mit 3.1.2 versuche

Bearbeiten

Versucht durch Herabstufung auf 3.1.2 und 3.1.1. Immer noch nicht in der Lage, dies gepatcht zu bekommen.

Ich hatte das gleiche Problem, aber mit der Aktualisierung einer Helmkarte über den Terraform-Helmanbieter.
Nachdem ich force_update = true in force_update = false geändert hatte, verschwand der Fehler.

Ich habe dieses Problem, wenn sich die Helm Chart-Version ändert und eine vorhandene Bereitstellung vorliegt.

Verwenden von Helm v3.2.0

Durch Deaktivieren des --force-Flags funktionierte es.

@technosophos --force Problem mit ClusterIP beheben, wenn Sie auf Helm 3 migrieren, da Helm 2 nicht versuchen, ClusterIP zu aktualisieren, wenn Helm 3 dies tut.
Helm 3 kann das Problem mit der unveränderlichen Datei matchLabels nicht lösen

Kubernetes ändert den Abschnitt spec: eines Dienstes

Sollte dies als Konstruktionsfehler in Kubernetes an der Wurzel angesehen werden? https://kubernetes.io/docs/concepts/services-networking/service/#choosing -your-own-ip-address erwähnt dieses Verhalten nicht. Ich hätte erwartet, dass ein zugewiesener Wert in den Abschnitt status gestellt wird.

(Ein ähnliches Verhalten besteht für .spec.nodeName eines Pod , aber es ist unwahrscheinlich, dass dies Helm-Benutzer betrifft.)

v3.2.3: Es schlägt mit --force fehl, es wird ohne --force übergeben. Nein ClusterIP: in der Diagrammvorlage. Was ich denke, https://github.com/helm/helm/pull/8000/files sollte beheben.

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

Ich beobachte dieses Problem bei 3.2.3 aber nicht bei 3.2.0 . Das Deaktivieren von Force war ebenfalls eine brauchbare Problemumgehung.

Zu Ihrer Information, das vom OP angesprochene Problem und die hier vorgebrachten Kommentare zu --force sind separate, diskrete Probleme. Versuchen wir, uns hier auf das Problem von OP zu konzentrieren.

Zur Verdeutlichung beschreibt das von OP beschriebene Problem eine potenzielle Regression @ n1koo, die unter https://github.com/helm/helm/issues/7956#issuecomment -620749552 identifiziert wurde. Das scheint ein legitimer Fehler zu sein.

Die anderen Kommentare, in denen die Entfernung von --force wird, sind aus Sicht von Kubernetes beabsichtigtes und erwartetes Verhalten. Mit --force bitten Sie Helm, eine PUT-Anfrage gegen Kubernetes zu stellen. Tatsächlich bitten Sie Kubernetes, Ihre Zielmanifeste (die in Ihrem Diagramm gerenderten Vorlagen von helm upgrade ) als Quelle der Wahrheit zu verwenden und die Ressourcen in Ihrem Cluster mit den gerenderten Manifesten zu überschreiben. Dies ist identisch mit kubectl apply --overwrite .

In den meisten Fällen geben Ihre Vorlagen keine Cluster-IP an. Dies bedeutet, dass helm upgrade --force die Cluster-IP des Dienstes entfernen (oder ändern) möchte. Dies ist aus Sicht von Kubernetes eine illegale Operation.

Dies ist auch in # 7082 dokumentiert.

Dies ist auch der Grund, warum das Entfernen von --force funktioniert: Helm führt eine PATCH-Operation durch, die sich vom Live-Status unterscheidet, die Cluster-IP in das gepatchte Manifest einfügt und die Cluster-IP während des Upgrades beibehält.

Wenn Sie das Objekt wie in Helm 2 gewaltsam entfernen und neu erstellen möchten, schauen Sie sich # 7431 an.

Hoffe das klärt die Dinge.

Lassen Sie uns in Zukunft versuchen, uns hier auf das Problem von OP zu konzentrieren.

Gibt es bekannte Problemumgehungen? Beim Versuch, https://github.com/helm/charts/tree/master/stable/rabbitmq-ha von 1.34.1 auf 1.46.4 zu aktualisieren, trat dasselbe Problem auf. Offensichtlich hat --force oder das Herabstufen des Ruders auf 3.1.3 nicht geholfen. Das Löschen des betreffenden Dienstes und helm upgrade haben geholfen

@EvgeniGordeev Dies wird eine grobe Lösung sein, die für mich mit kleinen Ausfallzeiten funktioniert hat. Deinstallieren Sie das Diagramm / installieren Sie es neu.

Wir haben dies auch mit dem Nginxinc-Ingress-Chart erreicht. Wir verwenden im Allgemeinen --force .

Gibt es Pläne für eine Lösung, um dieses Problem zu beheben, da dieses Problem noch offen ist, oder wird davon ausgegangen, dass es wie geplant funktioniert (es ist schwer zu erkennen, dass dies + die anderen Probleme sind, die mit demselben Verhalten geöffnet wurden)? Ich habe eine Erklärung gelesen, dass dies ein Problem mit dem Diagramm ist, dass selbst und clusterIP: "" nicht verwendet werden sollten und stattdessen der Wert vollständig weggelassen werden sollte.

Ist dies etwas, das wir mit den Diagrammentwicklern verfolgen sollten?

@cdunford - die vorgeschlagene Korrektur, um die Verwendung von --force zu beenden, wie vorgeschlagen wurde https://github.com/helm/helm/issues/7956#issuecomment -643432099.

Diese PR könnte auch das Problem beheben: # 7431 (wie auch in diesem Kommentar vorgeschlagen) ...

Wir haben dieses Problem zum N-Mal getroffen. Wir verwenden auch das Flag --force in unserer Pipeline.

Das ursprüngliche Problem kam mit helm2. Wird es auch in helm2 behoben? @ Bacongobbler

@bacongobbler Warum unterscheidet sich die Bereitstellung von "Kraft" von dem Problem, wenn das

Ich meine, ich habe gerade das Problem mit Helm 3.3.4, https://artifacthub.io/packages/helm/bitnami/nginx, festgestellt und keine Werte geändert. Getestet in drei verschiedenen Clouds: GCP / GKE, Azure / AKS und AWS / EKS, fehlgeschlagen in allen drei.

Sofort gearbeitet, nachdem ich Helm auf 3.1.3 herabgestuft habe UND auch an 3.3.4 ohne "--force" -Flag gearbeitet habe.

Ich dachte, ich hätte in meinem früheren Kommentar ziemlich deutlich gemacht, dass es zwei separate, eindeutige Fälle gibt, in denen ein Benutzer diesen Fehler sehen kann. Eines ist der Fall von OP. Der andere ist von der Verwendung von --force. Wir konzentrieren uns hier auf das Thema OP.

Aus Respekt vor den Menschen, die das gleiche Problem wie das OP haben, hören Sie bitte auf, diesen Thread zu entführen, um über --force zu sprechen. Wir versuchen zu diskutieren, wie das Problem von OP gelöst werden kann. Wenn Sie über Themen sprechen möchten, die für das vom OP beschriebene Problem nicht relevant sind, öffnen Sie entweder ein neues Ticket oder sehen Sie sich die Vorschläge an, die ich zuvor gemacht habe.

@tibetsam in Bezug auf die Behebung dieses https://helm.sh/blog/helm-v2-deprecation-timeline/ .

Ich glaube, ich habe es geschafft, das Problem von OP mit der Jupytherhub-Helmkarte zu reproduzieren.
Mit den folgenden Anweisungen können Sie das Problem hoffentlich reproduzieren:

Wichtig
Das Jupyterhub-Helmdiagramm enthält kein spec.clusterIP -Feld in seinen Service-Spezifikationen, wie Sie (zum Beispiel) hier sehen können: https://github.com/jupyterhub/zero-to-jupyterhub-k8s/blob/c0a43af12a89d54bcd6dcb927fdcc2f623 /jupyterhub/templates/hub/service.yaml#L17 -L29

Ich benutze Helm und Art, um das Problem zu reproduzieren:

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

Wie zu reproduzieren

1. Erstellen Sie einen neuen Artencluster

kind create cluster

1. Erstellen Sie eine Datei mit dem Namen config.yaml mit folgendem Inhalt (zufällig generiertes Hex):

proxy:
  secretToken: "3a4bbf7405dfe1096ea2eb9736c0df299299f94651fe0605cfb1c6c5700a6786"

Zu Ihrer Information Ich folge den Anweisungen für die Installation der Steuerdatei ( Link )

1. Helm-Repository hinzufügen

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

1. Installieren Sie das Diagramm (mit der Option --force ).

RELEASE=jhub
NAMESPACE=jhub

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

1. Wiederholen Sie Schritt 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

Ich bin in Ruder 3.3.4 und das ist immer noch ein Problem

Die Ausgabe von Helm 2.14.1 ist entweder ohne --force

Problemumgehung : type.spec: NodePort Mein Helmchart-Upgrade wurde behoben.

Wir haben das gleiche Problem in Version 3.4.1 mit dem Flag --force.

@bacongobbler Ich weiß, dass Sie wachsam versucht haben, das Problem des OP (getrennt von # 6378) vor einer Entführung zu bewahren. Ich dachte, es könnte denjenigen helfen, die ihre Fehlermeldung überprüfen, um festzustellen, ob dieser Thread für sie ist oder nicht:

Ist Ihre Fehlermeldung "Fehler: UPGRADE FEHLGESCHLAGEN: Fehler beim Ersetzen ..." aufgetreten und Sie

Ist Ihre Fehlermeldung "Fehler: UPGRADE FEHLGESCHLAGEN: kann nicht _patch_ ..." und Sie haben _ --force nicht in Ihrem Befehl verwendet? Bitte posten Sie in dieser Ausgabe, wie Sie es reproduziert haben.

@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

Ich habe das gleiche Problem mit Helm 3.4.2. Ich führe ein Helmdiagramm aus, das eine Bereitstellung, ein Dienstkonto und einen Dienst erstellt. Ich füge meiner vorhandenen Gruppe von Beschriftungen in meinem Diagramm während der Bereitstellung eine Beschriftung hinzu, und jetzt wird das Upgrade abgelehnt:

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

Grundsätzlich scheint es so, als ob Sie nach der ersten Helmbereitstellung niemals ein Etikett hinzufügen können.

Es klingt schrecklich, aber könnte Helm eine Liste von "unveränderlichen Feldern" implementieren, die eine Sonderbehandlung erhalten würden?

In diesem Fall wäre ein "unveränderliches Feld" das spec.clusterIP des Service-Objekts - Helm würde es als unveränderlich betrachten und eine solche API-Anfrage generieren, die beide a) nicht versuchen würde, es zu ersetzen, b) nicht versuchen, es zu entfernen , c) nicht versuchen, es zu aktualisieren.

In der Praxis würde Helm nach dem aktuellen Wert eines unveränderlichen Feldes suchen und diesen Wert in die Nutzdaten der API-Anforderung aufnehmen. Infolgedessen würde der k8s-API-Server die Anfrage von Helm als "OK, sie versuchen nicht, dieses Feld zu ändern" sehen.

Die aktuelle Situation ist, dass Helm mit bestimmten Serviceressourcen sehr unzuverlässig ist, da Helm davon ausgeht, dass es die Wahrheit einer bestimmten Ressource enthält. Dies ist eine falsche Annahme, die zu dem Problem in diesem Problem führt, da eine Ressource möglicherweise serverseitig neue Eigenschaften erhalten hat, von denen Helm nichts weiß. Daher sollte Helm wissen, welche Bereiche einer besonderen Behandlung bedürfen, um ein konformer k8s-Bürger zu sein.

PS. Außerdem implementiert kubectl eine Menge logischer Clientseiten, wodurch kubectl mit diesen impliziten Anforderungen arbeiten kann.

@ jbilliau-rcd

Versuchen Sie, --force nicht zu verwenden

@Vor

Ich denke, mit der Drei-Wege-Zusammenführung passiert etwas Verrücktes. Möglicherweise wird die zuletzt angewendete Anmerkung irgendwie falsch aufgezeichnet.

Am Ende fand ich es heraus; Anscheinend können Sie Beschriftungen auf einem Deployment und auf der Pod-Spezifikation ändern, aber NICHT auf dem Match-Selektor ...... Kubernetes gefällt das nicht. Was mir fremd ist; Wie soll ich meine Bereitstellung sonst so ändern, dass nur Pods auf version "v2" beispielsweise während einer kanarischen Bereitstellung ausgewählt werden? Derzeit habe ich keine Möglichkeit, das zu tun, also bin ich in diesem Teil verwirrt.

Ein Upgrade auf Helmversion 3.5.0 hat das Problem behoben.

Ein Upgrade auf Helmversion 3.5.0 hat das Problem behoben.

wie genau?

Ein Upgrade auf Helmversion 3.5.0 hat das Problem behoben.

Helm Version 3.5.0 funktioniert immer noch nicht.
Aber ohne --force wird gearbeitet.

Schlagen Sie dies in Helm 3.5.2

Ich habe versucht, --force zu entfernen, habe aber immer noch das gleiche Problem.

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

Bisher wurde eine vernünftige Problemumgehung gefunden - --reuse-values flag. Funktioniert für meinen Fall.

3.5.2 hat dieses Problem immer noch mit / ohne --reuse-Werten

3.5.3 hat auch dies: /