kubernetes configMap详解

zhk2369

Kubernetes的ConfigMap说明
　　这篇博文，我们来说一说，关于在kubernetes的pod中自定义配置的问题。
　　我们知道，在几乎所有的应用开发中，都会涉及到配置文件的变更，比如说在web的程序中，需要连接数据库，缓存甚至是队列等等。而我们的一个应用程序从写第一行代码开始，要经历开发环境、测试环境、预发布环境只到最终的线上环境。而每一个环境都要定义其独立的各种配置。如果我们不能很好的管理这些配置文件，你的运维工作将顿时变的无比的繁琐。为此业内的一些大公司专门开发了自己的一套配置管理中心，如360的Qcon，百度的disconf等。kubernetes也提供了自己的一套方案，即ConfigMap。kubernetes通过ConfigMap来实现对容器中应用的配置管理。
　　创建ConfigMap
　　创建ConfigMap的方式有4种：

• 　　通过直接在命令行中指定configmap参数创建，即--from-literal
  
• 　　通过指定文件创建，即将一个配置文件创建为一个ConfigMap--from-file=
  
• 　　通过指定目录创建，即将一个目录下的所有配置文件创建为一个ConfigMap，--from-file=
  　　通过yaml文件来创建，另一种是通过kubectl直接在命令行下创建。
  
• 　　事先写好标准的configmap的yaml文件，然后kubectl create -f 创建
  

使用ConfigMap
　　使用ConfigMap有三种方式，一种是通过环境变量的方式，直接传递pod，另一种是通过在pod的命令行下运行的方式，第三种是使用volume的方式挂载入到pod内
　　更新 ConfigMap 后：

• 　　使用该 ConfigMap 挂载的 Env 不会同步更新
  
• 　　使用该 ConfigMap 挂载的 Volume 中的数据需要一段时间（实测大概10秒）才能同步更新
  

　　ENV 是在容器启动的时候注入的，启动之后 kubernetes 就不会再改变环境变量的值，且同一个 namespace 中的 pod 的环境变量是不断累加的，参考 Kubernetes中的服务发现与docker容器间的环境变量传递源码探究。为了更新容器中使用 ConfigMap 挂载的配置，可以通过滚动更新 pod 的方式来强制重新挂载 ConfigMap，也可以在更新了 ConfigMap 后，先将副本数设置为 0，然后再扩容。
　　使用ConfigMap的限制条件：
　　configmap 必须在pod之前创建
　　configmap受namespace限制(
　　在pod对configmap进行挂载操作时，容器内部只能挂载为目录，无法挂载为文件。在挂载到容器内部后，目录中将包含configmap定义的每个item，如果该目录下原来还有文件，则容器内的该目录将会被挂载的configmap覆盖。如果应用程序需要保留原来的其他文件，则需要进行额外的处理。可以将configmap挂载到容器内部的临时目录，再通过启动脚本将配置文件复制或者链接到(cp或link命令)应用所用的实际配置目录下。
　　Kubernetes的ConfigMap说明
　　参考https://www.cnblogs.com/breezey/p/6582082.html
　　kubernetes configMap 热更新测试
　　https://www.kubernetes.org.cn/3138.html
　　Kubernetes的ConfigMap详解
　　参考https://blog.csdn.net/liukuan73/article/details/79492374