Kubernetes 配置管理 ConfigMap(十二)

一、背景

很多情况下我们为某一应用做好镜像,当我们想修改其中的一些参数的时候,就变得比较麻烦,又要重新制作镜像,我们是不是有一种方式,让镜像根据不同的场景调用我们不同的配置文件呢,那我们就需要用到 k8s 的另外一种资源,那就是 ConfigMap。

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

二、创建 ConfigMap

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

创建ConfigMap的方式有4种:

  • 通过直接在命令行中指定configmap参数创建,即--from-literal
  • 通过指定文件创建,即将一个配置文件创建为一个ConfigMap,--from-file=<文件>
  • 通过一个文件内多个键值对,--from-env-file=<文件>
  • 事先写好标准的configmap的yaml文件,然后kubectl create -f 创建。

2.1、通过 --from-literal

kubectl create configmap test-config1 --from-literal=db.host=172.18.8.200 --from-literal=db.port=‘3306‘

查看配置的内容。

[[email protected] ~]# kubectl get cm test-config1 -o yaml
apiVersion: v1
data:
  db.host: 172.18.8.200
  db.port: "3306"
kind: ConfigMap
metadata:
  creationTimestamp: "2018-12-16T04:32:42Z"
  name: test-config1
  namespace: default
  resourceVersion: "3676"
  selfLink: /api/v1/namespaces/default/configmaps/test-config1
  uid: a0ee762b-00eb-11e9-9fa7-000c291fb1b3

2.2、通过 --from-file

echo -n 172.18.8.200 > ./db.host
echo -n 3306 > ./db.port
kubectl create cm test-config2 --from-file=./db.host --from-file=./db.port

查看配置内容:

[[email protected] ~]# kubectl get cm test-config2 -o yaml
apiVersion: v1
data:
  db.host: 172.18.8.200
  db.port: "3306"
kind: ConfigMap
metadata:
  creationTimestamp: "2018-12-16T04:37:50Z"
  name: test-config2
  namespace: default
  resourceVersion: "4107"
  selfLink: /api/v1/namespaces/default/configmaps/test-config2
  uid: 583ed4e7-00ec-11e9-9fa7-000c291fb1b3

每个文件内容对应一个信息条目。

2.3、通过--from-env-file

cat << EOF > env.txt
db.host=172.18.8.200
db.port=3306
EOF
kubectl create cm test-config3 --from-env-file=env.txt

查看配置内容:

[[email protected] ~]# kubectl get cm test-config3 -o yaml
apiVersion: v1
data:
  db.host: 172.18.8.200
  db.port: "3306"
kind: ConfigMap
metadata:
  creationTimestamp: "2018-12-16T04:43:02Z"
  name: test-config3
  namespace: default
  resourceVersion: "4544"
  selfLink: /api/v1/namespaces/default/configmaps/test-config3
  uid: 12746e5f-00ed-11e9-9fa7-000c291fb1b3

2.4、YAML 配置文件

配置文件内容如下。

apiVersion: v1
kind: ConfigMap
metadata:
  name: test-config4
data:
  db.host: 172.18.8.200
  db.port: "3306"

创建并查看其内容。

[[email protected] ~]# kubectl apply -f db.yaml
configmap/test-config4 created
[[email protected] ~]# kubectl get cm test-config4 -o yaml
apiVersion: v1
data:
  db.host: 172.18.8.200
  db.port: "3306"
kind: ConfigMap
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","data":{"db.host":"172.18.8.200","db.port":"3306"},"kind":"ConfigMap","metadata":{"annotations":{},"name":"test-config4","namespace":"default"}}
  creationTimestamp: "2018-12-16T04:49:01Z"
  name: test-config4
  namespace: default
  resourceVersion: "5045"
  selfLink: /api/v1/namespaces/default/configmaps/test-config4
  uid: e87cdafa-00ed-11e9-9fa7-000c291fb1b3

三、ConfigMap 使用

使用ConfigMap有二种方式:

  • 第一种是通过环境变量的方式,直接传递给pod;
  • 第二种是作为volume的方式挂载到pod内。

3.1、通过环境变量使用

使用valueFromconfigMapKeyRefnamekey指定要用的key。

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: mypod
    image: busybox
    args: [ "/bin/sh", "-c", "sleep 3000" ]
    env:
    - name: DB_HOST
      valueFrom:
        configMapKeyRef:
          name: test-config4
          key: db.host
    - name: DB_PORT
      valueFrom:
        configMapKeyRef:
          name: test-config4
          key: db.port

还可以通过envFromconfigMapRefname使得configmap中的所有key/value对都自动变成环境变量。

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: mypod
    image: busybox
    args: [ "/bin/sh", "-c", "sleep 3000" ]
    envFrom:
    - configMapRef:
        name: test-config3

3.2、作为volume挂载使用

test-config4所有key/value挂载进来:

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: mypod
    image: busybox
    args: [ "/bin/sh", "-c", "sleep 3000" ]
    volumeMounts:
    - name: db
      mountPath: "/etc/db"
      readOnly: true
  volumes:
  - name: db
    configMap:
      name: test-config4

进入容器查看,看到在db文件夹下以每一个key为文件名value为值创建了多个文件。

[[email protected] ~]# kubectl exec -it mypod -- /bin/sh
/ # cd /etc/db
/etc/db # ls -al
total 0
drwxrwxrwx    3 root     root            89 Dec 16 05:23 .
drwxr-xr-x    1 root     root            16 Dec 16 05:23 ..
drwxr-xr-x    2 root     root            36 Dec 16 05:23 ..2018_12_16_05_23_04.654058863
lrwxrwxrwx    1 root     root            31 Dec 16 05:23 ..data -> ..2018_12_16_05_23_04.654058863
lrwxrwxrwx    1 root     root            14 Dec 16 05:23 db.host -> ..data/db.host
lrwxrwxrwx    1 root     root            14 Dec 16 05:23 db.port -> ..data/db.port
/etc/db # cat db.host
172.18.8.200/etc/db # 

3.3、ConfigMap的热更新

使用该 ConfigMap 挂载的 Env 不会同步更新;
使用该 ConfigMap 挂载的 Volume 中的数据需要一段时间(实测大概10秒)才能同步更新。

3.4、最佳使用方法

大多数情况下,配置信息都以文件形式提供,所以在创建 ConfigMap 时通常采用 --from-file 或 YAML 方式,读取 ConfigMap 时通常采用 Volume 方式。
比如我们的 MySQL 配置文件/etc/my.cnf

[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
symbolic-links=0
[mysqld_safe]
log-error=/var/log/mariadb/mariadb.log
pid-file=/var/run/mariadb/mariadb.pid
!includedir /etc/my.cnf.d

创建CongifMap。

kubectl create cm mysql-cm --from-file=/etc/my.cnf

查看创建好的cm。

[[email protected] ~]# kubectl get cm mysql-cm -o yaml
apiVersion: v1
data:
  my.cnf: |
    [mysqld]
    datadir=/var/lib/mysql
    socket=/var/lib/mysql/mysql.sock
    symbolic-links=0
    [mysqld_safe]
    log-error=/var/log/mariadb/mariadb.log
    pid-file=/var/run/mariadb/mariadb.pid
    !includedir /etc/my.cnf.d
kind: ConfigMap
metadata:
  creationTimestamp: "2018-12-16T05:38:29Z"
  name: mysql-cm
  namespace: default
  resourceVersion: "9273"
  selfLink: /api/v1/namespaces/default/configmaps/mysql-cm
  uid: d1201233-00f4-11e9-9fa7-000c291fb1b3

在 Pod 中使用此 ConfigMap,配置文件为:

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: mypod
    image: busybox
    args: [ "/bin/sh", "-c", "sleep 3000" ]
    volumeMounts:
    - name: mysql
      mountPath: "/tmp"
  volumes:
  - name: mysql
    configMap:
      name: mysql-cm
      items:
      - key: my.cnf
        path: mysql/my.cnf

创建 Pod 并读取配置信息:

[[email protected] ~]# kubectl exec -it mypod sh
/ # cat /tmp/mysql/my.cnf
[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
symbolic-links=0
[mysqld_safe]
log-error=/var/log/mariadb/mariadb.log
pid-file=/var/run/mariadb/mariadb.pid
!includedir /etc/my.cnf.d
/ # exit

关于挂在路径大家可以自行进行修改。

原文地址:http://blog.51cto.com/wzlinux/2331050

时间: 2024-11-09 07:19:40

Kubernetes 配置管理 ConfigMap(十二)的相关文章

Kubernetes部署(十二):helm部署harbor企业级镜像仓库

相关内容: Kubernetes部署(一):架构及功能说明Kubernetes部署(二):系统环境初始化Kubernetes部署(三):CA证书制作Kubernetes部署(四):ETCD集群部署Kubernetes部署(五):Haproxy.Keppalived部署Kubernetes部署(六):Master节点部署Kubernetes部署(七):Node节点部署Kubernetes部署(八):Flannel网络部署Kubernetes部署(九):CoreDNS.Dashboard.Ingre

Kubernetes之(十二)存储卷

目录 Kubernetes之(十二)存储卷 简介 emptyDir存储卷 hostPath存储卷 nfs共享存储卷 PV和PVC NFS使用PV和PVC 配置NFS存储 定义PV 定义PVC 查看验证 测试访问 StorageClass Kubernetes之(十二)存储卷 简介 为了保证数据的持久性,必须保证数据在外部存储在docker容器中,为了实现数据的持久性存储,在宿主机和容器内做映射,可以保证在容器的生命周期结束,数据依旧可以实现持久性存储.但是在k8s中,由于pod分布在各个不同的节

现代&ldquo;十二要素应用&rdquo;与 Kubernetes

"十二要素应用"为开发SaaS应用提供了方法上的指导,而Docker能够提供打包依赖,解耦后端服务等特性,使得两者非常吻合.这篇文章介绍了Docker特性怎样满足了开发"十二要素应用"的对应要点. "十二要素应用"为构建SaaS应用提供了方法论,是由知名PaaS云计算平台Heroku的创始人Adam Wiggins提出的.请参考这篇 Heroku 创始人 Adam Wiggins 发布十二要素应用宣言. Dockerfile 与k8s/helm

[email&#160;protected]一个高效的配置管理工具--Ansible configure management--翻译(十二)

如无书面授权,请勿转载 第五章 自定义模块 External inventories In the first chapter we saw how Ansible needs an inventory file, so that it knows where its hosts are and how to access them. Ansible also allows you to specify a script that allows you to fetch the inventor

Heroku创始人Adam Wiggins发布十二要素应用宣言

Heroku是业内知名的云应用平台,从对外提供服务以来,他们已经有上百万应用的托管和运营经验.前不久,创始人Adam Wiggins根据这些经验,发布了一个“十二要素应用宣言(The Twelve-Factor App)”,该宣言由国内工作于安居客的程序员梁山将其翻译为中文,InfoQ中文站摘录如下. 十二要素应用宣言 简介: 如今,软件通常会作为一种服务来交付,它们被称为网络应用程序,或“软件即服务”(SaaS).“十二要素应用程序”(12-Factor App)为构建如下的SaaS应用提供了

微服务-十二要素

前言 今天看"如何实现现代应用的快速落地"公开课,提到十二要素,之前文章也提到多次,这里统一汇总下: 十二要素 如今,软件通常会作为一种服务来交付,它们被称为网络应用程序,或"软件即服务"(SaaS)."十二要素应用程序"(12-Factor App)为构建如下的SaaS应用提供了方法论: 使用标准化流程自动配置,从而使新的开发者花费最少的学习成本加入这个项目: 和操作系统之间尽可能的划清界限,在各个系统中提供最大的可移植性: 适合部署在现代的云

Kubernetes的ConfigMap说明

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

42. 蛤蟆的数据结构笔记之四十二图的遍历之广度优先

42. 蛤蟆的数据结构笔记之四十二图的遍历之广度优先 本篇名言:"生活真象这杯浓酒 ,不经三番五次的提炼呵 , 就不会这样一来可口 ! -- 郭小川" 继续看下广度优先的遍历,上篇我们看了深度遍历是每次一个节点的链表是走到底的. 欢迎转载,转载请标明出处:http://write.blog.csdn.net/postedit/47029275 1.  原理 首先,从图的某个顶点v0出发,访问了v0之后,依次访问与v0相邻的未被访问的顶点,然后分别从这些顶点出发,广度优先遍历,直至所有的

C和指针 (pointers on C)——第十二章:使用结构和指针

第十二章 使用结构和指针 这章就是链表.先单链表,后双向链表. 总结: 单链表是一种使用指针来存储值的数据结构.链表中的每个节点包含一个字段,用于指向链表的下一个节点. 有一个独立的根指针指向链表的第1个节点.单链表只能从一个方向遍历. 如何insert单链表:1.新节点的link字段必须设置为指向它的后面节点.2.前一个节点的link字段必须指向这个新节点. 为了防止可能会插入链表的起始位置这种情况,在C中,可以保存一个指向必须进行修改的link字段的指针,而不是保存一个指向前一个节点的指针.