01 引言
应用部署的一个最佳实践是将应用所需的配置信息与程序分类，就像是微服务Nacos配置中心一样。因此，kubernetes从1.2版本开始就提供了一种统一的应用配置管理方案，也就是本文要讲的ConfigMap。
02 ConfigMap
2.1 ConfigMap概述
ConfigMap以一个或多个key:value的形式保存在Kubenetes系统中供应用使用，它既可以表示一个变量的值（例如： apploglevel=info），也可以用于表示一个完整的配置文件内容（例如：server.xml=<?xml...>...）。
典型用法如下：
- 生成容器的环境变量；
- 设置容器启动命令的启动参数（需要设置为环境变量）；
- 以Volume的形式挂载为容器内部的文件或目录。
2.2 创建ConfigMap资源对象
2.2.1 通过YAML文件方式创建
2.2.1.1 变量
cm-appvars.yaml展示了将几个应用所需的变量定义为ConfigMap的用法：
apiVersion: v1 kind: ConfigMap metadata: name: cm-appvars data: apploglevel: info appdatadir: /var/data
运行kubectl create命令创建ConfigMap：
$ kubectl create -f cm-appvars.yarml
查看创建好的ConfigMap：
2.2.1.2 配置文件
接下来，展示将两个配置文件（server.xml和logging.properties）定义为ConfigMap的用法，设置key为配置文件的别名，value则是配置文件的全部文本内容：
运行kubectl create 命令创建该ConfigMap：
查看创建好的ConfigMap：
查看已创建的ConfigMap的详细内容，可以看到两个配置文件的全文：
…
2.2.2 通过kubectl命令行方式创建
2.2.2.1 from-file / from-literal
不使用YAML文件，直接通过 kubectl create configmap也可以创建ConfigMap，可以使用参数--from-file或--from-literal指定的内容，并且可以在一行命令中指定多个参数。
① 通过--from-file参数从文件中进行创建，可以指定key的名称，也可以在一个命令行中创建包含多个key的ConfigMap，语法如下：
kubectl create configmap NAME --from-file=[key=]source --from-file=[key=]source • 1
② 通过--from-file参数在目录下进行创建，该目录下的每个配置文件名都被设置为key，文件内容被设置为value，语法如下：
kubectl create configmap NAME --from-file=config-files-dir • 1
③使用--from-literal时会从文本中进行创建，直接将指定的key#=value#创建为ConfigMap的内容，语法如下：
kubectl create configmap NAME --from-literal=key1=value1 --from-literal=key2=value2 • 1
2.2.2.2 举例
在当前目录下含有配置文件server.xml，可以创建一个包含该文件内容的ConfigMap：
假设在configfiles目录下包含两个配置文件server.xml和logging.properties，创建一个包含这两个文件内容的ConfigMap：
使用--from-literal来创建：
03 Pod使用ConfigMap
容器应用对ConfigMap的使用有以下两种方法：
- 通过环境变量获取
ConfigMap中的内容； - 通过
Volume挂载的方式将ConfigMap中的内容挂载为容器内部的文件或目录。
3.1 通过环境变量的方式使用ConfigMap
以前面创建的ConfigMap"cm-appvars"为例：
在Pod “cm-test-pod”的定义中，将ConfigMap “cm-appvars”中的内容以环境变量（APPLOGLEVEL和APPDATADIR）方式设置为容器内部的环境变量，容器的启动命令将显示这两个环境变量的值（“env|grep APP”）:
运行kubectl create -f命令创建该Pod，由于是测试Pod，所以该Pod在运行完启动命令后将会退出，并且不会被系统自动重启（restartPolicy=Never）：
运行kubectl get pods --show-all 命令查看已经停止的Pod：
查看该Pod的日志，可以看到启动命令env|grep APP的运行结果如下：
这说明容器内部的环境变量使用ConfigMap cm-appvars中的值进行了正确设置。
Kubenetes从1.6版本开始引入了一个新的字段envFrom，实现了在Pod环境中将ConfigMap（也可用于Secret资源对象）中所定义的key=value自动生成为环境变量：
通过这个定义，在容器内生成如下环境变量：
3.2 通过volumeMount使用ConfigMap
在如下所示的cm-appconfigfiles.yaml例子中包含两个配置文件的定义（server.xml和logging.properties）:
在Pod "cm-test-app"的定义中，将ConfigMap “cm-appconfigfiles”中的内容以文件的形式挂载到容器内部的/configfiles目录下。Pod配置文件cm-test-app.yaml的内容如下：
创建该pod：
登录容器，查看到在/configfiles目录下存在server.xml和logging.properties文件，他们的内容就是ConigMap“cm-appconfigfiles”中两个key定义的内容：
如果在引用ConfigMap是不指定items，则使用volumeMount方式在容器内的目录下为每个item都生成一个文件名为key的文件。
Pod配置文件cm-test-app.yaml的内容如下：
创建该Pod：
登录容器，查看到在/configfiles目录下存在key-loggingproperties和key-serverxml文件，文件的名称来自在ConfigMap cm-appconfigfiles中定义的两个key的名称，文件的内容则为value的内容：
04 使用ConfigMap的限制条件
限制条件如下：
- ConfigMap必须在Pod之前创建，Pod才能引用它；
- 如果Pod使用envFrom基于ConfigMap定义环境变量，则无效的环境变量名称（例如名称以数字开头）将被忽略，并在事件记录中被记录为InvalidVariableNames。
- ConfigMap受命名空间限制，只有处于相同命名空间中的Pod才可以引用它。
- ConfigMap无法用于静态Pod
