ConfigMapがhelm upgrade
更新されないという問題が引き続き発生します。 これは永続的な問題ではないため、再現方法を正確にシナリオで示すことはできません。 できるだけ多くの情報を提供するように努めます。 永続的な問題ではないと言っている場合、ConfigMapを変更しているときに常に発生するとは限りませんが、発生した場合は何度でもアップグレードを実行でき、値は変更されません。
私はこのような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"
configmapがkubectlで変更されたようです。 Helmは、クラスターで実行されているものではなく、最後のリリースで差分を取ります。
はい、おそらくそうです。 迅速な回答をありがとう!
同じ問題が発生したため、ヘルムがconfigmapの更新に失敗したことが1時間でわかりました。
これはユーザーにとって非常に混乱していると思います。構成マップをkubectlで変更すると、1)helm configmap値を更新するか、2)configmapを削除してhelmを使用して再デプロイする以外は更新されません。
では、フラグを追加するか、 --force
フラグを認識して、前回のリリースでは確認せず、クラスター内で実行中のフラグを確認することはできますか?
最も参考になるコメント
同じ問題が発生したため、ヘルムがconfigmapの更新に失敗したことが1時間でわかりました。
これはユーザーにとって非常に混乱していると思います。構成マップをkubectlで変更すると、1)helm configmap値を更新するか、2)configmapを削除してhelmを使用して再デプロイする以外は更新されません。
では、フラグを追加するか、
--force
フラグを認識して、前回のリリースでは確認せず、クラスター内で実行中のフラグを確認することはできますか?