Helm: --set analiza solo valores numéricos como float64

¿Funciona de manera diferente si haces --set tag=\"1\" ?

Gracias a @chancez conocemos el problema exacto: durante las conversiones desde y hacia JSON realizadas por ghodss/yaml , los números enteros se convierten en float64s para representar el tipo numérico de Javascript. Esto hace que todos los enteros por encima de cierto valor se representen en notación científica.

Me ha mordido el mismo problema. La forma de superar la joroba (o el error) es hacer esto:

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

Otra solución alternativa que hemos utilizado es hacer cosas como esta:

--set port=":1234567"

Luego en la plantilla:

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

¡Qué asco! 😷

Esto es una molestia, y la solución alternativa de @ipedrazas no parece funcionar para mí, o cualquier otra combinación de citar / escapar que he probado.

Todavía no estoy dispuesto a tragarme mi orgullo y probar el feo truco de @technosophos ...

Por ahora, estoy tratando de solucionar esto expandiendo mi script de implementación para escribir los datos como yaml en un archivo temporal y usarlo como un argumento -f .

De vez en cuando, me enfrento al mismo problema con la etiqueta de imagen.
Intentaré utilizar una de estas soluciones. Espero que se solucione pronto :)

En mi caso, viendo esto a continuación en --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"}

También estoy experimentando el mismo problema en el timón 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

Reducir YAML a JSON elimina mucha información, la mayoría relacionada con los tipos. Significa que no puede escribir valores de verificación antes de la implementación.

Supongo que esto se puede resolver moviéndolo a una biblioteca yaml diferente. Quizás este: https://github.com/go-yaml

Mientras luchaba con este problema hoy, descubrí que el filtro toString puede ayudar con esto:

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

Luego pude pasar el puerto en la línea de comando ( --set dockerPort=2376 ) y hacer que se interpretara correctamente.

Acabamos de ver esto en 2.7.2 y la mayoría de las soluciones no funcionan realmente para nosotros, excepto escribir todas las opciones --set en un archivo local y pasarlas a través de helm -f locals.yml .

También he visto esto en 2.7.2 (y como resultado archivé # 3246), así que +1 en este tema. Como en https://github.com/kubernetes/helm/issues/3001 , también estaba usando los SHA de git para mis etiquetas de imagen de Docker. Mi solución alternativa por ahora, FWIW, es agregar un sufijo a las etiquetas de imagen con -gitsha

+1 para mí también.

$ 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

Después de la implementación, obtengo esto:

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

También obtengo InvalidImageName al ejecutar kubectl get pods .

Agregar | toString no parece hacer una diferencia para mí.

puedes simplemente hacer:

{{ .Values.tag | int64 }}

@laverite en gráficos absolutamente, pero esto está usando el analizador --set. Este problema solo existe para el analizador --set. los valores pasados ​​a través de values.yaml se analizan correctamente. :)

Parece que esto está relacionado con # 3155

sí, créelo @jesselang

También https://github.com/kubernetes/helm/issues/3246

El mismo problema aquí con el timón 2.8.0.

@bacongobbler o @technosophos Tengo una solución para este problema en el # 3599, ya hay una aprobación, solo necesito otra. ¡Gracias!

resuelto a través de # 3599

gracias por el ping @ arturo-c :)

Ver este error también con Helm 2.9.1

Me pregunto por qué helm lint no capta esto. Ver # 4099

Tengo curiosidad por saber por qué esto se resolvió agregando --set-string , en lugar de corregir lo que me parece un error obvio en --set .

¿Es probable que alguien tenga la intención de que los números se vean obligados a utilizar la notación científica en sus archivos yaml?

dos palabras: compatibilidad con versiones anteriores :)

Podemos cambiar la forma en que el analizador --set coacciona valores enteros en Helm 3, pero en términos generales, hemos optado por evitar cambiar el comportamiento esperado de la funcionalidad principal como --set ya que hay tantos usuarios ejecutando Helm en producción. Tampoco podemos forzar todos los valores en --set a cadenas, ya que eso romperá el comportamiento existente, como el comportamiento esperado en torno a valores nulos y verdaderos en archivos de valores, por lo que --set-string se aceptó como viable solución por el momento.

¿Compatibilidad al revés? ¿De una característica que es simplemente 'WTF' y probablemente no muchos la quieran o la usen? ¿En una herramienta que se encuentra en un intenso desarrollo y que en realidad no se ha adoptado de forma generalizada? Sugiero repensar eso y arreglarlo antes de que sea realmente tarde.

@technosophos gracias.
Ejemplo:

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

es trabajo para mi.

@OndraZizka, gracias por los comentarios (muy apasionados). Definitivamente estamos buscando abordar algunos de estos problemas de comportamiento extraños que el analizador --set tiene para Helm 3, probablemente reemplazándolo con algo similar al nuevo analizador --set-string .

Estoy totalmente de acuerdo en que el comportamiento de --set es muy extraño en este caso (e incluso completamente incorrecto), pero no podemos esperar reemplazar una biblioteca de análisis completa por otra y estar seguros de que no habrá otra coerción errores en el nuevo sistema. El intercambio de bibliotecas de coacción se consideraría un cambio incompatible con versiones anteriores.

Por el momento, --set-string es una gran característica y se la recomiendo a cualquier otra persona que tenga este error que use --set-string tanto como sea posible cuando no confíe en la coerción de tipos. De esa forma, los valores se ven obligados a ser coaccionados como una cadena y no como un flotador.

Desafortunadamente, cuando Ansible formatea un dict en yaml (que es my values.yaml), no agrega comillas, lo cual es un gran problema para mí. No puedo creer que tenga que usar este maldito truco: replace ":" ""

si necesita una solución que funcione sin prefijar la etiqueta con : y eliminarla más tarde, puede usar esta (tl; dr: cuando la etiqueta es un número, use printf para imprimirlo, de lo contrario imprima el cuerda que tienes)

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

El error también ocurre con helm ... -f myval.yaml

Para su información, esto se solucionó en https://github.com/helm/helm/pull/6010.

@bacongobbler todavía me está sucediendo con la versión de helm v2.14.3

¿Puedes abrir una nueva edición? Gracias.

reapertura debido a la necesidad de revertir # 6010 en # 6749.

¿Alguna ETA cuando la solución estaría disponible?

ver # 6888.

@sagarkal para asegurarnos de que estamos en la misma página: la solución antes mencionada solo tiene como objetivo alcanzar Helm v3, no v2 (lo declaro como un contribuyente aleatorio, la decisión real siempre depende del equipo). El cambio es relativamente masivo y no debería considerarse 100% seguro para fusionarse en la rama 2.x, que ahora es solo parche. Mientras tanto, si tiene la oportunidad, sería genial si pudiera probar la rama de relaciones públicas en su caso de uso y hacernos saber si las cosas funcionan como se espera. ¡Eso ayudaría mucho!

Usar --set-string image.tag=6599236 funcionó para mí con una plantilla simple como esta

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

Ejecutando esto con un valor entero grande especificado en el archivo de valores del gráfico. Se convierte implícitamente en un flotador con notación científica. Simplemente lanzando el valor a int solucionó esto, y parece mucho más limpio que algunas de las otras soluciones que he visto:

# values.yaml

tomcat:
  maxPostSize: 2097152

# Cast to int when used

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

Esto se probó con Helm v3.1.1.

¡Es bueno saber eso! Definitivamente es una solución fácil en comparación con muchas de las que he visto. ¡Gracias!

@Rathgore La --set-string funciona siempre.

@ m0rganic No he probado esto, pero podrías intentar usar toString lugar de int o establecer explícitamente el tipo usando !!str . Esto no es necesario si solo está usando --set-string pero también necesitamos este comportamiento para los valores definidos en el gráfico.

@ m0rganic No he probado esto, pero podrías intentar usar toString lugar de int o establecer explícitamente el tipo usando !!str . Esto no es necesario si solo está usando --set-string pero también necesitamos este comportamiento para los valores definidos en el gráfico.

toString no funciona y, en algunos casos, no pude usar !!str .

¿Existe un plan para corregir este comportamiento? Este problema ha estado abierto durante bastante tiempo ...

Consulte el n. ° 6888. De otra manera no. Hemos documentado muchos patrones para usar. Pero no hemos encontrado una solución que resuelva más problemas de los que causa. Siéntase libre de probar suerte en un PR.

¡Gracias por la rápida respuesta! No estoy seguro de que ninguna de las soluciones propuestas resuelva mi caso de uso, pero lo intentaré de nuevo.

¿Funciona de manera diferente si haces --set tag=\"1\" ?

en mi caso usé "" en los valores int, float y bool y funcionó, gracias

Según este comentario , puede parecer que esto ya no es un problema para Helm 3, solo para Helm 2. Me encantaría saber quién sigue teniendo este problema, cómo y con qué versiones de Helm.

Para los usuarios de Helm 2, solo estamos

para timón 2, puede lanzar lo que desee entre () como el ejemplo a continuación

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

Asumiré que esto se ha solucionado para Helm 3, ya que han pasado 3 semanas desde la última vez que publiqué que parece que se ha solucionado. Si todavía hay otras personas que experimentan este problema con Helm 3, no dude en discutirlo y podemos volver a abrir este problema. ¡Gracias!

Esto sigue siendo un problema; Estoy en 3.3.0 y sigo experimentando esto.

¿Puede proporcionar una demostración?

Feliz de hacerlo, pero no estoy completamente seguro de cómo hacerlo; Tengo un gráfico que tiene en su values.yaml un campo que se ve así:

customEnv:
  SOME_ENV_VAR: 10000000

y luego en templates/deployment.yaml , tengo esto:

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

Cuando ejecuto helm template , obtengo este valor en la salida renderizada:

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

y luego mi aplicación implementada falla cuando intenta analizar el valor de SOME_ENV como un número.

Bueno. Logré reproducir el mismo problema siguiendo sus instrucciones con Helm 3.3.1. Gracias. Reapertura.

Estoy abordando el mismo problema desde un ángulo ligeramente diferente. Mi appVersion es 8482e77 , si hago referencia a appVersion cualquier lugar, se representa como +Inf . Esto es divertido de depurar BTW.

Editar:
cambiar appVersion de appVersion: 8482e77 a appVersion: "8482e77" solucionó mi problema

Eso es de esperar. Sin comillas, YAML analiza ese valor como notación científica (ya que 8482e77 significa “8482 * 10 ^ 77”). Si desea que un valor se trate como una cadena, envuélvalo entre comillas.

Tuve este problema con la etiqueta de imagen contianer. El problema se solucionó creando el asistente a continuación:

+{{/* 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 }}

Y luego, en el manifiesto de implementación:

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

¿Se solucionó este problema? si no, me gustaría arreglar esto.

No. Ver arriba . Asegúrese de leer el hilo y probarlo usted mismo. :)

Este problema se ha marcado como obsoleto porque ha estado abierto durante 90 días sin actividad. Este hilo se cerrará automáticamente en 30 días si no se produce más actividad.

golpe, sigue siendo un problema

Estoy usando esta solución alternativa cuando encuentro este problema en los identificadores de confirmación numéricos quizás:

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

luego usar con

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

Resuelve problemas si su cadena original nunca contiene un punto y e+ , aunque no sé si es una cadena de números muy larga, se omitirá algo.

@urakagi desafortunadamente, eso no funciona si su valor es: 1800000

¿Hay alguna solución prevista para este problema?

¿Alguna actualización?

@bacongobbler el repro de @edobry es en realidad un problema diferente. Este fue originalmente sobre valores que se pasan con --set , que ahora se ha corregido y se agregó la opción --set-string .

La reproducción se trata de un número dentro de values.yaml que se cambia a notación científica. La reproducción se puede arreglar citando el número en values.yaml , si debe tratarse como una cadena. Si se usa como un número, las notaciones no deberían ser un problema.

Miré el código y creo que podría cambiar el comportamiento para generar números en notación estándar en lugar de números de hasta 20 dígitos decimales. Después de eso, parece haber algún límite de implementación en el analizador yaml subyacente que redondea números muy grandes y / o los convierte en notación científica.

También intenté encontrar otro problema que se ocuparía del problema como se describe en la reproducción de

Entonces, cuando alguien usa, por ejemplo, etiquetas numéricas, que no tienen ningún valor numérico (no se define aritmética en ellas), deben estar entrecomilladas en values.yaml para ser tratadas como cadenas y eso debería solucionar el problema:

# 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"

Por lo tanto, creo que esto se puede cerrar y se puede abrir un nuevo problema si alguien piensa que el análisis de números sin comillas debería seguir algunas otras reglas de las que ya hace.