21.Kubernetes之ConfigMap

应用部署的一个最佳实践是将应用所需的配置信息于程序进行分离，这样可以使得应用程序被更好的复用，通过不用配置文件也能实现更灵活的功能。将应用打包为容器镜像后，可以通过环境变量或外挂文件的方式在创建容器时进行配置注入。ConfigMap是Kubernetes v1.2版本开始提供的一种统一集群配置管理方案。 　　

1、ConfigMap：容器应用的配置管理

容器使用ConfigMap的典型用法如下：

（1）生产为容器的环境变量。
（2）设置容器启动命令的启动参数（需设置为环境变量）。
（3）以Volume的形式挂载为容器内部的文件或目录。

ConfigMap以一个或多个key:value的形式保存在Kubernetes系统中共应用使用，既可以用于表示一个变量的值，也可以表示一个完整的配置文件内容。

通过yuaml配置文件或者直接使用kubelet create configmap 命令的方式来创建ConfigMap

2、创建ConfigMap资源、对象

1) 通过 yaml 配置文件方式创建

例1：下面的例子 cm-appvars.yaml描述了将几个应用所需的变量定义为 ConfigMap 的用法:
# vim cm-appvars.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: cm-appvars
data:
  apploglevel: info
  appdatadir:/var/data

执行kubectl create命令创建该ConfigMap

$ kubectl create -f cm-appvars.yaml
configmap "cm-appvars.yaml"created

查看创建好的 ConfigMap:

# kubectl get configmap
NAME DATA AGE
cm-appvars 2  3s

查看描述：

# kubectl describe configmap cm-appvars
Name:         cm-appvars
Namespace:    default
Labels:       <none>
Annotations:  <none>

Data
====
appdatadir:
----
/var/data
apploglevel:
----
info
Events:  <none>

查看 yaml：

# kubectl get configmap cm-appvars -o yaml
apiVersion: v1
data:
  appdatadir: /var/data
  apploglevel: info
kind: ConfigMap
metadata:
  creationTimestamp: 2018-11-09T01:47:14Z
  name: cm-appvars
  namespace: default
  resourceVersion: "338011"
  selfLink: /api/v1/namespaces/default/configmaps/cm-appvars
  uid: 62177666-e3c1-11e8-aa71-340a985c23a9
例2：下面的例子cm-appconfigfile.yaml将两个配置文件server.xml和logging.properties定义为configmap的用法，设置key为配置文件的别名，value则是配置文件的文本的全部内容：
apiVersion: v1
kind: ConfigMap
metadata:
  name: cm-appvars
data:
  key-serverxml:
    <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
    <encoder charset="utf-8"> <!-- encoder 可以指定字符集，对于中文输出有意义 -->
        <!-- %.-1level 只显示信息级别的首字母,%-5level 左对齐显示信息级别全称 -->
        <!-- 如需自定义关键字，用 %mdc{键名} 表示,程序中用MDC.put("键名","键值")设置，可动态设置 [%logger:%line]-->
        <Pattern>[%date{yyyy-MM-dd HH:mm:ss}] [%-5level] %logger %line --%mdc{client} [%X{TRACE_LOG_ID}] %msg%n
        </Pattern>
    </encoder>
</appender>
  key-loggingproperties:
        java -Xms1024m -Xmx2048m -Xmn1536m -Xss256k -XX:MaxPermSize=128m -XX:+UseConcMarr
        kSweepGC -XX:CMSFullGCsBeforeCompaction=5 -XX:+UseCMSCompactAtFullCollection -XXX
        :+PrintGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:/tmp/jvm.log -XX:+HH
        eapDumpOnOutOfMemoryError -Dcom.sun.management.jmxremote -Dcom.sun.management.jmm
        xremote.port=4445 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management..
        jmxremote.authenticate=false -XX:HeapDumpPath=/tmp/heapdump.hprof -jar /data/appp
        deploy/$ENVIRONMENT/${PROJECT_JAR} >$jetty_log_path/$PROJECT_NAME.log

执行 kubectl create 命令创建该 Conf1gMap:

$kubectl create -f cm-appconfigfiles.yaml
configmap ”cm-appconfigfiles” created

查看创建好的 ConfigMap:

# kubectl get configmap cm-appconfigfiles
NAME DATA AGE
cm-appconfigfiles 2 14s

查看描述：

# kubectl describe configmap cm-appconfigfiles
Name:         cm-appconfigfiles
Namespace:    default
Labels:       <none>
Annotations:  <none>

Data
====
key-loggingproperties:
----
java -Xms1024m -Xmx2048m -Xmn1536m -Xss256k -XX:MaxPermSize=128m -XX:+UseConcMarr kSweepGC -XX:CMSFullGCsBeforeCompaction=5 -XX:+UseCMSCompactAtFullCollection -XXX :+PrintGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:/tmp/jvm.log -XX:+HH eapDumpOnOutOfMemoryError -Dcom.sun.management.jmxremote -Dcom.sun.management.jmm xremote.port=4445 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.. jmxremote.authenticate=false -XX:HeapDumpPath=/tmp/heapdump.hprof -jar /data/appp deploy/$ENVIRONMENT/${PROJECT_JAR} >$jetty_log_path/$PROJECT_NAME.log
key-serverxml:
----
<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> <encoder charset="utf-8"> <!-- encoder 可以指定字符集，对于中文输出有意义 --> <!-- %.-1level 只显示信息级别的首字母,%-5level 左对齐显示信息级别全称 --> <!-- 如需自定义关键字，用 %mdc{键名} 表示,程序中用MDC.put("键名","键值")设置，可动态设置 [%logger:%line]--> <Pattern>[%date{yyyy-MM-dd HH:mm:ss}] [%-5level] %logger %line --%mdc{client} [%X{TRACE_LOG_ID}] %msg%n</Pattern> </encoder> </appender>
Events:  <none>

查看己创建的 ConfigMap 的详细内容，可以看到两个配置文件的全文 :

# kubectl get configmap cm-appconfigfiles -o yaml
apiVersion: v1
data:
  key-loggingproperties: java -Xms1024m -Xmx2048m -Xmn1536m -Xss256k -XX:MaxPermSize=128m
    -XX:+UseConcMarr kSweepGC -XX:CMSFullGCsBeforeCompaction=5 -XX:+UseCMSCompactAtFullCollection
    -XXX :+PrintGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:/tmp/jvm.log
    -XX:+HH eapDumpOnOutOfMemoryError -Dcom.sun.management.jmxremote -Dcom.sun.management.jmm
    xremote.port=4445 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management..
    jmxremote.authenticate=false -XX:HeapDumpPath=/tmp/heapdump.hprof -jar /data/appp
    deploy/$ENVIRONMENT/${PROJECT_JAR} >$jetty_log_path/$PROJECT_NAME.log
  key-serverxml: <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
    <encoder charset="utf-8"> <!-- encoder 可以指定字符集，对于中文输出有意义 --> <!-- %.-1level 只显示信息级别的首字母,%-5level
    左对齐显示信息级别全称 --> <!-- 如需自定义关键字，用 %mdc{键名} 表示,程序中用MDC.put("键名","键值")设置，可动态设置 [%logger:%line]-->
    <Pattern>[%date{yyyy-MM-dd HH:mm:ss}] [%-5level] %logger %line --%mdc{client}
    [%X{TRACE_LOG_ID}] %msg%n</Pattern> </encoder> </appender>
kind: ConfigMap
metadata:
  creationTimestamp: 2018-11-09T02:14:33Z
  name: cm-appconfigfiles
  namespace: default
  resourceVersion: "340465"
  selfLink: /api/v1/namespaces/default/configmaps/cm-appconfigfiles
  uid: 32d3f97b-e3c5-11e8-aa71-340a985c23a9

2) 通过 kubelet 命令行方式创建

不使用 yaml 文件，直接通过kubectl create configmap也可以创建 ConfigMap，可以使用参数--from-file或--from-literal指定内容，并且可以在一行命令中指定多个参数。
(1) 通过--from-file参数从文件中进行创建，可以指定key的名称，也可以在一个命令行中创建包含多个 key 的 ConfigMap，语法为:

# kubectl create configmap NAME --from-file=[key=]source --from-file=[key=]source

(2)通过--from-file参数从目录中进行创建，该目录下的每个配置文件名都被设置为 key. 文件的内容被设置为 value，语法为 :

# kubectl create configmap NAME --from-file=config-files-dir

(3) --from-literal从文本中进行创建，直接将指定的key#=value#创建为ConfigMap的内容，语法为:

# kubectl create configmap NAME --from-literal=keyl=valuel --from-literal= key2=value2

下面对这几种用法举例说明。

  1. 例如，当前目录下含有配置文件server.xml，可以创建一个包含该文件内容的 ConfigMap:

    # kubectl create confiqmap cm-server.xml --from-file=server.xml
  2. 假设 configfiles 目录下包含两个配置文件 server.xml 和 logging.properties，创建一个包含这两个文件内容的 ConfigMap: 
    # kubectl create configmap cm-appconf --from-file=configfiles
  3. 使用 --from-literal 参数进行创建的示例如下: 
    #kubectl create configmap cm-appenv --from-literal=loglevel=info --from-literal=appdatadir=/var/data

    查看

     kubectl describe configmap cm-appenv
 Name:         cm-appenv
 Namespace:    default
 Labels:       <none>
 Annotations:  <none>

 Data
 ====
 appdatadir:
 ----
 /var/data
 loglevel:
 ----
 info
 Events:  <none>

容器应用对 ConfigMap 的使用有以下两种方法。

  1. 通过环境变量获取 ConfigMap 中的内容。
  2. 通过 Volume 挂载的方式将 ConfigMap 中的内容挂载为容器内部的文件或目录。

3、在Pod中使用 ConfigMap

1) 通过环境变量方式使用 ConfigMap

以前面创建的 ConfigMap “cm-appvars”为例 :

# vim cm-appvars.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: cm-appvars
data:
  apploglevel: info
  appdatadir: /var/data

在 Pod “cm-test-pod”的定义中，将 ConfigMap “cm-appvars”中的内容以环境变量 (APPLOGLEVEL和APPDATADIR)设置为容器内部的环境变量，容器的启动命令将显示这两个环境变量的值(“env|grep APP”):

apiVersion: v1
kind: Pod
metadata:
  name: cm-test-pod
spec:
  containers:
  - name: cm-test
    image: busybox
    command: ["/bin/sh","-c","env|grep APP"]
    env:
    - name: APPLOGLEVEL             # 定义环境变量的名称
      valueFrom:                    # key "apploglevel" 对应的值
        configMapKeyRef:
          name: cm-appvars          # 环境变量的值取自 cm-appvars 中
          key: apploglevel          # key 为 "apploglevel"
    - name: APPDATADIR
      valueFrom:
        configMapKeyRef:
          name: cm-appvars
          key: appdatadir
  restartPolicy: Never

使用 kubectl create -f 命令创建该 Pod，由于是测试 Pod，所以该Pod在执行完启动命令后将会退出，井且不会被系统自动重启(restartPolicy=Never):

kubectl create -f cm-test-pod.yaml
pod ” cm-test-pod” created

使用kubectl get pods --show-all查看己经停止的 Pod:

kubectl get pods --show-all
Flag --show-all has been deprecated, will be removed in an upcoming release
NAME                                      READY     STATUS      RESTARTS   AGE
cm-test-pod                               0/1       Completed   0          4m

查看该 Pod 的日志，可以看到启动命令 env | grep APP 的执行结果如下:

kubectl logs cm-test-pod
APPDATADIR=/var/data
APPLOGLEVEL=info

说明容器内部的环境变量使用 ConfigMap cm-appvars 中的值进行了正确的设置。

从 Kubernetes vl.6 开始，引入了一个新的字段 envFrom，实现在 Pod 环境内将 ConfigMap (也可用于 Secret 资源对象〉中所有定义的key=value自动生成为环境变量:

apiVersion: v1
kind: Pod
metadata:
  name: cm-test-pod-env
spec:
  containers:
    - name: cm-test
      image: busybox
      command: ["/bin/sh","-c","env"]
      envFrom:
      - configMapRef:
         name: cm-appvars   # 根据 cm-appvars 中的 key=value 自动生成环境变量
  restartPolicy: Never

通过这个定义，在容器内部将会生成如下环境变量:

# kubectl logs cm-test-pod-env
apploglevel=info
appdatadir=/var/data

需要说明的是 ，环境变量的名称受 POSIX 命名规范([a-zA-Z][a-zA-Z0-9]*)约束 ，不能以数字开头。如果包含非法字符，则系统将跳过该条环境变量的创建，并记录一个 Event 来描 述环境变量无法生成，但并不阻止 Pod 的启动。

2)通过 volumeMount 使用 ConfigMap

在pod "cm-test-app"定义中，将configmap "cm-appconfigfile"中的内容以文件形式mount到容器内部configfiles目录中。

Pod配置文件cm-test-app.yaml内容如下：

apiVersion: v1
kind: Pod
metadata:
  name: cm-test-app
spec:
  containers:
  - name: cm-test-app
    image: kubeguide/tomcat-app:v1
    ports:
    - containerPort: 8080
    volumeMounts:
    - name: serverxml                             # 引用volume名
      mountPath: /configfiles                     # 挂载到容器内部目录
  volumes:
    - name: serverxml
      configMap:
        name: cm-appconfigfiles                  # 使用configmap定义的的cm-appconfigfile
        items:
        - key: key-serverxml                    # 将key=key-serverxml
          path: server.xml                      # value将server.xml文件名进行挂载
        - key: key-loggingproperties            # 将key=key-loggingproperties
          path: logging.properties              # value将logging.properties文件名进行挂载

创建该Pod：

#kubectl create -f cm-test-app.yaml
Pod "cm-test-app"created　　

登录容器查看configfiles目录下的server.xml和logging.properties文件，他们的内容就是configmap “cm-appconfigfile”中定义的两个key的内容

# kubectl exec -ti cm-test-app -- bash

# cat /configfiles/server.xml
<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> <encoder charset="utf-8"> <!-- encoder 可以指定字符集，对于中文输出有意义 --> <!-- %.-1level 只显示信息级别的首字母,%-5level 左对齐显示信息级别全称 --> <!-- 如需自定义关键字，用 %mdc{键名} 表示,程序中用MDC.put("键名","键值")设置，可动态设置 [%logger:%line]--> <Pattern>[%date{yyyy-MM-dd HH:mm:ss}] [%-5level] %logger %line --%mdc{client} [%X{TRACE_LOG_ID}] %msg%n</Pattern> </encoder> </appender>[email protected]:/usr/local/tomcat# 

# cat /configfiles/logging.properties
java -Xms1024m -Xmx2048m -Xmn1536m -Xss256k -XX:MaxPermSize=128m -XX:+UseConcMarr kSweepGC -XX:CMSFullGCsBeforeCompaction=5 -XX:+UseCMSCompactAtFullCollection -XXX :+PrintGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:/tmp/jvm.log -XX:+HH eapDumpOnOutOfMemoryError -Dcom.sun.management.jmxremote -Dcom.sun.management.jmm xremote.port=4445 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.. jmxremote.authenticate=false -XX:HeapDumpPath=/tmp/heapdump.hprof -jar /data/appp deploy/$ENVIRONMENT/${PROJECT_JAR} >$jetty_log_path/$PROJECT_NAME.log

如果在引用 ConfigMap 时不指定 items，则将使用 volumeMount 方式在容器内的目录中为每个item生成一个文件名为key的文件。

Pod配置文件cm-test-app2.yaml内容如下：

apiVersion: v1
kind: Pod
metadata:
  name: cm-test-app2
spec:
  containers:
  - name: cm-test-app2
    image: kubeguide/tomcat-app:v1
    ports:
    - containerPort: 8080
    volumeMounts:
    - name: serverxml                          # 引用volume名
      mountPath: /configfiles                  # 挂载到容器内部目录
  volumes:
  - name: serverxml                            # 定义 volume 名
    configMap:
      name: cm-appconfigfiles                  # 使用configmap定义的的cm-appconfigfile

创建该Pod：

#kubectl create -f cm-test-app2.yaml
Pod "cm-test-app2"created　　

登录容器，查看到/configfiles目录下存在key-loggingproperties和key-serverxml文件，文件的名称来自 ConfigMap cm-appconfigfiles 中定义的两个key
的名称，文件的内容则为 value 的内容:

# ls /configfiles
key-loqqingproperties key-serverxml

使用ConfigMap的条件限制

  • configmap必须在pod之间创建
  • configmap也可以定义为属于某个Namespace，只有处于相同namespaces中的pod可以引用
  • configmap中配额管理还未能实现
  • kubelet只支持可以被API Server管理的Pod使用ConfigMap。kubelet在本Node上通过--manifest-url或--config自动创建的静态 Pod 将无法引用 Conf1gMap。
  • 在 Pod 对 ConfigMap进行挂载(volumeMount)操作时，容器内部只能挂载为“目录”， 无法挂载为“文件”。在挂载到容器内部后，目录中将包含 ConfigMap 定义的每个item,如果该目录下原来还有其他文件，则容器内的该目录将会被挂载的 ConfigMap 覆盖。 如果应用程序需要保留原来的其他文件，则需要进行额外的处理。可以将 ConfigMap 挂载到容器内部的临时目录，再通过启动脚本将配置文件复制或者链接到( cp 或 link 命令)应用所用的实际配置目录下。

链接：https://www.orchome.com/1317
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

原文地址：https://www.cnblogs.com/linux20190409/p/10976329.html

时间： 2024-11-09 07:19:38

21.Kubernetes之ConfigMap的相关文章

Kubernetes的ConfigMap说明

这篇博文,我们来说一说,关于在kubernetes的pod中自定义配置的问题. 我们知道,在几乎所有的应用开发中,都会涉及到配置文件的变更,比如说在web的程序中,需要连接数据库,缓存甚至是队列等等.而我们的一个应用程序从写第一行代码开始,要经历开发环境.测试环境.预发布环境只到最终的线上环境.而每一个环境都要定义其独立的各种配置.如果我们不能很好的管理这些配置文件,你的运维工作将顿时变的无比的繁琐.为此业内的一些大公司专门开发了自己的一套配置管理中心,如360的Qcon,百度的disconf等

kubernetes用configmap实现容器中mysql应用配置文件的管理

1.configmap的作用理解 configMap起什么作用的呢?举个例子,启用一个mysql容器.一般来说,mysql容器重要的有两部分,一部分为存储数据,一部分为配置文件my.cnf.前面有测试过,存储数据可以用pv pvc实现和容器的分离解耦.配置文件也能够实现和容器的分离解耦,也就是说mysql容器能够直接读取并使用预先配置好的配置文件(而不是使用容器中默认自带的配置文件),非常方便.这就是configMap的功能. kubernetes使用configMap来实现对容器中应用的配置文

Kubernetes 配置管理 ConfigMap(十二)

一.背景 很多情况下我们为某一应用做好镜像,当我们想修改其中的一些参数的时候,就变得比较麻烦,又要重新制作镜像,我们是不是有一种方式,让镜像根据不同的场景调用我们不同的配置文件呢,那我们就需要用到 k8s 的另外一种资源,那就是 ConfigMap. 我们知道,在几乎所有的应用开发中,都会涉及到配置文件的变更,比如说在web的程序中,需要连接数据库,缓存甚至是队列等等.而我们的一个应用程序从写第一行代码开始,要经历开发环境.测试环境.预发布环境只到最终的线上环境.而每一个环境都要定义其独立的各种

Kubernetes之ConfigMap和Secret

目录 Kubernetes之ConfigMap和Secret ConfigMap ConfigMap创建方式 存储卷方式挂载configmap 使用nginx-www配置nginx Secret 创建 Secret Kubernetes之ConfigMap和Secret 简介 ConfigMap和Secret是kubernetes系统上两种特殊类型的存储卷,ConfigMao对象用于为容器中的应用提供配置数据以定制程序行为,不过年敏感的配置信息,例如密钥,证书等通常由Secret对象来进行配置,

Kubernetes的ConfigMap解析

ConfigMap功能在Kubernetes1.2版本的时候就有了,许多应用程序会从配置文件.命令行参数或环境变量中读取配置信息.这些配置信息需要与docker image解耦,你总不能每修改一个配置就重做一个image吧?ConfigMap API给我们提供了向容器中注入配置信息的机制,ConfigMap可以被用来保存单个属性,也可以用来保存整个配置文件或者JSON二进制大对象. ConfigMap概览 ConfigMap API资源用来保存key-value pair配置数据,这个数据可以在

Kubernetes 学习21 kubernetes高级调度方式

一.概述 1.上集讲了Scheduler在实现调度时分三步实现调度过程.首先是预选,即从所有节点中选择基本符合选择条件的节点.而后在基本符合条件的节点中使用优选函数计算他们各自的得分并加以比较.并从最高得分的节点中随机选择出一个运行pod的节点,这就是我们的控制平面中scheduler所实现负责的主要功用.同时如果在某些调度场景中我们期望能够通过自己的预设去影响他的一些调度方式,比如就是把我们的pod运行在某些特定的节点之上的时候可以通过自己的预设操作去影响他的预选和优选过程从而使得调度操作能符

kubernetes configMap详解

Kubernetes的ConfigMap说明 这篇博文,我们来说一说,关于在kubernetes的pod中自定义配置的问题. 我们知道,在几乎所有的应用开发中,都会涉及到配置文件的变更,比如说在web的程序中,需要连接数据库,缓存甚至是队列等等.而我们的一个应用程序从写第一行代码开始,要经历开发环境.测试环境.预发布环境只到最终的线上环境.而每一个环境都要定义其独立的各种配置.如果我们不能很好的管理这些配置文件,你的运维工作将顿时变的无比的繁琐.为此业内的一些大公司专门开发了自己的一套配置管理中

kubernetes ConfigMap和Secret

1 容器化应用配置方式概述 1 启动时直接向命令传递参数 docker 容器可用来运行单个应用程序,在制作docker镜像时,Dockerfile中的ENTRYPOINT 和 CMD 指令可用于指定容器启动时要运行的程序及相关的参数,CMD 指令以列表的形式指定要运行的程序及相关的参数,但若同时存在ENTRYPOINT指令,则CMD指令列表中的所有元素都被视为是ENTRYPOINT中程序的命令行参数,另外,在基于某镜像使用Docker 命令创建容器时,可在命令行向ENTRYPOINT中的程序传递

Kubernetes数据持久化之Secret与ConfigMap

ConfigMap和Secret是Kubernetes中两种特殊类型的存储卷,ConfigMap这种资源对象主要用于提供配置数据以定制程序行为,不过一些敏感的配置信息,比如像用户名.密码.密钥等通常都是由Secret这种资源对象来进行配置的,他们将相应的配置信息保存于对象中,而后在Pod资源上以存储卷的形式将其挂载并获取相应配置,以实现配置与镜像文件的解耦. 一.Secret资源对象 1) Secret概述 Secret资源对象存储数据的方式是以键值对的方式进行存储的,在Pod资源进行Secre