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.
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
AusgabeClient: &version.Version{SemVer:"v2.4.1", GitCommit:"46d9ea82e2c925186e1fc620a8320ce1314cbb02", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.4.1", GitCommit:"46d9ea82e2c925186e1fc620a8320ce1314cbb02", GitTreeState:"clean"}
helm upgrade
AusgabeREVISION: 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"
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?
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?