<p>обновление руля не выполняется с spec.clusterIP: Invalid value: "": field is immutable</p>

Предоставлено недостаточно информации для воспроизведения. Расскажите, пожалуйста, как создать воспроизводимую диаграмму и какие команды Helm вы использовали.

Привет, вот шаги воспроизведения
Имея два файла yaml служб, как показано ниже.

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

Затем поместите туда два файла в helm1 / templates / и установите. Он показывает, что служба prometheus использует clusterIP, а версия 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

Теперь обновите раздел для nginx.yaml до новой версии 1.16.

        image: nginx:1.16

и prometheus.yaml, изменив его на LoadBalancer.

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

Теперь поместите их как helm2 и выполните обновление. Затем вы можете увидеть, что обновление вызывает некоторые ошибки, но служба nginx проходит через обновление до новой версии, но prometheus не обновляется, поскольку он все еще использует IP-адрес кластера.

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

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

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

список руля показывает

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

история руля

# 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

У нас такое же поведение с v3.2.0, переход на v3.1.3 - наше временное исправление.

У меня много этого с моей миграцией Helm 2 -> 3. Когда я пытаюсь обновить конвертированные версии в первый раз, я получаю много этого. Это пока для графиков Nginx Ingress, Prometheus Operator, Graylog и Jaeger. Большинству из них я доволен простым удалением сервисов и разрешением Helm воссоздавать их, но для Nginx Ingress это не вариант ...

Только что нашел этот https://github.com/helm/helm/issues/6378#issuecomment -557746499, который объясняет проблему в моем случае.

Закрытие дубликатом №6378. @cablespaghetti нашел более глубокое объяснение такого поведения, которое подробно описано.

Сообщите нам, если это не сработает для вас.

@GaramNick, зачем вам откатиться на более

@bacongobbler Пока ты здесь. Есть ли способ исправить эту ситуацию без удаления релиза и повторного развертывания? Кажется, я не могу сделать это под управлением 2 или 3. Я хочу взломать существующие данные о выпуске, поэтому Хелм считает, что clusterIP всегда опускался, и поэтому никаких исправлений не требуется.

Вы пробовали kubectl edit ?

У нас есть та же проблема, и переход на 3.1.3 исправил ее и для нас. Я предполагаю, что это связано с новой логикой в https://github.com/helm/helm/pull/7649/commit/d829343c1514db17bee7a90624d06cdfbffde963, учитывая, что это Create а не обновление, таким образом пытаясь установить пустое IP без повторного использования заполненного

Интересная находка. спасибо за расследование.

@jlegrone есть шанс, что у вас будет время разобраться в этом?

@bacongobbler Наш

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/

В версии 3.2.0 эта команда не работает с Service "service-name" is invalid: spec.clusterIP: Invalid value: "": field is immutable

На v3.1.3 это работает нормально.

Дайте мне знать, если хотите получить больше информации.

То же самое. У нас был следующий service.yaml, отлично работавший с helm2 в течение многих месяцев.
После миграции команда helm 3.2 helm upgrade завершилась ошибкой сохранения, как указано выше. Переход на 3.1.3 решил эту проблему.

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

У нас возникла та же проблема, и при переходе на версию 3.1.3 она была исправлена ​​и у нас. Я предполагаю, что это связано с новой логикой в ​​d829343, учитывая, что это Create, а не обновление, таким образом пытаясь установить пустой IP-адрес и не использовать повторно заполненный

@ n1koo Можете ли вы объяснить, почему вы думаете, что это код, вызывающий проблему? Поскольку это код установки, а не обновления, а также код в 3.1 - это ` create и он работает.

Я рассматриваю проблему с @adamreese , и мы _думали_, что это патч, который идентифицировал @ n1koo . Метод Create будет обходить обычное трехстороннее различие в службе, в результате чего для параметра clusterIP службы будет установлено значение «» вместо значения, заданного Kubernetes. В результате манифест, отправленный на сервер API, _ кажется_ сбрасывающим IP-адрес кластера, что недопустимо для службы (и определенно не то, что предполагал пользователь).

Мы все еще изучаем этот вопрос, и я обновлю его, если мы узнаем больше.

Итак, https://github.com/helm/helm/issues/6378#issuecomment -557746499 правильно. Пожалуйста, прочтите это, прежде чем продолжить решение этой проблемы. Если установлено clusterIP: "" , Kubernetes назначит IP. При следующем обновлении Helm, если снова clusterIP:"" , будет выдана указанная выше ошибка, потому что _to Kubernetes_ покажется, что вы пытаетесь сбросить IP. (Да, Kubernetes изменяет раздел службы spec: !)

Когда метод Create обходит 3-стороннее различие, он устанавливает clusterIP: "" вместо того, чтобы устанавливать его на IP-адрес, назначенный Kubernetes.

Воспроизвести:

$ 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

Во второй раз, когда вы запустите обновление, оно завершится ошибкой.

Я не могу воспроизвести случай @IdanAdar на master .

@GaramNick недостаточно информации о сервисе, который вы используете, чтобы мы могли воспроизвести вашу ошибку.

Моя ситуация:
version.BuildInfo{Version:"v3.2.0", GitCommit:"e11b7ce3b12db2941e90399e874513fbd24bcb71", GitTreeState:"clean", GoVersion:"go1.13.10"}
также протестировано с
version.BuildInfo{Version:"v3.2.1", GitCommit:"fe51cd1e31e6a202cba7dead9552a6d418ded79a", GitTreeState:"clean", GoVersion:"go1.13.10"}

учитывая следующий шаблон услуги:

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

что приводит к следующему после 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: {}

Если я затем загружу точно такую ​​же диаграмму, что и в версии 0.0.5 и снова upgrade --install я получу следующее:
Error: UPGRADE FAILED: failed to replace object: Service "hub-alt-bor" is invalid: spec.clusterIP: Invalid value: "": field is immutable

Единственное отличие - это значение метки helm.sh/chart которая теперь имеет значение hub-0.0.5

Это огромный блокиратор.

@GaramNick недостаточно информации о сервисе, который вы используете, чтобы мы могли воспроизвести вашу ошибку.

@technosophos Что вам нужно? Рад предоставить более подробную информацию!

Обновлять! Обновление не выполняется ТОЛЬКО при использовании helm upgrade --install w / --force . Теперь меньше блокиратора.

Ой! Это интересно. Это должно упростить отслеживание ошибки.

Привет @technosophos @bacongobbler, у нас те же 2 проблемы:

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

1. Проблема
   У нас есть шаблон Service без clusterIP но кубернеты автоматически назначат clusterIP :

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

после перехода на Helm 3 с помощью helm 2to3 convert и попробуйте обновить тот же выпуск helm3 upgrade --install --force :

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

если я сделаю то же самое без --force -> helm3 upgrade --install отлично работает без ошибок.

1. Проблема
   если я хочу изменить spec.selector.matchLabels в Deployment, которое является неизменяемым полем без --force я получаю сообщение об ошибке:

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

если я сделаю то же самое с --force я получаю ошибку:

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

Возможно ли реализовать то же поведение для --force что и для helm 2 потому что мы можем без каких-либо ошибок обновить неизменяемое поле?

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 .

Я пробовал убрать опцию силы. Я пробовал с v3.1.3, v3.2.0, а также v3.2.1, все та же проблема.

Трассировки стека

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

У меня возникает эта проблема при изменении версии Helm Chart и наличии существующего развертывания.

Использование Helm v3.2.0

Я могу подтвердить, что переход на 3.1.2 работает.

@ gor181 Как это воспроизвести? Что ломалось на 3.2, а на 3.1 работало? Диаграмма (или, по крайней мере, шаблон svc) и команды - это то, что нам нужно, чтобы понять, что изменилось.

@azarudeena @alexandrsemak - для вас обоих причиной этого является флаг --force . Если вы удалите --force , обновление будет работать?

@technosophos попробовал без силы, не сработало. Планирую попробовать с 3.1.2

@azarudeena, не могли бы вы предоставить набор инструкций по воспроизведению вашей проблемы? Вы показали некоторые выходные данные службы и шаблона развертывания, но затем вы также сослались на values.yaml.tmp выходные данные которого нам неизвестны, или на Chart.yaml.

Не могли бы вы предоставить образец диаграммы, который мы можем использовать для воспроизведения вашей проблемы?

@bacongobbler Я делюсь структурой.

Chart.yaml

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

Я разместил свой шаблон yaml выше,

мое значение yaml.tmp, как показано ниже

zipkinProxy:
  replicaCount: 1

image:
  repository: openzipkin/zipkin

Я упаковываю его как helm package --versionиспользуя то же самое с обновлением. Сообщите мне, работает ли это? Я обновлю здесь, как только попробую с 3.1.2

Редактировать

Пробовал понижением до 3.1.2 и 3.1.1. Все еще не могу исправить это.

Я столкнулся с той же проблемой, но с обновлением диаграммы штурвала через провайдера terraform helm.
После того, как я изменил force_update = true на force_update = false , ошибка исчезла.

У меня возникает эта проблема при изменении версии Helm Chart и наличии существующего развертывания.

Использование Helm v3.2.0

Отключение флага --force заставило его работать.

@technosophos --force Решите проблему с ClusterIP, когда вы переходите на Helm 3 в качестве Helm 2, не пытайтесь обновить ClusterIP, когда это делает Helm 3.
Helm 3 не может решить проблему с неизменяемым файлом, представленным как matchLabels

Kubernetes изменяет раздел службы spec:

Следует ли считать это недостатком дизайна в Kubernetes в корне? https://kubernetes.io/docs/concepts/services-networking/service/#choosing -your-own-ip-address не упоминает об этом поведении. Я ожидал, что назначенное значение будет помещено в раздел status .

(Аналогичное поведение существует для .spec.nodeName из Pod , но это вряд ли повлияет на пользователей Helm.)

v3.2.3: он не работает с --force, он проходит без --force. В шаблоне диаграммы нет ClusterIP: . Что, я думаю, https://github.com/helm/helm/pull/8000/files должен был исправить.

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

Я наблюдаю эту проблему на 3.2.3 но не на 3.2.0 . Отключение силы также было полезным обходным путем.

К вашему сведению, проблема, поднятая OP, и поднятые здесь комментарии по поводу --force являются отдельными, дискретными проблемами. Попробуем здесь сосредоточиться на проблеме OP.

Чтобы уточнить, проблема, которую описывает OP, - это потенциальная регрессия @ n1koo, указанная в https://github.com/helm/helm/issues/7956#issuecomment -620749552. Это похоже на законную ошибку.

Другие комментарии, в которых упоминается удаление --force работающего на них, являются преднамеренным и ожидаемым поведением с точки зрения Kubernetes. С помощью --force вы просите Helm сделать запрос PUT против Kubernetes. Фактически вы просите Kubernetes использовать ваши целевые манифесты (шаблоны, отображаемые в вашей диаграмме из helm upgrade ) в качестве источника истины и перезаписывать ресурсы в вашем кластере обработанными манифестами. Это идентично kubectl apply --overwrite .

В большинстве случаев в ваших шаблонах не указывается IP-адрес кластера, что означает, что helm upgrade --force запрашивает удаление (или изменение) IP-адреса кластера службы. С точки зрения Kubernetes, это незаконная операция.

Это также задокументировано в # 7082.

Вот почему также работает удаление --force : Helm выполняет операцию PATCH, сравнивая текущее состояние, объединяя IP-адрес кластера с исправленным манифестом, сохраняя IP-адрес кластера при обновлении.

Если вы хотите принудительно удалить и воссоздать объект, как это было сделано в Helm 2, взгляните на # 7431.

Надеюсь, это проясняет ситуацию.

Двигаясь вперед, давайте попробуем сосредоточиться здесь на проблеме OP.

Есть ли какие-нибудь обходные пути? Столкнулся с той же проблемой при попытке обновить https://github.com/helm/charts/tree/master/stable/rabbitmq-ha с 1.34.1 до 1.46.4. Очевидно --force или штурвал понижение до 3.1.3 не помогает, удалению данной службы и helm upgrade сделали помощь

@EvgeniGordeev Это будет грубое решение, которое сработало для меня с небольшим

Мы также достигли этого с диаграммой входящего трафика nginxinc. Обычно мы используем --force .

Поскольку эта проблема все еще открыта, есть ли планы исправить ее, или это считается работающим, как задумано (трудно отличить от этого + другие проблемы, открытые с таким же поведением)? Я прочитал одно объяснение, что это проблема с диаграммой, которая сама по себе и clusterIP: "" не должны использоваться, а вместо этого следует полностью опустить значение.

Это то, за чем мы должны разобраться с разработчиками диаграмм?

@cdunford - предлагаемое исправление, чтобы прекратить использование --force как было предложено https://github.com/helm/helm/issues/7956#issuecomment -643432099.

Этот PR также может решить проблему: # 7431 (как указано в этом комментарии) ...

Мы сталкиваемся с этой проблемой N раз, мы также используем флаг --force в нашем конвейере.

исходная проблема возникла вместе с helm2, так будет ли она исправлена ​​и в helm2? @bacongobbler

@bacongobbler, почему вы говорите, что обеспечение "силы" отличается от проблемы, если помогает его удаление ИЛИ понижение версии?

Я имею в виду, что я только что столкнулся с проблемой с Helm 3.3.4, https://artifacthub.io/packages/helm/bitnami/nginx диаграммой, и значения не изменились. Протестировано на трех разных облаках: GCP / GKE, Azure / AKS и AWS / EKS, не удалось на всех трех.

Сработал сразу после того, как я понизил версию Helm до 3.1.3 И также работал над 3.3.4 без флага "--force".

Я думал, что довольно ясно дал понять в своем предыдущем комментарии, что есть два отдельных, уникальных случая, когда пользователь может увидеть эту ошибку. Один из них - случай OP. Другой - от использования --force. Здесь мы сосредоточены на проблеме OP.

Из уважения к людям, которые сталкиваются с той же проблемой, что и OP, пожалуйста, прекратите использовать эту ветку, чтобы говорить о --force. Мы пытаемся обсудить, как решить проблему с ОП. Если вы хотите поговорить о темах, которые не имеют отношения к проблеме, описанной в OP, пожалуйста, либо откройте новую заявку, либо ознакомьтесь с предложениями, которые я сделал ранее.

@tibetsam относительно исправления этого для Helm 2: нет. Мы больше не предоставляем исправления ошибок для Helm 2. См. Https://helm.sh/blog/helm-v2-deprecation-timeline/ для получения дополнительной информации.

Я думаю, мне удалось воспроизвести проблему OP с помощью диаграммы управления jupytherhub.
Надеюсь, с помощью приведенных ниже инструкций вам удастся воспроизвести проблему:

Важный
Диаграмма управления Jupyterhub не содержит поля spec.clusterIP в своих спецификациях службы, как вы можете видеть (например) здесь: https://github.com/jupyterhub/zero-to-jupyterhub-k8s/blob/c0a43af12a89d54bcd6dcb927fd14ac2f6 /jupyterhub/templates/hub/service.yaml#L17 -L29

Я использую helm и вид, чтобы воспроизвести проблему:

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

Как воспроизвести

1. Создать новый вид кластера

kind create cluster

1. Создайте файл с именем config.yaml со следующим содержимым (сгенерированный случайным образом шестнадцатеричный):

proxy:
  secretToken: "3a4bbf7405dfe1096ea2eb9736c0df299299f94651fe0605cfb1c6c5700a6786"

К вашему сведению, я следую инструкциям по установке файла helm ( ссылка )

1. Добавить репозиторий helm

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

1. Установите диаграмму (с опцией --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. Повторите шаг 5

Ошибка:

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

Я в руле 3.3.4, и это все еще проблема

Проблема с Helm 2.14.1 присутствует либо без --force

Временное решение: перейти к type.spec: NodePort фиксированного мое обновлению helmchart.

У нас такая же проблема с v3.4.1 с флагом --force.

@bacongobbler Я знаю, что вы бдительно пытались не допустить угона проблемы OP (отдельно от # 6378). Я подумал, что это может помочь тем, кто отправляет сообщения, просмотреть свое сообщение об ошибке, чтобы узнать, предназначена ли эта ветка для них или нет:

Имеется ли у вас сообщение об ошибке «Ошибка: ОБНОВЛЕНИЕ НЕ выполнено: не удалось _ заменить_ ...» и вы _использовали_ --force в своей команде? GOTO # 6378

Ваше сообщение об ошибке «Ошибка: ОБНОВЛЕНИЕ НЕ выполнено: невозможно _patch_ ...», и вы _ не использовали _ --force в своей команде? Пожалуйста, опубликуйте в этом выпуске, как вы это воспроизвели.

@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

У меня такая же проблема с Helm 3.4.2. Я запускаю helm-chart, который создает развертывание, сервисный аккаунт и сервис. Я добавляю метку к существующему набору меток на диаграмме развертывания, и теперь она отказывается обновляться:

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

По сути, кажется, что вы никогда не сможете добавить метку после первоначального развертывания руля.

Звучит ужасно, но мог ли Хельм реализовать список «неизменяемых полей», для которых требовалась бы особая обработка?

В этом случае "неизменным полем" будет spec.clusterIP объекта службы - Helm будет считать его неизменным и сгенерирует такой запрос API, который а) не будет пытаться заменить его, б) не будет пытаться удалить его. , в) не пытайтесь его обновить.

На практике Helm будет искать текущее значение неизменяемого поля и включать это значение в полезные данные запроса API. В результате сервер API k8s увидит запрос Helm как «хорошо, они не пытаются изменить это поле».

Текущая ситуация такова, что Helm очень ненадежен с особенно сервисными ресурсами, потому что Helm предполагает, что он владеет правдой данного ресурса. Это ложное предположение, которое приводит к проблеме в этой проблеме, поскольку ресурс мог получить новые свойства на стороне сервера, о которых Хелм не знает. Следовательно, Хелм должен знать, какие поля нуждаются в особой обработке, чтобы соответствовать требованиям k8s.

PS. Также kubectl реализует много логики на стороне клиента, что позволяет kubectl выполнять эти неявные требования.

@ jbilliau-rcd

попробуйте не использовать --force

@pre

Я думаю, что с трехсторонним слиянием происходит что-то странное. Возможно, последняя примененная аннотация как-то неправильно записывается.

В конце концов я понял это; очевидно, вы можете изменить метки в Deployment и спецификации модуля, но НЕ в селекторе совпадений ... Kubernetes не любит этого. Что для меня странно; как еще я должен изменить свое развертывание, чтобы выбрать только модули на version "v2", скажем, во время канареечного развертывания? В настоящее время у меня нет возможности сделать это, поэтому я запутался в этом.

Обновление до версии Helm 3.5.0 решило проблему.

Обновление до версии Helm 3.5.0 решило проблему.

как именно?

Обновление до версии Helm 3.5.0 решило проблему.

Helm версии 3.5.0 все еще не работает.
Но без --force работает.

Нажмите это в Helm 3.5.2

Я попытался удалить --force но проблема не исчезла.

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

Пока нашел разумный обходной путь - флаг --reuse-values . Работает в моем случае.

3.5.2 все еще имеет эту проблему, с / без --reuse-values

3.5.3 также имеет это: /