kubernetes configMap详解

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说明

参考http://www.javashuo.com/article/p-mzvdomkb-ex.html

kubernetes configMap 热更新测试

https://www.kubernetes.org.cn/3138.html

Kubernetes的ConfigMap详解

参考https://blog.csdn.net/liukuan73/article/details/79492374