Helm: Обновление Helm не удалось обновить ConfigMap

Созданный на 23 мая 2017  ·  3Комментарии  ·  Источник: helm/helm

У меня по-прежнему возникают проблемы с тем, что ConfigMaps не обновляется на helm upgrade . Это не постоянная проблема, поэтому я не могу дать точного сценария воспроизведения. Я постараюсь дать как можно больше информации. Когда я говорю, что это не постоянная проблема, я имею в виду, что это не всегда происходит, когда я меняю ConfigMaps, но когда это произойдет, я могу запустить обновление любое количество раз, и значение не изменится.

Что я пытаюсь сделать

У меня есть ConfigMap, которая выглядит так. Я пытаюсь изменить значение APP_DOMAIN с 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

Я запускаю helm upgrade чтобы изменить это значение на develop.europa.mydomain.com . Вы можете увидеть вывод отладки Helm. Обновление завершается успешно, но ConfigMap остается прежней.

helm version вывод

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

helm upgrade вывод

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

Самый полезный комментарий

У меня была такая же проблема, из-за которой несколько часов я понял, что рулю не удалось обновить конфигурационную карту.
Я думаю, что это довольно сбивает с толку пользователей, и после того, как конфигурационная карта изменена с помощью kubectl, она не будет обновляться, за исключением 1) либо обновления значений конфигурации Helm, 2) или удаления карты конфигурации и использования helm для повторного развертывания.

Итак, не могли бы вы добавить флаг или распознать флаг --force , чтобы не проверять последний выпуск, но проверять с работающим в кластере?

Все 3 Комментарий

Похоже, что конфигурационная карта была изменена с помощью kubectl. Helm будет различать последний выпуск, а не то, что работает в кластере.

Да, наверное, так. Спасибо за быстрый ответ!

У меня была такая же проблема, из-за которой несколько часов я понял, что рулю не удалось обновить конфигурационную карту.
Я думаю, что это довольно сбивает с толку пользователей, и после того, как конфигурационная карта изменена с помощью kubectl, она не будет обновляться, за исключением 1) либо обновления значений конфигурации Helm, 2) или удаления карты конфигурации и использования helm для повторного развертывания.

Итак, не могли бы вы добавить флаг или распознать флаг --force , чтобы не проверять последний выпуск, но проверять с работающим в кластере?

Была ли эта страница полезной?
0 / 5 - 0 рейтинги