Helm: --set analysiert nur Zahlenwerte als float64

Funktioniert es anders, wenn Sie --set tag=\"1\" ?

Dank @chancez kennen wir das genaue Problem: Während der von ghodss/yaml Konvertierungen zu und von JSON werden Ganzzahlen in float64s umgewandelt, um den numerischen Typ von Javascript darzustellen. Dies führt dazu, dass alle ganzen Zahlen über einem bestimmten Wert in wissenschaftlicher Notation dargestellt werden.

Ich bin von dem gleichen Problem gebissen worden. Der Weg, um über den Buckel (oder den Käfer) hinwegzukommen, ist folgender:

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

Eine andere Problemumgehung, die wir verwendet haben, besteht darin, solche Dinge zu tun:

--set port=":1234567"

Dann in der Vorlage:

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

Yuck! 😷

Dies ist ein verdammter Schmerz, und die

Ich bin noch nicht ganz bereit, meinen Stolz zu schlucken und @technosophos 'hässlichen Hack zu versuchen ...

Im Moment hacke ich dies, indem ich mein Bereitstellungsskript erweitere, um die Daten als yaml in eine temporäre Datei zu schreiben und diese als -f -Argument zu verwenden.

Ich habe von Zeit zu Zeit das gleiche Problem mit dem Bild-Tag.
Ich werde versuchen, eine dieser Problemumgehungen zu verwenden. Ich hoffe es wird bald behoben :)

In meinem Fall sehen Sie dies unten auf --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"}

Ich habe auch das gleiche Problem auf 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

Durch das Reduzieren von YAML auf JSON werden viele Informationen entfernt, von denen die meisten typenbezogen sind. Dies bedeutet, dass Sie vor der Bereitstellung keine Prüfwerte eingeben können.

Ich denke, dies kann gelöst werden, indem Sie in eine andere Yaml-Bibliothek wechseln. Vielleicht dieses: https://github.com/go-yaml

Als ich heute mit diesem Problem zu kämpfen hatte, fand ich heraus, dass der Filter toString dabei helfen kann:

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

Dann konnte ich den Port in der Kommandozeile übergeben ( --set dockerPort=2376 ) und ihn richtig interpretieren lassen.

Wir haben dies gerade in 2.7.2 gesehen und die meisten Problemumgehungen funktionieren bei uns nicht wirklich, außer dass Sie alle --set -Optionen in eine lokale Datei schreiben und diese über helm -f locals.yml .

Ich habe dies auch in 2.7.2 gesehen (und als Ergebnis # 3246 eingereicht), also +1 zu diesem Thema. Wie in https://github.com/kubernetes/helm/issues/3001 habe ich auch die Git-SHAs für meine Docker-Image-Tags verwendet. Meine derzeitige Problemumgehung, FWIW, besteht darin, Bild-Tags mit -gitsha

+1 auch für mich.

$ 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

Nach der Bereitstellung erhalte ich Folgendes:

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

Ich bekomme auch InvalidImageName wenn ich kubectl get pods .

Das Anhängen von | toString scheint für mich keinen Unterschied zu machen.

kannst du einfach machen:

{{ .Values.tag | int64 }}

@laverite in Diagrammen absolut, aber dies verwendet den Parser --set. Dieses Problem besteht nur für den Parser --set. Werte, die über values.yaml übergeben werden, werden korrekt analysiert. :) :)

Es scheint, dass dies mit # 3155 zusammenhängt

Ja, glauben Sie so @jesselang

Auch https://github.com/kubernetes/helm/issues/3246

Gleiches Problem hier mit Helm 2.8.0.

@bacongobbler oder @technosophos Ich habe eine Lösung für dieses Problem auf # 3599, es gibt bereits eine Genehmigung, brauche nur eine andere. Vielen Dank!

gelöst über # 3599

danke für den ping @ arturo-c :)

Diesen Fehler auch mit Helm 2.9.1 sehen

Ich frage mich, warum helm lint das nicht fängt. Siehe # 4099

Ich bin gespannt, warum dies durch Hinzufügen von --set-string gelöst wurde, anstatt einen für mich offensichtlichen Fehler in --set beheben.

Ist es wahrscheinlich, dass jemand beabsichtigt, Zahlen in seinen Yaml-Dateien zur wissenschaftlichen Notation zu zwingen?

zwei Wörter: Abwärtskompatibilität :)

Wir können ändern, wie der Parser --set ganzzahlige Werte in Helm 3 --set geändert wird, da so viele Benutzer Helm ausführen in Produktion. Wir können auch nicht alle Werte in --set zu Zeichenfolgen zwingen, da dies das vorhandene Verhalten wie das erwartete Verhalten um Null- und Wahrheitswerte in --set-string als funktionsfähig akzeptiert Lösung vorerst.

Abwärtskompatibilität? Von einer Funktion, die einfach nur "WTF" ist und wahrscheinlich nicht viele wollen oder verwenden? In einem Tool, das sich in einer starken Entwicklung befindet und nicht wirklich weit verbreitet ist? Ich schlage vor, das zu überdenken und zu beheben, bevor es wirklich spät ist.

@technosophos danke.
Beispiel:

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

Es ist Arbeit für mich.

@OndraZizka danke für das (sehr leidenschaftliche) Feedback. Wir versuchen definitiv, einige dieser wackeligen Verhaltensprobleme zu lösen, die der Parser --set für Helm 3 hat, wahrscheinlich indem wir ihn durch etwas ersetzen, das dem neuen Parser --set-string ähnelt.

Ich stimme voll und ganz zu, dass das Verhalten von --set in diesem Fall sehr seltsam ist (und sogar völlig falsch), aber wir können nicht erwarten, eine gesamte Parsing-Bibliothek durch eine andere zu ersetzen, und wir können sicher sein, dass es keinen anderen Zwang gibt Fehler im neuen System. Das Austauschen von Zwangsbibliotheken würde als rückwärts inkompatible Änderung angesehen.

Derzeit ist --set-string eine großartige Funktion, und ich empfehle es jedem, der auf diesen Fehler stößt, dringend, --set-string so oft wie möglich zu verwenden, wenn Sie sich nicht auf Typenzwang verlassen. Auf diese Weise müssen Werte als Zeichenfolge und nicht als Float erzwungen werden.

Wenn Ansible ein Diktat für yaml formatiert (das sind meine Werte.yaml), werden leider keine Anführungszeichen hinzugefügt, was für mich ein großes Problem darstellt. Ich kann nicht glauben, dass ich diesen blutigen Hack benutzen muss: replace ":" ""

Wenn Sie eine Problemumgehung benötigen, bei der dem Tag kein : vorangestellt und später entfernt wird, können Sie diese verwenden (tl; dr: Wenn das Tag eine Zahl ist, verwenden Sie printf, um es zu drucken, andernfalls drucken Sie das String, den du hast)

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

Der Fehler tritt auch bei helm ... -f myval.yaml

Zu Ihrer Information, dies wurde in https://github.com/helm/helm/pull/6010 behoben

@bacongobbler passiert

Können Sie eine neue Ausgabe eröffnen? Vielen Dank.

Wiedereröffnung wegen der Notwendigkeit, # 6010 in # 6749 zurückzusetzen.

Gibt es eine ETA, wann das Update verfügbar wäre?

siehe # 6888.

@sagarkal , um sicherzustellen, dass wir auf derselben Seite sind: Der oben genannte Fix zielt nur darauf ab, Helm v3 und nicht v2 zu erreichen (ich erkläre dies als zufälligen Mitwirkenden, die eigentliche Entscheidung liegt immer beim Team). Die Änderung ist relativ massiv und sollte nicht als 100% sicher angesehen werden, um in den 2.x-Zweig integriert zu werden, der jetzt nur noch Patches enthält. Wenn Sie in der Zwischenzeit eine Chance haben, wäre es großartig, wenn Sie den PR-Zweig anhand Ihres Anwendungsfalls testen und uns mitteilen könnten, ob die Dinge wie erwartet funktionieren. Das würde sehr helfen!

Die Verwendung von --set-string image.tag=6599236 hat bei mir mit einer einfachen Vorlage wie dieser funktioniert

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

Dies wird mit einem großen ganzzahligen Wert ausgeführt, der in der Wertedatei des Diagramms angegeben ist. Es wird implizit in einen Float mit wissenschaftlicher Notation umgewandelt. Nur den Wert auf int behoben und scheint viel sauberer zu sein als einige der anderen Problemumgehungen, die ich gesehen habe:

# values.yaml

tomcat:
  maxPostSize: 2097152

# Cast to int when used

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

Dies wurde mit Helm v3.1.1 getestet.

Das ist gut zu wissen! Das ist definitiv eine einfache Problemumgehung im Vergleich zu vielen anderen, die ich gesehen habe. Vielen Dank!

@Rathgore Das Casting in ein Int ist perfekt, wenn ständig mit Ints gearbeitet wird. In meinem Fall muss der Eingabewert jedoch als Zeichenfolge behandelt werden, wird jedoch (manchmal) in Form von Ziffern angezeigt. Zum Beispiel der verkürzte 7-Längen-Github-Commit-Hash, manchmal ist es eine Zeichenfolge und manchmal ist es nur eine Zeichenfolge. In diesem Fall funktioniert die Übergabe des Werts mit der Option --set-string jedes Mal.

@ m0rganic Ich habe dies nicht getestet, aber Sie könnten versuchen, toString anstelle von int oder den Typ explizit mit !!str . Dies ist nicht erforderlich, wenn Sie nur --set-string aber wir benötigen dieses Verhalten auch für im Diagramm definierte Werte.

@ m0rganic Ich habe dies nicht getestet, aber Sie könnten versuchen, toString anstelle von int oder den Typ explizit mit !!str . Dies ist nicht erforderlich, wenn Sie nur --set-string aber wir benötigen dieses Verhalten auch für im Diagramm definierte Werte.

toString funktioniert nicht und in einigen Fällen konnte ich !!str .

Gibt es einen Plan, um dieses Verhalten zu beheben? Diese Ausgabe ist schon eine ganze Weile offen ...

Siehe # 6888. Ansonsten nein. Wir haben viele zu verwendende Muster dokumentiert. Wir haben jedoch keine Lösung gefunden, die mehr Probleme löst als sie verursacht. Fühlen Sie sich frei, sich an einer PR zu versuchen.

Danke für die schnelle Antwort! Ich bin nicht sicher, ob eine der vorgeschlagenen Problemumgehungen meinen Anwendungsfall löst, aber ich werde es erneut versuchen.

Funktioniert es anders, wenn Sie --set tag=\"1\" ?

In meinem Fall habe ich "" in den Werten int, float und bool verwendet und es hat funktioniert, danke

Aufgrund dieses Kommentars scheint dies kein Problem mehr für Helm 3 zu sein, sondern nur für Helm 2. Ich würde gerne hören, wer wie und mit welchen Versionen von Helm noch auf dieses Problem stößt.

Für Helm 2-Benutzer akzeptieren wir derzeit

Für Helm 2 können Sie wie im folgenden Beispiel zwischen ()) beliebig umwandeln

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

Ich gehe davon aus, dass dies für Helm 3 behoben wurde, da es 3 Wochen her ist, seit ich das letzte Mal gepostet habe, dass dies behoben zu sein scheint. Wenn noch andere dieses Problem mit Helm 3 haben, können Sie dies gerne besprechen, und wir können dieses Problem erneut öffnen. Vielen Dank!

Dies ist immer noch ein Problem; Ich bin auf 3.3.0 und erlebe dies immer noch.

Können Sie bitte eine Demonstration vorlegen?

Glücklich, aber ich bin mir nicht ganz sicher, wie ich das machen soll. Ich habe ein Diagramm, das in seinem values.yaml ein Feld hat, das so aussieht:

customEnv:
  SOME_ENV_VAR: 10000000

und dann in templates/deployment.yaml ich folgendes:

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

Wenn ich helm template ausführe, erhalte ich diesen Wert in der gerenderten Ausgabe:

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

und dann schlägt meine bereitgestellte Anwendung fehl, wenn versucht wird, den Wert von SOME_ENV als Zahl zu analysieren.

Okay. Ich habe es geschafft, dasselbe Problem gemäß Ihren Anweisungen mit Helm 3.3.1 zu reproduzieren. Vielen Dank. Wiedereröffnung.

Ich treffe das gleiche Problem aus einem etwas anderen Blickwinkel. Mein appVersion ist 8482e77 , wenn ich auf appVersion verweise, wo immer es als +Inf gerendert wird. Es macht Spaß, BTW zu debuggen.

Bearbeiten:
Das Ändern der AppVersion von appVersion: 8482e77 auf appVersion: "8482e77" mein Problem behoben

Das ist zu erwarten. Ohne Anführungszeichen analysiert YAML diesen Wert als wissenschaftliche Notation (da 8482e77 "8482 * 10 ^ 77" bedeutet). Wenn Sie möchten, dass ein Wert als Zeichenfolge behandelt wird, setzen Sie ihn in Anführungszeichen.

Ich hatte dieses Problem mit dem Contianer-Image-Tag. Das Problem wurde behoben, indem der folgende Helfer erstellt wurde:

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

Und dann beim Bereitstellungsmanifest:

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

Ist dieses Problem behoben? wenn nicht, dann möchte ich das beheben.

Siehe oben . Bitte lesen Sie unbedingt den Thread und testen Sie ihn selbst. :) :)

Dieses Problem wurde als veraltet markiert, da es seit 90 Tagen ohne Aktivität geöffnet ist. Dieser Thread wird in 30 Tagen automatisch geschlossen, wenn keine weiteren Aktivitäten stattfinden.

Beule, immer noch ein Problem

Ich verwende diese Problemumgehung, wenn ich auf dieses Problem bei möglicherweise numerischen Festschreibungs-IDs stoße:

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

dann verwenden mit

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

Es löst Probleme, wenn Ihre ursprüngliche Zeichenfolge niemals Punkt und e+ , obwohl ich nicht weiß, ob es sich um eine sehr lange Zeichenfolge handelt, wird alles weggelassen.

@urakagi leider funktioniert das nicht, wenn dein Wert ist: 1800000

Ist für dieses Problem ein Fix geplant?

Irgendwelche Updates?

@bacongobbler der Repro von @edobry ist eigentlich ein anderes Problem. In diesem Fall ging es ursprünglich um Werte, die mit --set , was nun behoben wurde und die Option --set-string hinzugefügt wurde.

Bei der Reproduktion geht es um eine Zahl innerhalb von Werten. Yaml wird in wissenschaftliche Notation umgewandelt. Der Repro kann durch Angabe der Zahl in values.yaml behoben werden, wenn er als Zeichenfolge behandelt werden soll. Wenn es als Zahl verwendet wird, sollten die Notationen kein Problem sein.

Ich habe mir den Code angesehen und denke, ich könnte das Verhalten ändern, um Zahlen in Standardnotation statt bis zu 20 Dezimalstellen auszugeben. Danach scheint es im zugrunde liegenden Yaml-Parser eine Implementierungsbeschränkung zu geben, die sehr große Zahlen rundet und / oder in wissenschaftliche Notation umwandelt.

Ich habe auch versucht, ein anderes Problem zu finden, das sich mit dem in @edobrys Repro beschriebenen

Wenn jemand z. B. numerische Tags verwendet, für die keine numerischen Werte vorhanden sind (auf denen keine Arithmetik definiert ist), sollte er in values.yaml in Anführungszeichen gesetzt werden, um als Zeichenfolgen behandelt zu werden. Dies sollte das Problem beheben:

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

Daher denke ich, dass dies geschlossen werden kann und ein neues Problem offen sein kann, wenn jemand der Meinung ist, dass das Parsen von nicht zitierten Zahlen anderen Regeln folgen sollte, als dies bereits der Fall ist.