У меня по-прежнему возникают проблемы с тем, что 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"
Похоже, что конфигурационная карта была изменена с помощью kubectl. Helm будет различать последний выпуск, а не то, что работает в кластере.
Да, наверное, так. Спасибо за быстрый ответ!
У меня была такая же проблема, из-за которой несколько часов я понял, что рулю не удалось обновить конфигурационную карту.
Я думаю, что это довольно сбивает с толку пользователей, и после того, как конфигурационная карта изменена с помощью kubectl, она не будет обновляться, за исключением 1) либо обновления значений конфигурации Helm, 2) или удаления карты конфигурации и использования helm для повторного развертывания.
Итак, не могли бы вы добавить флаг или распознать флаг --force
, чтобы не проверять последний выпуск, но проверять с работающим в кластере?
Самый полезный комментарий
У меня была такая же проблема, из-за которой несколько часов я понял, что рулю не удалось обновить конфигурационную карту.
Я думаю, что это довольно сбивает с толку пользователей, и после того, как конфигурационная карта изменена с помощью kubectl, она не будет обновляться, за исключением 1) либо обновления значений конфигурации Helm, 2) или удаления карты конфигурации и использования helm для повторного развертывания.
Итак, не могли бы вы добавить флаг или распознать флаг
--force
, чтобы не проверять последний выпуск, но проверять с работающим в кластере?