J'ai des problèmes avec ConfigMaps qui ne sont pas mis à jour sur helm upgrade
. Ce n'est pas un problème permanent, donc je ne peux pas donner un scénario exact comment se reproduire. Je vais essayer de donner le plus d'informations possible. Quand je dis que ce n'est pas un problème permanent, je veux dire que cela ne se produit pas toujours lorsque je change ConfigMaps, mais quand cela se produit, je peux exécuter la mise à niveau un nombre illimité de fois et la valeur ne changera pas.
J'ai un ConfigMap qui ressemble à ceci. J'essaye de changer la valeur de APP_DOMAIN
de test.mydomain.com
à develop.europa.mydomain.com
.
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
Je lance un helm upgrade
pour changer cette valeur en develop.europa.mydomain.com
. Vous pouvez voir la sortie de débogage de Helm. La mise à niveau se termine avec succès mais le ConfigMap reste le même.
helm version
sortieClient: &version.Version{SemVer:"v2.4.1", GitCommit:"46d9ea82e2c925186e1fc620a8320ce1314cbb02", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.4.1", GitCommit:"46d9ea82e2c925186e1fc620a8320ce1314cbb02", GitTreeState:"clean"}
helm upgrade
sortieREVISION: 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"
Il semble que le configmap a été modifié avec kubectl. Helm diffère sur la dernière version plutôt que sur ce qui est en cours d'exécution dans le cluster.
Oui, c'est probablement le cas. Merci pour la réponse rapide!
J'ai eu le même problème qui a causé quelques 1 heure pour comprendre que la barre n'a pas pu mettre à jour la configuration.
Je pense que c'est assez déroutant pour les utilisateurs, et une fois la configmap modifiée avec kubectl, elle ne sera pas mise à jour sauf 1) soit mettre à jour les valeurs de configmap de helm, 2) soit supprimer la configmap et utiliser helm pour redéployer.
Pourriez-vous donc ajouter un indicateur, ou reconnaître l'indicateur --force
, pour ne pas vérifier avec la dernière version, mais pour vérifier avec celui en cours d'exécution dans le cluster?
Commentaire le plus utile
J'ai eu le même problème qui a causé quelques 1 heure pour comprendre que la barre n'a pas pu mettre à jour la configuration.
Je pense que c'est assez déroutant pour les utilisateurs, et une fois la configmap modifiée avec kubectl, elle ne sera pas mise à jour sauf 1) soit mettre à jour les valeurs de configmap de helm, 2) soit supprimer la configmap et utiliser helm pour redéployer.
Pourriez-vous donc ajouter un indicateur, ou reconnaître l'indicateur
--force
, pour ne pas vérifier avec la dernière version, mais pour vérifier avec celui en cours d'exécution dans le cluster?