Helm: --set анализирует только числовые значения как float64

Будет ли работать иначе, если вы сделаете --set tag=\"1\" ?

Благодаря @chancez мы знаем точную проблему: во время преобразований в JSON и из него, выполняемых ghodss/yaml , целые числа преобразуются в float64 для представления числового типа Javascript. Это приводит к тому, что все целые числа выше определенного значения будут представлены в экспоненциальной нотации.

Меня укусила та же проблема. Чтобы преодолеть горб (или ошибку), нужно сделать следующее:

--set bignumber=\\"a185576882739235744\\"

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

--set port=":1234567"

Затем в шаблоне:

{{ .Values.port | replace ":" "" }}

Фу! 😷

Это чертовски больно, и обходной путь

Я еще не совсем готов проглотить свою гордость и попробовать уродливый хак @technosophos ...

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

Время от времени я сталкиваюсь с одной и той же проблемой для тега изображения.
Я попробую использовать один из этих обходных путей. Надеюсь скоро исправят :)

В моем случае, увидев это ниже на --set image.tag=5997578 :

$ kubetctl describe po msj-treasure-map-msj-treasure-map-192172122-dnb80
...
Events:
  Type     Reason         Age               From                                    Message
  ----     ------         ----              ----                                    -------
  Normal   Scheduled      1m                default-scheduler                       Successfully assigned msj-treasure-map-msj-treasure-map-192172122-dnb80 to ip-10-253-13-113.ec2.internal
  Warning  InspectFailed  15s (x9 over 1m)  kubelet, ip-10-253-13-113.ec2.internal  Failed to apply default image tag "596297932419.dkr.ecr.us-east-1.amazonaws.com/msj-trmap-uwsgi:5.997578e+06": couldn't parse image reference "596297932419.dkr.ecr.us-east-1.amazonaws.com/msj-trmap-uwsgi:5.997578e+06": invalid reference format
  Warning  InspectFailed  15s (x9 over 1m)  kubelet, ip-10-253-13-113.ec2.internal  Failed to apply default image tag "596297932419.dkr.ecr.us-east-1.amazonaws.com/msj-trmap-nginx:5.997578e+06": couldn't parse image reference "596297932419.dkr.ecr.us-east-1.amazonaws.com/msj-trmap-nginx:5.997578e+06": invalid reference format
  Warning  FailedSync     15s (x9 over 1m)  kubelet, ip-10-253-13-113.ec2.internal  Error syncing pod, skipping: [failed to "StartContainer" for "msj-treasure-map-uwsgi" with InvalidImageName: "Failed to apply default image tag \"596297932419.dkr.ecr.us-east-1.amazonaws.com/msj-trmap-uwsgi:5.997578e+06\": couldn't parse image reference \"596297932419.dkr.ecr.us-east-1.amazonaws.com/msj-trmap-uwsgi:5.997578e+06\": invalid reference format"
, failed to "StartContainer" for "msj-treasure-map-nginx" with InvalidImageName: "Failed to apply default image tag \"596297932419.dkr.ecr.us-east-1.amazonaws.com/msj-trmap-nginx:5.997578e+06\": couldn't parse image reference \"596297932419.dkr.ecr.us-east-1.amazonaws.com/msj-trmap-nginx:5.997578e+06\": invalid reference format"

$ helm version                                                                                                                                                                             
Client: &version.Version{SemVer:"v2.5.1", GitCommit:"7cf31e8d9a026287041bae077b09165be247ae66", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.5.1", GitCommit:"7cf31e8d9a026287041bae077b09165be247ae66", GitTreeState:"clean"}

У меня такая же проблема с Helm 2.6.2.

Client: &version.Version{SemVer:"v2.6.2", GitCommit:"be3ae4ea91b2960be98c07e8f73754e67e87963c", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.6.2", GitCommit:"be3ae4ea91b2960be98c07e8f73754e67e87963c", GitTreeState:"clean"}

• 1

Удаление YAML до JSON удаляет много информации, в основном связанной с типом. Означает, что вы не можете вводить проверочные значения перед развертыванием.

Я думаю, это можно решить, перейдя в другую библиотеку yaml. Может быть, этот: https://github.com/go-yaml

Сегодня, борясь с этой проблемой, я обнаружил, что в этом может помочь фильтр toString :

dockerPort: {{ .Values.dockerPort | toString }}

Затем я смог передать порт в командной строке ( --set dockerPort=2376 ) и правильно его интерпретировать.

Мы только что видели это в 2.7.2, и большинство обходных путей для нас не работают, кроме записи всех параметров --set в локальный файл и передачи их через helm -f locals.yml .

Я также видел это в 2.7.2 (и в результате подал № 3246), так что +1 по этому вопросу. Как и в https://github.com/kubernetes/helm/issues/3001 , я также использовал Git SHA для своих тегов изображений докеров. На данный момент мой обходной путь, FWIW, заключается в добавлении к тегам изображений суффиксов -gitsha

+1 и для меня.

$ helm version                                                                                                                                    ⏎
Client: &version.Version{SemVer:"v2.7.2", GitCommit:"8478fb4fc723885b155c924d1c8c410b7a9444e6", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.7.2", GitCommit:"8478fb4fc723885b155c924d1c8c410b7a9444e6", GitTreeState:"clean"}

$ git rev-parse --short HEAD
6180689

$ helm upgrade foobar \
    -i charts/foobar \
    --set image.tag=$(git rev-parse --short HEAD) \
    --reuse-values

После развертывания я получаю следующее:

Failed to apply default image tag "gcr.io/foobar/foobar:6.180689e+06": couldn't parse image reference "gcr.io/foobar/foobar:6.180689e+06": invalid reference format
Error syncing pod

Я также получаю InvalidImageName при запуске kubectl get pods .

Добавление | toString , похоже, не имеет для меня значения.

ты можешь просто сделать:

{{ .Values.tag | int64 }}

@laverite в диаграммах абсолютно, но для этого используется парсер --set. Эта проблема существует только для парсера --set. значения, переданные через values.yaml, анализируются правильно. :)

Похоже, это связано с # 3155

да, думаю, да @jesselang

Также https://github.com/kubernetes/helm/issues/3246

Та же проблема здесь с helm 2.8.0.

@bacongobbler или @technosophos У меня есть исправление этой проблемы на # 3599, уже есть одно одобрение, просто нужно другое. Спасибо!

решено через # 3599

спасибо за пинг @ arturo-c :)

Также вижу эту ошибку в Helm 2.9.1

Интересно, почему helm lint этого не улавливает? См. №4099

Мне любопытно, почему это было решено добавлением --set-string вместо исправления того, что мне кажется очевидной ошибкой в --set .

Возможно ли, что кто-то намеревается привести числа в научную нотацию в своих файлах yaml?

два слова: обратная совместимость :)

Мы можем изменить то, как парсер --set приводит к целочисленным значениям в Helm 3, но в целом мы решили предотвратить изменение ожидаемого поведения основных функций, таких как --set поскольку Helm работает очень много в производстве. Мы также не можем привести все значения в --set к строкам, поскольку это нарушит существующее поведение, такое как ожидаемое поведение вокруг нулевых и истинных значений в файлах значений, поэтому --set-string было принято как работоспособное решение на данный момент.

Обратная совместимость? О функции, которая представляет собой просто "WTF" и, вероятно, не многие хотят или не используют ее? В инструменте, который находится в стадии интенсивной разработки и не получил широкого распространения? Я предлагаю переосмыслить это и исправить, пока еще не поздно.

@technosophos спасибо.
Пример:

kind: Secret
data:
  some_db_port: {{ .Values.dbInfo.db_port | replace ":" "" | b64enc }}

это работа для меня.

@OndraZizka, спасибо за (очень страстный) отзыв. Мы определенно ищем решение некоторых из этих неустойчивых поведенческих проблем, которые есть у парсера --set для Helm 3, вероятно, заменив его чем-то похожим на новый парсер --set-string .

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

На данный момент --set-string - отличная функция, и я настоятельно рекомендую всем, кто сталкивается с этой ошибкой, по возможности использовать --set-string если вы не полагаетесь на приведение типов. Таким образом, значения принудительно приводятся как строка, а не как число с плавающей запятой.

К сожалению, когда Ansible форматирует dict в yaml (это мой values.yaml), он не добавляет никаких кавычек, что для меня является большой проблемой. Не могу поверить, что мне нужно использовать этот чертов взлом: replace ":" ""

если вам нужна работа, которая работает без префикса тега : и удаления его позже, вы можете использовать этот (tl; dr: когда тег является числом, используйте printf для его печати, в противном случае распечатайте строка у тебя есть)

{{- $tag :=  .Values.image.tag }}
{{- $type := printf "%T" $tag }}
image: "{{ .Values.image.repository }}:{{if eq $type "float64"}}{{ printf "%.0f" $tag }}{{ else }}{{ $tag }}{{ end }}"

Ошибка также возникает с helm ... -f myval.yaml

К вашему сведению, это было исправлено в https://github.com/helm/helm/pull/6010.

@bacongobbler все еще происходит у меня с версией Helm v2.14.3

Вы можете открыть новый выпуск? Спасибо.

повторное открытие из-за необходимости вернуть # 6010 в # 6749.

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

см. №6888.

@sagarkal, чтобы убедиться, что мы находимся на одной странице: вышеупомянутое исправление нацелено только на Helm v3, а не на v2 (я заявляю, что это случайный участник, фактическое решение всегда остается за командой). Это относительно масштабное изменение, и его не следует считать на 100% безопасным для слияния с веткой 2.x, которая сейчас доступна только для исправлений. А пока, если у вас есть шанс, было бы здорово, если бы вы могли протестировать ветвь PR в соответствии со своим вариантом использования и сообщить нам, работает ли все, как ожидалось. Это очень поможет!

Использование --set-string image.tag=6599236 сработало для меня с таким простым шаблоном, как этот

  ...
      containers:
        - name: {{ .Chart.Name }}
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
          env:
  ...

Попадание в это с большим целым значением, указанным в файле значений диаграммы. Он неявно преобразуется в число с плавающей запятой с научным обозначением. Просто приведение значения к int исправило это и кажется намного чище, чем некоторые другие обходные пути, которые я видел:

# values.yaml

tomcat:
  maxPostSize: 2097152

# Cast to int when used

{{ .Values.tomcat.maxPostSize | int }}

Это было протестировано с Helm v3.1.1.

Это хорошо знать! Это определенно простой обходной путь по сравнению со многими из тех, что я видел. Спасибо!

@Rathgore Приведение к --set-string работает каждый раз.

@ m0rganic Я не тестировал это, но вы можете попробовать использовать toString вместо int или явно указать тип с помощью !!str . В этом нет необходимости, если вы просто используете --set-string но нам также нужно такое поведение для значений, определенных в диаграмме.

@ m0rganic Я не тестировал это, но вы можете попробовать использовать toString вместо int или явно указать тип с помощью !!str . В этом нет необходимости, если вы просто используете --set-string но нам также нужно такое поведение для значений, определенных в диаграмме.

toString не работает, а в некоторых случаях я не мог использовать !!str .

Есть ли план исправить такое поведение? Этот вопрос был открытым довольно давно ...

См. №6888. В противном случае нет. Мы задокументировали множество шаблонов для использования. Но мы не нашли решения, которое решает больше проблем, чем вызывает. Не стесняйтесь попробовать свои силы в PR.

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

Будет ли работать иначе, если вы сделаете --set tag=\"1\" ?

в моем случае я использовал "" в значениях int, float и bool, и это сработало, спасибо

Основываясь на этом комментарии , может показаться, что это больше не проблема для Helm 3, а только для Helm 2. Я хотел бы услышать, кто все еще сталкивается с этой проблемой, как и с какими версиями Helm.

Для пользователей Helm 2 на данный момент мы принимаем только исправления безопасности , поэтому мы не будем пытаться исправлять эту ошибку для Helm 2. Однако, если это все еще актуально для Helm 3, я был бы признателен за дополнительную информацию от сообщества по именно эта ошибка.

для Helm 2 вы можете использовать все, что хотите, между (), как в примере ниже

{{- range $i := until (int .Values.deployment.numberofracks) }}
  - name: rack{{$i}}
{{- end}}

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

Это все еще проблема; Я нахожусь на 3.3.0 и все еще испытываю это.

Не могли бы вы предоставить демонстрацию?

С удовольствием, но я не совсем уверен, как это сделать; У меня есть диаграмма, в которой есть поле values.yaml которое выглядит следующим образом:

customEnv:
  SOME_ENV_VAR: 10000000

а затем в templates/deployment.yaml меня есть это:

    ...
    containers:
      - name: someContainer
        env:
           {{- range $key, $value := .Values.customEnv }}
            - name: {{ $key | quote }}
              value: {{ $value | quote }}
          {{- end }}
    ...

Когда я запускаю helm template , я получаю это значение в визуализированном выводе:

    ...
    containers:
      - name: someContainer
        env:
            - name: "SOME_ENV"
              value: "1e+07"
   ...

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

Хорошо. Мне удалось воспроизвести ту же проблему, следуя вашим инструкциям с Helm 3.3.1. Спасибо. Повторное открытие.

Я затрагиваю ту же проблему под немного другим углом. Мой appVersion равен 8482e77 , если я буду ссылаться на appVersion любом месте, он будет отображаться как +Inf . Это весело отлаживать BTW.

Редактировать:
изменение appVersion с appVersion: 8482e77 на appVersion: "8482e77" устранило мою проблему

Этого следовало ожидать. Без кавычек YAML анализирует это значение как научное представление (поскольку 8482e77 означает «8482 * 10 ^ 77»). Если вы хотите, чтобы значение трактовалось как строка, заключите его в кавычки.

У меня была проблема с тегом изображения contianer. Проблема была решена при создании помощника ниже:

+{{/* Generate Image Name */}}
+{{- define "helpers.image" }}
+{{- $tag := printf "%f" .Values.app.image.tag -}} 
+{{- if regexMatch "^[0-9]+\\.[0-9]+$" $tag }}
+{{ .Values.image.repository }}:{{ .Values.image.tag | int }}
+{{- else }}
+{{ .Values.image.repository }}:{{ .Values.image.tag }}
+{{- end }}
+{{- end }}

А затем в манифесте развертывания:

   containers:
       - name: {{ template "helpers.fullname" . }}
         image: {{ template "helpers.image" . }}

эта проблема исправлена? если нет, то я хотел бы это исправить.

Нет. См. Выше . Обязательно прочтите эту ветку и проверьте сами. :)

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

шишка, все еще проблема

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

{{- define "numericSafe" -}}
{{- if . | toString | contains "e+" -}}
{{ . | toString | replace "." "" | regexFind "^\\d+" }}
{{- else -}}
{{ . }}
{{- end -}}
{{- end -}}

затем используйте с

{{ include "numericSafe" .Values.git.commitID }}

Он решает проблемы, если исходная строка никогда не содержит точки и e+ , хотя я не знаю, будет ли это очень длинная числовая строка, что-либо будет пропущено.

@urakagi, к сожалению, это не сработает, если ваше значение: 1800000

Планируется ли исправить эту проблему?

Любые обновления?

@bacongobbler репродукция от @edobry - совсем другая проблема. Первоначально этот был о значениях, передаваемых с помощью --set , который теперь был исправлен и был добавлен параметр --set-string .

Репро - это число внутри values.yaml, преобразованное в научную нотацию. Воспроизведение может быть исправлено путем цитирования числа в values.yaml , если его следует рассматривать как строку. Если он используется как число, с обозначениями не должно быть проблем.

Я заглянул в код и думаю, что смогу изменить поведение, чтобы выводить числа в стандартной нотации, а не до 20 десятичных цифр. После этого, похоже, есть некоторый предел реализации в базовом синтаксическом анализаторе yaml, который округляет очень большие числа и / или превращает их в научную нотацию.

Я также попытался найти другую проблему, которая решила бы проблему, как описано в

Поэтому, когда кто-то использует, например, числовые теги, которые не имеют числовых значений (для них не определена арифметика), они должны быть заключены в кавычки в values.yaml чтобы они рассматривались как строки, и это должно решить проблему:

# values.yaml
foo: "10000000"

# template
foo: {{ .Values.foo | quote }}



md5-aba98a385ca8fe457cb1f98967ed3bf1



# Source: foo/templates/x.yaml
foo: "10000000"



md5-265ed31678f08bdbd76c259b974f5398



# Source: foo/templates/x.yaml
foo: "1e+07"



md5-3df6a1bc5fe8f474ded5c2033aaf11a3



# Source: foo/templates/x.yaml
foo: "10000000"

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