这篇博文,咱们来讲一说,关于在kubernetes的pod中自定义配置的问题。mysql
咱们知道,在几乎全部的应用开发中,都会涉及到配置文件的变动,好比说在web的程序中,须要链接数据库,缓存甚至是队列等等。而咱们的一个应用程序从写第一行代码开始,要经历开发环境、测试环境、预发布环境只到最终的线上环境。而每个环境都要定义其独立的各类配置。若是咱们不能很好的管理这些配置文件,你的运维工做将顿时变的无比的繁琐。为此业内的一些大公司专门开发了本身的一套配置管理中心,如360的Qcon,百度的disconf等。kubernetes也提供了本身的一套方案,即ConfigMap。kubernetes经过ConfigMap来实现对容器中应用的配置管理。web
建立ConfigMap的方式有两种,一种是经过yaml文件来建立,另外一种是经过kubectl直接在命令行下建立。sql
咱们先来看第一种,在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:api
kubectl create -f test-cfg.yml
第二种方式是直接使用kubectl在命令行下建立缓存
直接将一个目录下的全部配置文件建立为一个ConfigMap:app
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建立的时候,经过在命令行直接传递键值对建立:memcached
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有三种方式,一种是经过环境变量的方式,直接传递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
最后须要说明两点:
一、ConfigMap必须在Pod以前建立
二、只有与当前ConfigMap在同一个namespace内的pod才能使用这个ConfigMap,换句话说,ConfigMap不能跨命名空间调用。