Kubernetes的ConfigMap详解

Kubernetes的ConfigMap详解【转】

转自：https://blog.csdn.net/liukuan73/article/details/79492374

ConfigMap是用来存储配置文件的kubernetes资源对象，所有的配置内容都存储在etcd中。

1.创建ConfigMap
创建ConfigMap的方式有4种：

通过直接在命令行中指定configmap参数创建，即--from-literal
通过指定文件创建，即将一个配置文件创建为一个ConfigMap--from-file=<文件>
通过指定目录创建，即将一个目录下的所有配置文件创建为一个ConfigMap，--from-file=<目录>
事先写好标准的configmap的yaml文件，然后kubectl create -f 创建
1.1 通过命令行参数--from-literal创建
示例
创建命令：

kubectl create configmap test-config1 --from-literal=db.host=10.5.10.116 --from-listeral=db.port='3306'

结果如图中data内容所示： 

1.2 指定文件创建
示例
配置文件app.properties的内容： 

 
创建命令（可以有多个--from-file）：

kubectl create configmap test-config2 --from-file=./app.properties
结果如图中data内容所示： 

可以看到指定文件创建时configmap会创建一个key/value对，key是文件名，value是文件内容。

假如不想configmap中的key为默认的文件名，还可以在创建时指定key名字：

kubectl create configmap game-config-3 --from-file=<my-key-name>=<path-to-file>
1.3 指定目录创建
示例
configs 目录下的config-1和config-2内容如下所示： 

创建命令：

kubectl create configmap test-config3 --from-file=./configs
结果如图中data内容所示： 

可以看到指定目录创建时configmap内容中的各个文件会创建一个key/value对，key是文件名，value是文件内容。

那假如目录中还包含子目录呢？继续做实验： 
在上一步的configs目录下创建子目录subconfigs，并在subconfigs下面创建两个配置文件，指定目录configs创建名为test-config4的configmap:

kubectl create configmap test-config4 --from-file=./configs
结果如下图所示： 

结果说明指定目录时只会识别其中的文件，忽略子目录

1.4 通过事先写好configmap的标准yaml文件创建
yaml文件如图所示： 
 
结果如图中data内容所示：

注意其中一个key的value有多行内容时的写法

2.使用ConfigMap
使用ConfigMap有三种方式:

第一种是通过环境变量的方式，直接传递给pod 
使用configmap中指定的key
使用configmap中所有的key
第二种是通过在pod的命令行下运行的方式(启动命令中)
第三种是作为volume的方式挂载到pod内
2.1 通过环境变量使用
示例： 
(1)使用valueFrom、configMapKeyRef、name、key指定要用的key:

apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  containers:
    - name: test-container
      image: k8s.gcr.io/busybox
      command: [ "/bin/sh", "-c", "env" ]
      env:
        - name: SPECIAL_LEVEL_KEY
          valueFrom:
            configMapKeyRef:
              name: special-config
              key: special.how
        - name: LOG_LEVEL
          valueFrom:
            configMapKeyRef:
              name: env-config
              key: log_level
  restartPolicy: Never
(2)还可以通过envFrom、configMapRef、name使得configmap中的所有key/value对都自动变成环境变量：

apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  containers:
    - name: test-container
      image: k8s.gcr.io/busybox
      command: [ "/bin/sh", "-c", "env" ]
      envFrom:
      - configMapRef:
          name: special-config
  restartPolicy: Never
2.2 在启动命令中引用
示例： 
在命令行下引用时，需要先设置为环境变量，之后可以通过$(VAR_NAME)设置容器启动命令的启动参数：

apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  containers:
    - name: test-container
      image: k8s.gcr.io/busybox
      command: [ "/bin/sh", "-c", "echo $(SPECIAL_LEVEL_KEY) $(SPECIAL_TYPE_KEY)" ]
      env:
        - name: SPECIAL_LEVEL_KEY
          valueFrom:
            configMapKeyRef:
              name: special-config
              key: SPECIAL_LEVEL
        - name: SPECIAL_TYPE_KEY
          valueFrom:
            configMapKeyRef:
              name: special-config
              key: SPECIAL_TYPE
  restartPolicy: Never
2.3 作为volume挂载使用
(1)把1.4中test-config4所有key/value挂载进来：

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx-configmap
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: nginx-configmap
    spec:
      containers:
      - name: nginx-configmap
        image: nginx
        ports:
        - containerPort: 80
        volumeMounts:     
        - name: config-volume4
          mountPath: /tmp/config4
      volumes:
      - name: config-volume4
        configMap:
          name: test-config4
进入容器中/tmp/config4查看： 

可以看到，在config4文件夹下以每一个key为文件名value为值创建了多个文件。

(2)假如不想以key名作为配置文件名可以引入items 字段，在其中逐个指定要用相对路径path替换的key：

     volumes:
      - name: config-volume4
        configMap:
          name: test-config4
          items:
          - key: my.cnf
            path: mysql-key
          - key: cache_host
            path: cache-host
进入容器中看： 

备注：

删除configmap后原pod不受影响；然后再删除pod后，重启的pod的events会报找不到cofigmap的volume；
pod起来后再通过kubectl edit configmap …修改configmap，过一会pod内部的配置也会刷新。
在容器内部修改挂进去的配置文件后，过一会内容会再次被刷新为原始configmap内容
(3)还可以为以configmap挂载进的volume添加subPath字段:

        volumeMounts:
        - name: config-volume5
          mountPath: /tmp/my
          subPath: my.cnf
        - name: config-volume5
          mountPath: /tmp/host
          subPath: cache_host
        - name: config-volume5
          mountPath: /tmp/port
          subPath: cache_port
        - name: config-volume5
          mountPath: /tmp/prefix
          subPath: cache_prefix
      volumes:
      - name: config-volume5
        configMap:
          name: test-config4
进入容器中看： 
 
注意在容器中的形式与（2）中的不同，（2）中是个链接，链到..data/<key-name>。 
备注：

删除configmap后原pod不受影响；然后再删除pod后，重启的pod的events会报找不到cofigmap的volume。
pod起来后再通过kubectl edit configmap …修改configmap，pod内部的配置也会自动刷新。
在容器内部修改挂进去的配置文件后，内容可以持久保存，除非杀掉再重启pod才会刷回原始configmap的内容。
subPath必须要与configmap中的key同名。
mountPath如/tmp/prefix： 
<1>当/tmp/prefix不存在时(备注：此时/tmp/prefix和/tmp/prefix/无异)，会自动创建prefix文件并把value写进去； 
<2>当/tmp/prefix存在且是个文件时，里面内容会被configmap覆盖； 
<3>当/tmp/prefix存在且是文件夹时，无论写/tmp/prefix还是/tmp/prefix/都会报错。
3.configmap的热更新研究
更新 ConfigMap 后：

使用该 ConfigMap 挂载的 Env 不会同步更新
使用该 ConfigMap 挂载的 Volume 中的数据需要一段时间（实测大概10秒）才能同步更新
ENV 是在容器启动的时候注入的，启动之后 kubernetes 就不会再改变环境变量的值，且同一个 namespace 中的 pod 的环境变量是不断累加的，参考 Kubernetes中的服务发现与docker容器间的环境变量传递源码探究。为了更新容器中使用 ConfigMap 挂载的配置，可以通过滚动更新 pod 的方式来强制重新挂载 ConfigMap，也可以在更新了 ConfigMap 后，先将副本数设置为 0，然后再扩容。