Helm: Helm-Upgrade schlägt fehl Upgrade ConfigMap

Erstellt am 23. Mai 2017  ·  3Kommentare  ·  Quelle: helm/helm

Ich habe immer wieder Probleme mit ConfigMaps, die nicht auf helm upgrade aktualisiert werden. Es ist kein permanentes Problem, daher kann ich kein genaues Szenario für die Reproduktion angeben. Ich werde versuchen, so viele Informationen wie möglich zu geben. Wenn ich sage, dass es kein dauerhaftes Problem ist, meine ich, dass es nicht immer passiert, wenn ich ConfigMaps ändere, aber wenn es passiert, kann ich das Upgrade beliebig oft ausführen und der Wert ändert sich nicht.

Was ich versuche zu tun

Ich habe eine ConfigMap, die so aussieht. Ich versuche, den Wert von APP_DOMAIN von test.mydomain.com auf develop.europa.mydomain.com zu ändern.

kubectl describe cm jupiter-config
Name:       jupiter-config
Namespace:  develop
Labels:     <none>
Annotations:    kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"v1","data":{"API_URL":"http://node-services","APP_DOMAIN":"test.mydomain.com","LOG_LEVEL":"info",...

Data
====
SHOW_ADS:
----
true
API_URL:
----
http://node-services
APP_DOMAIN:
----
test.mydomain.com
HTTP_DEBUG:
----
true
LOG_LEVEL:
----
info

Ich führe ein helm upgrade , um diesen Wert in develop.europa.mydomain.com zu ändern. Sie können die Debug-Ausgabe von Helm sehen. Das Upgrade wird erfolgreich abgeschlossen, die ConfigMap bleibt jedoch unverändert.

helm version Ausgabe

Client: &version.Version{SemVer:"v2.4.1", GitCommit:"46d9ea82e2c925186e1fc620a8320ce1314cbb02", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.4.1", GitCommit:"46d9ea82e2c925186e1fc620a8320ce1314cbb02", GitTreeState:"clean"}

helm upgrade Ausgabe

REVISION: 61
RELEASED: Tue May 23 15:11:34 2017
CHART: jupiter-0.1.0
USER-SUPPLIED VALUES:
cluster: europa
config:
  API_URL: http://node-services
  APP_DOMAIN: develop.europa.mydomain.com
  HTTP_DEBUG: "true"
  LOG_LEVEL: info
  SHOW_ADS: "true"
resources:
  limits:
    cpu: 500m
    memory: 500Mi
  requests:
    cpu: 100m
    memory: 100Mi
scaling:
  maxReplicas: 4
  minReplicas: 2
version: 1

COMPUTED VALUES:
cluster: europa
config:
  API_URL: http://node-services
  APP_DOMAIN: develop.europa.mydomain.com
  HTTP_DEBUG: "true"
  LOG_LEVEL: info
  SHOW_ADS: "true"
resources:
  limits:
    cpu: 500m
    memory: 500Mi
  requests:
    cpu: 100m
    memory: 100Mi
scaling:
  maxReplicas: 4
  minReplicas: 2
version: 1

HOOKS:
MANIFEST:

---
# Source: jupiter/templates/config.yaml
kind: ConfigMap
apiVersion: v1
metadata:
  name: jupiter-config
data:
  API_URL: http://node-services
  APP_DOMAIN: develop.europa.mydomain.com
  HTTP_DEBUG: "true"
  LOG_LEVEL: info
  SHOW_ADS: "true"
questiosupport

Hilfreichster Kommentar

Ich hatte das gleiche Problem, das einige 1 Stunde verursachte, um herauszufinden, dass das Ruder die Konfigurationskarte nicht aktualisieren konnte.
Ich denke, dies ist für Benutzer ziemlich verwirrend, und sobald die mit kubectl geänderte Konfigurationskarte aktualisiert wurde, wird sie nur aktualisiert, außer 1) entweder die Helmkonfigurationskartenwerte aktualisieren, 2) oder die Konfigurationskarte löschen und die Helmverwaltung erneut bereitstellen.

Könnten Sie also ein Flag hinzufügen oder das Flag --force , um nicht mit der letzten Version zu prüfen, sondern mit dem laufenden im Cluster?

Alle 3 Kommentare

Es sieht so aus, als ob die Konfigurationskarte mit kubectl geändert wurde. Helm unterscheidet sich eher von der letzten Version als von dem, was im Cluster ausgeführt wird.

Ja, das ist wahrscheinlich der Fall. Danke für die schnelle Antwort!

Ich hatte das gleiche Problem, das einige 1 Stunde verursachte, um herauszufinden, dass das Ruder die Konfigurationskarte nicht aktualisieren konnte.
Ich denke, dies ist für Benutzer ziemlich verwirrend, und sobald die mit kubectl geänderte Konfigurationskarte aktualisiert wurde, wird sie nur aktualisiert, außer 1) entweder die Helmkonfigurationskartenwerte aktualisieren, 2) oder die Konfigurationskarte löschen und die Helmverwaltung erneut bereitstellen.

Könnten Sie also ein Flag hinzufügen oder das Flag --force , um nicht mit der letzten Version zu prüfen, sondern mit dem laufenden im Cluster?

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen