我一直在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"
看起来configmap已使用kubectl进行了修改。 Helm将在最后一个版本上进行差异化,而不是集群中正在运行的内容。
是的,可能就是这种情况。 感谢你及时的答复!
我遇到了同样的问题,导致花了1个小时才弄清头盔无法更新configmap。
我认为这对用户来说非常混乱,一旦使用kubectl修改了configmap,它将不会更新,除了1)更新helm configmap值,2)或删除configmap并使用helm重新部署。
因此,您是否可以添加一个标志或识别--force
标志,以不与上一发行版进行检查,而是与集群中正在运行的一个进行检查?
最有用的评论
我遇到了同样的问题,导致花了1个小时才弄清头盔无法更新configmap。
我认为这对用户来说非常混乱,一旦使用kubectl修改了configmap,它将不会更新,除了1)更新helm configmap值,2)或删除configmap并使用helm重新部署。
因此,您是否可以添加一个标志或识别
--force
标志,以不与上一发行版进行检查,而是与集群中正在运行的一个进行检查?