kubernetes之十： ConfigMap

ConfigMap是用来存储配置文件的Kubernetes的资源对象，配置对象存储在Etcd中，配置的形式可以是完整的配置文件或者key/value的形式

传统的应用服务，每个服务都有自己的配置文件，各自配置文件存储在服务所在节点，对于单体应用，这种存储没有任何问题，
但是随着用户数量的激增，一个节点不能满足线上用户使用，故服务可能从一个节点扩展到十个节点，这就导致，
如果有一个配置出现变更，就需要对应修改十次配置文件。这种人肉处理，显然不能满足线上部署要求，
故引入了各种类似于 ZooKeeper 中间件实现的配置中心，但配置中心属于 “侵入式” 设计，
需要修改引入第三方类库，它要求每个业务都调用特定的配置接口，破坏了系统本身的完整性，
而Kubernetes 利用了 Volume 功能，完整设计了一套配置中心，其核心对象就是ConfigMap，
使用过程不用修改任何原有设计，即可无缝对 ConfigMap；为什么呢？

kubectl create configmap configmaptest --from-literal=foo=bar --from-literal=one=two



[root@master01 ~]# kubectl get configmap configmaptest -o yaml
apiVersion: v1
data:
  foo: bar
  one: two
kind: ConfigMap
metadata:
  name: configmaptest
  namespace: default

[root@master01 template]# cat db.properties 
driverClassName=com.mysql.jdbc.Driver

kubectl create configmap config-files --from-file=/data/k8s/template/db.properties 



[root@master01 template]# kubectl get configmap config-files -o yaml
apiVersion: v1
data:
  db.properties: |
     driverClassName=com.mysql.jdbc.Driver
kind: ConfigMap
metadata:
  creationTimestamp: "2020-08-12T13:52:35Z"
  managedFields:
  - apiVersion: v1
    fieldsType: FieldsV1
    fieldsV1:
      f:data:
        .: {}
        f:db.properties: {}
    manager: kubectl
    operation: Update
    time: "2020-08-12T13:52:35Z"
  name: config-files
  namespace: default
  resourceVersion: "491983"
  selfLink: /api/v1/namespaces/default/configmaps/config-files
  uid: bfeacb89-fdd7-41d7-8089-ce1a1629b102
You have new mail in /var/spool/mail/root

kubectl create configmap config-dir --from-file=/data/k8s/template/config/


[root@master01 ~]# kubectl get configmap config-dir -o yaml
apiVersion: v1
data:
  db.properties: |
    driverClassName=com.mysql.jdbc.Driver
  svc.properties: |
    #server
    protocol=tcp
  system.properties: |
    time=100
kind: ConfigMap
metadata:
  name: config-dir
  namespace: default