Helm: Helm 3 - nginx aktualisieren - spec.clusterIP: Ungültiger Wert: "": Feld ist unveränderlich

Dies hängt wahrscheinlich mit einer kürzlichen Änderung in Helm 3 zusammen, bei der jetzt eine Dreiwege-Merge-Patch-Strategie ähnlich wie bei kubectl verwendet wird. Siehe #6124

Wenn Sie Schritte zur Reproduktion angeben können, wäre das wunderbar. Danke!

Sicher!

Ich habe einen AKS-Cluster erstellt.

Ich erstelle eine öffentliche IP in der Ressourcengruppe MC_*.

Ich habe die IP-Adresse dieser öffentlichen IP in $ip gespeichert.

Dann habe ich diesen Befehl im Grunde zweimal ausgeführt:

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

Dies ähnelt der Vorgehensweise in https://docs.microsoft.com/en-us/azure/aks/ingress-static-ip.

Der Unterschied besteht darin, dass ich ein Helm-Upgrade durchführe --installiere zweimal. Der Zweck davon ist, eine einzige Befehlszeile (unbedingt) in meinem CI/CD zu haben.

Lassen Sie es mich wissen, wenn Sie mehr Details zum Reproduzieren benötigen.

War das genug, um sich zu reproduzieren? Ich kann ein Bash-Skript bereitstellen, wenn es hilft.

Entschuldigung, ich habe die Woche Zeit beim Helm Summit EU, also hatte ich noch keine Zeit, um zu antworten.

Ah... keine Sorge. Genieße den Gipfel!

Ich habe auch dieses Problem

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

Das nginx-ingress-Diagramm lässt sich beim ersten Durchlauf problemlos installieren, bei einem Upgrade jedoch ...

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

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

Ich glaube, dies ist ein Problem mit dem nginx-Ingress-Diagramm, nicht mit helm3. Standardmäßig versucht das Diagramm immer, controller.service.clusterIP = "" und defaultBackend.service.clusterIP = "" zu passieren, es sei denn, Sie legen controller.service.omitClusterIP=true und defaultBackend.service.omitClusterIP=true .

Link zu Quellen:
https://github.com/helm/charts/blob/master/stable/nginx-ingress/values.yaml#L321
https://github.com/helm/charts/blob/master/stable/nginx-ingress/templates/controller-service.yaml#L22

Problemumgehung:

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

Ich habe es versucht, aber ich erhalte immer noch den gleichen Fehler

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

ingx-values.yaml

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

Wie Sie unten sehen können, enthält die Vorlage keine clusterIP.

Helm-Vorlage ingx stable/nginx-ingress -f ingx-values.yaml

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

Ich vermute, dass es passiert ist, weil ich es ursprünglich ohne omitClusterIP-Parameter bereitgestellt habe und helm v3 versucht, eine 3-Wege-Zusammenführung mit dem ursprünglichen Manifest durchzuführen, das clusterIP: ""

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

Ich konnte es beheben, indem ich zuerst das vorhandene Diagramm löschte und es mit den Optionen omitClusterIP . Unterm Strich funktioniert die vorgeschlagene @bambash nur, wenn Sie Chart installieren und diese Optionen von Anfang an auf "true" gesetzt haben

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

Es wäre großartig, wenn es in helm v3 eine Möglichkeit gäbe, die Zusammenführung mit dem bestehenden Manifest zu überspringen

Entschuldigung, ich hätte angeben sollen, dass diese Werte bei der Erstinstallation der Version festgelegt werden müssen. Das Aktualisieren einer vorhandenen Version kann sich als schwieriger erweisen...

Ich stoße auf dieses Problem mit metric-server-2.8.8, das keine clusterIP in seinen Werten hat, und einigen anderen Diagrammen mit helm v3.0.0-rc.2. irgendein Rat? Ich bin mir nicht sicher, wie ich vorgehen soll.

Mein Problem scheint mit helmfile v0.95.0 zu sein. Ich werde es dort verfolgen :)

Ich habe das gleiche Problem, auch ohne den Diensttyp oder die ClusterIP mit helm v3.0.0-rc.2 einzustellen, wenn ich die Option --force mit dem Befehl helm update --install verwende. Ohne die --force funktioniert es gut

@johannges , das gleiche

Die Einstellung omitClusterIP: true scheint für defaultBackend- und Controller- Dienste zu funktionieren, aber nicht für die Metriken .

Ich denke, dies ist ein Problem mit Helm mit der Option --force während des Upgrades.
Helm versucht, den Dienst neu zu erstellen, ersetzt jedoch auch spec.clusterIP, sodass ein Fehler ausgegeben wird.
Ich kann dies mit meinem eigenen benutzerdefinierten Diagramm bestätigen.
Error: UPGRADE FAILED: failed to replace object: Service "litespeed" is invalid: spec.clusterIP: Invalid value: "": field is immutable

Eigentlich war es ein Fehler von meiner Seite, das Weglassen der clusterIP-Definition bei der Initialisierung des Dienstes (oder des Diagramms) funktioniert gut 👍

Dieser Fehler trat auch bei vorhandenen bereitgestellten _kafka_- und _redis_-Diagrammversionen auf. Das Entfernen von --force dies tatsächlich behoben.

Jetzt erhalte ich einen neuen Fehler von der _redis_-Version:
Error: UPGRADE FAILED: release redis failed, and has been rolled back due to atomic being set: cannot patch "redis-master" with kind StatefulSet: StatefulSet.apps "redis-master" is invalid: spec: Forbidden: updates to statefulset spec for fields other than 'replicas', 'template', and 'updateStrategy' are forbidden

Mit @bacongobbler vereinbart, dass dies mit der Drei-Wege-Merge-Patch-Strategie von Helm v3 zusammenhängt, die wahrscheinlich dazu führt, dass Felder (sogar mit den gleichen Werten wie zuvor) an das Update/den Patch übergeben werden, den Kubernetes nach der ersten Erstellung als unveränderlich/unveränderlich betrachtet.

Falls jemand hier landet, der helm v3 über Terraform verwendet, da Sie ihm nicht direkt sagen können, dass er --force ich Erfolg, das Diagramm manuell mit helm delete löschen und dann Terraform erneut auszuführen. das ist scheiße aber es funktioniert.

Bearbeiten: der ganze Fehler: ("nginx-ingress-singleton-controller" ist der Release-Name, den ich gesetzt habe. Er hat keine spezifische Bedeutung)

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

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

@zen4ever hat das Problem in https://github.com/helm/helm/issues/6378#issuecomment -532766512 genagelt. ich versuche es mal genauer zu erklären....

Wie andere darauf hingewiesen haben, tritt das Problem auf, wenn ein Diagramm eine ClusterIP mit einer leeren Zeichenfolge definiert. Wenn der Dienst installiert ist, füllt Kubernetes dieses Feld mit der ClusterIP, die es dem Dienst zugewiesen hat.

Wenn helm upgrade aufgerufen wird, fordert das Diagramm zum Entfernen von clusterIP auf, daher lautet die Fehlermeldung spec.clusterIP: Invalid value: "": field is immutable .

Dies geschieht aufgrund des folgenden Verhaltens:

1. Bei der Installation gab das Diagramm an, dass clusterIP eine leere Zeichenfolge sein soll
2. Kubernetes hat dem Dienst automatisch clusterIP zugewiesen. Wir verwenden 172.17.0.1 für dieses Beispiel
3. Auf helm upgrade möchte das Diagramm, dass clusterIP eine leere Zeichenfolge ist (oder im obigen Fall von @zen4ever wird es weggelassen).

Beim Generieren des Drei-Wege-Patches sieht es, dass der alte Zustand "" , der Live-Zustand derzeit "172.17.0.1" und der vorgeschlagene Zustand "" . Helm hat festgestellt, dass der Benutzer angefordert hat, clusterIP von "172.17.0.1" in "" zu ändern, und hat daher einen Patch bereitgestellt.

In Helm 2 ignorierte es den Live-Status, sodass keine Änderung (alter Status: clusterIP: "" zu neuer Status: clusterIP: "" ) und kein Patch generiert wurde, der dieses Verhalten umging.

Meine Empfehlung wäre, die Vorlagenausgabe zu ändern. Wenn kein clusterIP als Wert angegeben wird, dann setzen Sie den Wert nicht auf einen leeren String... Lassen Sie das Feld komplett weg.

zB im Fall von stable/nginx-ingress :

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

Sollte geändert werden in:

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

Deshalb funktioniert auch --set controller.service.omitClusterIP=true in diesem Fall.

TL;DR macht dies in Ihren Dienstvorlagen nicht:

clusterIP: ""

Andernfalls versucht Helm, die ClusterIP des Dienstes von einer automatisch generierten IP-Adresse in eine leere Zeichenfolge zu ändern, daher die Fehlermeldung.

Hoffe das hilft!

Als vorübergehende Lösung, wenn Sie versuchen, dies vorerst zum Laufen zu bringen, während dieses Problem behoben wird, habe ich festgestellt, dass ich ein Update durchführen konnte, wenn ich Folgendes tat:

1. Rufen Sie die clusterIP-Werte für den Controller und das Standard-Backend ab über:
   kubectl get svc | grep ingress
2. Fügen Sie Ihrer vorhandenen Helmwerte-Datei die folgenden Überschreibungen hinzu:
   controller: service: clusterIP: <cluster-ip-address-for-controller> defaultBackend: service: clusterIP: <cluster-ip-address-for-default-backend>
3. Führen Sie das Update durch.

Ich habe dies für einen von mir ausgeführten Cluster getestet und es war keine Erholung erforderlich.

Das funktioniert auch. Guter Anruf @treacher. Wenn Sie den gleichen Wert über --set oder in Ihrer Wertedatei festlegen, wird kein Patch generiert, da das Upgrade den Wert von clusterIP nicht ändern möchte.

Das Schließen funktioniert absichtlich gemäß dem oben beschriebenen Verhalten des Drei-Wege-Merge-Patches. Aktionspunkt ist, dass diese Diagramme der Empfehlung oben in https://github.com/helm/helm/issues/6378#issuecomment-557746499 folgen. Hier auf Helms Seite ist nichts zu tun. :)

https://github.com/helm/charts/pull/19146/files erstellt! Danke @bacongobbler

@zen4ever hat das Problem in #6378 (Kommentar) genagelt. ich versuche es mal genauer zu erklären....

Wie andere darauf hingewiesen haben, tritt das Problem auf, wenn ein Diagramm eine ClusterIP mit einer leeren Zeichenfolge definiert. Wenn der Dienst installiert ist, füllt Kubernetes dieses Feld mit der ClusterIP, die es dem Dienst zugewiesen hat.

Wenn helm upgrade aufgerufen wird, fordert das Diagramm zum Entfernen von clusterIP auf, daher lautet die Fehlermeldung spec.clusterIP: Invalid value: "": field is immutable .

Dies geschieht aufgrund des folgenden Verhaltens:

1. Bei der Installation gab das Diagramm an, dass clusterIP eine leere Zeichenfolge sein soll
2. Kubernetes hat dem Dienst automatisch clusterIP zugewiesen. Wir verwenden 172.17.0.1 für dieses Beispiel
3. Auf helm upgrade möchte das Diagramm, dass clusterIP eine leere Zeichenfolge ist (oder im obigen Fall von @zen4ever wird es weggelassen).

Beim Generieren des Drei-Wege-Patches sieht es, dass der alte Zustand "" , der Live-Zustand derzeit "172.17.0.1" und der vorgeschlagene Zustand "" . Helm hat festgestellt, dass der Benutzer angefordert hat, clusterIP von "172.17.0.1" in "" zu ändern, und hat daher einen Patch bereitgestellt.

In Helm 2 ignorierte es den Live-Status, sodass keine Änderung (alter Status: clusterIP: "" zu neuer Status: clusterIP: "" ) und kein Patch generiert wurde, der dieses Verhalten umging.

Meine Empfehlung wäre, die Vorlagenausgabe zu ändern. Wenn kein clusterIP als Wert angegeben wird, dann setzen Sie den Wert nicht auf einen leeren String... Lassen Sie das Feld komplett weg.

zB im Fall von stable/nginx-ingress :

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

Sollte geändert werden in:

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

Hallo @bacongobbler , ich denke, da wir, wenn kein Wert angegeben wird, immer noch clusterIP: "" ... besser wäre es, wenn der Wert clusterIP: "" in der Wertedatei vollständig auskommentiert ist. Dadurch wird es aus gerenderten Manifesten weggelassen, wenn es festgelegt ist, und sollte zukünftige Kopfschmerzen ersparen. Wenn jedoch helm3 verwendet wird und der aktuelle Helmstatus clusterIP: "" gesetzt hat, müssen die ClusterIP-Adressen in Wertedateien hartcodiert werden.

Aus diesem Grund funktioniert auch --set controller.service.omitClusterIP=true in diesem Fall.

TL;DR macht dies in Ihren Dienstvorlagen nicht:

clusterIP: ""

Andernfalls versucht Helm, die ClusterIP des Dienstes von einer automatisch generierten IP-Adresse in eine leere Zeichenfolge zu ändern, daher die Fehlermeldung.

Hoffe das hilft!

Hey @bacongobbler , wir hatten das gleiche Problem während der Migration von helm v2 auf helm v3. Wir verwenden type: ClusterIP im Service, lassen aber ClusterIP überhaupt weg und wir erhalten:

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

Wir haben spec.clusterIP: in unserer Helm-Vorlage nicht, aber wir haben diesen Fehler nach der Migration der Veröffentlichung über Helm 2to3 erhalten

Servicevorlage:

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

Selbes Problem hier. Die Sache ist, dass wir den Service nicht angerührt haben. Es ist Ingress, der vor dem Upgrade geändert wurde.

Es wirkt sich auf Ressourcen mit unveränderlichem Feld aus, wenn das Flag --force von helm upgrade --install gelöscht und das unveränderliche Feld nicht berührt wird. Alles funktioniert gut. Aber wenn Sie stoßende Apiversion von Ressourcen wollen??? Sie müssen Ressourcen neu erstellen, aber Helm 3 wird die Ressourcen nicht aktualisieren....
@bacongobbler ^^^

habe versucht, hpa mit neuer apiVersion von helm 3 zu aktualisieren:
Error: UPGRADE FAILED: rendered manifests contain a new resource that already exists. Unable to continue with update: existing resource conflict: kind: HorizontalPodAutoscaler, namespace: stage, name: dummy-stage

@bacongobbler und @ kritcher722 Daumen abgestürzten Kommentar wurde aktualisiert, wenn Sie dies wünschen unten die Daumen zu entfernen, aber wenn noch freundlich in Uneinigkeit erarbeiten, warum es eine gute Idee, clusterIP: "" in den gerenderten Manifeste.

Sieht so aus, als ob Microsoft Mentor des Projekts ist. Ich sehe Stil. :)

Bitte wieder öffnen. Problem ist nicht behoben. Dieser von nasseemkullah vorgeschlagene "Hack" ist nicht angemessen. Bitten Sie die Leute nicht, auf den Kopf zu springen. Repariere es einfach. Sehr schlechter Migrationsweg. Helm ist scheiße.

@antonakv was für ein Start ins Jahr :)
Ich denke, im Allgemeinen spielen wir mit dem Feuer, wenn wir clusterIP als konfigurierbaren Wert in einem Diagramm bereitstellen, und können nicht einem Tool/einer Person/PR im Besonderen die Schuld geben.
Wenn clusterIP ein konfigurierbarer Wert sein muss, die standardmäßig nicht in der gerenderten Vorlage sein soll, ist , dass die Idee meiner Kommentierung aus in den Werten Dateien per https://github.com/helm/charts/blob/270172836fd8cf56d787cf7d04d938856de0c794/stable /nginx-ingress/values.yaml#L236

Dies sollte, wenn ich mich nicht irre, künftige Kopfschmerzen für diejenigen vermeiden, die das Diagramm ab dieser Änderung installieren. Aber für diejenigen von uns (mich eingeschlossen), die es zuvor installiert und dann zu helm3 migriert haben, befürchte ich, dass das Festhalten der aktuellen clusterIP-Werte in unseren Wertedateien ODER das Deinstallieren und Neuinstallieren des Diagramms (verursacht Ausfallzeiten!) die einzigen Optionen sind, die ich sehen.

Meine Meinung ist meine eigene, ich werde nicht dafür bezahlt, am Steuer zu arbeiten, nur ein Endbenutzer wie Sie. Diejenigen, die für diese Vollzeitarbeit bezahlt werden, können möglicherweise mehr Einblicke bieten.

Frohes neues Jahr und viel Glück! Geben Sie das Ruder nicht auf, gemeinsam können wir es besser machen.

Hey @bacongobbler , wir hatten das gleiche Problem während der Migration von helm v2 auf helm v3. Wir verwenden type: ClusterIP im Service, lassen aber ClusterIP überhaupt weg und wir erhalten:

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

Wir haben spec.clusterIP: in unserer Helm-Vorlage nicht, aber wir haben diesen Fehler nach der Migration der Veröffentlichung über Helm 2to3 erhalten

Servicevorlage:

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

Wir haben das gleiche Problem. Wir definieren clusterIP in unserem Diagramm überhaupt nicht und es ist in der endgültigen Vorlage nicht vorhanden. Wir erhalten jedoch immer noch den gleichen Fehler und nur mit --force Flag.

Wir haben das gleiche Problem:

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

spec.clusterIP ist nicht Teil der Service-Vorlage, aber mit Helm 3.0.2 und einem helm upgrade ... --force --install Aufruf sehen wir auch:

Fehler: UPGRADE FAILED: Objekt konnte nicht ersetzt werden: Dienst "Dummy" ist ungültig: spec.clusterIP: Ungültiger Wert: "": Feld ist unveränderlich

Bitte wieder öffnen.

@tomcruise81 siehe https://github.com/helm/helm/issues/7350 für den Thread zu --force . Das führt zu demselben Fehler, aber es liegt daran, wie kubectl replace zu funktionieren scheint. Es ist ein anderes Problem als das hier beschriebene, das sich auf DienstclusterIPs und die Dreiwege-Merge-Patch-Strategie bezieht ( helm upgrade ohne das --force Flag).

@bacongobbler - danke für die schnelle Antwort und Klarstellung. Anschauen:

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

die https://github.com/kubernetes/cli-runtime/blob/master/pkg/resource/helper.go#L155 -L181 verwenden, scheint der Aufruf von helper.Replace dies nicht zu tun dasselbe wie kubectl replace -f ... --force (beachten Sie die --force am Ende).

Ich vermute, dass hier die Verwirrung groß ist.

Ich kenne meine Erwartung von helm upgrade ... --force und die Verwendung einer Ersatzstrategie war, dass es dasselbe tun würde wie kubectl replace -f ... --force .

Hey @bacongobbler , wir hatten das gleiche Problem während der Migration von helm v2 auf helm v3. Wir verwenden type: ClusterIP im Service, lassen aber ClusterIP überhaupt weg und wir erhalten:
Error: UPGRADE FAILED: failed to replace object: Service "dummy" is invalid: spec.clusterIP: Invalid value: "": field is immutable
Wir haben spec.clusterIP: in unserer Helm-Vorlage nicht, aber wir haben diesen Fehler nach der Migration der Veröffentlichung über Helm 2to3 erhalten
Servicevorlage:

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

Wir haben das gleiche Problem. Wir definieren clusterIP in unserem Diagramm überhaupt nicht und es ist in der endgültigen Vorlage nicht vorhanden. Wir erhalten jedoch immer noch den gleichen Fehler und nur mit --force Flag.

Ich habe auch überprüft, dass im Release-Manifest kein clusterIP :

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

Das gleiche hier - wir definieren ClusterIP nirgendwo, sehen aber immer noch den Fehler

Wenn ich noch etwas damit herumspiele, habe ich Folgendes beobachtet:

• helm upgrade ... --force --install - ergibt _Der Dienst "Dummy" ist ungültig:spec.clusterIP : Ungültiger Wert: "": Feld ist unveränderlich_
• helm template ... | kubectl apply -f - - funktioniert
• helm template ... | kubectl replace -f - - ergibt _Der Dienst "Dummy" ist ungültig:spec.clusterIP : Ungültiger Wert: "": Feld ist unveränderlich_
• helm template ... | kubectl replace --force -f - - funktioniert

kubectl-Version - 1.14.6
Helmversion - 3.0.2

@tomcruise81 Sie können versuchen, das Helm-Plugin 2to3 zu verwenden und von der helm2 zur helm3-Version zu migrieren und --force löschen, wenn Sie es zuvor verwendet haben.
Es ist Arbeit für uns.
Was mich betrifft und wie für andere Leute aussieht, hat --force ein Fehlverhalten und sollte diesen Fall mit unveränderlichem Feld wie bei mir behandeln

@alexandrsemak - danke für die Empfehlung. In meinem Fall sehe ich dies auf einem Diagramm, das nur mit Helm 3 installiert oder aktualisiert wurde.

Gleiches Problem bei mir! Verwenden von

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

In meinem Fall definiere ich ClusterIP für keinen der in meinem Diagramm verwendeten Dienste, aber ich

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

Wie andere Benutzer bereits sagten, liegt der Grund darin, dass Kubernetes dem Dienst beim ersten Mal automatisch eine ClusterIP zuweist (zB clusterIP: 10.96.26.65 ) und es beim Upgradeversuch mit clusterIP: "" kollidiert. Bitte beachte, dass ich dies nicht in meinen Vorlagen erzeuge: clusterIP: ""

Bitte öffne diesen

Ich habe das gleiche Problem.

@juan131 @Ronsevet : remove --force Die Bedeutung hat sich geändert.

mit dem gleichen Problem in benutzerdefinierten Diagrammen konfrontiert.
Wir definieren Clusterip nirgendwo.
Helm v3.0.2
kubectl 1.14.8

Das Problem besteht darin, dass ein Diagramm manchmal im Fehlerzustand bleibt, obwohl die Pods erstellt wurden und ausgeführt werden. Wenn wir versuchen, dieselbe Version zu aktualisieren, funktioniert dies nicht ohne Gewalt.
Da die Pods ausgeführt werden, kann die Version nicht gelöscht und neu erstellt werden.
Es muss eine Möglichkeit geben, "Kraft" anzuwenden

Das gleiche gilt für mich - ich habe dem Dienst gerade ein zusätzliches Label hinzugefügt und bin mit diesem Fehler konfrontiert. Außerdem definiere ich ClusterIP nirgendwo - bitte öffnen Sie das Problem erneut

@bacongobbler Wir stellen StorageClasses als Teil unseres Diagramms bereit und die Parameter von helm upgrade --force fehl.
Nicht sicher, wie dieser Fall für die StorageClasses-Aktualisierung behandelt werden soll. Irgendwelche Vorschläge?

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

Es funktionierte in helm v2 gut, da helm upgrade --force verwendet wurde, um das Löschen zu erzwingen und StorageClass neu zu erstellen .

Wenn jemand Symptome hat, die nicht auf die Erklärung in https://github.com/helm/helm/issues/6378#issuecomment -557746499 zurückzuführen sind, können Sie bitte eine neue Ausgabe mit Ihren Ergebnissen und wie wir sie reproduzieren können, eröffnen? es auf unserer Seite?

Das vom OP angesprochene Problem war auf das oben beschriebene Szenario zurückzuführen, bei dem ein Diagramm die ClusterIP bei der Installation auf eine leere Zeichenfolge festlegte. Es ist durchaus möglich, dass es andere Szenarien gibt, in denen dieser spezielle Fall auftreten kann, wie andere mit der Verwendung des --force Flags erwähnt haben. Diese Fälle sollten separat besprochen werden, da Diagnose und Lösung von den zuvor gegebenen Ratschlägen abweichen können.

Danke schön!

@mssachan siehe #7082 und den Entwurfsvorschlag in #7431 für Ihren Anwendungsfall. Dieser Vorschlag zielt darauf ab, kubectl replace —force zu implementieren, was dem Verhalten von helm install —force von Helm 2 ähnlich wäre.

@mssachan siehe #7082 und den Entwurfsvorschlag in #7431 für Ihren Anwendungsfall. Dieser Vorschlag zielt darauf ab, kubectl replace —force zu implementieren, was dem Verhalten von helm install —force von Helm 2 ähnlich wäre.

Es ist gut, dass dies geschieht. Auch wenn das Flag --force weggelassen wird, erhalte ich beim Aktualisieren von Diagrammen immer noch den Fehler. Zum Beispiel mit cert-manager :

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

@mssachan siehe #7082 und den Entwurfsvorschlag in #7431 für Ihren Anwendungsfall. Dieser Vorschlag zielt darauf ab, kubectl replace —force zu implementieren, was dem Verhalten von helm install —force von Helm 2 ähnlich wäre.

Es ist gut, dass dies geschieht. Auch wenn das Flag --force weggelassen wird, erhalte ich beim Aktualisieren von Diagrammen immer noch den Fehler. Zum Beispiel mit cert-manager :

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

@sc250024 Ich habe genau das gleiche Problem, nachdem ich Helm v2 auf v3 aktualisiert habe. Der Upgrade-Fortschritt war reibungslos und ohne Fehler, dann versuche ich, den cert-manager von helm zu aktualisieren, scheiterte mit der gleichen Ausgabe.

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

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

Alle Problemumgehungen für den Fall, dass --force nicht verwendet wird oder überhaupt keine Option für das Setzen von clusterIP wird. Dies ist mein Service-Manifest:

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

@davidfernandezm hast du dafür schon mal eine lösung gefunden? Ich sehe dasselbe auf meiner Seite und meine Dienste sind genau so definiert wie Ihre. Es wird keine Option für clusterIP festgelegt, und dennoch schlägt Helm bei einem Upgrade fehl.

Hier gilt das gleiche

Bekomme dies auch, re: die beiden obigen Kommentare.

Bitte geben Sie weitere Informationen an. Wir können Ihnen nicht helfen, ohne die Ursache zu verstehen oder zu verstehen, wie dieses Problem in Ihrem Fall auftritt. Danke.

@antonakv dieses Problem Duplikat von 7956
@bacongobbler mehr Infos

Ich habe das gleiche Problem, auch ohne den Diensttyp oder die ClusterIP mit helm v3.0.0-rc.2 einzustellen, wenn ich die Option --force mit dem Befehl helm update --install verwende. Ohne die --force funktioniert es gut

Cool! Ich habe mich von Ihrer Antwort inspirieren lassen, dass ich die Zeile force: .. in der Helmdatei yaml kommentieren muss:

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

Es funktioniert

Ich habe alle oben genannten ausprobiert, keine hat bei mir funktioniert. Ich musste nginx-ingress aus meinem Diagramm deaktivieren, ein Upgrade durchführen, es wieder aktivieren und erneut aktualisieren. Dies führte zu einer Änderung der vom Cloud-Anbieter zugewiesenen IP-Adresse, die jedoch nicht geschadet hat.

Ich habe das gleiche Problem, auch ohne den Diensttyp oder die ClusterIP mit helm v3.0.0-rc.2 einzustellen, wenn ich die Option --force mit dem Befehl helm update --install verwende. Ohne die --force funktioniert es gut

Beste Lösung, bei mir funktioniert es, danke!

Wir haben das gleiche Problem und konnten keine Abhilfe finden.
Es ist ziemlich einfach zu reproduzieren

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

Ich habe mich gefragt, warum das --force hier nicht funktioniert, sollte es nicht force resource updates through a replacement strategy wenn dies eine Ersetzungsstrategie ist, dann sollte der Dienst entfernt und dann ersetzt werden?

@bacongobbler Ich bin zu diesem Thread gekommen, nachdem ich https://github.com/helm/helm/issues/7956 überprüft habe

Wie bei allen vorherigen Kommentatoren: Wir haben "clusterIP" überhaupt nicht in Vorlagen, aber der Fehler ist mit dem neuesten Helm immer noch vorhanden, wenn das Flag --force verwendet wird.

Helmversion: 3.4.1

"helm -n kube-system get manifest CHART_NAME | grep clusterIP" zeigt keine Ergebnisse.

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

Dieselbe Erklärung in https://github.com/helm/helm/issues/6378#issuecomment -557746499 gilt auch hier in Ihrem Fall @nick4fake. Der Unterschied besteht darin, dass Sie bei --force Kubernetes auffordern, Ihr vollständig gerendertes Manifest zu übernehmen und das aktuelle Live-Objekt gewaltsam zu überschreiben. Da Ihr Manifest kein Feld clusterIP , nimmt Kubernetes dies an und geht davon aus, dass Sie versuchen, das Feld clusterIP aus dem Live-Objekt zu entfernen, daher der Fehler Invalid value: "": field is immutable .

@bacongobbler Es tut mir wirklich leid, wenn ich hier etwas übersehe, vielleicht weiß ich einfach nicht genug über Helm-Interna.

"Meine Empfehlung wäre, die Vorlagenausgabe zu ändern. Wenn keine ClusterIP als Wert bereitgestellt wird, dann setzen Sie den Wert nicht auf eine leere Zeichenfolge... Lassen Sie das Feld vollständig aus."

Was ist also die Lösung? Bedeutet das, dass das Flag "--force" überhaupt nicht verwendet werden kann, wenn das clusterIP-Feld nicht auf einen statischen Wert gesetzt ist?

Was Kubernetes betrifft: ja.

Nach meinem Verständnis ein Problem bei Kubernetes, da sich "erzwungenes Überschreiben" nicht wie "löschen und neu erstellen" verhält. Gibt es einen Upstream-Fehler?

Andererseits ist Helm auch irreführend, denn --force wird als "Ressourcenaktualisierung durch eine Ersatzstrategie erzwingen" beschrieben. Während es in Wirklichkeit keinen Ersatz durchführt, versucht es nur, Ressourcen gewaltsam zu überschreiben (es wäre besser, das Flag --force-overwrite ). Erzwungenes Ersetzen würde wie Löschen und erneutes Erstellen aussehen (es könnte ein Flag --force-recreate ). Natürlich könnte --force-recreate für einige Ressourcen etwas gefährlich sein, aber es würde immer erfolgreich sein.

Wie auch immer, Helm könnte einen Fallback-Workaround für solche Probleme implementieren. Wenn das aktuelle Verhalten (beschrieben als --force-overwrite ) fehlschlägt und einen unveränderlichen Feldfehler erkennt, sollte es die Ressource löschen und neu erstellen (als --force-recreate ).