为了能够准确和深刻理解Kubernetes ConfigMap的功能和价值，我们需要从Docker说起。我们知道，Docker通过将程序、依赖库、数据及配置文件“打包固化”到一个不变的镜像文件中的做法，解决了应用的部署的难题，但这同时带来了棘手的问题，即配置文件中的参数在运行期如何修改的问题。我们不可能在启动Docker容器后再修改容器里的配置文件，然后用新的配置文件重启容器里的用户主进程。为了解决这个问题，Docker提供了两种方式：
◎ 在运行时通过容器的环境变量来传递参数；
◎ 通过Docker Volume将容器外的配置文件映射到容器内。
这两种方式都有其优势和缺点，在大多数情况下，后一种方式更合适我们的系统，因为大多数应用通常从一个或多个配置文件中读取参数。但这种方式也有明显的缺陷：我们必须在目标主机上先创建好对应的配置文件，然后才能映射到容器里。
上述缺陷在分布式情况下变得更为严重，因为无论采用哪种方式，写入（修改）多台服务器上的某个指定文件，并确保这些文件保持一致，都是一个很难完成的目标。此外，在大多数情况下，我们都希望能集中管理系统的配置参数，而不是管理一堆配置文件。针对上述问题，Kubernetes给出了一个很巧妙的设计实现，如下所述。
首先，把所有的配置项都当作key-value字符串，当然value可以来自某个文本文件，比如配置项password=123456、user=root、host=192.168.8.4用于表示连接FTP服务器的配置参数。这些配置项可以作为Map表中的一个项，整个Map的数据可以被持久化存储在Kubernetes的Etcd数据库中，然后提供API以方便Kubernetes相关组件或客户应用CRUD操作这些数据，上述专门用来保存配置参数的Map就是Kubernetes ConfigMap资源对象。
接下来，Kubernetes提供了一种内建机制，将存储在etcd中的ConfigMap通过Volume映射的方式变成目标Pod内的配置文件，不管目标Pod被调度到哪台服务器上，都会完成自动映射。进一步地，如果ConfigMap中的key-value数据被修改，则映射到Pod中的“配置文件”也会随之自动更新。于是，Kubernetes ConfigMap就成了分布式系统中最为简单（使用方法简单，但背后实现比较复杂）且对应用无侵入的配置中心。ConfigMap配置集中化的一种简单方案如图所示。
◆Config Map用于保存配置数据的键值对,可以用来保存单个属性也可以用来保存配置文件
◆Config Mapi可以使用命令行基于字面值、文件或目录来创建或通过 configmap对象定义文件创建
◆Config Map可以通过三种方式在Pod中使用:环境变量、容器命令行参数或以文件形式通过数据卷插件挂载到Pod中
configMap的创建：
1.目录创建
--from-file指定在目录下的所有文件都会被用在 Configmap里面创建一个键值对,键的名字就是文件名,值就是文件的内容
2。使用文件创建
只要指定为一个文件就可以从当个文件中创建configMap
--from-file这个参数可以使用多次，你可以使用两次分别制定上个示例中的两个配置文件，这样就跟指定整个目录一样
3.使用字面值创建
利用--from-literal 参数传递配置信息，该参数可以使用多次，格式如下
使用示例：
1.添加环境变量
Pod启动时便会打赢对应的key的value,可以方便验证
2.数据卷使用configmap
在数据卷里面使用这个configMap,有不同的选项，最基本的就是讲文件填入数据卷中。在这个文件中key就是文件名，value就是文件内容
启动pod后我们可以去容器中查看etc/config下多了两个文件special.how和special.type,内容分别为vary和charm
3.滚动更新
