Kubernetes的ConfigMap说明

这篇博文,我们来说一说,关于在kubernetes的pod中自定义配置的问题。

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

创建ConfigMap

创建ConfigMap的方式有两种,一种是通过yaml文件来创建,另一种是通过kubectl直接在命令行下创建。

我们先来看第一种,在yaml文件中,配置文件以key-value键值对的形式保存,当然也可以直接放一个完整的配置文件,在下面的示例中,cache_hst、cache_port、cache_prefix即是key-value键值对,而app.properties和my.cnf都是配置文件:

apiVersion: v1
kind: ConfigMap
metadata:
  name: test-cfg
  namespace: default
data:
  cache_host: memcached-gcxt
  cache_port: "11211"
  cache_prefix: gcxt
  my.cnf: |
    [mysqld]
    log-bin = mysql-bin
  app.properties: |
    property.1 = value-1
 property.2 = value-2
 property.3 = value-3

创建ConfigMap:

kubectl create -f test-cfg.yml

第二种方式是直接使用kubectl在命令行下创建

直接将一个目录下的所有配置文件创建为一个ConfigMap:

kubectl create configmap test-config --from-file=./configs

直接将一个配置文件创建为一个ConfigMap:

kubectl create configmap test-config2 --from-file=./configs/db.conf --from-file=./configs/cache.conf

在使用kubectl创建的时候,通过在命令行直接传递键值对创建:

kubectl create configmap test-config3 --from-literal=db.host=10.5.10.116 --from-listeral=db.port=‘3306‘

我们可以通过如下方式查看创建的ConfigMap:

kubectl get configmaps
kubectl get configmap test-config -o yaml
kubectl describe configmap test-config

使用ConfigMap

使用ConfigMap有三种方式,一种是通过环境变量的方式,直接传递pod,另一种是通过在pod的命令行下运行的方式,第三种是使用volume的方式挂载入到pod内

第一种方式示例:

ConfigMap文件:

apiVersion: v1
kind: ConfigMap
metadata:
  name: special-config
  namespace: default
data:
  special.how: very
  special.type: charm

第一个pod示例:

apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  containers:    - name: test-container
      image: gcr.io/google_containers/busybox
      command: [ "/bin/sh", "-c", "env" ]      env:        - name: SPECIAL_LEVEL_KEY
          valueFrom:
            configMapKeyRef:
              name: special-config
              key: special.how        - name: SPECIAL_TYPE_KEY
          valueFrom:
            configMapKeyRef:
              name: special-config
              key: special.type
  restartPolicy: Never

第二个pod示例:

apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  containers:    - name: test-container
      image: gcr.io/google_containers/busybox
      command: [ "/bin/sh", "-c", "env" ]      env:        - name: CACHE_HOST
          valueFrom:
            configMapKeyRef:
              name: test-cfg
              key: cache_host
              optional: true
  restartPolicy: Never

第二种方式在命令行下引用时,需要先设置为环境变量,之后 可以通过$(VAR_NAME)设置容器启动命令的启动参数,示例:

ConfigMap文件示例:

apiVersion: v1
kind: ConfigMap
metadata:
  name: special-config
  namespace: default
data:
  special.how: very
  special.type: charm

Pod示例:

apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  containers:    - name: test-container
      image: gcr.io/google_containers/busybox
      command: [ "/bin/sh", "-c", "echo $(SPECIAL_LEVEL_KEY) $(SPECIAL_TYPE_KEY)" ]      env:        - name: SPECIAL_LEVEL_KEY
          valueFrom:
            configMapKeyRef:
              name: special-config
              key: special.how        - name: SPECIAL_TYPE_KEY
          valueFrom:
            configMapKeyRef:
              name: special-config
              key: special.type
  restartPolicy: Never

第三种方式,使用volume将ConfigMap作为文件或目录直接挂载,其中每一个key-value键值对都会生成一个文件,key为文件名,value为内容,下面是一个示例:

ConfigMap示例:

apiVersion: v1
kind: ConfigMap
metadata:
  name: special-config
  namespace: default
data:
  special.how: very
  special.type: charm

第一个pod示例,简单的将上面创建的ConfigMap直接挂载至pod的/etc/config目录下:

apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  containers:    - name: test-container
      image: gcr.io/google_containers/busybox
      command: [ "/bin/sh", "-c", "cat /etc/config/special.how" ]
      volumeMounts:      - name: config-volume
        mountPath: /etc/config
  volumes:    - name: config-volume
      configMap:
        name: special-config
  restartPolicy: Never

第二个pod示例,只将ConfigMap的special.how这个key挂载到/etc/config目录下的一个相对路径path/to/special-key,如果存在同名文件,直接覆盖。其他的key不挂载:

apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  containers:    - name: test-container
      image: gcr.io/google_containers/busybox
      command: [ "/bin/sh","-c","cat /etc/config/path/to/special-key" ]
      volumeMounts:      - name: config-volume
        mountPath: /etc/config
  volumes:    - name: config-volume
      configMap:
        name: special-config
        items:        - key: special.how
          path: path/to/special-key
  restartPolicy: Never

最后需要说明两点:

1、ConfigMap必须在Pod之前创建

2、只有与当前ConfigMap在同一个namespace内的pod才能使用这个ConfigMap,换句话说,ConfigMap不能跨命名空间调用。

时间: 2024-11-09 07:14:24

Kubernetes的ConfigMap说明的相关文章

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配置数据,这个数据可以在

21.Kubernetes之ConfigMap

应用部署的一个最佳实践是将应用所需的配置信息于程序进行分离,这样可以使得应用程序被更好的复用,通过不用配置文件也能实现更灵活的功能.将应用打包为容器镜像后,可以通过环境变量或外挂文件的方式在创建容器时进行配置注入.ConfigMap是Kubernetes v1.2版本开始提供的一种统一集群配置管理方案. 1.ConfigMap:容器应用的配置管理 容器使用ConfigMap的典型用法如下: (1)生产为容器的环境变量.(2)设置容器启动命令的启动参数(需设置为环境变量).(3)以Volume的形

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

8月最新基于kubernetes的应用编排实践

本文根据8月22日腾讯云研发工程师颜卫在DockOne社群线上直播分享整理.颜卫来自腾讯云容器服务团队,现在主要从事腾讯云容器服务应用编排和微服务相关开发工作. 1 今天交流的话题主要会分为三部分 1.为什么需要应用编排 2.kubernetes社区应用编排发展现状 3.腾讯云容器服务应用编排的实践这几个方面做介绍. 在腾讯云容器服务应用编排的实践部分,主要会涉及1.配置管理,2.应用模板管理,3.基于应用的服务组管理等内容. 为什么需要应用编排: "微服务"架构大家都知道,他具有开发