Sigo teniendo problemas con ConfigMaps que no se actualizan en helm upgrade
. No es un problema permanente, así que no puedo dar un escenario exacto sobre cómo reproducirlo. Intentaré dar la mayor cantidad de información posible. Cuando digo que no es un problema permanente, me refiero a que no siempre sucede cuando cambio ConfigMaps, pero cuando sucede, puedo ejecutar la actualización tantas veces como desee y el valor no cambiará.
Tengo un ConfigMap que se ve así. Estoy intentando cambiar el valor de APP_DOMAIN
de test.mydomain.com
a 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
Ejecuto helm upgrade
para cambiar este valor a develop.europa.mydomain.com
. Puede ver la salida de depuración de Helm. La actualización se completa correctamente, pero ConfigMap permanece igual.
helm version
salidaClient: &version.Version{SemVer:"v2.4.1", GitCommit:"46d9ea82e2c925186e1fc620a8320ce1314cbb02", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.4.1", GitCommit:"46d9ea82e2c925186e1fc620a8320ce1314cbb02", GitTreeState:"clean"}
helm upgrade
salidaREVISION: 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"
Parece que el mapa de configuración se modificó con kubectl. Helm se diferenciará de la última versión en lugar de lo que se está ejecutando en el clúster.
Sí, ese es probablemente el caso. ¡Gracias por la rápida respuesta!
Tuve el mismo problema que causó que durante 1 hora descubrí que el timón no pudo actualizar el mapa de configuración.
Creo que esto es bastante confuso para los usuarios, y una vez que el mapa de configuración se modificó con kubectl, no se actualizará excepto 1) actualizar los valores del mapa de configuración de helm, 2) o eliminar el mapa de configuración y usar helm para volver a implementarlo.
Entonces, ¿podría agregar una bandera, o reconocer la bandera --force
, para no verificar con la última versión, pero verifique con la que se está ejecutando en el clúster?
Comentario más útil
Tuve el mismo problema que causó que durante 1 hora descubrí que el timón no pudo actualizar el mapa de configuración.
Creo que esto es bastante confuso para los usuarios, y una vez que el mapa de configuración se modificó con kubectl, no se actualizará excepto 1) actualizar los valores del mapa de configuración de helm, 2) o eliminar el mapa de configuración y usar helm para volver a implementarlo.
Entonces, ¿podría agregar una bandera, o reconocer la bandera
--force
, para no verificar con la última versión, pero verifique con la que se está ejecutando en el clúster?