Helm: A atualização do Helm falha na atualização do ConfigMap

Criado em 23 mai. 2017  ·  3Comentários  ·  Fonte: helm/helm

Eu continuo tendo problemas com os ConfigMaps que não são atualizados em helm upgrade . Não é um problema permanente, então não posso dar um cenário exato de como reproduzi-lo. Vou tentar dar o máximo de informações possível. Quando estou dizendo que não é um problema permanente, quero dizer que nem sempre acontece quando estou alterando os ConfigMaps, mas quando acontece, posso executar a atualização quantas vezes quiser e o valor não mudará.

O que estou tentando fazer

Eu tenho um ConfigMap que se parece com isso. Estou tentando alterar o valor de APP_DOMAIN de test.mydomain.com para 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

Eu corro um helm upgrade para alterar este valor para develop.europa.mydomain.com . Você pode ver a saída de depuração do Helm. A atualização é concluída com sucesso, mas o ConfigMap permanece o mesmo.

helm version output

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

helm upgrade output

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

Comentários muito úteis

Eu tive o mesmo problema causado por apenas 1 hora para descobrir que o leme falhou ao atualizar o configmap.
Acho que isso é bastante confuso para os usuários e, uma vez que o configmap seja modificado com kubectl, ele não será atualizado, exceto 1) atualizar os valores do configmap do helm, 2) ou excluir o configmap e usar o helm para reimplantar.

Portanto, você poderia adicionar um sinalizador, ou reconhecer o sinalizador --force , para não verificar a última versão, mas verificar com a que está em execução no cluster?

Todos 3 comentários

Parece que o configmap foi modificado com kubectl. O Helm será diferente na última versão, em vez do que está sendo executado no cluster.

Sim, provavelmente é o caso. Obrigado pela resposta rápida!

Eu tive o mesmo problema causado por apenas 1 hora para descobrir que o leme falhou ao atualizar o configmap.
Acho que isso é bastante confuso para os usuários e, uma vez que o configmap seja modificado com kubectl, ele não será atualizado, exceto 1) atualizar os valores do configmap do helm, 2) ou excluir o configmap e usar o helm para reimplantar.

Portanto, você poderia adicionar um sinalizador, ou reconhecer o sinalizador --force , para não verificar a última versão, mas verificar com a que está em execução no cluster?

Esta página foi útil?
0 / 5 - 0 avaliações