摘要：kubernetes更新configmap之后，目前并不会触发pod的滚动更新，可以通过修改 pod annotations的方式强制触发pod控制器的滚动更新。
kubernetes更新configmap之后，目前并不会触发pod的滚动更新，可以通过修改 pod annotations的方式强制触发pod控制器的滚动更新。
给deployment控制器打补丁：
kubectl patch deployment $deployment_name --patch '{"spec":{"template":{"metadata":{"anonations":{"version/config":"666666"}}}}}'
更新configmap之后，使用这个configmap挂载的Env不会同步更新。使用这个configmap挂载的volume中的数据需要一段时间（大概经历10秒）才能同步更新。
kubectl edit deployment $deployment_name -n $namespace_name
在spec.template.metadata下添加： anonations:
"version/config": "3276816"
需要添加的版本内容需要是字符串类型。
查看滚动更新的效果：
kubectl get pod -n $namespace_name
查看配置的解释：
kubectl explain deployment.spec.template.metadata.anonations
可以查看到字段是字符串类型，需要把版本号加上双引号。
当anonations这个值出现变化后，就会触发pod控制器的滚动更新。
创建configmap:
kubectl create cm default-nginx -- from-file=default.conf
查看configmap:
kubectl get cm -n $namespace_name
基于deployment类型的pod控制器的资源清单文件创建pod：
kubectl create -f deployment.yaml
查看pod的创建状态：
默认的镜像下载策略是Always，如果镜像有最新版latest，那么如果不指定镜像版本那么默认会使用最新的镜像版本，也就是最新稳定版。默认的镜像加载策略如果发现镜像版本是latest最新稳定版本的话，它会默认尝试从远程拉取镜像。因为本地镜像版本的最新稳定版，很可能和远程镜像仓库的最新稳定版本不是一致的，所以会从远程拉取最新稳定版latest的镜像版本。如果想改变的话，可以把当前的镜像的下载策略imagePullPolicy从默认的Always改成：如果本地有就不下载的：IfNotPresent。
查看pod的状态变化：
进入pod容器内部：
kubectl exec -it $pod_name -c $container_name -- /bin/bash
可以查看到/etc/nginx/config.d/下面的default.conf
可以看到nginx默认监听的是TCP 80号端口。
修改configmap的内容：
kubectl edit cm default-nginx -n $namespace_name
然后可以把默认的监听端口从listen 80改成listen 8080。
查看pod控制器的名字：
kubectl get deployment -n $namespace_name
修改pod控制器，去添加版本信息，触发重载：
kubectl edit deployment hotupdate-deploy -n $namespace_name
在模板的metadata元数据下面添加：
anonations:
"version/config": "666666"
查看触发自动更新的情况：
kubectl get pod -n $namespace_name
这样做的好处是：不需要修改镜像版本，不需要修改环境变量，就可以触发当前的自动趋向最新版，而且是滚动更新的，在整个过程中不会让用户访问丢失。
检查deployment的滚动更新状态，确定滚动更新是否完成：
kubectl rollout status deployment/$deployment_name -n $namespace_name
如果修改镜像的版本，可以使用kubectl patch打补丁的方式去修改deployment这个pod控制器，因为可以把这个语句放在脚本里面去执行，而不是像edit这样用交互的方式去进pod控制器deployment内部去修改。
用打补丁的方式去触发pod的重载，可以解决容器中的nginx版本更新之后不能重载的问题。
可以通过打补丁这个接口去触发pod的重载：
kubectl patch deployment $deployment_name --patch '{"spec":{"template":{"metadata":{"anonations":{"version/config":"666666"}}}}}'
查看镜像版本：
kubectl get deployment hotupdate-deploy -n $namespace_name -o yaml
查看pod触发滚动更新的情况：
kubectl get pod -n $namespace_name -o wide
或者：
kubectl get pod -n $namespace_name -o wide -w
Configmap的内容变化了，但是nginx不会随着配置文件的改变而发生变化。可以通过打补丁的方式，背后的deployment会自动触发滚动更新，使应用能根据配置文件自动趋向到最新版本。
如果应用是云原生的，那么就可以基于当前的配置自动发生更新，趋向到最新版本，打补丁的操作甚至都不需要去做，只需要去修改configmap配置文件本身。
更新完成configmap后，使用configmap挂载的env不会同步更新。如果pod使用configmap的方式是环境变量的话，那么修改configmap的源对象之后，环境变量并不会发生改变。
当pod使用configmap的方式为卷的方式挂载为文件的时候，它支持热更新。不过一般需要一段时间以后，才能同步原因。因为configmap是一种注入的策略，注入的策略大概10秒内完成。
Configmap还有一种不可变值的选项，并不是所有的时候都希望configmap的配置信息是允许被改变的。因为如果任何人都可以随意改变configmap的话，那么极有可能把服务搞崩溃了。可能某些操作并不是想做的，结果误操作了。可以设置一个值，让configmap变成不可修改的状态。
对于大量使用configmap的集群来说，禁止变更configmap的内容有好处：
①：防止意外或者非预期的更新导致应用的中断。
②：通过将configmap标记为不可变，来关闭kube-apiserver对它的监视，可以显著降低kube-apiserver的负载，提升kubernetes集群的性能。
如果configmap要热更新，需要频繁地监控kube-apiserver 来确认当前的configmap对象有没有发生改变，以此才做到热更新，会消耗大量的资源。设置configmap为不可改变，可以释放部分kube-apiserver的访问压力。
设置不可改变：
immutable: true
可以把这个选项加入到控制器的部分，设置为不可改变。
查看不可改变configmap选项的解释：
kubectl explain cm
如果开启了这个选项，再重新交互式地编辑configmap的话，会不让保存。
kubectl edit cm $configmap_name
会无法保存。
如果immutable设置成true之后，再去改变configmap，那就只能把configmap去删掉了，它是不可逆的过程。
如果修改configmap为不可改变的状态，那么是不可回退的，也就是不可逆的。解决方案就是删除当前的configmap，然后重新创建一个无immutable标记的configmap。
它的优点是两个：
①：防止出现一些错误的修改。
②：减少对kube-apiserver的请求压力。因为不需要去监控kube-apiserver来确认configmap有没有发生变化。
它的主要作用就是将当前pod内部的应用程序或者配置文件给抽象出来，放入configmap，然后再挂载给我们需要的 pod 中去使用，并且支持热更新。
美丽景色
鼓励的话语：是雄鹰就应该翱翔于天空，只有经历风暴，才能无惧所有！
来源：博雅教育