Contents

Kubernetes教程(六)---通过ConfigMap与Secret管理配置文件

本文主要记录了 Kubernetes 中的几种 Projected Volume,包括 ConfigMap、Secret、Downward API、ServiceAccountToken等。

1. 概述

在 Kubernetes 中,有几种特殊的 Volume,它们存在的意义不是为了存放容器里的数据,也不是用来进行容器和宿主机之间的数据交换。

这些特殊 Volume 的作用,是为容器提供预先定义好的数据

所以,从容器的角度来看,这些 Volume 里的信息就是仿佛是被 Kubernetes“投射”(Project)进入容器当中的。这正是 Projected Volume 的含义。

到目前为止,Kubernetes 支持的 Projected Volume 一共有四种:

  • 1)ConfigMap;
  • 2)Secret;
  • 3)Downward API;
  • 4)ServiceAccountToken。

ConfigMap 顾名思义,是用于保存配置数据的键值对,可以用来保存单个属性,也可以保存配置文件。

Secret 可以为 Pod 提供密码、Token、私钥等敏感数据;对于一些非敏感数据,比如应用的配置信息,则可以使用 ConfigMap。

就是把数据存放到 Etcd 中。然后,你就可以通过在 Pod 的容器里挂载 Volume 的方式,访问到这些 Secret、ConfigMap 里保存的信息了。

Downward API,它的作用是:让 Pod 里的容器能够直接获取到这个 Pod API 对象本身的信息。

不过,需要注意的是,Downward API 能够获取到的信息,一定是 Pod 里的容器进程启动之前就能够确定下来的信息

其实,Secret、ConfigMap,以及 Downward API 这三种 Projected Volume 定义的信息,大多还可以通过环境变量的方式出现在容器里。但是,通过环境变量获取这些信息的方式,不具备自动更新的能力。所以,一般情况下,都建议使用 Volume 文件的方式获取这些信息,Volume 方式可以自动更新,不过可能会有一定延迟。

ServiceAccountToken 一种特殊的 Secret,是 Kubernetes 系统内置的一种“服务账户”,它是 Kubernetes 进行权限分配的对象。

另外,为了方便使用,Kubernetes 已经为你提供了一个默认“服务账户”(default Service Account)。并且,任何一个运行在 Kubernetes 里的 Pod,都可以直接使用这个默认的 Service Account,而无需显示地声明挂载它(k8s 默认会为每一个Pod 都挂载该Volume)。

2. ConfigMap

# 创建
$ kubectl create configmap 
# 删除
$ kubectl delete configmap ConfigMap名称
# 编辑
$ kubectl edit configmap ConfigMap名称
# 查看-列表
$ kubectl get configmap
# 查看-详情
$ kubectl describe configmap ConfigMap名称

1. 创建

可以使用 kubectl create configmap 从以下多种方式创建 ConfigMap。

  • 1)yaml 描述文件:事先写好标准的configmap的yaml文件,然后kubectl create -f 创建
  • 2)–from-file:通过指定目录或文件创建,将一个或多个配置文件创建为一个ConfigMap
  • 3)–from-literal:通过直接在命令行中通过 key-value 字符串方式指定configmap参数创建
  • 4)–from-env-file:从 env 文件读取配置信息并创建为一个ConfigMap

yaml 描述文件

$ kubectl create -f configmap.yaml 
configmap/test-conf created
$ kubectl get configmaps
NAME        DATA   AGE
cm1   1      8s
$ kubectl describe configmap test-conf
Name:         cm1
Namespace:    default
Labels:       <none>
Annotations:  <none>

Data
====
user:
----
name: "17x"
github: "https://github.com/lixd"
blog: "https://www.lixueduan.com"
Events:  <none>

configmap.yaml 如下:

apiVersion: v1
kind: ConfigMap
metadata: 
  name: cm1
  namespace: default
data:
  user: |+
    name: "17x"
    github: "https://github.com/lixd"
    blog: "https://www.lixueduan.com"    

–from-file

  • 1)单文件
$ kubectl create configmap cm2 --from-file=conf-17x.yaml 
configmap/cm1 created
$ kubectl get configmaps
NAME   DATA   AGE
cm2    1      17s
$ kubectl get configmap cm2 -o go-template='{{.data}}'
map[user:name: "17x"
github: "https://github.com/lixd"
blog: "https://www.lixueduan.com"]

配置文件如下

User: "17x"
Github: "https://github.com/lixd"
Blog: "https://www.lixueduan.com"
  • 2)目录
# 从 conf 目录下多个文件读取配置信息
$ kubectl create configmap cm3 --from-file=conf
configmap/cm3 created
$ kubectl get configmaps
NAME        DATA   AGE
cm3         2      8s
$ kubectl get configmap cm3 -o go-template='{{.data}}'
map[conf1.yaml:User: "17x"
Github: "https://github.com/lixd"
Blog: "https://www.lixueduan.com"
 conf2.yaml:User: "17x"
Github: "https://github.com/lixd"
Blog: "https://www.refersmoon.com"

–from-literal

每个 –from-literal 对应一个信息条目。

$ kubectl create configmap cm4 --from-literal=name="17x" --from-literal=blog="https://www.lixueduan.com"
configmap "cm4" created
$ kubectl get configmap cm4 -o go-template='{{.data}}'
map[blog:https://www.lixueduan.com name:17x][root@iZ2ze9ebgot9h2acvk4uabZ configmap]

–from-env-file

$ kubectl create configmap cm5 --from-env-file=conf.env 
configmap/cm5 created
$ kubectl get configmap cm5 -o go-template='{{.data}}'
map[blog:https://www.lixueduan.com github:https://github.com/lixd name:17x]

conf.env文件如下

语法为 key=value

name=17x
github=https://github.com/lixd
blog=https://www.lixueduan.com

2. 使用

Pod 可以通过三种方式来使用 ConfigMap,分别为:

  • 将 ConfigMap 中的数据设置为环境变量
  • 使用 Volume 将 ConfigMap 作为文件或目录挂载
    • 注意:ConfigMap 中的每一个Key都会单独挂载为一个文件

注意!!

  • ConfigMap 必须在 Pod 使用它之前创建
  • 使用 envFrom 时,将会自动忽略无效的键
  • 一个Pod 只能使用同一个命名空间的 ConfigMap

用作环境变量

$ kubectl create configmap cm1 --from-literal=first="hello world" --from-literal=second="hello configmap"
$ kubectl create configmap env-cm --from-literal=log_level=INFO
apiVersion: v1
kind: Pod
metadata:
  name: test-pod
spec:
  containers:
    - name: test-container
      image: busybox
      command: [ "/bin/sh", "-c", "env" ]
      env:
        - name: CUSTOM_FIRST
          valueFrom:
            configMapKeyRef:
              name: cm1
              key: first
        - name: CUSTOM_SECOND
          valueFrom:
            configMapKeyRef:
              name: cm1
              key: second
      envFrom:
        - configMapRef:
            name: env-cm
  restartPolicy: Never

通过 env单个指定或者通过envFrom直接加载整个 configmap

根据以上 yaml 文件创建 pod 并查看日志

$ kubectl apply -f cm.yaml
# 查看日志 会打印出一堆环境变量 其中就有我们指定的 configmap
$ kubectl logs test-pod
log_level=INFO
CUSTOM_FIRST=hello world
CUSTOM_SECOND=hello configmap

使用 Volume 将 ConfigMap 作为文件或目录挂载

apiVersion: v1
kind: Pod
metadata:
  name: test-pod
spec:
  containers:
  - image: busybox
    name: app
    volumeMounts:
    - mountPath: /etc/foo
      name: foo
      readOnly: true
    args:
    - /bin/sh
    - -c
    - sleep 10; touch /tmp/healthy; sleep 30000
  volumes:
  - name: foo
    configMap:
      name: cm1

进入 pod 查看,会在前面指定的 /etc/foo 目录下创建 configmap中的文件

$ kubectl apply -f cm2.pod.yaml 
# 进入 pod 查看,会在前面指定的 /etc/foo 目录下创建 configmap中的文件
$ kubectl exec -it test-pod sh
$ cd /etc/foo/
$ ls
first   second
$ cat first 
hello world

3. Secret

Secret 和 Configmap 类似,不过 Secret 是加密后的,一般用于存储敏感数据,如 比如密码,token,密钥等。

Secret有三种类型:

  • 1)Opaque:base64 编码格式的 Secret,用来存储密码、密钥等;但数据也可以通过base64 –decode解码得到原始数据,所以加密性很弱。

  • 2)Service Account:用来访问Kubernetes API,由Kubernetes自动创建,并且会自动挂载到Pod的 /run/secrets/kubernetes.io/serviceaccount 目录中。

  • 3)kubernetes.io/dockerconfigjson : 用来存储私有docker registry的认证信息。

1. 创建

Secret 同样有多种创建方式

  • 1)yaml 描述文件:事先写好标准的secret的yaml文件,然后kubectl create -f 创建
  • 2)–from-file:通过指定目录或文件创建,将一个或多个配置文件创建为一个Secret
  • 3)–from-literal:通过直接在命令行中通过 key-value 字符串方式指定configmap参数创建

yaml 描述文件

$ kubectl apply -f secret.yaml 
secret/mysecret created

# describe 或者 get 命令不会直接显示 secret 中的内容
$ kubectl get secret mysecret -o go-template='{{.data}}'
map[hello:d29ybGQ=

secret.yaml 内容如下:

注意:通过yaml创建Opaque类型的Secret值需要base64编码

$ echo -n 'world'|base64
d29ybGQ=
#secret.yaml
---
apiVersion: v1
kind: Secret
metadata: 
  name: mysecret
type: Opaque
data:  
  hello: d29ybGQ=

–from-file

直接从文件创建,默认 key 为文件名

$ cat hello.txt 
world
# generic 表示创建普通 secret
$ kubectl create secret generic s1 --from-file=hello.txt 
secret/s1 created
$ kubectl get secrets
NAME                                              TYPE                                  DATA   AGE
s1                                                Opaque                                1     20s
# describe 或者 get 命令不会直接显示 secret 中的内容
$ kubectl get secret s1 -o go-template='{{.data}}'
map[hello.txt:d29ybGQK]

–from-literal

字符串方式可以手动指定 key、value

$ kubectl create secret generic s2 --from-literal=hello=world
secret/s2 created
$ kubectl get secret s1 -o go-template='{{.data}}'
map[hello:d29ybGQ=]

2. 使用

同样有两种方式:

  • 将 Secret 中的数据设置为环境变量
  • 使用 Volume 将 Secret 作为文件或目录挂载

用作环境变量

和 configmap 类似,把 configMapKeyRef 替换成 secretKeyRef 即可,同时 secret 是单个的,所以也去掉了批量获取的 envFrom 字段。

# secret-env.yaml
---
apiVersion: v1
kind: Pod
metadata:
  name: test-secret-env-pod
spec:
  containers:
    - name: test-container
      image: busybox
      command: [ "/bin/sh", "-c", "env" ]
      env:
        - name: CUSTOM_HELLO
          valueFrom:
            secretKeyRef:
              name: s2
              key: hello
  restartPolicy: Never

运行pod并查看打印出来的环境变量

$ kubectl apply -f secret-env.yaml 
pod/test-secret-env-pod created

$ kubectl logs test-secret-env-pod
CUSTOM_HELLO=world

Volume 挂载方式

# secret.pod.yaml
---
apiVersion: v1
kind: Pod
metadata:
  name: test-secret-pod
spec:
  containers:
  - name: test-secret
    image: busybox
    args:
    - sleep
    - "3600"
    volumeMounts:
    - name: config
      mountPath: "/etc/foo"
      readOnly: true
  volumes:
  - name: config
    projected:
      sources:
      - secret:
          name: mysecret

创建Pod后进入容器查看,可以看到在指定目录/etc/foo中存在我们指定的secret中的内容hello

$ kubectl exec -it test-secret-pod sh
/ # ls
bin   dev   etc   home  proc  root  sys   tmp   usr   var
$ cd etc/foo/
$ ls
hello
$ cat hello 
world

4. Downward API

它的作用是:让 Pod 里的容器能够直接获取到这个 Pod API 对象本身的信息。

不过,需要注意的是,Downward API 能够获取到的信息,一定是 Pod 里的容器进程启动之前就能够确定下来的信息

举个例子

apiVersion: v1
kind: Pod
metadata:
  name: test-downwardapi-volume
  labels:
    zone: us-est-coast
    cluster: test-cluster1
    rack: rack-22
spec:
  containers:
    - name: client-container
      image: k8s.gcr.io/busybox
      command: ["sh", "-c"]
      args:
      - while true; do
          if [[ -e /etc/podinfo/labels ]]; then
            echo -en '\n\n'; cat /etc/podinfo/labels; fi;
          sleep 5;
        done;
      volumeMounts:
        - name: podinfo
          mountPath: /etc/podinfo
          readOnly: false
  volumes:
    - name: podinfo
      projected:
        sources:
        - downwardAPI:
            items:
              - path: "labels"
                fieldRef:
                  fieldPath: metadata.labels

在这个 Pod 的 YAML 文件中,我定义了一个简单的容器,声明了一个 projected 类型的 Volume。只不过这次 Volume 的数据来源,变成了 Downward API。而这个 Downward API Volume,则声明了要暴露 Pod 的 metadata.labels 信息给容器。

5. 参考

https://kubernetes.io/docs/concepts/configuration/configmap/

https://kubernetes.io/docs/concepts/configuration/secret/

深入剖析Kubernetes