kubernetes ConfigMap

容器化应用配置

容器化应用配置的常见方式

命令行参数

Dockerfile中的ENTRYPOINT和CMD指令用于指定容器启动时要运行的程序及其相关参数。其中，CMD指令以列表形式指定要运行的程序及其相关参数，若同时存在ENTRYPOINT指令，则CMD指令中的列表所有元素均为视作由ENTRYPOINT的命令行参数。另外，在基于某镜像创建容器时，可以通过向ENTRYPOINT中的程序传递额外的自定义参数，甚至还可以修改要运行的应用程序。

在kubernetes系统上创建pod资源时，也能够向容器化应用传递命令行参数，甚至指定运行其它应用程序，相关的字段分别为pods.spec.containers[].command和pods.spec.containers[].args。

将配置文件嵌入镜像文件

所谓将配置文件嵌入镜像文件是指用户在Dockerfile中使用COPY指令把定义好的配置文件复制到镜像文件系统上的目标位置，或者使用RUN指定调用sed或echo一类命令修改配置文件，从而达到为容器化应用提供自定义配置文件的目的。

这种方式的优势在于简单易用，用户无需任何额外的设定就能启动符合需求的容器，但配置文件相关的任何额外的修改需求都要重新构建镜像文件来实现，时间长效率低。

通过环境变量向容器注入配置信息

通过环境变量为镜像提供配置信息是最常见的容器应用配置方式之一。在基于此类镜像启动容器时，通过docker run命令的-e选项向环境变量传值既能实现应用配置，命令的使用格式为docker run -e SETTING1=foo -e SETTING2=bar <imagename>。非云原生的应用程序容器化时通常会借助ENTRYPOINT启动脚本以在启动时获取到这些变量信息，并在启动容器应用之前，通过sed或echo等一类命令将变量值替换到配置文件中。一般来说，ENTRYPOINT启动脚本应该为这些环境变量提供默认值，以便于在用户未向环境变量传值时也能基于此类必须环境变量的镜像启动容器。

使用环境变量这种配置方式的优势在于配置信息的动态化供给，不过有些应用程序的配置也能会复杂到难以通过键值格式的环境变量完成。我们也可以让容器的ENTRYPOINT启动脚本通过网络中的键值存储系统获取配置参数，常用的该类存储系统有Consul或etcd等，它们能够支持多级嵌套的数据结构，因为能够提供较之环境更为复杂的配置信息。不过，这种方式为容器化应用引入了额外的依赖条件。

kubernetes系统支持在为pod资源配置容器时使用spec.containers.env为容器的环境变量传值从而完成应用配置。

通过存储卷向容器注入配置信息

Docker存储卷能够将宿主机之上的任何文件或目录映射进容器文件系统上，因此可以事先将配置文件放置于宿主机之上的模特定路径中，而后在启动容器时进行加载。这种方式灵活易用，但也依赖用户事先将配置数据提供在宿主机上的特定路径。而且在多主机模型中，若容器存在被调度至任一主机运行的可能性时，用户还需要将配置文件共享在任意宿主机以确保容器能正确获取到它们。

kubernetes系统把配置信息保存于标准的API资源ConfigMap和Secret中，pod资源可通过抽象化的同名存储卷插件将相关的资源对象关联为存储卷，而后引用该存储卷上的数据复制给环境变量，或者由容器直接挂载作为配置文件使用。ConfigMap和Secret资源是kubernetes系统上的一等公民，也是配置pod容器应用最常用的方式。

容器环境变量

在运行时配置Docker容器中应用程序的第二种方式是在容器启动时向其传递环境变量。Docker原生的应用程序应该使用很小的配置文件，并且在每一项参数都可由环境变量或命令行选项覆盖，从而能够在运行时完成任意的按需配置。然而，目前只有极少数一部分应用程序是为容器环境原生设计的，毕竟为容器原生重构应用程序工程浩大。好在有利用容器启动脚本为应用程序预设运行环境的方法可用，通行的做法是将变量环境替换值应用程序 配置文件中，而后由此脚本启动相应的应用程序，基于这类镜像运行容器时，即可通过向环境变量传递的方式来配置应用程序。

在kubernetes中使用此类镜像启动时，也可以在pod资源或pod模板资源中定义，通过为容器配置段使用env参数来定义使用的环境变量列表。通过环境变量配置容器化应用时，需要在容器配置中嵌套使用env字段，它的值是一个由环境变量构建的列表。每个环境变量通常由name和value字段构成。

• name <string>：环境变量的名称，必选字段。
• value <string>：环境变量的值，通过$(VAR_NAME)引用。
• valueFrom <Object>：环境变量值的引用源，例如当前pod资源的名称、名称空间、标签等，不能与非空值的value字段同时使用，及环境变量的值要么源于value字段，要么源于valueFrom字段，二者不可同时提供数据。valueFrom字段可引用的值有多种来源，包括当前pod资源的属性值，容器相关的系统资源配置、ConfigMap对象中的key以及Secret对象中的Key，它们分别要使用不用的嵌套字段进行定义。
• fieldRef <Object>：当前pod资源的指定字段，目前支持使用的字段包括metadata.name、metadata.namespace、metadata.labels、metadata.annotations、spec.nodeName、spec.serviceAccountName、status.hostIP和status.podIP等。
• configMapKeyRef <Object>：ConfigMap对象中的特定Key。
• secretKeyRef <Object>：Secret对象中的特定Key。
• resourcefieldRef <Object>：当前容器的特定系统资源的最小值或最大值，目前支持的引用包括limits.cpu、limits.memory、limits.ephemeral-storage、requests.cpu、requests.memory和requests.ephemeral-storage。

apiVersion: v1
kind: Pod
metadata:
  name: env-demo
  labels:
    purpose: demonstrate-environment-variables
spec:
  containers:
  - name: env-demo-container
    image: busybox
    command: ["httpd"]
    args: ["-f"]
    env:
    - name: HELLO_WORLd
      value: just a demo
    - name: MY_NODE_NMAE
      valueFrom:
        fieldRef:
          fieldPath: spec.nodeName
    - name: MY_NODE_IP
      valueFrom:
        fieldRef:
          fieldPath: status.hostIP
    - name: MY_POD_NAMESPEC
      valueFrom:
        fieldRef:
          fieldPath: metadata.namespace
 restartPolicy: OnFailure

该示例它配置容器通过环境变量引用当前pod资源及其所在的节点的相关属性值。

这种配置方式的缺陷无法在容器应用运行过程中更新环境变量从而达到更新应用的目的，这通常意味着用户不得不为production、development和stage等不同的环境分别配置pod资源。

ConfigMap资源

ConfigMap资源用于在运行时将配置文件、命令行参数、环境变量、端口号以及其它配置工作绑定至pod的容器和系统组件。kubernetes借助于ConfigMap对象实现了将配置文件从容器镜像中解耦，从而增强了工作负载的可移植性，是配置更易于更改和管理，并防止将配置数据硬编码到pod配置清单中。但ConfigMap资源用于存储和共享非敏感、未加密的配置信息，若要在集群中使用敏感信息，则必须使用Secret资源。

一个ConfigMap对象就是一系列配置数据的集合，这些数据可注入到pod的容器当中为容器应用所使用，注入的途径有直接挂载存储卷和传递为环境变量两种。ConfigMap支持存储诸如单个属性一类的细粒度的信息，也可用于存储粗粒度的信息，例如将整个配置文件保存在ConfigMap对象之中。

创建ConfigMap对象

ConfigMap是kubernetes标准的API资源类型，它隶属于名称空间级别，支持命令式命令、命令式对象配置及声明式对象配置3种管理接口。命令式命令的创建操作可通过kubectl create configmap进行，它支持基于目录、文件或字面量值获取配置数据完成ConfigMap对象的创建。命令格式如下：

kubectl create configmap <map-name> <data-source>

命令中的<data-source>就是可以通过直接给定的键值、文件或目录来获取的配置数据来源，但无论是哪一种数据供给方式，配置数据都要转换为键值类型，其中的键由用户在命令行给出或是文件类型数据源的文件名，且技能由字母、数字、连接后和点号组成，而值则是字面量值或文件数据源的内容。

字面量值数据源

为kubectl create configmap命令使用--from-literal选项可在命令行直接给出键值对来创建ConfigMap对象，重复使用此选项则可以一次传递多个键值对。命令格式如下：

kubectl create configmap configmap_name --from-literal=key-1=value-1 ...

示例

~# kubectl create configmap demoapp-config --from-literal=demoapp.host='0.0.0.0' --from-literal=demoapp.port='8080' --namespace='default'
configmap/demoapp-config created

查看示例信息

~# kubectl get configmaps demoapp-config -o yaml
apiVersion: v1
data:
  demoapp.host: 0.0.0.0
  demoapp.port: "8080"
kind: ConfigMap
metadata:
  creationTimestamp: "2022-06-08T07:05:14Z"
  name: demoapp-config
  namespace: default
  resourceVersion: "1652038"
  uid: 9b06f84a-9e25-4e5c-9f49-81a05febce21

文件数据源

ConfigMap资源也可以用于为应用程序提供大段配置，这些大段配置通常保存于一到多个文本编码的文件中，可由kubectl createconfigmap命令挺高--from-file选项一次加载一个配置文件的内容为指定键的值，多个文件的加载可以重复使用--from-file选项完成。命令格式如下：

kubectl create configmap <configmap_name> --from-file[=<key-name>]=<path-to-file> --from-file[=<key-name>]=<path-to-file>

示例

~# kubectl create configmap nginx-confs --from-file=./nginx.conf --from-file=status.cfg=./status.conf  --namespace='default'
configmap/nginx-confs created

查看示例信息

查看代码

~# kubectl get configmaps nginx-confs -o yaml
apiVersion: v1
data:
  nginx.conf: "\n#user  nobody;\nuser nginx nginx;\nworker_processes  auto;\n\nworker_rlimit_nofile
    65535;\nworker_priority -5;\n#error_log  logs/error.log;\n#error_log  logs/error.log
    \ notice;\n#error_log  logs/error.log  info;\n\n#pid        logs/nginx.pid;\n\n\nevents
    {\n    use epoll;\n    worker_connections  65535;\n    accept_mutex on;\n}\n\n\n\nhttp
    {\n    include       mime.types;\n    default_type  application/octet-stream;\n
    \   #limit_rate 3M;\t\n\n    log_format  main  '$remote_addr - $remote_user [$time_iso8601]
    \"$request\" '\n                      '$status $body_bytes_sent \"$http_referer\"
    \"$http_x_user_id\" \"$http_Authorization\"  '\n                     '\"$http_user_agent\"
    \"$http_x_forwarded_for\"';\n\n    #log_format  upstream  '$http_x_forwarded_for
    - $remote_user [$time_iso8601] \"$request\" $status $body_bytes_sent \"$http_referer\"
    \"$http_user_agent\"';\n\n    #access_log  logs/access.log  upstream;\n\n\n#  limit_rate
    1024K;\n\n    include /usr/local/nginx/conf/vhosts/*.conf;\n\n    ssl_ciphers
    ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4;\n
    \   ssl_protocols TLSv1 TLSv1.1 TLSv1.2;\n\n\n\n    server_names_hash_bucket_size
    128;\n    client_header_buffer_size 2k;\n    large_client_header_buffers 4 4k;\n
    \   client_max_body_size 8m;\n\n    sendfile        on;\n    tcp_nopush     on;\n\n
    \   #keepalive_timeout  0;\n    keepalive_timeout  35;\n \n    aio on;\n\n    fastcgi_cache_path
    /usr/local/nginx/fcgi levels=1:2:1 keys_zone=fcgi:20m inactive=120s;\n    fastcgi_connect_timeout
    300;\n    fastcgi_send_timeout 300;\n    fastcgi_read_timeout 300;\n    fastcgi_buffer_size
    4k;\n    fastcgi_buffers 8 4k;\n    fastcgi_busy_buffers_size 8k;\n    fastcgi_temp_file_write_size
    8k;\n    fastcgi_cache fcgi;\n    fastcgi_keep_conn on;\n    fastcgi_cache_valid
    200 302 10m;\n    fastcgi_cache_valid 301 1h;\n    fastcgi_cache_valid any 1m;\n
    \   fastcgi_cache_key $request_uri;\n    fastcgi_cache_min_uses 1;\n    fastcgi_cache_use_stale
    error timeout invalid_header http_500;\n\n    proxy_cache_path /usr/local/nginx/proxy
    levels=1:1:1 keys_zone=pxycache:20m max_size=1g;\n    open_file_cache max=20480
    inactive=20s;\n    open_file_cache_min_uses 1;\n    open_file_cache_valid 30s;\n\n
    \   gzip  on;\n    gzip_min_length 64k;\n    gzip_http_version 1.1;\n    gzip_comp_level
    6;\n    gzip_types text/plain application/json application/x-javascript application/css
    application/xml application/xml+rss text/javascript application/x-httpd-php image/jpeg
    image/gif image/png image/x-ms-bmp;\n    gzip_vary on;\n\n\n    server {\n        listen
    \      80;\n        server_name  localhost;\n\n        #charset koi8-r;\n\n        #access_log
    \ logs/host.access.log  main;\n\n        location / {\n            root   html;\n
    \           set_real_ip_from   10.1.10.0/24;\n            real_ip_header     X-Forwarded-For;\n
    \           index  index.html index.htm index.php;\n        }\n\n        #error_page
    \ 404              /404.html;\n\n        # redirect server error pages to the
    static page /50x.html\n        #\n        error_page   500 502 503 504  /50x.html;\n
    \       location = /50x.html {\n            root   html;\n        }\n\n       \n
    \   }\n\n}\n\n\n"
  status.cfg: |
    server {
        listen       80;
        server_name 127.0.0.1;
        location /nginx_status {
              stub_status on;
              access_log off;
        }
    }
kind: ConfigMap
metadata:
  creationTimestamp: "2022-06-08T07:21:41Z"
  name: nginx-confs
  namespace: default
  resourceVersion: "1653587"
  uid: 49c7d792-d514-4d49-aa66-722a5077289e

目录数据源

对于配置文件较多且无需自定义键名称的场景，可以直接在kubectl create configmap命令的--from-file选项上附加一个目录路径就能将该目录下的所有文件创建与同一个configmap资源中，各文件名即为键名。命令格式如下：

kubectl create configmap <configmap_name> --from-file=<path-to-directory>

示例

~# kubectl create configmap nginx-config-files --from-file=./nginx-config.d/
configmap/nginx-config-files created

查看示例信息

查看代码

~# kubectl describe configmaps nginx-config-files
Name:         nginx-config-files
Namespace:    default
Labels:       <none>
Annotations:  <none>
Data
myserver.conf:
server {

listen       80;

server_name  localhost;
    #charset koi8-r;

    #access_log  logs/host.access.log  main;

    location / {
        root   html;
        set_real_ip_from   10.1.10.0/24;
        real_ip_header     X-Forwarded-For;
        index  index.html index.htm index.php;
    }

    #error_page  404              /404.html;

    # redirect server error pages to the static page /50x.html
    #
    error_page   500 502 503 504  /50x.html;
    location = /50x.html {
        root   html;
    }

   
}

status.conf:
server {

listen       80;

server_name 127.0.0.1;

location /nginx_status {

stub_status on;

access_log off;

}

}
Events:  <none>

ConfigMap资源配置清单

基于配置文件创建configmap资源时，它所使用的字段包括通常的apiVersion、Kind和metadata字段，以及用于存储数据的关键字段data。示例如下：

apiVersion: v1
data:
  demoapp.host: 0.0.0.0
  demoapp.port: "8080"
kind: ConfigMap
metadata:
  creationTimestamp: "2022-06-08T07:05:14Z"
  name: demoapp-config
  namespace: default
  resourceVersion: "1652038"
  uid: 9b06f84a-9e25-4e5c-9f49-81a05febce21

若键值来自文件内容，使用配置文件创建configmap资源的便捷性远不如直接通过命令行进行创建，因此我们可先使用命令行加载文件或目录的方式进行创建，在创建完成后使用get -o yaml命令获取到相关信息后进行编辑留存。

通过环境变量引用configmap键值

pod资源配置清单中，除了使用value字段直接给定变量值之外，容器环境变量的赋值还支持通过在valueFrom字段中嵌套configMapKeyRef来引用ConfigMap对象的键值，它的具体使用格式如下：

env：
- name: <string> # 要赋值的环境变量名
  valueFrom:     # 定义变量值引用
    configMapKeyRef:   # 变量值来自ConfigMap对象的某个指定键的值
      key <string>:    # 键名称
      name <string>:   # ConfigMap对象的名称
      optional <boolean>: # 指定的ConfigMap对象或者指定的键值名称是否为可选
      

这种方式赋值的环境变量的使用方式与直接赋值的环境变量并无区别，它们都可用于容器的启动脚本或直接传递给容器应用等。

查看代码

apiVersion: v1
kind: ConfigMap
metadata:
  name: demoapp-config
  namespace: default
data:
  demoapp.port: "8080"
  demoapp.host: 0.0.0.0
---
apiVersion: v1
kind: Pod
metadata:
  name: configmaps-env-demo
  namespace: default
spec:
  containers:
  - image: 。。。
    name: demoapp
    env:
    - name: PORT
      valueFrom:
        configMapKeyRef:
          name: demoapp-config
          key: demoapp.port
          optional: false
    - name: HOST
      valueFrom:
        configMapKeyRef:
          name: demoapp-config
          key: demoapp.host
          optional: true

需要注意的是，被引用的ConfigMap资源必须事先存在，否则将无法在pod对象中启动引用了ConfigMap对象的容器，但未引用或不存在ConfigMap资源的容器将不受影响。另外，ConfigMap是名称空间级别的资源，它必须与引用的它的pod资源在同一名称空间内。

若ConfigMap资源中存在较多的键值数据，而且其大部分甚至是全部键值数据都需要由容器引用时，pod资源支持在容器中使用envFrom字段直接将ConfigMap资源中的所有键值一次性导入。

envFrom：
- prefix: <string>    # 为引用的ConfigMap对象中的所有变量添加一个前缀名
  configMapKeyRef:   # 定义引用的ConfigMap对象
    name <string>:   # ConfigMap对象的名称
    optional <boolean>: # 指定的ConfigMap对象或者指定的键值名称是否为可选

envFrom字段值是对象列表，用于同时从多个ConfigMap对象导入键值数据。为了避免从多个ConfigMap引入键值数据是产生键名冲突，可以为每个引用中将被导入的键使用prefix字段指定一个特定的前缀，例如HTCFG_一类的字符串，于是ConfigMap对象中的PORT键名将成为容器中名为HTCFG_PORT的变量。

如果键名中使用了连字符“-”，转换为变量的过程会自动将其替换为下划线“_”。

apiVersion: v1
kind: ConfigMap
metadata:
  name: demoapp-config-for-envfrom
  namespace: default
data:
  PORT: "8090"
  HOST: 0.0.0.0
---
apiVersion: v1
kind: Pod
metadata:
  name: configmaps-envfrom-demo
  namespace: default
spec:
  containers:
  - image: redis:alpine
    name: demoapp
    envFrom:
    - prefix: wgs_
      configMapRef:
        name: demoapp-config-for-envfrom
        optional: false

 查了变量结果

~# kubectl exec configmaps-envfrom-demo -- printenv
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
HOSTNAME=configmaps-envfrom-demo
wgs_HOST=0.0.0.0
wgs_PORT=8090

ConfigMap存储卷

使用环境变量导入ConfigMap对象中来源于较长的内容文件的键值会导致占据过多的内存空间，而考虑此类数据通常用于为容器应用提供配置文件，将其内容直接以文件格式进行引用是为了更好地选择。pod资源的configMap存储卷插件专用于以存储卷形式引用ConfigMap对象，其键值数据是容器中的ConfigMap存储卷挂载点路径或直接指向的配置文件。

挂载存储卷

基于ConfigMap存储卷插件管理至pod资源上的ConfigMap对象可由内部的容器挂载为一个目录，该ConfigMap对象的每个键名称转为容器挂载点路径下的一个文件名，键值则映射为相应文件的内容。挂载点路径应该以容器加载配置文件的目录为其名称，每个键名也应该有意设计为对应容器应用加载的配置文件名称。

apiVersion: v1
kind: Pod
metadata:
  name: configmaps-volume-demo
  namespace: default
spec:
  containers:
  - image: nginx:alpine
    name: nginx-server
    volumeMounts:
    - name: ngxconfs
      mountPath: /etc/nginx/conf.d/
      readOnly: true
  volumes:
  - name: ngxconfs
    configMap:
      name: nginx-config-files
      optional: false

挂载存储卷中的部分键值

有些场景中，用户很可能期望仅向容器中的挂载点暴露pod资源关联的ConfigMap对象上的部分键值，这个在通过一个ConfigMap对象为单个pod资源中的多个容器分别提供配置是尤其常见。

查看代码

apiVersion: v1
kind: Pod
metadata:
  name: configmaps-volume-demo2
  namespace: default
spec:
  containers:
  - name: proxy
    image: envoyproxy/envoy-alpine:v1.14.1
    command: ['/bin/sh','-c','envoy -c /etc/envoy/..data/envoy.yaml']
    volumeMounts:
    - name: appconfs
      mountPath: /etc/envoy
      readOnly: true
  - name: demo
    image: 。。。
    imagePullPolicy: IfNotPresent
    env:
    - name: PORT
      valueFrom:
        configMapKeyRef:
          name: demoapp-confs
          key: demoapp.port
          optional: false
    - name: HOST
      valueFrom:
        configMapKeyRef:
          name: demoapp-confs
          key: demoapp.host
          optional: true
  volumes:
  - name: appconfs
    configMap:
      name: demoapp-confs
      items:
      - key: envoy.yaml
        path: envoy.yaml
        mode: 0644
      - key: lds.conf
        path: lds.conf
        mode: 0644
      optional: false

ConfigMap卷插件中的items字段的值是一个对象列表，可嵌套使用3个字段来组合指定要引用的特定键。

• key <string>： 要引用的键名称，必选字段。
• path <string>：对于的键在挂载点目录中映射的文件名称，它可不同于键名称，必选字段。
• mode <string>： 文件的权限模式，可用范围为0-0777。

该示例中，把envoy.yaml和lds.yaml两个键名分别映射为/etc/envoy目录下的两个与键名相同的文件，且均使用0644的权限。

独立挂载存储卷中的单个键值

前两中方式中，无论是挂载ConfigMap对象中的所有还是部分文件，挂载点目录下原有的文件都会被隐藏，对于期望将ConfigMap对象提供的配置文件补充在挂载点目录下的需求来说，这种方式难以实现。事实上，此种需求可以通过在容器上的VolumeMount字段中使用subpath字段来解决，该字段用于支持从存储卷挂载单个文件或单个目录而非整个存储卷。

apiVersion: v1
kind: Pod
metadata:
  name: configmap-volume-demo3
  namespace: default
spec:
  containers:
  - image: nginx:alpine
    name: nginx-server
    volumeMounts:
    - name: ngxconfs
      mountPath: /etc/nginx/conf.d/nginx.conf
      subPath: nginx.conf
      readOnly: true
    - name: ngxconfs
      mountPath: /etc/nginx/conf.d/status.cfg
      subPath: status.cfg
      readOnly: true
  volumes:
  - name: ngxconfs
    configMap:
      name: nginx-config-files

容器应用重载新配置

相较于环境变量来说，使用ConfigMap资源为容器应用提供配置的优势之一在于支持容器应用动态更新其配置：用户直接更新ConfigMap对象，而后由相关pod对象的容器应用重载其配置文件即可。

挂载有ConfigMap存储卷的容器，挂载点目录中的文件都是符合链接，它们指向了挂载点目录中名为..data隐藏属性的子目录，而..data自身也是一个符合链接，它指向了名字形如..2022_05_15_03_34_10.435155001这样的以挂载操作时的时间戳命名的临时隐藏目录，该目录才是存储卷的真正挂载点。

这中符合链接设定的好处在于，当引用的ConfigMap对象中的数据发送改变时，它将被重新挂载至一个以当前时间戳命名的新的临时目录下，而后将..data指向这个新的挂载点便达到了同时更新存储卷上所有文件数据的目的。

ConfigMap对象中的数据更新同步至应用容器后并不能直接触发生效新配置，还需要在容器上执行应用重载操作。

对于不支持配置文件重载操作的容器应用来说，仅那些在ConfigMap对象更新后创建的pod资源中的容器会应用到新配置，因此手动重启旧有的容器之前会存在配置不一致的问题。即使对于支持重载操作的应用来说，由于新的配置信息并非同步推送进所有容器中，而且在各容器中进行的手动重载操作也未必能同时进行，因此更新时，短时间内仍会存在配置不一致的现象。还有，以单个文件形式独立挂载ConfigMap存储卷中的容器并未采用两级链接的方式进行文件映射，因此存储卷无法确保所有挂载的文件可以被同时更新至容器。为了确保信息一致性，目前这种类型的挂载不支持文件更新操作。

有些云原生应用支持配置更新时的自动重载功能，例如envoy支持基于XDS协议订阅文件系统上的配置文件，并在该类配置文件更新时间戳发生变动时自动重载配置。然而，采用联合挂载多层叠加且进行写时复制的容器隔离文件系统来说，这种时间戳的更新未必能触发内核中的通知机制，也就能以触发应用程序的自动重载功能。总结起来，在pod资源中调用ConfigMap对象时要注意以下几个问题。

• 以存储卷方式引用的ConfigMap对象必须先于pod对象存在，除非在pod对象中把它们系统标记为optional，否则将会导致pod无法正常启动；同样，即时ConfigMap对象存在，但引用的键名不存在时，也会导致同样的错误。
• 以环境变量方式引用的ConfigMap对象的键不存在时会被忽略，pod对象可以正常启动，但错误引用的信息会以InvalidVariableName事件记录与日志中。
• ConfigMap对象时名称空间级的资源，能够引用它的pod对象必须位于同一名称空间。
• kubelet仅支持那些由API Server管理pod资源来引用ConfigMap对象，因而那些由kubelet在节点上通过--manifest-url或--config选项加载配置清单创建的静态pod，以及有用户直接通过kubelet的RESTful API创建的pod对象。

ConfigMap无法替代配置文件，它仅在kubernetes系统上代表对应用程序配置文件的引用。