configmap 和 secret 概述

2023-10-26 14:09:46

本篇文章是对 configmap 和 secret 的一个总结，详细信息可看这里

1. configmap 和 secret 概述

在 container 的 image 中可通过 ENTRYPOINT 和 CMD 分别定义执行命令和参数。其中，ENTRYPOINT 定义容器启动时调用的可执行程序，CMD 指定传递给 ENTRYPOINT 的参数。

传递的参数可被 pod 的文本定义覆盖。并且，对于容器的主进程也有两种形式运行：

以 shell 形式运行，此种形式下容器的主进程即 1 号进程是 bash 进程，image 中指定的可执行被 bash 进程调用。
以 exec 形式运行，该形式下容器的主进程即为 image 中指定的可执行程序。

两种形式的执行示例如下：

shell 形式： ENTRYPOINT startup hello.world
exec 形式： ENTRYPOINT ["startup", hello.world]

注意，以 shell 形式运行的容器，其无法响应 Kubernetes 发送的 signal TERM 信号。即在容器 graceful shutdown 时，容器会忽视 kubernetes 发送的 signal TERM 信号。对于“规定”时间内未响应的容器，kubernetes 会再次发送 KILL 信号强制 kill 容器。详细信息看这里。

对于容器的启动命令传递参数是常见的，那么对于配置文件呢？直接传递配置文件而不是环境变量该怎么做呢？
Kubernets 为应对这种场景（当然不局限于这一种场景），引入 configmap 的概念。configmap 和 pod 的定义解耦，使得同一份 configmap 可以被多个 pod 使用，同时 configmap 可以动态传递参数给容器，而不需要容器重启。

configmap 可以往容器中传递环境变量，命令行参数和文本文件。其中，传递文本文件是通过 configmap 卷的方式实现的。

类似于 configmap，secret 可以被看作为一种“加密”数据的 configmap，它存放的是“敏感”数据，如系统自带的 default serviceaccount，其访问 kubernetes 需要系统自带的 default token secret 实现认证，鉴权操作。

2. configmap 和 pod

前面说了使用 configmap 的好处之一是可以动态更改容器配置，而不需要重启容器。试想如果配置通过 image 传递给 pod，如果需要更改 image 的配置则势必要重新部署 pod 以使 image 改动生效。此种场景下对业务势必有影响，而使用 configmap 则不需要。

创建 configmap 和 pod 如下：

[root@chunqiu configmap (Master)]# cat configmap.yaml
kind: ConfigMap
apiVersion: v1
metadata:
  name: initparse
data:
  parse: |
    import json

[root@chunqiu configmap (Master)]# cat statefulSet.yaml  
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: chunqiu
spec:
  replicas: 1
  ...
  template:
    ...
    spec:
      volumes:
      - name: oam-init-volume
        configMap:
          name: initparse
      containers:
      - name: oam
        volumeMounts:$
        - name: oam-init-volume$
          mountPath: /etc/config/parse

使用 statefulSet 创建 pod。其中， configmap 以卷的形式 mount 到容器中的 /etc/config/parse 路径下：

[root@chunqiu configmap (Master)]# kubectl exec -it chunqiu-0 /bin/bash -n chunqiu
[root@chunqiu-0:/]
# cat /etc/config/parse/parse
import json

可以看到 configmap 中的内容已被 mount 到容器中。进一步地，修改 configmap 中的配置，查看改动是否动态映射到容器中：

# 修改 configmap
[root@chunqiu configmap (Master)]# kubectl edit configmaps initparse -n chunqiu
configmap/initparse edited

[root@chunqiu configmap (Master)]# kubectl describe configmaps initparse -n chunqiu
Name:         initparse
Namespace:    chunqiu

Data
====
parse:
----
import json
import log

# 查看容器内文件是否改动
[root@chunqiu configmap (Master)]# kubectl exec -it chunqiu-0 /bin/bash -n chunqiu
[root@chunqiu-0:/]
# cat /etc/config/parse/parse
import json
import log

在另一个窗口 watch pod 的更新，发现 pod 未更新。可以看到改动生效了，且容器并未重启。

这里有几点需要注意的是：

修改 configmap 到容器内的改动生效是需要几分钟的延迟的，为什么有几分钟延迟可看这里。
如果 configmap 中使用 subPath，那么容器对 configmap 的动态更新是无效的。
configmap 需要在容器创建前建好，否则容器会提示找不到 configmap。对于 mount 环境变量到容器中的 configmap，环境变量是在主进程启动前即 mount 好，所以主进程中的参数可以使用 configmap mount 的环境变量。
“多次”更改 configmap 并不会以相同频率更新容器中的文件。可以查看容器中的隐藏文件如下：

[root@chunqiu-0:/etc/config/parse]
# ls -lA
total 0
drwxr-xr-x. 2 root root 19 Sep  6 15:41 ..2021_09_06_15_41_46.939921926
lrwxrwxrwx. 1 root root 31 Sep  6 15:41 ..data -> ..2021_09_06_15_41_46.939921926
lrwxrwxrwx. 1 root root 12 Sep  6 15:40 parse -> ..data/parse

映射到容器中的文本文件实际上是一个指向 ..data/parse 的软链接，该软链接经过层层链接最终指向文本为日期+时间+字符串的文本，该文本即是 kubernetes 映射到容器中的实际文件。可以看出，kubernetes 并不是对 configmap 的多次改动频繁更新，而是只更新一次。再次更新 configmap 查看文件文件内容：

# 更新 configmap 信息
[root@chunqiu configmap (Master)]# kubectl edit configmaps initparse -n chunqiu
configmap/initparse edited
[root@chunqiu configmap (Master)]# kubectl describe configmaps initparse -n chunqiu
Name:         initparse

Data
====
parse:
----
import json
import log
import print

# 查看容器中文本文件
[root@chunqiu-0:/etc/config/parse]
# ls -lA
total 0
drwxr-xr-x. 2 root root 19 Sep  6 15:59 ..2021_09_06_15_59_07.176029107
lrwxrwxrwx. 1 root root 31 Sep  6 15:59 ..data -> ..2021_09_06_15_59_07.176029107
lrwxrwxrwx. 1 root root 12 Sep  6 15:40 parse -> ..data/parse

[root@chunqiu-0:/etc/config/parse]
# cat /etc/config/parse/parse
import json
import log
import print

可以看到，容器中的文本文件在过一段时间后更新，且最终链接到的文本文件亦被更新。

2.1 secret 和 pod

mount secret 到 pod 的方式和 configmap 类似，这里不做过多展开。值得一提的是 secret 中的数据保存在内存中，而不是硬盘：

[root@chunqiu-0:/etc/config/parse]
# mount | grep parse
/dev/sda5 on /etc/config/parse type xfs (ro,relatime,seclabel,attr2,inode64,noquota)

[root@chunqiu-0:/etc/config/parse]
# mount | grep service
tmpfs on /run/secrets/kubernetes.io/serviceaccount type tmpfs (ro,relatime,seclabel)

可以看到，前面 configmap mount 到容器的文本文件，是以 xfs 形式保存在 sda5 这块硬盘上，而 secret mount 的文本文件是以 tmpfs 的形式保存在 node 上的内存中，数据不会被外部应用读写到，安全性更高。

3. statefulSet 和 configmap

这里简要提下 statefulSet 和 configmap，configmap 可以 mount 到多个由 statefulSet 管理的 pod 上。

对于 statefulSet 来说其默认的管理 pod 策略是 OrderedReady，即对于 statefulSet 的更新，scale，创建，删除等操作严格按照顺序进行，前一个 pod 状态没有 running 无法进行后一个 pod 操作。

不过，对于不需要定义这么严格的按顺序操作的 statefulSet 该怎么做呢？
Kubernetes 提供了 .spec.podManagementPolicy 为 Parallel 的参数来修改 pod 的管理策略。对于定义为 Parallel 的管理策略，pod 的创建，删除，scale 不需要按顺序 ready，不过 pod 的更新还是和 OrderedReady 类型保持一致。

码农公寓

1. configmap 和 secret 概述

2. configmap 和 pod

2.1 secret 和 pod

3. statefulSet 和 configmap

相关文章