为了能够准确和深刻理解Kubernetes ConfigMap的功能和价值，我们需要从Docker说起。
我们知道，Docker通过将程序、依赖库、数据及配置文件“打包固化”到一个不变的镜像文件中的做法，解决了应用部署的难题，但这同时带来棘手的问题，即配置文件中的参数在运行期间如何修改的问题。
我们不可能在启动Docker容器后再修改容器里的配置文件，然后用新的配置文件重启容器里的用户主进程。为了解决这个问题，Docker提供了两种方式：
- 在运行时通过容器的环境变量来传递参数；
- 通过Docker Volume将容器外的配置文件映射到容器内。
这两种方式都有各自的优缺点，在大多数情况下，后一种方式更适合我们的系统，因为大多数应用通常从一个或多个配置文件中读取参数。但是这种方式也有明显的缺陷：我们必须在目标主机上创建好对应的配置文件，然后才能映射到容器里。
这些缺陷在分布式情况下变得更为严重，因为无论采用哪种方式，修改多台服务器上的某个指定文件，并确保这些文件保持一致，都是一个很难完成的目标。
在大多数情况下，我们都希望能看到集中管理系统的配置参数，而不是管理一堆配置文件。针对这些问题，k8s给出了一个很巧妙的设计实现：
首先，把所有的配置项都当作key-value字符串，当然value可以来自某个文本文件，比如配置项password=123456、user=root、host=192.168.1.2用于表连接FTP服务器的配置参数。这些配置项可以作为Map（k-v）表中的一个项，整个Map的数据可以被持久化存储在k8s的Etcd数据库中，然后提供API以方便k8s相关组件或客户应用CRUD操作这些数据，上述专门用来保存配置参数的Map就是Kubernetes ConfigMap资源对象。
接下来，k8s提供了一种内建机制，将存储在etcd中的ConfigMap通过Volume映射方式变成目标Pod内的配置文件，不管目标Pod被调度到哪台服务器上，都会自动映射。如果ConfigMap的key-value数据被修改，则映射到目标Pod中的“配置文件”也会随之自动更新。于是，Kubernetes ConfigMap就成了分布式系统中最为简单且对应用无侵入的配置中心。
ConfigMap与配置文件相比，我们可以使用ConfigMap将配置从镜像中解耦出来，保证镜像的可移植性。此外ConfigMap存储在etcd中，被k8s纳入管理，我们只需要通过调用api-server的接口来完成对配置的修改。
ConfigMap与Secret相比，ConfigMap不存储敏感数据，只存储简单的文本数据（明文）。Secret则存储token、私钥（密文）等敏感信息。
ConfigMap的使用方式
-------未完待续
