要解决的问题：
我们知道，Docker通过将程序、依赖库、数据及配置文件“打包固化”到一个不变的镜像文件中的做法，解决了应用的部署的难题，但这同时带来了棘手的问题，即配置文件中的参数在运行期如何修改的问题。我们不可能在启动Docker容器后再修改容器里的配置文件，然后用新的配置文件重启容器里的用户主进程。
为了解决这个问题，Docker提供了两种方式：
【读书笔记-k8s- 1.4 基本概念和术语-ConfigMap】◎ 在运行时通过容器的环境变量来传递参数；
◎ 通过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中的“配置文件”也会随之自动更新。于是，KubernetesConfigMap就成了分布式系统中最为简单（使用方法简单，但背后实现比较复杂）且对应用无侵入的配置中心。
推荐阅读
- 读书笔记-k8s- 1.4 基本概念和术语-Annotation
- Kubernetes|k8s之Prometheus-node-down解决
- kubesphere|（十四）从零开始搭建k8s集群——使用KubeSphere管理平台搭建一个高可用的基于Raft的kafka集群服务
- k8s|基于streamx闲聊flink在k8s上的部署实战