configmap 和 secret 概述


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

1. configmap 和 secret 概述

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

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

  1. 以 shell 形式运行,此种形式下容器的主进程即 1 号进程是 bash 进程,image 中指定的可执行被 bash 进程调用。
  2. 以 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 类型保持一致。

上一篇:【Python3爬虫】当爬虫碰到表单提交,有点意思


下一篇:NR UCI Multiplexing on PUSCH