kubernetes之configmap
ConfigMap概述
目的
把应用的代码和配置分开，通过配置configmap管理pod，一种统一的集群配置管理方案。ConfigMap API资源提供了将配置数据注入容器的方式，同时保持容器是不知道Kubernetes的。ConfigMap可以被用来保存单个属性，也可以用来保存整个配置文件或者JSON二进制等对象。
基本原理
ConfigMap是存储通用的配置变量的。ConfigMap有点儿像一个统一的配置文件，使用户可以将分布式系统中用于不同模块的环境变量统一到一个对象中管理；而它与配置文件的区别在于它是存在集群的“环境”中的，并且支持K8s集群中所有通用的操作调用方式。而资源的使用者可以通过ConfigMap来存储这个资源的配置，这样需要访问这个资源的应用就可以同通过ConfigMap来引用这个资源。相当通过创建Configmap封装资源配置。configmap以一个或者多个key:value的形式保存在k8s系统中供应用使用，既可以用于表示一个变量的值（eg.apploglevel:info)，也可以用于表示一个完整配置文件的内容（eg： server.xml=<?xml...>...)可以通过yaml配置文件或者直接用kubectl create configmap 命令行的方式来创建 ConfigMap。
创建ConfigMap资源对象
- 通过yaml配置文件方式创建
- 通过kubectl命令行方式创建
- 通过 --from-file 参数从文件中进行创建
- 通过 --from-file 参数从目录中进行创建
- 使用 --from-literal 是会从文本中进行创建
在pod中使用ConfigMap
- 通过环境变量方式使用ConfigMap
- 通过volumeMount使用ConfigMap
使用ConfigMap的限制条件
- ConfigMap必须在Pod之前创建
- ConfigMap受Namespace限制，只有处于相同的Namespace中的Pod才可以引用它.
- ConfigMap中的配额管理还没实现
- kubelet只支持可以被API Server管理的Pod使用ConfigMap。kubelet在本地Node上通过--manifest-url 或 --config自动创建的静态Pod将无法引用configMap.
- 在Pod对ConfigMap进行挂载（volumeMount）操作时，在容器内部只能挂载为“目录”，无法挂载为“文件”。在挂载到容器内部后，在目录下将包含ConfigMap定义的每个item，如果在该目录下原来还有其他文件，则容器内的该目录将被挂载的ConfigMap覆盖。如果应用程序需要保留原来的其他文件，则需要进行额外的处理。可以将ConfigMap挂载到容器内部的临时目录，再通过启动脚本将配置文件复制或者链接到（cp或link命令）应用所用的实际配置目录下。
备注
- 删除configmap后原pod不受影响；然后再删除pod后，重启的pod的events会报找不到cofigmap的volume。
- pod起来后再通过kubectl edit configmap …修改configmap，pod内部的配置也会自动刷新。
- 在容器内部修改挂进去的配置文件后，内容可以持久保存，除非杀掉再重启pod才会刷回原始configmap的内容。
- subPath必须要与configmap中的key同名。
- mountPath如/tmp/prefix：
<1>当/tmp/prefix不存在时(备注：此时/tmp/prefix和/tmp/prefix/无异)，会自动创建prefix文件并把value写进去；
<2>当/tmp/prefix存在且是个文件时，里面内容会被configmap覆盖；
<3>当/tmp/prefix存在且是文件夹时，无论写/tmp/prefix还是/tmp/prefix/都会报错
