摘要：在传统环境中自动化运维平台里有一个核心的功能称作配置中心。很多台应用服务器的配置储存在配置中心中。同样一个场景的业务，它们的配置信息应该是一致的。但是由于商业化的目的在变化，导致配置文件也需要跟着商业化的目的发生改变。但是很多台应用服务器修改配置信息的话，可能
在传统环境中自动化运维平台里有一个核心的功能称作配置中心。很多台应用服务器的配置储存在配置中心中。同样一个场景的业务，它们的配置信息应该是一致的。但是由于商业化的目的在变化，导致配置文件也需要跟着商业化的目的发生改变。但是很多台应用服务器修改配置信息的话，可能非常复杂。这样就需要开发一个配置中心，首先会在每个应用服务器的节点上安装一个agent端，agent端的作用就是监听当前目标配置中心的配置选项是否发生更新动作。如果发生了变化，那么agent端要从远程的配置中心去下载最新的配置文件，去替换当前应用服务器的配置文件，并且触发应用程序去实现配置的重载，让我们当前最新的配置生效。如果后期想要发布新的版本的话，那么只需要在配置中心的某一个域名服务下去添加最新的stable最新的稳定版本，然后让agent去指向到最新的版本，再一次去触发后端真实服务器的更新和重载，整个过程对我们来说完全是无痕的。不需要我们去做任何的动作，这就是configmap模型。
configmap的定义：
ConfigMap功能在kubernetes v1.2 版本中引入，许多应用程序从配置文件、命令行参数和环境变量中读取配置信息。configmap API给我们提供了向容器中注入配置信息的机制，configmap 可以被用来保存单个属性，也可以用来保存整个配置文件或者Json二进制等对象。
查看configmap :
kubectl api-resources | grep -i configmaps
configmaps简写是cm
但凡跟配置信息挂钩的，都可以保存在configmap里面，再提供给pod去使用。
对于configmap，还有一个重要性的信息需要注意：configmap是一种替换机制，不是共享的机制。
共享的含义就是：前端user需要访问多台安装了nginx服务的web server，每台web server都可以通过挂载后端文件服务器共享出来的NFS文件目录去实现数据一致的共享。
注入的方式是：ser需要访问多台安装了nginx服务的web server，每台web server通过提供给它的指令去实现数据的一致。注入就是通过指令的方式用新的数据去替换掉原来旧的文件内容，来保证多个pod之间的数据是一致的。
让多个服务内部之间的不同文件达到数据一致的两种思想：
①：共享
②：注入
共享：每次在读取文件的时候，都会发生网络I/O。
ConfigMap机制用的是注入，并不是共享。注入的优势是：一次注入之后，多次读取不会消耗网络I/O。
一般情况下都是把都是把配置文件放入ConfigMap中，然后挂载到服务器中。注入一次就发生一次网络I/O，后续不管怎么在服务器中读取这个文件，都不会再有新的网络I/O出现。可以分批次按照当前集群的压力去一点一点地把所有的pod注入完毕，它的峰值网络I/O会更低、更缓。
对于共享来说，数百个pod同时读取共享存储服务器端的配置文件，那就可能产生峰值的网络I/O出现。
共享和注入，各有利弊。共享适用于好多不同的小文件一起共享出来，用哪个就读取哪个的场景。
注入适合于就一两个配置文件，大概率会使用它的情况。
ConfigMap要保存的是当前的配置参数，也就一两个小文件。这也就是ConfigMap选择注入的方式区实现的原因。
ConfigMap就是存储信息，然后给pod去使用。
ConfigMap的创建：
①：通过文件或者目录创建：
kubectl create configmap $configmap_name --file-from=$filename or $directory_path
举例：
kubectl create configmap game-config --from-file=hong.file
就是把当前的文件，变成当前的配置对象，这个对象就是configmap的game-config对象。
--from-file要求文件中的内容是一行一对，key=value。比如file=hong.file，那么hong.file里面的内容是：
name=zhangsan
pass=123
这样创建的时候，文件名就会变成key，文件内容就会变成value。被保存到当前的配置对象game-config里。
当文件内部不是key=value的格式，那么在使用时依然是文件名变成key，文件内容变成value。
当文件内部一行一对，并且满足key等于value的格式是可以在使用时注入pod内部变成环境变量的。
如果文件内部不是一行一对的key和value格式的话，那么它们没有办法变成环境变量的，只能再把它还原成文件去使用。
②：通过命令行参数直接创建：
kubectl create configmap $configmap_name --from-literal=key1=value1 --from-literal=key2=value2
这条命令把需要的参数key和value直接编写并且写入了命令行的选项中，这种方式更适合key和value比较简短的场景。
适合from-literal这种方案，如果需要创建十几个或者几十行key和value，那么这种方式是不建议的。
如果key和value的行数比较多，建议使用--from-file的方式，再去创建到configmap的对象里。
创建configmap:
kubectl create configmap test-configmap --from-file=hong.file -n $namespace_name
查看configmap:
kubectl get cm -n $namespace_name
查看configmap的内容：
kubectl get cm $configmap_name -n $namespace_name -o yaml
它可以把资源对象输出成资源清单的方式。
可以看到data字段，竖杠代表新的一行。
可以通过命令的方式区创建configmap资源对象。
如果需要保存成资源清单的话，可以加上一个--dry-run -o yaml> filename.yaml
这样就不需要手动编写configmap的资源清单文件了。
查看configmap的方式：
kubectl describe cm $configmap_name -n $namespace_name
查看当前configmap内部数据的方式：
①：kubectl get cm $configmap_name -n $namespace_name -o yaml
②：kubectl describe cm $configmap_name -n $namespace_name
使用命令方式创建configmap的方法：
kubectl create cm literal-configmap --from-literal=name=zhangsan --from-literal=pass=abc -n $namespace_name
--from-literal适合比较简短的key和value的方式。
也可以使用资源清单文件的方式创建configmap。可以按照业务需要，使用--from-file、--from-literal使用参数或者使用清单文件yaml的方式创建configmap这个资源对象。
可以把configmap这些资源对象变成pod内部可以调用的数据。
荷花
鼓励的话语：人生没有白走的路，每走一步都算数。你我都在人生的路上！
来源：小安科技观
