1. ConfigMap/Secret 介绍

  我们学习了 Kubernetes 里的三种 API 对象:Pod、Job 和 CronJob,虽然还没有讲到更高级的其他对象,但使用它们也可以在集群里编排运行一些实际的业务了。

1.1 为什么kubernets 要使用应用的配置管理?

  不过想让业务更顺利地运行,有一个问题不容忽视,那就是应用的配置管理

  配置文件,你应该有所了解吧,通常来说应用程序都会有一个,它把运行时需要的一些参数从代码中分离出来,让我们在实际运行的时候能更方便地调整优化,比如说 Nginx 有 nginx.conf、Redis 有 redis.conf、MySQL 有 my.cnf 等等。

  我们在“入门篇”里学习容器技术的时候讲过,可以选择两种管理配置文件的方式。第一种是编写 Dockerfile,用 COPY 指令把配置文件打包到镜像里;第二种是在运行时使用 docker cp 或者 docker run -v,把本机的文件拷贝进容器

  但这两种方式都存在缺陷。第一种方法相当于是在镜像里固定了配置文件,不好修改,不灵活,第二种方法则显得有点“笨拙”,不适合在集群中自动化运维管理。

  对于这个问题 Kubernetes 有它自己的解决方案,你也应该能够猜得到,当然还是使用 YAML 语言来定义 API 对象,再组合起来实现动态配置。

  Kubernetes 里专门用来管理配置信息的两种对象:ConfigMap Secret,使用它们可以灵活地配置、定制我们的应用。

1.2 有什么类别的配置信息?

首先你要知道,应用程序有很多类别的配置信息,但从数据安全的角度来看可以分成两类:

  • 一类是明文配置,也就是不保密,可以任意查询修改,比如服务端口、运行参数、文件路径等等。
  • 一类则是机密配置,由于涉及敏感信息需要保密,不能随便查看,比如密码、密钥、证书等等。

这两类配置信息本质上都是字符串,只是由于安全性的原因,在存放和使用方面有些差异,所以 Kubernetes 也就定义了两个 API 对象,ConfigMap 用来保存明文配置Secret 用来保存秘密配置

2. 什么是 ConfigMap?

2.1 创建ConfigMap模板文件

  先来看 ConfigMap,我们仍然可以用命令 kubectl create 来创建一个它的 YAML 样板。注意,它有简写名字“cm”,所以命令行里没必要写出它的全称:

export out="--dry-run=client -o yaml"        # 定义Shell变量
kubectl create cm info $out

得到的样板文件大概是这个样子:

apiVersion: v1
kind: ConfigMap
metadata:
  name: info

  你可能会有点惊讶,ConfigMap 的 YAML 和之前我们学过的 Pod、Job 不一样,除了熟悉的“apiVersion”“kind”“metadata”,居然就没有其他的了,最重要的字段“spec”哪里去了?这是因为 ConfigMap 存储的是配置数据,是静态的字符串,并不是容器,所以它们就不需要用“spec”字段来说明运行时的“规格”。

  既然 ConfigMap 要存储数据,我们就需要用另一个含义更明确的字段“data”。

2.1.1 ConfigMap 怎么生成带data 字段的 模板

  你需要在 kubectl create 后面多加一个参数 --from-literal ,表示从字面值生成一些数据:

kubectl create cm info --from-literal=k=v $out

#会输出以下信息
apiVersion: v1
data:
  k: v
kind: ConfigMap
metadata:
  creationTimestamp: null
  name: info

  注意,因为在 ConfigMap 里的数据都是 Key-Value 结构,所以 --from-literal 参数需要使用 k=v 的形式。

  把 YAML 样板文件修改一下,再多增添一些 Key-Value,就得到了一个比较完整的 ConfigMap 对象:

apiVersion: v1
kind: ConfigMap
metadata:
  name: info

data:
  count: '10'
  debug: 'on'
  path: '/etc/systemd'
  greeting: |
    say hello to kubernetes.

2.2 创建ConfigMap 对象

kubectl apply -f cm.yml

2.3 查看ConfigMap 对象信息

kubectl get cm  
kubectl describe cm info #查看状态

你可以看到,现在 ConfigMap 的 Key-Value 信息就已经存入了 etcd 数据库,后续就可以被其他 API 对象使用。

在这里插入图片描述

3. 什么是 Secret?

  了解了 ConfigMap 对象,我们再来看 Secret 对象就会容易很多,它和 ConfigMap 的结构和用法很类似,不过在 Kubernetes 里 Secret 对象又细分出很多类,比如:

  • 访问私有镜像仓库的认证信息
  • 身份识别的凭证信息
  • HTTPS 通信的证书和私钥
  • 一般的机密信息(格式由用户自行解释)

  前几种我们现在暂时用不到,所以就只使用最后一种。

3.1 创建Secret模板文件

创建 YAML 样板的命令是 kubectl create secret generic ,同样,也要使用参数 --from-literal 给出 Key-Value 值:

kubectl create secret generic user --from-literal=name=root $out

得到的 Secret 对象大概是这个样子:

apiVersion: v1
data:
  name: cm9vdA==
kind: Secret
metadata:
  creationTimestamp: null
  name: user

  Secret 对象第一眼的感觉和 ConfigMap 非常相似,只是“kind”字段由“ConfigMap”变成了“Secret”,后面同样也是“data”字段,里面也是 Key-Value 的数据。

  不过,既然它的名字是 Secret,我们就不能像 ConfigMap 那样直接保存明文了,需要对数据“做点手脚”。你会发现,这里的“name”值是一串“乱码”,而不是刚才在命令行里写的明文“root”。

3.2 使用base64 对数据进行编码存储

   这串“乱码”就是 Secret 与 ConfigMap 的不同之处,不让用户直接看到原始数据,起到一定的保密作用。不过它的手法非常简单,只是做了 Base64 编码,根本算不上真正的加密,所以我们完全可以绕开 kubectl,自己用 Linux 小工具“base64”来对数据编码,然后写入 YAML 文件,比如

echo -n "123456" | base64
MTIzNDU2

   我们再来重新编辑 Secret 的 YAML,为它添加两个新的数据,方式可以是参数 --from-literal 自动编码,也可以是自己手动编码:

apiVersion: v1
kind: Secret
metadata:
  name: user

data:
  name: cm9vdA==  # root
  pwd: MTIzNDU2   # 123456
  db: bXlzcWw=    # mysql

3.3 创建Secret对象及获取Secret信息

   接下来的创建和查看对象操作和 ConfigMap 是一样的,使用 kubectl apply、kubectl get、kubectl describe:

kubectl apply  -f secret.yml
kubectl get secret
kubectl describe secret user

   这样一个存储敏感信息的 Secret 对象也就创建好了,而且因为它是保密的,使用 kubectl describe 不能直接看到内容,只能看到数据的大小,你可以和 ConfigMap 对比一下。
在这里插入图片描述

4. 如何使用 ConfigMap/Secret ?

   在前面讲 Pod 的时候,说过描述容器的字段“containers”里有一个“env”,它定义了 Pod 里容器能够看到的环境变量。

   当时我们只使用了简单的“value”,把环境变量的值写“死”在了 YAML 里,实际上它还可以使用另一个“valueFrom”字段,从 ConfigMap 或者 Secret 对象里获取值,这样就实现了把配置信息以环境变量的形式注入进 Pod,也就是配置与应用的解耦

4.1 ConfigMap/Secret 解释

   由于“valueFrom”字段在 YAML 里的嵌套层次比较深,初次使用最好看一下 kubectl explain 对它的说明:

   “valueFrom”字段指定了环境变量值的来源,可以是“configMapKeyRef”或者“secretKeyRef”,然后你要再进一步指定应用的 ConfigMap/Secret 的“name”和它里面的“key”,要当心的是这个“name”字段是 API 对象的名字,而不是 Key-Value 的名字。

   下面我就把引用了 ConfigMap 和 Secret 对象的 Pod 列出来,给你做个示范,为了提醒你注意,我把“env”字段提到了前面:

  1. 这个 Pod 的名字是“env-pod”,镜像是“busybox”,执行命令 sleep 睡眠 300 秒,我们可以在这段时间里使用命令 kubectl exec 进入 Pod 观察环境变量。

  2. 你需要重点关注的是它的“env”字段,里面定义了 4 个环境变量,COUNT、GREETING、USERNAME、PASSWORD。

  3. 对于明文配置数据, COUNT、GREETING 引用的是 ConfigMap 对象,所以使用字段“configMapKeyRef”,里面的“name”是 ConfigMap 对象的名字,也就是之前我们创建的“info”,而“key”字段分别是“info”对象里的 count 和 greeting。

  4. 同样的对于机密配置数据, USERNAME、PASSWORD 引用的是 Secret 对象,要使用字段“secretKeyRef”,再用“name”指定 Secret 对象的名字 user,用“key”字段应用它里面的 name 和 pwd 。

apiVersion: v1
kind: Pod
metadata:
  name: env-pod

spec:
  containers:
  - env:
      - name: COUNT
        valueFrom:
          configMapKeyRef:
            name: info
            key: count
      - name: GREETING
        valueFrom:
          configMapKeyRef:
            name: info
            key: greeting
      - name: USERNAME
        valueFrom:
          secretKeyRef:
            name: user
            key: name
      - name: PASSWORD
        valueFrom:
          secretKeyRef:
            name: user
            key: pwd

    image: busybox
    name: busy
    imagePullPolicy: IfNotPresent
    command: ["/bin/sleep", "300"]

4.1.1 图示ConfigMap 和 Secret 在 Pod 里的组合关系

  这段解释确实是有点绕口令的感觉,因为 ConfigMap 和 Secret 在 Pod 里的组合关系不像 Job/CronJob 那么简单直接,所以我还是用画图来表示它们的引用关系:
在这里插入图片描述

4.2 创建pod,验证环境变量

  我们用 kubectl apply 创建 Pod,再用 kubectl exec 进入 Pod,验证环境变量是否生效:

4.2.1 ConfigMap 创建

kubectl apply -f cm.yml
test@juzi:/k8s$ cat cm.yml
apiVersion: v1
kind: ConfigMap
metadata:
  name: info

data:
  count: '10'
  debug: 'on'
  path: '/etc/systemd'
  greeting: 
    say hello to kubernetes.

4.2.2 Secret 创建

kubectl apply -f secret.yml
test@juzi:/k8s$ cat secret.yml
apiVersion: v1
kind: Secret
metadata:
  name: user

data:
  name: cm9vdA==  # root
  pwd: MTIzNDU2   # 123456
  db: bXlzcWw=    # mysql

4.2.3 Pod 创建

kubectl apply -f env-pod.yml
test@juzi:/k8s$ cat env.yml
apiVersion: v1
kind: Pod
metadata:
  name: env-pod

spec:
  containers:
  - env:
      - name: COUNT
        valueFrom:
          configMapKeyRef:
            name: info
            key: count
      - name: USERNAME
        valueFrom:
          secretKeyRef:
            name: user
            key: name

    image: busybox:latest
    name: busy
    imagePullPolicy: IfNotPresent
    command: ["/bin/sleep", "300"]

4.2.4 验证环境变量是否生效

kubectl exec -it env-pod -- sh
echo $COUNT
echo $GREETING
echo $USERNAME $PASSWORD

  这张截图就显示了 Pod 的运行结果,可以看到在 Pod 里使用 echo 命令确实输出了我们在两个 YAML 里定义的配置信息,也就证明 Pod 对象成功组合了 ConfigMap 和 Secret 对象。

  以环境变量的方式使用 ConfigMap/Secret 还是比较简单的,下面来看第二种加载文件的方式。
在这里插入图片描述

5. 如何以 Volume 的方式使用 ConfigMap/Secret?

  Kubernetes 为 Pod 定义了一个“Volume”的概念,可以翻译成是“存储卷”。如果把 Pod 理解成是一个虚拟机,那么 Volume 就相当于是虚拟机里的磁盘。

  我们可以为 Pod“挂载(mount)”多个 Volume,里面存放供 Pod 访问的数据,这种方式有点类似 docker run -v,虽然用法复杂了一些,但功能也相应强大一些。

  在 Pod 里挂载 Volume 很容易,只需要在“spec”里增加一个“volumes”字段,然后再定义卷的名字和引用的 ConfigMap/Secret 就可以了。要注意的是 Volume 属于 Pod,不属于容器,所以它和字段“containers”是同级的,都属于“spec”。

5.1 定义Volume且引用 ConfigMap/Secret

5.1.1 定义 Volume

  下面让我们来定义两个 Volume,分别引用 ConfigMap 和 Secret,名字是 cm-vol 和 sec-vol:

spec:
  volumes:
  - name: cm-vol
    configMap:
      name: info
  - name: sec-vol
    secret:
      secretName: user

5.1.2 挂载Volume(容器中挂载)

  有了 Volume 的定义之后,就可以在容器里挂载了,这要用到“volumeMounts”字段,正如它的字面含义,可以把定义好的 Volume 挂载到容器里的某个路径下,所以需要在里面用“mountPath”“name”明确地指定挂载路径和 Volume 的名字。

  containers:
  - volumeMounts:
    - mountPath: /tmp/cm-items
      name: cm-vol
    - mountPath: /tmp/sec-items
      name: sec-vol

5.1.3 volumes 和 volumeMounts 的关系

  把“volumes”和“volumeMounts”字段都写好之后,配置信息就可以加载成文件了。这里我还是画了图来表示它们的引用关系:

  你可以看到,挂载 Volume 的方式和环境变量又不太相同。环境变量是直接引用了 ConfigMap/Secret,而 Volume 又多加了一个环节,需要先用 Volume 引用 ConfigMap/Secret然后在容器里挂载 Volume,有点“兜圈子”“弯弯绕”。

  这种方式的好处在于:以 Volume 的概念统一抽象了所有的存储,不仅现在支持 ConfigMap/Secret,以后还能够支持临时卷、持久卷、动态卷、快照卷等许多形式的存储,扩展性非常好。
在这里插入图片描述

5.2 完整描述Volume且引用 ConfigMap/Secret 的YAML文件

5.2.1 创建ConfigMap资源对象

kubectl apply -f /tmp/cm-items
test@juzi:/k8s/volume$ cat /tmp/cm-items
apiVersion: v1
kind: ConfigMap
metadata:
  name: info

data:
  count: '10'
  debug: 'on'
  path: '/etc/systemd'
  greeting: "say hello to kubernetes."

5.2.2 创建Secret资源对象

kubectl apply -f /tmp/sec-items
test@juzi:/k8s$ cat /tmp/sec-items
apiVersion: v1
kind: Secret
metadata:
  name: user

data:
  name: cm9vdA==  # root
  pwd: MTIzNDU2   # 123456
  db: bXlzcWw=    # mysql

5.2.3 创建Pod 资源并引用Volum

 kubectl apply -f vol-pod.yml
test@juzi:/k8s/volume$ cat /tmp/cm-items
apiVersion: v1
kind: ConfigMap
metadata:
  name: info

data:
  count: '10'
  debug: 'on'
  path: '/etc/systemd'
  greeting: "say hello to kubernetes."

test@juzi:/k8s/volume$ cat vol-pod.yml
apiVersion: v1
kind: Pod
metadata:
  name: vol-pod

spec:
  volumes:
  - name: cm-vol
    configMap:
      name: info
  - name: sec-vol
    secret:
      secretName: user

  containers:
  - volumeMounts:
    - mountPath: /tmp/cm-items
      name: cm-vol
    - mountPath: /tmp/sec-items
      name: sec-vol

    image: busybox
    name: busy
    imagePullPolicy: IfNotPresent
    command: ["/bin/sleep", "300"]

5.3 查看Pod 信息

kubectl apply -f vol-pod.yml
kubectl get pod
kubectl exec -it vol-pod -- sh

会看到,ConfigMap 和 Secret 都变成了目录的形式,而它们里面的 Key-Value 变成了一个个的文件,而文件名就是 Key。

因为这种形式上的差异,以 Volume 的方式来使用 ConfigMap/Secret,就和环境变量不太一样。环境变量用法简单,更适合存放简短的字符串,而 Volume 更适合存放大数据量的配置文件,在 Pod 里加载成文件后让应用直接读取使用。
在这里插入图片描述

6. ConfigMap/Secret 小结

  我们学习了两种在 Kubernetes 里管理配置信息的 API 对象 ConfigMap 和 Secret,它们分别代表了明文信息和机密敏感信息,存储在 etcd 里,在需要的时候可以注入 Pod 供 Pod 使用。
简单小结一下今天的要点:

  1. ConfigMap 记录了一些 Key-Value 格式的字符串数据,描述字段是“data”,不是“spec”。
  2. Secret 与 ConfigMap 很类似,也使用“data”保存字符串数据,但它要求数据必须是 Base64 编码,起到一定的保密效果。
  3. 在 Pod 的“env.valueFrom”字段中可以引用 ConfigMap 和 Secret,把它们变成应用可以访问的环境变量。
  4. 在 Pod 的“spec.volumes”字段中可以引用 ConfigMap 和 Secret,把它们变成存储卷,然后在“spec.containers.volumeMounts”字段中加载成文件的形式。
  5. ConfigMap 和 Secret 对存储数据的大小没有限制,但小数据用环境变量比较适合,大数据应该用存储卷,可根据具体场景灵活应用

7. 思考

7.1 说一说你对 ConfigMap 和 Secret 这两个对象的理解,它们有什么异同点?

7.2 如果我们修改了 ConfigMap/Secret 的 YAML,然后使用 kubectl apply 命令更新对象,那么 Pod 里关联的信息是否会同步更新呢?你可以自己验证看看。

Logo

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐