Это укусило меня и сегодня.

Похоже, это могло произойти из-за этой фиксации:
https://github.com/helm/helm/commit/32d7f1a3fc226c1745a58b51e318b7362bc7a0bf

TL; DR - Исправить проверку манифеста

К сожалению, если у вас что-то уже развернуто с пустой строкой, вы не можете развернуть что-то «исправленное», поскольку ваши уже развернутые компоненты не пройдут проверку. Единственный выход - helm delete --purge чтобы избавиться от шаблонов-нарушителей из истории и продолжить работу. Или откатить штурвал / румпель

Как обсуждалось с одним из членов сообщества ранее сегодня, # 5576 был изменением. До версии 2.14 Helm автоматически принимал ошибки проверки схемы, но начиная с версии 2.14 проверяются все манифесты, в том числе принятые ранее. Конечным результатом является то, что обновление до 2.14 приводит к тому, что Tiller не проходит проверку манифеста на ранее принятых диаграммах, предотвращая обновления. Извини за это!

Устранение этого несложно: перейти на версию 2.13.1, чтобы обновить ее до тех пор, пока не будет выпущено исправление.

5643 следует исправить это, поскольку проверка выполняется только для новых манифестов, добавляемых в выпуск, и мы хотели бы услышать, решит ли это проблемы, поднятые здесь. Если это так, нам может потребоваться вырезать 2.14.1 с исправлением.

РЕДАКТИРОВАТЬ: # 5576 был PR, который внес изменения. # 5643 - это пиар, который должен это исправить. :)

Я могу завтра попробовать # 5643, если меня не опередят.

Разве благоразумный курс действий не выявит ошибок проверки, которые раньше «незаметно» терпели неудачу, с предупреждением, которое в будущем выпуске станет ошибкой? Или, по крайней мере, соблюдать флаг силы или что-то подобное, которое позволяет пользователю выбирать, как с ним обращаться?

Всем спасибо за ответы!
Я попытался загрузить двоичные файлы из последней сборки Helm Canary, но проблема все еще воспроизводится. Я не уверен, что эти двоичные файлы соответствуют последней версии master.
У меня проблемы со сборкой Helm локально, поэтому я был бы очень заинтересован в результатах вашего теста

Я не уверен, что эти двоичные файлы соответствуют последней версии master.

Проверьте вывод helm version - он должен сказать вам, под каким коммитом работают ваш клиент helm и tiller. Поскольку патч в # 5643 был патчем на стороне сервера, вам необходимо убедиться, что tiller был обновлен.

То же самое, используя k8s 1.8.4:

`Ошибка: ошибка проверки" ": ошибка проверки данных: [ValidationError (Deployment.spec.template.spec.containers [1] .ports [0]): неизвестное поле" exec "в io.k8s.api.core.v1. ContainerPort, ValidationError (Deployment.spec.template.spec.containers [1] .ports [0]): неизвестное поле «initialDelaySeconds» в io.k8s.api.core.v1.ContainerPort]

Ошибка: ошибка проверки "": ошибка проверки данных: ValidationError (StatefulSet.spec): отсутствует обязательное поле "serviceName" в io.k8s.api.apps.v1beta1.StatefulSetSpec Ошибка: ОБНОВЛЕНИЕ НЕ выполнено: ошибка проверки "": ошибка проверки данных: ValidationError (StatefulSet.spec): отсутствует обязательное поле «serviceName» в io.k8s.api.apps.v1beta1.StatefulSetSpec`

Я не уверен, что эти двоичные файлы соответствуют последней версии master.

Проверьте вывод helm version - он должен сказать вам, под каким коммитом работают ваш клиент helm и tiller. Поскольку патч в # 5643 был патчем на стороне сервера, вам необходимо убедиться, что tiller был обновлен.

Спасибо @bacongobbler ! После вашего комментария я обновил свой румпель:

Client: &version.Version{SemVer:"v2.14+unreleased", GitCommit:"9fb19967bab21ecb9748440a99487f2fb0560f63", GitTreeState:"clean"}
Server: &version.Version{SemVer:"canary+unreleased", GitCommit:"9fb19967bab21ecb9748440a99487f2fb0560f63", GitTreeState:"clean"}

Однако я все еще получаю ту же ошибку при запуске helm install . :(
Ошибка: ошибка проверки: ошибка проверки "": ошибка проверки данных: неизвестный тип объекта "nil" в Deployment.spec.template.metadata.annotations.buildID

Фиксация соответствует https://github.com/helm/helm/commit/9fb19967bab21ecb9748440a99487f2fb0560f63 , поэтому похоже, что проблема все еще воспроизводится в моем случае, несмотря на исправление.

Можем ли мы получить расчетное время прибытия исправления? Я действительно хотел бы избежать исправления моего сервера с помощью самосборного руля / румпеля. Спасибо!

@ daniv-msft Не могли бы вы попробовать сделать это в своем шаблоне yaml?

template:
  metadata:
    labels:
      app: {{ template "gateway.name" . }}
      draft: {{ default "draft-app" .Values.draft }}
      release: {{ .Release.Name }}
    annotations:
      buildID: {{ .Values.buildID | quote }}

@SeriousM пока можно 9fb19967 и он у меня работает

@SeriousM пока можно 9fb19967 и он у меня работает

у нас есть много конвейеров выпуска azure DevOps (30+), и каждый из них пытается поддерживать последнюю стабильную версию сборки. Сейчас я мог бы понизить версию, но как только будет запущен следующий конвейер сборки, версия вернется на 2.14.0, и я действительно не перебираю все 30+, чтобы отключить шаг и снова включить его позже. Извините, но мне нужно дождаться исправления.

Есть ли ETA на исправлении?

@ daniv-msft Не могли бы вы попробовать сделать это в своем шаблоне yaml?

template:
  metadata:
    labels:
      app: {{ template "gateway.name" . }}
      draft: {{ default "draft-app" .Values.draft }}
      release: {{ .Release.Name }}
    annotations:
      buildID: {{ .Values.buildID | quote }}

Это мое содержимое файла deployment.yaml, который соответствует пути Deployment.spec.template.metadata.annotations.buildID :

spec:
  template:
    metadata:
      annotations:
        buildID: {{ .Values.buildID }}
      labels:
        app: {{ template "fullname" . }}
        env: {{ .Values.labels.env }}

Как вы думаете, | quote может решить проблему?

@SeriousM Ой. Какую ошибку вы получаете сейчас? И я попробовал | quote с основной фиксацией, а не выпущенной версией, и он в основном будет окружать значение двойными кавычками, и это полезно, когда значение пустое, поскольку yaml отображается как

  annotations:
    buildID: ""

Если вы не используете | quote , он будет отображаться как

  annotations:
    buildID: 

что приведет к ошибке проверки, описанной в проблеме. Я проверил это, используя эту фиктивную диаграмму, которую я создал:

issue-5750.tar.gz

@SeriousM Ой. Какую ошибку вы получаете сейчас?

Моя ошибка Error: UPGRADE FAILED: error validating "": error validating data: unknown object type "nil" in Deployment.spec.template.metadata.annotations.buildID но я не понимаю почему. Сначала я подумал, что buildID не был передан в команду cli из azure DevOps, но поскольку @ daniv-msft получил ту же ошибку, я думаю, это из-за проверки сервера.

@SeriousM Ой. Какую ошибку вы получаете сейчас?

Я попытался изменить свой deployment.yaml, добавив | quote и даже вообще убрав metadata/annotations/buildID но это не помогло.

Это ошибка, которую я получил, когда удалил аннотацию buildID:

Error: failed decoding reader into objects: error validating "": error validating data: unknown object type "nil" in Deployment.spec.template.metadata.annotations.buildID

Что касается выпуска 2.14.1, мы, вероятно, не сможем сократить выпуск до окончания KubeCon.

Что касается выпуска 2.14.1, мы, вероятно, не сможем сократить выпуск до окончания KubeCon.

Вы имеете в виду этот KubeCon?

KubeCon EU, который состоится на следующей неделе, а не в ноябре. :)

KubeCon EU, который состоится на следующей неделе, а не в ноябре. :)

Итак, мы можем ожидать исправления в виде v2.14.1 на 24.5.19?
Могу я как-нибудь его скомпилировать?

@SeriousM Первая полученная ошибка:
Error: UPGRADE FAILED: error validating "": error validating data: unknown object type "nil" in Deployment.spec.template.metadata.annotations.buildID
возникает из-за проблемы в yamls шаблона диаграммы, которую вы, кажется, исправили с помощью | quote

Следующая ошибка
Error: failed decoding reader into objects: error validating "": error validating data: unknown object type "nil" in Deployment.spec.template.metadata.annotations.buildID
возникает из-за плохого манифеста в существующей версии. Чтобы избежать этого, румпель не должен проверять манифесты выпуска и проверять только манифесты, предоставленные пользователем, и это то, что делает PR https://github.com/helm/helm/pull/5643 (fix) и имеет был объединен с мастером. Вы можете использовать канареечный образ культиватора, чтобы проверить, все ли это работает для вас. Если неудачные выпуски исправлены один раз (путем обновления с соответствующими манифестами), то, если конвейер использует версию 2.14, проблем с проверкой не возникнет.

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

Как я могу развернуть этот образ?

@SeriousM С любой версией клиента

helm init --tiller-namespace <namespace> --upgrade --canary-image

Чтобы получить последний клиент helm (мастер), вы можете использовать это: https://helm.sh/docs/using_helm/#from -canary-builds

Итак, похоже, что # 5643 действительно исправляет проблему проверки манифеста:

helm version
Client: &version.Version{SemVer:"v2.14.0", GitCommit:"05811b84a3f93603dd6c2fcfe57944dfa7ab7fd0", GitTreeState:"clean"}
Server: &version.Version{SemVer:"canary+unreleased", GitCommit:"9fb19967bab21ecb9748440a99487f2fb0560f63", GitTreeState:"clean"}

Release "belligerent-horse" has been upgraded.
LAST DEPLOYED: Fri May 17 10:32:12 2019
NAMESPACE: default
STATUS: DEPLOYED

RESOURCES:
==> v1/ConfigMap
NAME                             DATA  AGE
<redacted>-belligerent-horse  1     181d
<redacted>                      2     181d

==> v1/Pod(related)
NAME                               READY  STATUS       RESTARTS  AGE
<redacted>-belligerent-horse-0  1/1    Running      0         5m16s
<redacted>-belligerent-horse-1  1/1    Terminating  0         17h

==> v1/Service
NAME           TYPE       CLUSTER-IP  EXTERNAL-IP  PORT(S)   AGE
<redacted>  ClusterIP  None        <none>       8080/TCP  181d

==> v1/StatefulSet
NAME                             READY  AGE
<redacted>-belligerent-horse  2/2    181d

Конечно, все еще необходимо установить любые недостающие поля проверки в «новых» шаблонах, но это, по крайней мере, позволит вам выполнить развертывание поверх существующих выпусков.

@SeriousM С любой версией клиента

helm init --tiller-namespace <namespace> --upgrade --canary-image

Чтобы получить последний клиент helm (мастер), вы можете использовать это: https://helm.sh/docs/using_helm/#from -canary-builds

Спасибо большое, попробую как можно скорее

@ fooka03 > Спасибо, что поделились результатами вашего теста! Несмотря на исправление, я все еще воспроизводю проблему как с моей собственной диаграммой, так и с диаграммой, предоставленной @ karuppiah7890 ( issue-5750.tar.gz ). Не могли бы вы поделиться диаграммой, которую вы используете, или сообщить нам, если вы заметите разницу в своей диаграмме по сравнению с этой?

@ karuppiah7890 > С предоставленной вами таблицей для успешной установки helm я должен добавить | quote в deployment.yaml, а buildID также должен быть указан в values.yaml. Если я комментирую строку в #buildID: "" или удаляю | quote , тогда ошибка воспроизводится, тогда как в версии 2.13.1 она работала нормально.

К сожалению, в моем случае на самом деле невозможно обновить файлы диаграмм, поэтому исправление, не предполагающее каких-либо изменений в существующих диаграммах, было бы намного проще обработать.

Я единственный, кто воспроизводит проблему, несмотря на исправление? Кажется, что версия Helm возвращает правильные версии, но есть ли что-нибудь еще, что я должен проверить, чтобы убедиться, что я использую последние версии?

Client: &version.Version{SemVer:"v2.14+unreleased", GitCommit:"9fb19967bab21ecb9748440a99487f2fb0560f63", GitTreeState:"clean"}
Server: &version.Version{SemVer:"canary+unreleased", GitCommit:"9fb19967bab21ecb9748440a99487f2fb0560f63", GitTreeState:"clean"}

@ daniv-msft В моей диаграмме в недопустимом шаблоне полностью отсутствовал ключ (имя_службы для набора состояний). Поскольку helm автоматически установил пустую строку (serviceName: "") в развернутом манифесте, я просто добавил serviceName: {{ .Values.serviceName | default "" | quote }} в свой шаблон. Фильтр default в этом случае означает, что мне не нужно указывать значение для serviceName.

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

В конечном итоге я думаю, что в вашем сценарии, когда вы не можете обновить файлы диаграмм, вы застрянете с использованием 2.13.1, пока они не будут изменены для прохождения проверки.

@ fooka03 > Спасибо за ответ! Раньше я не понимал, что исправление будет применяться только к обновленным развернутым диаграммам, а не к новым.

В моем случае, к сожалению, придерживаться версии 2.13.1 тоже не вариант. :(
Диаграммы, которые мы создали и которые работали для v2.13.1, предоставляются нашим пользователям как часть инструмента, и даже несмотря на то, что мы будем выпускать новую версию, исправляющую это, мы не можем заставить наших пользователей использовать последнюю версию нашего инструмента.
Публикация новой версии инструмента / диаграмм может уменьшить влияние, но в любом случае мы будем иметь некоторые из наших пользователей, пытающихся установить предыдущие версии наших диаграмм с Helm v2.14.0, и, таким образом, получить ошибку проверки.

Хотя я понимаю, что мой случай специфичен, разве это изменение не повредит некоторые другие диаграммы, которые были созданы ранее (я думаю о https://github.com/helm/charts/tree/master/ стабильный)?

Если это так, можно ли отложить изменение валидации на Helm v3 и / или применить предложение @StephanX выше и отобразить предупреждение на данный момент?

Есть мысли о стратегии смягчения последствий, @mortent? Возможно, нам следует вытащить это и перенести в Helm 3. Хотя это, безусловно, полезно, похоже, что оно нарушает существующие варианты использования, которые ранее работали. Что ты об этом думаешь?

@bacongobbler Я согласен, мы должны вытащить это. Основываясь на обсуждении здесь, я не уверен, что простого ограничения валидации новыми манифестами (как в # 5643) будет достаточно, чтобы помочь всем пользователям. У меня есть PR, который отключает проверку схемы во всех случаях: # 5760.

Было бы здорово, если бы кто-то, у кого возникли проблемы, мог убедиться, что это действительно решает их проблемы.

Я просто использовал изображение канарейки, но получил ту же ошибку, что и раньше: Error: failed decoding reader into objects: error validating "": error validating data: unknown object type "nil" in Deployment.spec.template.metadata.annotations.buildID .
Поэтому я сделал все, что мог, и удалил свойство annotations.buildID из deployment.yaml . Вероятно, это не способ решения этой проблемы другими, но вы можете, просто удалите его.
Образ тиллера 2.14.0 запускаю без проблем.

@SeriousM похоже, что канареечная сборка основана только на главной ветке, вам нужно будет построить # 5760 самостоятельно, поскольку она еще не объединена.

У меня здесь серьезный сбой, поэтому я, вероятно, не смогу сегодня протестировать его сам.

Спасибо за ваши ответы! Я также хотел бы протестировать исправление ошибки, но у меня все еще возникают проблемы с локальной сборкой Helm.
Я просмотрел запрос на вытягивание, и, хотя я не знаком с кодовой базой, изменение выглядит довольно простым.

Можно ли будет выполнить pull-request, чтобы я мог попробовать это в следующей сборке Canary?
В худшем случае, если что-то действительно пойдет не так, все равно можно будет отменить эту фиксацию до того, как она достигнет реальных пользователей, верно?

Мы использовали прямые ссылки YAML в течение последних 2 лет в нашем values.yaml без каких-либо проблем. Это недействительный YAML, но он сработал и упростил жизнь нашим разработчикам.
YAML слишком прост и ограничен для более сложных конфигураций, но до сих пор использовался декларативный язык Helm.

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

Мы отказываемся от этого изменения и сокращаем 2.14.1.

Звучит хорошо, спасибо @bacongobbler и всем, кто
Я попробую исправить, как только оно будет доступно.

Самое интересное, что я получаю ту же ошибку проверки "" для restartPolicy на AKS (так же, как OP), для GCP, DigitalOcean и локально с Kubernetes Desktop этого не происходит вообще.

Все, у кого есть эта проблема, используют AKS?

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

В своем случае я могу подтвердить (без использования helm или любого другого инструмента, стоящего за kubectl), что проблема по какой-то причине связана с AKS. И хотя я закомментировал поле, в котором он жаловался, ошибка все равно произошла.

Я не уверен, почему это происходит, но это только в кластерах AKS.

Есть идеи, когда будет доступна версия 2.14.1?

@WoLfulus Я вижу это в версии 2.14.0 на GKE:

$ helm upgrade my-release --install --namespace test ./my-chart/ -f ./my-chart/values.yaml
UPGRADE FAILED
Error: failed decoding reader into objects: error validating "": error validating data: ValidationError(Deployment.spec.template): unknown field "annotations" in io.k8s.api.core.v1.PodTemplateSpec
Error: UPGRADE FAILED: failed decoding reader into objects: error validating "": error validating data: ValidationError(Deployment.spec.template): unknown field "annotations" in io.k8s.api.core.v1.PodTemplateSpec

$ helm version
Client: &version.Version{SemVer:"v2.14.0", GitCommit:"05811b84a3f93603dd6c2fcfe57944dfa7ab7fd0", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.14.0", GitCommit:"05811b84a3f93603dd6c2fcfe57944dfa7ab7fd0", GitTreeState:"clean"}

@WoLfulus Я использую кластер ручного прядения, поэтому он определенно не ограничивается AKS. Я не уверен, как вы проводили свои тесты, чтобы понять, почему вы столкнулись с таким непоследовательным поведением.

@andyast из того, что @bacongobbler говорил ранее, это должно произойти не раньше, чем на этой неделе. Они были отложены из-за кубекона, который был на прошлой неделе.
https://github.com/helm/helm/issues/5750#issuecomment -493464958

@ fooka03 и @achton

Это действительно странно.

Я думаю, что это как-то связано с AKS (в моем случае), но моя проблема была немного другой.

Я пытался установить restartPolicy для initContainers развертывания (которого нет в спецификации Container , но некоторые поставщики (DigitalOcean) приняли его, как если бы kubectl был вызван с --validate=false ).

Мне пришлось удалить restartPolicy , чтобы он работал на AKS.

Поэтому я думаю, что в моем случае это не имело ничего общего с Helm, хотя формат ошибки точно такой же, как и в этой проблеме.

когда мы можем ожидать исправления для этого?

Запрос на вытягивание https://github.com/helm/helm/pull/5760, отключающий проверку, был объединен с мастером @bacongobbler (спасибо!).
Я предполагаю, что, как упоминал @ fooka03 , версия 2.14.1 не будет доступна раньше, чем через пару дней, но я хотел поделиться хорошими новостями. :)

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

Для тех, кто хочет попробовать канареечные сборки: https://helm.sh/docs/using_helm/#from -canary-builds

Кто-нибудь смог протестировать канарейку и подтвердить, исправили ли эту проблему исправления, примененные к мастеру? Я бы хотел, чтобы эта ошибка была проверена и исправлена ​​перед тем, как вырезать 2.14.1, чтобы избежать необходимости в 2.14.2. Спасибо!

Сегодня я протестирую исправление в сборке канареек и сообщу вам результат.

Я могу подтвердить, что у нас это сработало

То же самое и здесь: я протестировал исправление из последней сборки canary, и оно нам тоже подходит.

@SeriousM С любой версией клиента

helm init --tiller-namespace <namespace> --upgrade --canary-image

Чтобы получить последний клиент helm (мастер), вы можете использовать это: https://helm.sh/docs/using_helm/#from -canary-builds

Это сработало для меня, большое спасибо

Кто-нибудь знает, как запретить конвейерам gitlab использовать helm: latest? Мы развертываем все через наши ноутбуки, так как gitlab использует версию 2.14. Это отнимает у нас много времени.

@pulpbill Как установить или получить клиент helm в GitLab? С релизов качаешь? или использовать образ докера? И вы хотите установить 2.13.1 правильно?

Я пытался найти образ докера для Helm, но не нашел ни одного официального. Если вы хотите, вы можете создать образ докера, загрузив и поместив в него двоичный файл helm, а затем вы можете использовать этот образ в конфигурации gitlab ci. Вы можете найти URL-адрес для загрузки двоичных файлов (всех версий) на странице выпусков - https://github.com/helm/helm/releases . И вы можете сделать то же самое (загрузить и установить в $PATH ) и внутри своего задания gitlab, если вы не хотите использовать образ докера и средство запуска докера в gitlab.

Попробуем, чтобы тема оставалась предметной. @pulpbill, если вы не против отправить электронное письмо в список рассылки helm-users или напрямую спросить команду gitlab, это было бы здорово; это больше похоже на проблему с gitlab, чем с Helm, и не похоже, что это связано с проблемой, присутствующей здесь.

AutoDevops загружает helm при выполнении задания развертывания, если вы посмотрите здесь: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/gitlab/ci/templates/Jobs/Deploy.gitlab- ci.yml # L472
Я думаю, что если вы установите env var HELM_VERSION в переменных cicd, это может позволить вам переопределить его, но я не уверен.

Спасибо @ karuppiah7890 и @mitchellmaler Спасибо за советы! Я помню, что я поднял и отправил gitlab для autodevops. Придется дождаться релиза 2.4.1, сейчас нет времени строить новый конвейер :(

@bacongobbler Извините за не по теме!

Выпущен Helm v2.14.1: https://github.com/helm/helm/releases/tag/v2.14.1

Привет, команда! Мы столкнулись с этой проблемой и в недавно выпущенной версии 3, но не в бета-версии v3.0.0-beta.4. Пожалуйста, помогите с разрешением.

это все еще происходит на v3.2.4 . v3.2.3 работает нормально.

это все еще происходит на v3.2.4 . v3.2.3 работает нормально.

То же происходит и с 3.2.3 на Mac

версия руля
version.BuildInfo {Версия: "v3.2.3", GitCommit: "8f832046e258e2cb800894579b1b3b50c2d83492", GitTreeState: "clean", GoVersion: "go1.13.12"}

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